ParentId support in @ViewConfig
July 12, 2011 at 10:40 pm #17985
Are there any plans to support more PrettyFaces features (parentId in particular) in Seam Faces? As I understand PrettyFaces is a URL rewrite plugin of choice in Seam’s @ViewConfig.
Are there any examples of non-trivial usage of URL rewrite with Seam 3?
Andy.July 13, 2011 at 5:31 am #21127
The @ViewConfig integration is currently limited by my understanding of what one can do with PrettyFaces. If you can suggest some features that should be implemented, with good use cases so I understand what’s going on, I’d be more than happy to flesh out the integration.
Discussion of what things should look like can happen here or on the Seam 3 forums, but ultimately the feature request will need a jira filed against it.July 13, 2011 at 5:32 am #21128July 13, 2011 at 5:33 am #21129
What brian saidJuly 13, 2011 at 1:07 pm #21130
I find PrettyFaces very useful when solving non-standard cases. For instance, in a virtual web application I would like a sort of sticky prefix in pages’ URL that would be set upon authentication and further used to distinguish /app1/home from /app2/home. It works for me in JSF w/o Seam Faces example, however I cannot make it working with Seam Faces: not only there is a limited support of URL rewrite in ViewConfig, the normal pretty-config.xml seems completely ignored.
Another problem (rather a Seam 3 problem): Seam 2 provides an arsenal of simple means to restrict access to a page (via pages.xml or annotations). Imagine a financial application with tons of pages and actions where access to a page or action is based on ACL. Do I have to create @ViewConfig interface with hundreds of enum entries or just one entry that is matched against a “universal” permission check method? It is not clear to me and there is nothing in the docs about ACL support by Seam security.
Overall, PrettyFaces is of great help for a developer in solving those daunting problems and the more of its features is available in Seam 3 the better.
Thanks Lincoln and Brian for your replies.
Andy.July 13, 2011 at 2:02 pm #21131
just a short note regarding the Seam 3 + PrettyFaces integration. The integration layer is based on a PrettyFaces SPI that allows to feed additional configuration (i.e. URL mappings) into the PrettyFaces core. So the Seam 3 integration is just an additional source for URL mappings. This means that every other way of configuring PrettyFaces (like
pretty-config.xmlor the PrettyFaces annotations) should also work fine. I’m a bit surprised that this doesn’t work in your case. Can you reliably reproduce this?
ChristianJuly 13, 2011 at 2:12 pm #21132
Hmm, I think he means that he can’t do this within the SeamFaces configuration.
However, @azakovorotny, in terms of restricting views in SeamFaces – you can also use non-mapping patterns for the @ViewPattern(“/admin/*”), that will trigger on any view in the admin folder, etc. Notice that this is the resource name, not the rewritten URL.
I believe that’s the case, brian can correct me if I’m wrongJuly 13, 2011 at 2:30 pm #21133
I added pretty-config.xml into Seam Faces 3.1.0-SNAPSHOT “viewconfig” example and non of my simple mappings were working. I will review it again – haven’t dived into details yet (have a time constraints on evaluating CDI/Seam for our project).
@ViewPattern(“/admin/*”) won’t fit nicely in my use case – it is good for role-based security model. In my case the page grouping does not necessarily correspond to the functions grouping (design spec), so I need to support ACL-centric security.
Thank you all, guys.
You must be logged in to reply to this topic.