There are some portal users that find a portal name limitation of minimum length of three, and starting with a letter (IdentifierValidator) too restraining. For example there is issue JBEPP-885. Some internal debate on the topic exposed some deeper issues here ... There are special contexts like 'g' (http://localhost:8080/portal/g/), and 'u'. Allowing portal names one char long could produce name collisions with these. On the other hand there are some other 'special' contexts like those mapped via web.xml: 'javascript', 'error', 'initiatelogin', 'errorlogin', 'login', 'dologin', 'rest', 'connector', 'gateinservlet', 'private', 'admin'. And I hear there are some others: 'download', 'upload', 'public'. Not sure if these are supposed to occur at portal site level, or page level. The point is that while there's some validation in place when adding new portal through admin UI, it seems a bit arbitrary - like why should a portal name not start with a digit, and what collition can happen at length == two? And we already have a name collision problem with names longer than two as mentioned above. To try if things would explode I loosened up the criteria, and created a portal called 1A, and things seem to keep working fine. It seems like loosening criteria to length >= 2, and 'can start with a digit' could easily be done, and give a little more freedom to users. But we should also think about improving things as they already are by maybe adding checks for site name against a list of reserved words for example. We could probably compile the web.xml url mappings programmatically, but that would not be an exhaustive list. Maybe we could manually collect all these special contexts into an exhaustive list, make it available through some service. That would still not prevent possible post-festum collisions if we introduce new 'special' context mappings in the future - they might all collide retroactively. Some other sources of collision that came up include: - language mapping URLs - i.e. http://localhost:8080/portal/fr/... but I don't know if that kind of urls are actually used anywhere - navigation controller - does it only work relative to portal site or can it override mapping for portal site name as well? - new additions via navigation.xml could clash with existing MOP nodes - how to react in that case? Navigation controller automatically overrides MOP with some warning? Similarly, we could loosen up page naming - there, navigation controller would definately be part of an equation. We could dynamically compile 'taken' names from NavigationController ... Another question is then how to deal with name collision when we detect them? We could detect them at GateIn startup time, or when adding a site or page through Site administration UI. We can disallow creation of conflicting name. That makes sense for portal names that conflict with mapped web.xml contexts. We could also just warn a user that name is in conflict, and the portal / page won't be reachable, but allow creation itself. I imagine there are some other considerations that I can't see ATM. Maybe someone can shed additional light on this, or add an opinion ... - marko _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

The short question is: Can we losen up the restriction for portal and page names to be >=2 alphanumeric characters rather than >=3 alaphanumeric characters while first character is a letter. Say I want to create a site for 3M, i can't call it "3M" because of UI restrictions at the moment. Marko's questions is the result of that investigation. Thomas. On 01/25/2012 10:18 PM, Julien Viet wrote: > Hi Marko, > > it's hard to answer your emails because it has too many concerns in it. We should find another way to discuss it. > > That being said I want to shed some light on the navigation controller: > > we need to use it more and more as main entry point of the portal as it is better and more flexible than web.xml because > > 1/ it does not enforce the portal deployment to use the URL mapping we provide by default (i.e in your example you are saying "/portal/g" but in controller.xml you can change it to something else) > 2/ it make configuration central > > We have a current prototype at the moment of converting the javascript serving to the navigation controller. Step by step we will convert other parts to use it. > > > > > On Jan 25, 2012, at 10:03 PM, Marko Strukelj wrote: > >> There are some portal users that find a portal name limitation of minimum length of three, and starting with a letter (IdentifierValidator) too restraining. >> >> For example there is issue JBEPP-885 <https://issues.jboss.org/browse/JBEPP-885>;. >> >> Some internal debate on the topic exposed some deeper issues here ... >> >> There are special contexts like 'g' (http://localhost:8080/portal/g/), and 'u'. Allowing portal names one char long could produce name collisions with these. >> >> On the other hand there are some other 'special' contexts like those mapped via web.xml: 'javascript', 'error', 'initiatelogin', 'errorlogin', 'login', 'dologin', 'rest', 'connector', 'gateinservlet', 'private', 'admin'. >> >> And I hear there are some others: 'download', 'upload', 'public'. Not sure if these are supposed to occur at portal site level, or page level. >> >> The point is that while there's some validation in place when adding new portal through admin UI, it seems a bit arbitrary - like why should a portal name not start with a digit, and what collition can happen at length == two? And we already have a name collision problem with names longer than two as mentioned above. >> >> To try if things would explode I loosened up the criteria, and created a portal called 1A, and things seem to keep working fine. >> >> It seems like loosening criteria to length >= 2, and 'can start with a digit' could easily be done, and give a little more freedom to users. >> >> But we should also think about improving things as they already are by maybe adding checks for site name against a list of reserved words for example. >> >> We could probably compile the web.xml url mappings programmatically, but that would not be an exhaustive list. Maybe we could manually collect all these special contexts into an exhaustive list, make it available through some service. That would still not prevent possible post-festum collisions if we introduce new 'special' context mappings in the future - they might all collide retroactively. >> >> Some other sources of collision that came up include: >> - language mapping URLs - i.e. http://localhost:8080/portal/fr/. <http://localhost:8080/portal/fr/>.. but I don't know if that kind of urls are actually used anywhere >> - navigation controller - does it only work relative to portal site or can it override mapping for portal site name as well? >> - new additions via navigation.xml could clash with existing MOP nodes - how to react in that case? Navigation controller automatically overrides MOP with some warning? >> >> >> Similarly, we could loosen up page naming - there, navigation controller would definately be part of an equation. We could dynamically compile 'taken' names from NavigationController ... >> >> Another question is then how to deal with name collision when we detect them? We could detect them at GateIn startup time, or when adding a site or page through Site administration UI. We can disallow creation of conflicting name. That makes sense for portal names that conflict with mapped web.xml contexts. We could also just warn a user that name is in conflict, and the portal / page won't be reachable, but allow creation itself. >> >> I imagine there are some other considerations that I can't see ATM. >> >> Maybe someone can shed additional light on this, or add an opinion ... >> >> >> - marko >> >> >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/gatein-dev > > > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev

I don't see any good reason to not allow it, but we should wait for Trong's advice when he comes back from the Tet next week. It seems to be more a legacy reason. On Jan 26, 2012, at 9:52 AM, Thomas Heute wrote: > > The short question is: Can we losen up the restriction for portal and page names to be >=2 alphanumeric characters rather than >=3 alaphanumeric characters while first character is a letter. > > Say I want to create a site for 3M, i can't call it "3M" because of UI restrictions at the moment. > > Marko's questions is the result of that investigation. > > Thomas. > > > > On 01/25/2012 10:18 PM, Julien Viet wrote: >> Hi Marko, >> >> it's hard to answer your emails because it has too many concerns in it. We should find another way to discuss it. >> >> That being said I want to shed some light on the navigation controller: >> >> we need to use it more and more as main entry point of the portal as it is better and more flexible than web.xml because >> >> 1/ it does not enforce the portal deployment to use the URL mapping we provide by default (i.e in your example you are saying "/portal/g" but in controller.xml you can change it to something else) >> 2/ it make configuration central >> >> We have a current prototype at the moment of converting the javascript serving to the navigation controller. Step by step we will convert other parts to use it. >> >> >> >> >> On Jan 25, 2012, at 10:03 PM, Marko Strukelj wrote: >> >>> There are some portal users that find a portal name limitation of minimum length of three, and starting with a letter (IdentifierValidator) too restraining. >>> >>> For example there is issue JBEPP-885 < https://issues.jboss.org/browse/JBEPP-885>;. >>> >>> Some internal debate on the topic exposed some deeper issues here ... >>> >>> There are special contexts like 'g' (http://localhost:8080/portal/g/), and 'u'. Allowing portal names one char long could produce name collisions with these. >>> >>> On the other hand there are some other 'special' contexts like those mapped via web.xml: 'javascript', 'error', 'initiatelogin', 'errorlogin', 'login', 'dologin', 'rest', 'connector', 'gateinservlet', 'private', 'admin'. >>> >>> And I hear there are some others: 'download', 'upload', 'public'. Not sure if these are supposed to occur at portal site level, or page level. >>> >>> The point is that while there's some validation in place when adding new portal through admin UI, it seems a bit arbitrary - like why should a portal name not start with a digit, and what collition can happen at length == two? And we already have a name collision problem with names longer than two as mentioned above. >>> >>> To try if things would explode I loosened up the criteria, and created a portal called 1A, and things seem to keep working fine. >>> >>> It seems like loosening criteria to length >= 2, and 'can start with a digit' could easily be done, and give a little more freedom to users. >>> >>> But we should also think about improving things as they already are by maybe adding checks for site name against a list of reserved words for example. >>> >>> We could probably compile the web.xml url mappings programmatically, but that would not be an exhaustive list. Maybe we could manually collect all these special contexts into an exhaustive list, make it available through some service. That would still not prevent possible post-festum collisions if we introduce new 'special' context mappings in the future - they might all collide retroactively. >>> >>> Some other sources of collision that came up include: >>> - language mapping URLs - i.e. http://localhost:8080/portal/fr/. < http://localhost:8080/portal/fr/>.. but I don't know if that kind of urls are actually used anywhere >>> - navigation controller - does it only work relative to portal site or can it override mapping for portal site name as well? >>> - new additions via navigation.xml could clash with existing MOP nodes - how to react in that case? Navigation controller automatically overrides MOP with some warning? >>> >>> >>> Similarly, we could loosen up page naming - there, navigation controller would definately be part of an equation. We could dynamically compile 'taken' names from NavigationController ... >>> >>> Another question is then how to deal with name collision when we detect them? We could detect them at GateIn startup time, or when adding a site or page through Site administration UI. We can disallow creation of conflicting name. That makes sense for portal names that conflict with mapped web.xml contexts. We could also just warn a user that name is in conflict, and the portal / page won't be reachable, but allow creation itself. >>> >>> I imagine there are some other considerations that I can't see ATM. >>> >>> Maybe someone can shed additional light on this, or add an opinion ... >>> >>> >>> - marko >>> >>> >>> _______________________________________________ >>> gatein-dev mailing list >>> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/gatein-dev >> >> >> >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev