Salient Soft

I have found the following sites useful :-

Tutorials

• Facelets Reference Documentation
• Icefaces Facelets Tutorial
• IBM Developerworks Facelets tutorial

Reference Information

• java.net Facelets Wiki – main page for the Facelets Wiki
• java.net Facelets Wiki FAQ – excellent and clear answers to common issues/gotchas
• c:forEach vs ui:repeat in Facelets – very useful and clear article on the gotchas around this and EL evaluation by Roger Keays

No Comments »

Helpful simple post about how facelets actually works.
http://www.theserverside.com/discussions/thread.tss?thread_id=41855

JSF central Inside Facelets tutorial series :-
http://www.jsfcentral.com/facelets/

IBM Developerworks articles (can also be downloaded as PDFs from the sites)

Facelets :-
http://www.ibm.com/developerworks/java/library/j-facelets/

JSF for nonbelievers articles – good introduction to JSF:-
http://www.ibm.com/developerworks/java/library/j-jsf1
http://www.ibm.com/developerworks/java/library/j-jsf2/
http://www.ibm.com/developerworks/java/library/j-jsf3/
http://www.ibm.com/developerworks/java/library/j-jsf4/

No Comments »

This tutorial describes how to use the Component showcase css and icons as the template for your own project.

I’ve not looked into it in detail, but it certainly makes sense to use the same look and feel and borrow from ICEfaces where necessary.

One of the comments is less than complementary about some of the CSS code in the example.

No Comments »

This ICEfaces article details the importance of the correct separation of concerns and scoping of JSF managed bean. Of particular importance is ensuring that you do not mix up the layers of the MVC design pattern, by mashing up different MVC concerns into a single managed bean. Correct splitting up of classes and scoping can avoid this and achieve the desired loose coupling.

The approach I have taken, which differs subtly from the above article but is fundamentally the same, is as follows :-

1. I encapsulate all calls to the business/service layer in a ModelBean. This bean exposes properties which hold all the business data fetched from the service layer, and various populate and save methods to fetch/populate those properties and finally persist modified versions of them back via the service layer. As I am using JPA and have generally elected not to use the DTO pattern,  the properties  are JPA entities, objects which are the result of JPA select constructor expressions, or primitive data values from the database. For clarity, the ModelBean is stateful and session scoped and so holds the properties all the time a page is being viewed/edited, whereas all the calls to the service layer are stateless. I might have a single model bean, or I might break it down into a number of separate beans, depending on what suits the design. Whilst there could be one per JSF page, typically I find that there is scope for a lot of re-use of common methods and properties acrosss pages. Conversely, for a larger application, it may become unmodular and unwieldy to have a single model bean. A fundamental point about this bean is that it does not  perform any controller logic, i.e. does not directly interact with the components on the page (although typically of course they will refer to its properties to get data).
2. I encapsulate all the logic which interacts with the components on the page in a controller bean for the page. Where the page contains subcomponents such as custom facelets tags (in my case, a TablePair tag is an example of this), I typically find that a good design is to have a separate child controller bean for each custom component, so that the controller mirrors the structure and requirements of the view. These controller beans do not access the business/service layer directly – all such access is routed via the ModelBean above. This separates all code which is directly aware of the business layer interface from controller code which is aware of the structure and handling of the page.
3. I ensure that the view (the JSF page, facelets and tags) does not contain any business or controller logic. As this post indicates in its last paragraph, the presence of logic expressions in JSF value expressions is often a warning bell that this may have occurred, and the view has been polluted with controller or model concerns. For example, the disable attribute on a JSF component is strictly a property reference to an enable/disable property in a controller bean. The conditions under which that property is enabled or disabled are strictly a controller issue. The above post also details design guidelines for state change management and event handling and propagation for the controller bean.

A good test of the design is to ask yourself the following questions:-

1. What would need to change if the call interface to the service layer changed? Would it be necessary to change any backing beans which also contain controller logic – which handle components on the page? If so, the design has become polluted. Consider a possible requirement where the service layer interface was enhanced, and the old interface was eventually due to be deprecated. You might have a situation where you needed to support both versions. Would this result in having 2 identical copies of some controller code which interacts with components on the page? If so, you have polluted the design and mixed controller concerns in with the model. If you had to perform any bug fixes on the duplicated controller code, you would have to update both copies identically to keep them in step, and so have broken modularity.
2. Conversely, what would need to change if the user interface to the page changed, but performed the same functions in terms of the model (perhaps the interface was improved to make it more user friendly)? Would it be necessary to change any beans which contain calls to the business/service layer? If so, the design has again become polluted. Consider a possible requirement where you needed to maintain both the old and the new versions of the user interface for a period until the old one had been completely phased out. This would require 2 versions of the controller beans to be maintained. Would this result in having 2 identical copies of some model code which directly calls the business/service layer? If so, you have polluted the design and mixed model concerns in with the controller. If you had to perform any bug fixes on the duplicated model code, you would have to update both copies identically to keep them in step, and so have broken modularity.

Comments Off on Correct Scoping/Separation of JSF Managed Beans

I created a simple test web app using ICEfaces, including the test/sample page that the plugin creates for you by default. When running the app on Glassfish, the error “Object doesn’t support this property or method” occurs and the page fails to load correctly. The same application works in Tomcat.

The issue turns out to be due to a single extra space in web.xml. The Eclipse code has an extra trailing space in the url pattern for the Persistent Faces Servlet mapping as follows :-

Broken Version with trailing space after the * – works on Tomcat 6, fails on GlassFish 2.1

<url-pattern>/xmlhttp/* </url-pattern>

Working Version without trailing space – works on both

<url-pattern>/xmlhttp/*</url-pattern>

The effect of the extra trailing space appears to be that GlassFish 2.1 does not obey the servlet mapping for this url pattern. Tomcat is not tripped up by the trailing space. An extra hazard for the unwary in Eclipse (Galileo) is that if you use the XML editor to edit web.xml, it hides the trailing space if it is present, so you could miss it even if you were aware of the potential issue. The text editor shows the space correctly.

My original post on this in the ICEfaces forums is here. This problem has been fixed in 1.8.2 – the bug tracker entry for the problem is here. Note that upgrading to 1.8.2 will not apply the fix to existing projects in Eclipse, only to new ones. For existing projects, you need to remove the extra space in web.xml manually.

No Comments »