Re: Can Pretty Faces/Rewrite help me?

Splash Forums PrettyFaces Users Can Pretty Faces/Rewrite help me? Re: Can Pretty Faces/Rewrite help me?

#22599

Colm
Participant

Hi Christian,

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”/>

or

<c:set scope=”request” var=”module” value=”super”/>

// then we apply a common view .. UserSearch.

<ui:define name=”Body”>

<ui:include src=”/WEB-INF/xhtml/views/UserSearch.xhtml”/>

</ui:define>

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.

Regards

Colm