Decide that all recommended apps must follow the best practices that apps which need to create app entries (data apps) with names provided by the user should not provide a custom UI but instead rely on the standard page creation UI. In practice this means offering a Template for the app.
Pros:
More usability by provided a consistent experience (and ensuring that all such apps have a template)
Solves the naming strategy validation
Also solves other consistency issue (basically all features available in the standard create UI become available to the apps - relates to Application pages layout best practices too).
Give more UI space to the app on its home page (since there’s no create UI)
Cons:
No custom UI which in some cases could feel as better for usability (but at the detriment of consistency), so not sure they’re better in the end regarding usability.
(slightly offtopic)
Small note that we could extend this strategy to AWM too (see also Loading...) and have a template for it to. This would be very consistent to me: whenever you wish to create something you click on the Create button. In this case it would be Create > Application.
Now it’s not easy and would mean several things:
Extend the scope of the Create UI so that it’s not only about Creating pages. This could mean moving the Create button elsewhere in a more global location (could be good since some users have problems understanding the Create button inside the page).
Improve the templating capability so that templates can be multi-steps (right now they’re basic and are single step or even 0-step).
Yes having a more generic create button/menu would be a good idea and it would help a lot discoverability (create page, create application, create macro, etc.)
However, for the 2 applications in question (and others as well), we may realize that it’s much harder to migrate to a template based creation. The refactoring that may occur from this need (which may turn out big) and the high QA level needed should not block the fixing of the page names for the custom create form. See my comment on Loading... .
I’m interested to migrate to template based creation in order to also verify that the create form and templates system can satisfy the functional needs of these applications (for example, I recently had a discussion about some limitations of the template system with @Oana-Lavinia_Florean , we realized that the default template system may be missing one usecase). This could help improve the usecases of the template system overall.
Also, it’s important to stress that completely custom creation forms or creation scripts is an important feature of XWiki and going towards using template based creation should not result in limited support for this custom creation. For example, if the page naming strategies API does not provide a script service, it should, regardless of the fact that these standard applications won’t actually need it.
Actually, this may be a too strong agreement.
I agree to follow this principle for all applications and content creation for which the underlying structuring of content in wiki pages makes sense and it can be reasonably exposed to the user.
For example, for the File Manager, it makes little sense to require that a user creates a folder as a wiki page from a folder template. The application creating pages behind the scenes while presenting to the user a higher level abstraction is perfectly valid for the FileManager and it should stay that way. This also applies to some of the content created through the forum, if I remember correctly.
However, for the 2 apps that you mentioned (FAQ, Blog), exposing the creation on the same path as the creation of a page is reasonable enough.
Sure. Maybe the issue is in the definition of “apps which need to create app entries (data apps) with names provided by the user”. The FileManager is not a traditional “data app”.
Could you explain what use case you have in mind? I don’t know the forum app well but it seems to me you can create a new forum, “Add forum”. Makes sense to go through a template for this. It also makes sense for “Add topic”. Where it doesn’t make sense is for “Add message” (which is similar to adding a comment) but that fits the definition since for adding a message the user doesn’t provide a name for the new message.
I didn’t remember exactly the structure of data of the forum, but I remembered that it stored some content in pages without necessarily telling the user that it’s a page, because it didn’t have the choice. I don’t have any specific usecase in mind, just this souvenir that it also presents very specific creation UI.
I haven’t tested the forum recently, but if indeed the semantic of the data is only drawn around the 3 entities you mentioned: forum, topic, message and at no point we’re using pages to store messages, then I agree fully that forum and topic can be created through the create form.