FTR I’ve discussed with Stephane verbally and Stephane will send a new mail with 3-4 questions we’ve identified.
Thanks -Vincent > On 22 Aug 2019, at 14:26, Vincent Massol <vinc...@massol.net> wrote: > > Hi Stephane, > >> On 22 Aug 2019, at 09:39, Stéphane Laurière <slauri...@xwiki.com> wrote: >> >> Hi Vincent, Hi all, >> >>> Hi Stephane and all, >>>> On 7 Aug 2019, at 14:22, Stéphane Laurière <slauri...@xwiki.com> wrote: >>>> >>>> Hi everyone, >>>> >>>> I'm following up on a thread started in 2015 about the best practices >>>> regarding app pages organization: >>>> >>>> - https://xwiki.markmail.org/message/657vcm6ylkz4yytc >>>> - >>>> https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPractices >>>> >>>> In this thread, the idea of introducing a dedicated common root area for >>>> all application technical pages was suggested by Denis: >>>> >>>> https://xwiki.markmail.org/message/kk5l3dwjmpfelkzp >>>> >>>> I'm wondering why this idea was not pushed further (it's not strictly >>>> incompatible with the current best practices, but most of the recent >>>> applications have their top level area, except a few like Notifications or >>>> ChartJS). >>> Indeed, right now, the best practice is a top level space named after the >>> app >>> (https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPractices). >>> I guess the reason we didn’t do anything else is because we lacked an >>> agreed proposal simply. >>>> Comparing with how other platforms do is inspirational (Microsoft Windows >>>> "Program Files" was mentioned in the thread). On Debian, the Maven package >>>> is installed in /usr/share/maven/ while files used and produced by Maven >>>> can be located anywhere. Along the same line, I would see as a userand >>>> developer experience improvement if we had the following structure: >>>> >>>> 1) Code: >>>> >>>> XWiki >>>> |- MyApp >>>> |- MyAppClass >>>> |- MyAppSheet >>>> |- … >>> I don’t think it’s a good idea to put the apps directlyunder the XWiki >>> space. I feel it would be better to have an “Applications” subspace as in: >>> XWiki >>> |_ Applications >>> |_ MyApp >>> |_ … >>> |_ Users >>> |_ … >>> This allows to put other things in the XWiki space, such as users for >>> example. >>> Note that for me the main reason to avoid putting spaces at the root isto >>> avoid using up namespaces that can then no longer be used by users. In this >>> spirit the minimum we could do is reserve only the “XWiki” space. >>>> 2) Data: the pages created by MyApp could then typically be located >>>> bydefault in a MyApp space at the root of the wiki, the user could >>>> howeverchoose which default space to use, or leave it empty (then the >>>> space from where the user fires the create action could be used, for >>>> instance, or any scriptable rule). >>> Why not. I’m just not sure I would mix app data pages with purecontent >>> pages and use up namespaces at the root (you end up with the same issue as >>> I mentioned above and you below). I agree that data pages shouldn’t go in >>> the /XWiki/Applications space though which should be readonly. >>> So there are some other options: >>> * In /XWiki/Data/MyApp >>> * Reserve another namespace entry at the root (“Data”):/Data/MyApp >>> You said " the user could however choose which default space to use”. How >>> would you plan to implement this? Right now, this would work only if the >>> app provides a template and the user uses this template to create a new >>> page. For example the FAQ app doesn’t do that and it provides a UI to >>> create a new FAQ entry and this goes in /FAQ/ directly. >> >> The default implementation I would propose would consist in creating data in >> the space from which the creation request occurs. Do you foresee some issues >> with that behaviour? > > Yes, having data scattered eveyrwhere in the wiki instead of in a single > place. > > And have data saved in places you don’t want because you’re not paying > attention to the location you’re at. > > This then makes it very hard to remove all data, move it to somewhere else, > put permissions on them, etc. Any bulk action becomes hard and requires > scripting. > >> If needed, we could add a field in the TemplateProvider class that would >> accept a script letting developers or users implement any rule for >> determining which space should be used. By "this would work only if the app >> provides a template", do you mean a TemplateProvider? Would this be then >> that TemplateProviders are not considered as a best practice already? > > As you said it’s a best practice only not something mandatory. For example > the FAQ app doesn’t provide a template provider right now and even if it did, > it still has a UI to create new entries. So that would also need to be > removed. Is that good or bad, I don’t know for sure. It has both pros and > cons. > >> >>>> Another issue I see with the current practice (raised by Clément A. >>>> orally) is that some application names may conflict with names the user >>>> would like to use for content that is not strictly related to the app. Not >>>> necessarily a big deal with one thousand of applications, but might become >>>> one with more, wouldn't it? >>> Sure and you get the same issue with your proposal of putting app data at >>> the root under /MyApp, no? >> >> It's different imho because my proposal is that, outside the "XWiki" space, >> only users would create new spaces, never the applications directly without >> first asking the user for a space name explicitely. >> >> I'm wondering if it's a good idea to reserve a space for data and to have >> one data subspace per app: first, along the operating system analogy, it's >> not very common to store files per their application origin basis, is it, or >> is the analogy irrelevant? > > On Windows at least this concept exists as you have 2 locations: > * Location for app code > * Location for app data > > And then users created directories and folders for their own data. > > It’s the same for all OSes AFAIK. On unix, you get /var/… for app data. > >> Second, the line between what we call "data" and "content" is getting more >> and more blurry (the Jupyter notebooks, just like XWiki are good examples of >> this), so the user may end up with page hierarchies that are difficult to >> understand. > > I don’t know what Jupyter notebooks are but what I know is that mixing apps > with content is hard for users and thus it would make sense to me to have a > location for app data that is separate by default from pure content created > by users. This has been asked countless times and we’re doing hacks to try to > spearate them (for ex, see the Applications Panel and the Navigation Panels). > >> >> Regarding the "XWiki" space, we probably agree that it is meant to be a >> "system" space, do we? > > Yes. > >> If that's the case, I'm wondering if storing the users and groups in that >> space is the best option, because they are actually writable data. > > Sure. We could consider users as app data for the User App. And thus put them > in the User app data location for example. > >> It's a bit specific since they are transversal, and their classes come with >> the platform, but it remains writable data. Their code could be located in >> the XWiki space, but the instances could be elsewhere, in a configurable >> location. Also, prefixing each user and group page with "XWiki" may not >> please all developers imho > > This is a different topic. The goal here is to have a user/group API > independent of the implementation and storing users and groups in the wiki > would be just one implementation. This means slome mapping between user/group > id and storage location. > >> : imagine you develop a Facebook like, should the user wall URLs contain >> "XWiki"? It's always possible to add URL rewriting rules, but that's more >> complex. The underlying reason could be brand marketing though, which is >> important. >> >> Following up on the operating system analogy, we could also consider log >> files (and possibly other aspects?). Even though most of the XWiki logs are >> currently stored on the file system, that could be interesting at some point >> to store some of them directly in the wiki for easing their archiving and >> consultation, couldn't it? In that case, we could also reserve a dedicated >> root space for them. Having very few top level reserved spaces such as >> "Logs", "Users", "Groups" (provided their name is configurable, also for >> localization reasons) might be acceptable, what do you think? > > I think I would prefer just 2 top level: “XWiki” and “App Data”. Regarding > logs they could be considered as app data from a System app for example. > > Interesting discussion, more feedback needed too :) > > Thanks > -Vincent > >> >>>> I understand that the layout proposed above would raise technical issues >>>> (XWiki space permissions for instance, mentionned in the 2015 thread, and >>>> others), however what's your view on it from a design perspective? (sorry >>>> if I overlooked strong arguments already expressed against it) >>> Thanks for starting this thread again. >>> One other point missing in this discussion is the migration from the >>> current status to any target. How would we achieve it? How do we migrate >>> anapp to follow any new best practice without breaking users? (Idea: >>> https://design.xwiki.org/xwiki/bin/view/Proposal/DocumentAliases). >> >> This looks powerful, I'm looking into it. >> >> Cheers >> >> Stéphane >> >> >>> Let’s start the discussion ;) >>> Thanks >>> -Vincent >>>> >>>> Cheers >>>> >>>> Stéphane >>>> >> >> >> -- >> Stéphane Laurière >> XWiki – https://xwiki.com