ParentId support in @ViewConfig

Splash Forums PrettyFaces Users ParentId support in @ViewConfig

This topic contains 7 replies, has 4 voices, and was last updated by  azakovorotny 10 years, 6 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #17985


    Hi Lincoln,

    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?

    Best regards,




    Hi Andy,

    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.


    What brian said :)



    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.




    Hey Andy,

    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.xml or 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?



    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 wrong :)




    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.



Viewing 8 posts - 1 through 8 (of 8 total)

The forum ‘PrettyFaces Users’ is closed to new topics and replies.

Comments are closed.