Application pages layout best practices

Hi everyone, Hi Vincent,

Following up on this follow-up:

I tried to summarize the current discussion status and the identified questions and use cases on a design page named Page Hierarchy Layout for now.

I’m also reacting below to some comments by @vmassol:

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.

It’s a risk indeed, but couldn’t it be addressed by the user interface? Let’s do an analogy how people organize data on a personal computer produced by applications such as a presentation software, an image editor, a photo album maker etc. They typically use the folders they wish, not folders bound to the applications, do they? However, 1) some operating systems come with “Pictures”, “Videos” folders, not sure how much it is used in practice. 2) Some applications behave differently, for instance a local mail reader will store all mail in a dedicated folder, but imho that’s more a downside because users end up replicating the same hierarchy across all these applications, i.e. the hierarchy they have in their head, which could be shared across all applications instead.

And have data saved in places you don’t want because you’re not paying attention to the location you’re at.

Indeed. That remains to be evaluated further I would say. Couldn’t further user design improvements mitigate this risk? (not easy, we agree)

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.

I agree as well. Generic bulk scripts could address this though, however they remain to be coded, and they could take longer when getting executed on scattered data.

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 rightnow and even if it did, it still has a UI to create new entries. So thatwould also need to be removed. Is that good or bad, I don’t knowfor sure. It has both pros and cons.

Specialized user interfaces may make sense as well, but it could be interesting to progressively evolve them to use the underlying TemplateProvider mechanism, and be as close as possible (or replaced by) the default XWiki create screen, while evolving this screen to become as simple as possible while keeping the ability to have many extensible options for advanced use cases.

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 directlywithout 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.

I had overlooked the need for internal application data. The design page that I mentioned at the top now introduces a var space that is meant to store such data (logs, cache, etc.).

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 thatmixing 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).

I was not aware of that, that could be interesting to know more about their motivations and the hinders they face with an approach that is more oriented toward a more data-agnostic hierarchy.

Jupyter can be seen as an editor for complex documents mixing code and content just like XWiki content editing framework, see this live example for instance:

A newly released open source software in the field of editors mixing code and content is Polynote by Netflix.

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.

Sure. We could consider users as app data for the User App. And thus put them in the User app data location for example.

We agree on this.

It’s a bit specific since they are transversal, and their classes comewith 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.


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 reservea 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.

OK. My preference goes for layout referenced as L4 in the design page…

Does the design page reflect the pros, cons and use cases we mentioned? Do the approaches proposed for solving possible issues raised seem realistic to you? What do you think?


Thank you for the your work @slauriere and for the nice summary of the various options at

We now need more opinions from others too.

Note that we just got the news mentions which failed to follow our guidelines at and what put fully under the XWiki space (in XWiki.Mentions). I also realized today that the same happened not long ago with the Notifications app wihich is in XWiki.Notifications (which is probably why the Mentions app did it…).

Note that there’s a way to salvage the current layout: to force users to put their content into a Content top level space. so basically consider that top level spaces are only app spaces and consider that content is an app.

There’s just one issue with this: how do we ensure that the URLs for content do not have Content in all of them (to not be too long)? One idea is to use a content URL type (rather than bin for content pages). I haven’t thought it through though.

I have the feeling that the best practices listed on are for applications that have public data (i.e. that create pages that the user should be able to navigate to, link to or include), like the ones generated with AppWithinMinutes. The term “XWiki application” is very broad and you can have an “app” that only has a SSX, or a JSX, or a color theme, i.e. an “app” that enhances the XWiki UI in some way. I’m pretty sure we discussed the distinction between “data” apps and “UI extension” apps somewhere. I don’t see the point in polluting the top level space for an app that only adds a link in some menu for instance. I find the XWiki space more suited for this. I’d rather leave the top level space for the user and for apps that create pages that the user navigates to (e.g. Blog, Forum, Meetings, etc.).

If you want a rule I’d say: if the app has no data or only internal data (i.e. data for which the storage can change at any time, like moving to a dedicated database table, or a Solr core or the file system) then use a nested space inside the XWiki space. Otherwise, if the app has public data, i.e. it creates pages that the user wants to navigate to, link to or include in other pages, then use a top level space.

ok so this is a new proposal. Could you edit and add your proposal there using the same format? I’m asking because we need all proposals to be listed there (and I find it helps to see an example as defined there). Then we can list pros and cons (one cons for this one for example is having 2 places for app code).

Thanks Marius for your feedback!

PS: I didn’t say it but I also don’t like too much that we use the top level namespace as we do now so I’m all for changing that (and I also include data apps which IMO should also not take namespaces for various reasons, one being that I think it’s good to separate apps from content).

So the way I see it:

  • We need to list all proposals on
  • Once we have them all, we do a vote
  • Once the vote is passed we document the new best practice for new apps
  • Then we brainstorm to see what we can do to migrate our current apps to the new layout. Depending on the results, we decide a strategy to move apps or decide it can’t be done (and thus the new layout is just used for new apps).


FTR, I added my proposal, L5.


1 Like