Reply To: What happened to PrettyFaces?

Splash Forums PrettyFaces Users What happened to PrettyFaces? Reply To: What happened to PrettyFaces?


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. 🙂