I never found a comprehensive standards that developers can adhere or follow or use as guideline or points to remember when designing the UI screens using JSF + richfaces. Its interesting that some well defined standards are not available for UI side in java technologies or atleast I didnt find any.
So here are some guidelines which for picking using JSF & Richfaces
1. Understand the current system or the system you are going to create using the JSF.
2. Understand the JSF lifecycle, without which any design we arrive will not be using JSF potential.
above 2 i think is very important for kickstart the JSF design in the first place and this is also gonna help us in development effort.
okay now going into the dev standards which i believe and followed when working with JSF & richfaces.
1. Dont use any tag unless you know what it translates to and whats its purpose.
(e.g) <h:panelGrid> translates to html table. so really think you have table used there or div will do.
<h:panelGroup layout=”block” /> will be rendered as div & without layout attribute it will be rendered as span.
2. Dont use rich tags when you can use simple JSF tag. <a4j> and <rich> tags when rendered comes with html component with added javascript/images/css and over which its difficult to have complete control ( though there are ways) but its very complicated than necessary and it also takes more time to render.
3. When designing the UI pages stop using “style” (inline styling) attribute and start using “styleClass”.
4. When we have error messages to be displayed next to the component or any custom messages to be displayed next to component, we will see some kind of jumping of the components when the message gets displayed. This is due to message suddenly appears and takes up some space to display the text. Avoid this by creating a placeholder for the messages as well. I mean when designing the UI page provide a static space for the <h:message> or <rich:message>
5. To simplify the dev effort we might easily use the <a4j:commandButton> or <a4j:commandLink> , may be we want to display a modal pop up without having to refresh the page or posting the page. But this will create what we discussed in point 2, it will add javascripts, images and CSS which are not required for this purpose. For this we can use <h:commandButton> and add <a4j:support>. simplifies the effort.
6. Try to have more control on CSS, this helps us to have external designer come in and create style classes. This makes the page more stable and styled which gels well with our JSF framework.
7. <a4j> and <rich> component comes with attribute called “ajaxSingle” which by default is false. Understand this attribute and make it to true. It will help us a big deal when we dont need all the elements submitted for validation.
8. Always create custom converter for the object to use those objects/entities directly in the page. This will avoid the additional view beans being used.
9. Design the Backing beans first and then the UI page. This helps us on the long run. Minimize the session scope objects and try keeping most in request scopes. Decide what to go in the session and what not. Getting the sign off on this and let stakeholders understand whats the backing bean design is about.
10. Last but not the least, this is pretty important that you keep the faces-config.xml for understanding our application design. It should be more like a site-map of a website. All the resource bundles, list, converters, validators, bean dependency injections all should be depicted in the faces-config.xml.
These are something i think is useful when deciding when developing. These are usual use cases i have seen in the applications. Most of all is POC before starting the application and best practices for that applications helps developers. Standards should be developed before starting the development.
One more suggestion when designing the UI framework is hide the core technical implementation from the developers so they dont mess with that and this will help the development effort to be fast. Easier said than done, so every project is unique and has its own requirements so please design with solution oriented and scalability in mind. We should be ready for changes in design but with minimal changes.
If anyone got any other points please……