What happened to PrettyFaces?

Splash Forums PrettyFaces Users What happened to PrettyFaces?

This topic contains 19 replies, has 4 voices, and was last updated by  Lincoln Baxter III 7 years, 5 months ago.

Viewing 5 posts - 16 through 20 (of 20 total)
  • Author
  • #24327

    Hey there,

    sorry for my delayed response. I was on vacation.

    OK, let me explain a few things. IMHO there are two cases for classes that carry mapping (or join) annotation(s):

    1. If mapping/join uses path parameters and page actions, I really thing that there should be only one annotation on the class. In my projects I typically have one special class for each “page” that carries the @Join annotation and which holds the parameter bindings and a page action for initialization. IMHO this pattern makes sense. I see no reason why you should want to declare two “complex” mappings on a single class. This makes it very difficult to distinguish which parameter or page action belongs to which mapping. If there is common functionality shared between the pages, this should go into a super class.
    2. If the you have many simple mappings, which don’t have any parameter or page actions, the situation is different. In theory it would be possible to have something like @Joins here and place it on a dummy class without any functionality. But IMHO it would be simpler do do something like this:

    Say you have a mapping like this:

    @URLMapping(id = "dashboard", pattern = "/dashboard", viewId = "/pages/dashboard.xhtml")

    With Rewrite you could use a configuration provider to define the mapping like this:

    .addRule( Join.path("/dashboard").to("/pages/dashboard.xhtml") )

    Your StaticPages class is a perfect example for this. Instead of annotating a dummy class with lots of annotations, you simply put the configuration into a configuration provider.

    If your join contains something like parameters, you bind the values to a foreign bean like this:

    .addRule( Join.path("/shop/{category}").to("/pages/category.xhtml") )

    As you see you can simply define the configuration in the configuration provider. There is no need to have @EJB or other stuff in the provider. All this can remain in your JSF bean. You simply move the metadata you placed on the class or in pretty-config.xml into a separate class.

    I’m not sure about your OrderBean class. In my opinion it is weird that the class handles different pages. However, with a configuration provider, you can simplify your configuration because you need less rules. /order/123/details/ and /order/123/history/ could be defined as:

    .addRule( Join.path("/order/{id}/{type}").to("/faces/pages/priv/order-{type}.xhtml") )

    Nice, isn’t it. Much easier and less rules. If all of the URLs can be described with such an abstract mapping, you can even use the @Join annotation:

    @Join(path="/order/{id}/{type}", to="/faces/pages/priv/order-{type}.xhtml")
    public class OrderBean {
      private Long id;

    BTW: You can have as many ConfigurationProviders as you like. So you could have only one for your application, or one for each group of pages or whatever you like. 🙂

    The problem with creating something like @Joins in Rewrite is, that it won’t be possible to handle parameters and page actions consistently with the new annotation API we created for Rewrite. It would be very very difficult to do something like that and as I said earlier, there are not many cases where it makes sense to have many joins on one class. But as I said, that’s just my opinion.

    But Rewrite also allows users to implement their own annotations. Perhaps this is an option for you? If you don’t use page actions and have only one path parameter, you could perhaps create your own annotation that builds the rules like you want them. Implementing a custom annotation is really simple.

    Take a look at the Join example. At first you create an annotation that carries the meta data you need:


    Then create a handler that processes this new annotation. The handler for joins is really simple:


    You could for example take this handler and just add some iteration logic to create multiple rules.

    Creating custom annotations is something we encourage users to create for special cases. I for example always have at least one custom rule which allows be to use an annotation on a class which specifies specific security constraints. Something like “User must have ADMIN role”.

    I hope this helps a bit. Feel free to ask any questions you have. 🙂




    Hi Christian!
    This time I was on vacation)) I got your point, don’t quite understand how it won’t be possible to handle parameters and page actions consistently but I trust you on this matter)) Nevertheless I still think that one-to-one page-class relationship is a major design flaw, which IMHO contradicts MVC as least, and it’s a pity that Rewrite annotations were initially created relying on such questionable mapping approach, but it’s great that it’s possible to create personal annotation handlers, you should have mentioned it earlier)) Maybe there should be its own set of annotations for JSF extension of Rewrite, not sure, have to play with Rewrite a bit more.



    Hey Oswald.

    There actually are annotations specifically for JSF 🙂 That’s what the rewrite-config-prettyfaces module is for! Just add this:


    Then use the standard prettyfaces documentation here: http://ocpsoft.org/docs/prettyfaces/snapshot/en-US/html_single/#config.annotations

    All the original prettyfaces annotations should work as expected 🙂



    This is the new PrettyFaces 🙂 Built on rewrite.


    It’s backwards compatible as well.

Viewing 5 posts - 16 through 20 (of 20 total)

You must be logged in to reply to this topic.

Comments are closed.