Can Pretty Faces/Rewrite help me?
June 11, 2012 at 8:17 am #18432
We have recently migrated a JSF Tiles 1.1 applicaiton to a JSF Facelets 2.0 applicaton. One of the side effects of moving from tiles is that we now have one Facelet View Definition for each tile we previously had. (We have the “meat and bones” of the view in a shared file in WEB-INF/xhtml/… – each View Definition will apply one of these views.)
We also use servlet role based security, restricting access to certain web folders via Security roles in web.xml. This means that if one role shares the same view, we have lots of duplication of Facelet View Definitions in each subfolder of the applicaiton.
I would like to “virtualise” these views somewhat to avoid having an explosion of new facelet files in each folder, and I beleive that pretty faces could help us to define the View Definition URLS in pretty faces configuration. It seems easier to manage a config files rather then have 1000s of definition files. Tiles I think worked for us in this regard and pretty faces seesm to offer simular.
One problem we have is that we used tiles to inject “request attributes” into views so we could deduce things like what menu should of been rendered or whether we were executing a “wizard” flow etc. Thier seems to be no such feature in pretty faces, meaning we cant directly migrate without re-engineering somewhat. Here are my questions:
1. What alternative patterns are people using to avoid duplicating simular view definitions in thier applications?
2. Does pretty faces have any work arounds to allow request attributes be injected when a URL is visited? What other patterns do people use to inject state into views in JSF?
3. URL Rewrite from Tuckey supports our requirement of setting request attributes when URLS are accessed, I have seen that OCP Rewrite will allow you to use URL Rewrite engine, does it support 100% of URL Rewrite features? When is pretty faces 4.0 due to be stable?
Many thanks for taking the time to read this, looking forward to hearing users views and suggestions.
ColmJune 12, 2012 at 6:55 am #22598
I’ll try to answer you questions one by one.
1. I think that most people are using the Facelets templating mechanism to define similar views. To be honest, I don’t fully understand why you are having duplicated views in your application. But PrettyFaces and Rewrite definitely allow to build an abstraction layer separating URLs visible to the user from the actual views rendered.
2. No, PrettyFaces doesn’t provide an easy way to set request attributes. Typically managed beans are used to represent state in a JSF application. I’ve never heard that someone used request attributes for this. And to be honest, I don’t see any reason for doing something like this.
3. If you are using Rewrite, it should be very simply to implement ANY behavior you want. Especially setting request attributes is easy. PrettyFaces 4.0 is currently in heavy development. I think we will have a “preview version” out soon. But the API and structure of PrettyFaces 4.0 is still very likely to change. But you could also use the JSF integration of Rewrite for now. This should do everything you need. However we are planning that PrettyFaces 4.0 will replace the Rewrite JSF integration module in the future.
ChristianJune 12, 2012 at 8:53 am #22599
Thanks for your reply. If any one futher wants to comment, ill just clarify some of Christians points…
“I don’t fully understand why you are having duplicated views in your application”
The views are not exactly duplicated, with Tiles, it was a common pattern to have view state injected into the tiles (which became request attributes). When we migrated from tiles, the easiest migration path was to do simular in facelet view definitons.
For example, in our applicaiton we have ability to search for registered users. An “administrator” user or a “supervisor” user can do this search. But, each of these user roles has a different navigation menu, so we injected the menu name into the View Definition, using the c:set attribute.
<c:set scope=”request” var=”module” value=”admin”/>
<c:set scope=”request” var=”module” value=”super”/>
// then we apply a common view .. UserSearch.
Because we are using JAAS role based security currently, we have one view definition (UserSearch.xhtml) in a subfolder “admin” and another View Definition in a subfolder “super”. I would like to use Pretty Faces to virtualise this URL, and not have two facelet files to realise these two URLS, but its limitation for us is the Request Attribute problem.
“Typically managed beans are used to represent state in a JSF application”.
I agree – this is the JSF way to set state. We use One View to one Backing Bean pattern. In the above scenario, one request scoped managed bean called “UserSearch” would act as a backing bean to the two UserSearch.xhtml View Definitions. If we moved the menu state to this backing bean, we would need two instances of this Bean, meaning we would have an explosion of Page Beans.. anyhow, this is probably a reflection on are archetecture after migrating from tiles then JSF.
“And to be honest, I don’t see any reason for doing something like this.”
The reason we have for doing this is because we are migrating from tiles/jsp to facelets. We have clients which we need to continue supporting and cant rewite from scratch.
Christain, really appreciate your answers, we will definitely review Rewrite. Glad you planning to introduce annotation based configuration for this, because I find writing rules like this in Java code a burden for applicaitons with hundreds of URLs.
ColmJune 12, 2012 at 6:20 pm #22600
Thanks for your reply.
I now understand why you are using request attributes. It’s just to keep the migration from Tiles simple, right? I’m don’t know Tiles very good, so this was confusing for me.
I think using PrettyFaces/Rewrite should work fine to virtualise the URLs. This way you could for example make the role of the user a part of the URL (like
/supervisor/users) and convert it into a query parameter or something else. PrettyFaces 3.x would be fine to inject the variable part of the URL into a request scoped bean or a query parameter. If you want to go with request attributes, Rewrite could surely do this.
I think in your case it definitely could make sense to use annotation based configuration to simplify the creation of a large number of rules. However, Rewrite is very modular. You could also build your own way of configuration. You could for example even build an extension of Rewrite that is able to read some custom data format for your rule definitions (perhaps some simplified XML syntax for your usecase). Or you could even parse your old Tiles configuration and build the corresponding rules from this. But as I said, I’m not a Tiles expert. This was just a thought. I just want to emphasize that extending Rewrite is very very simple. Feel free to post on the forums if you need some help on the API. Perhaps looking at the current code of PrettyFaces 4.0 gives a nice introduction into how simple it is to build custom annotations to configure Rewrite.
Unfortunately I have to note that Rewrite currently doesn’t have much documentation. This is caused mainly by the fact that the framework is still under heavy development. But the API is getting very very stable and we don’t assume that there are any more major changes to it. And I think that you will get answers to your questions very quickly if you post to the forums.
ChristianJune 13, 2012 at 8:52 pm #22601
I will definitely evaluate pretty faces 4.0 for our platform. Seems like it will be a good choice for us.
You must be logged in to reply to this topic.