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

Reply via email to