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?
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?
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? 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.
Regarding the "XWiki" space, we probably agree that it is meant to be a "system" space, do we? 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. 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: 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 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
