Coming back on this topic, the discussion continued a bit on the JIRA issue (https://jira.xwiki.org/browse/XWIKI-16861)
I’m +1 with the general idea, now I have questions regarding the details. The main one being: do we want it to be prevented on backend side or only on frontend side?
@tmortagne already said on JIRA that it should be done only on frontend, WDYT?
Regarding what kind of options we should provide for this feature, @vmassol developed a bit too on JIRA, saying:
I would go further than this. We need to offer extension points so that admins can provide different cleaning strategy for page names (we’ve had the need expressed several times) - https://forum.xwiki.org/t/prevent-creation-of-pages-with-and-in-the-name/5852/3 . We would offer just one basic implementation based on removing forbidden characters (configurable in the Admin UI and/or xwiki configuration files). What’s important is that it can be replaced by customizations. Actually it’s not just an OR but can also be an AND. IMO the best is to list in the Admin UI all existing filters applied for page names with the ability to enable/disable them.
Example of strategies other than stripping forbidden characters:
- Replace all spaces by dashes ("-").
- Shorten page name to a max size
- Transform into CamelCase syntax
WDYT?
Quite frankly I’m not quite sure how to allow such extension point at frontend level with the current architecture, especially since it appears we don’t necessarily use the same standard way to put names everywhere (e.g. AWM names or user names).
Now I guess we could change the architecture to rely more on the server for all names: basically to have a component to submit name to and to receive a filtered name as answer. It wouldn’t be difficult to do, and it would allow easily different strategies, but I’m a bit afraid about the performance penalty it would cause.