3:18 p.m.
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.
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