[seam-issues] [JBoss JIRA] Created: (JBSEAM-4795) Pages xml should support smaller scoped wildcards
Pages xml should support smaller scoped wildcards
-------------------------------------------------
Key: JBSEAM-4795
URL: https://issues.jboss.org/browse/JBSEAM-4795
Project: Seam
Issue Type: Feature Request
Components: Framework
Affects Versions: 2.2.0.GA
Environment: Jboss AS 4.2. Seam 2.2.0, Richfaces
Reporter: Martin Frey
Currently the pages.xml ignores multiple wildcard page declarations. This makes is very
hard and/or noisy if you have an application which needs login on most of the top level
pages.
My configuration looks similar to this:
* login required true
/login.xhtml login required false
To speed up page loading we have decided to load the richfaces JS files upfront with :
org.richfaces.LoadScriptStrategy ALL
Because of these declarations in the pages.xml the first time a user comes to the
application he is not logged in and is correctly redirected to the login page.
Unfortunatly the pages.xml needs login also for each sub pages like /a4j/... and because
of this we are returning a BLANK JS file. Since it is cached it will not be reloaded until
the user specificly requests it. The same happens with CSS files for example.
Unfortunatly it is not not easily possible to declare something like this:
* login required true
/a4j/* login required false (here i would need to declare each resource viewIds)
/login.xhtml login required false
Because the Pages class is simply ignoring other wildcards if the top level wildcard is
found. I've created a subclass of the Pages component for the simple purpose of
telling it to ignore login flags for /a4j/* and *org/richfaces* requests.
I would recommend to allow the declaration of smaller scoped wildcards in the pages.xml to
simplify the configuration of these flags. I'm not sure yet if it would be even good
if one can define if the smaller scope or the bigger one has the priority.
If this idea has some votes i'm very happy to help implementing it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira