I've just found a series of articles published on IBM Developer Works called "JSF for non believers" written by Richard Hightower. They seem to be a good tutorial into JSF.
There are 4 articles in the series namely:
Frank Silbermann
2/8/2011 06:16:56 pm

In regard to web frameworks, the phrase “component-oriented” has two distinct connotations. One is that the page is assembled using pieces that each encapsulate highly sophisticated stateful behavior and interfaces. (This is in contrast to the lower-level CGI approach in which the HTML produces an HTTPRequest object, and the code processes that object to produce new HTML.)

The other connotation of “component-oriented” is that one can assemble the application using a WYSIWYG tool, using built-in wizards and property editors. The use of the term is ambiguous when discussing JSF, because JSF exhibits both types of component orientation.

The article “JSF Component Development” says, “The litmus test for a component model is: Can you buy components from third-party vendors and plug them into your application?” That is indeed an important quality. But there is another important quality which the the articles’ author, Richard Hightower, does not consider.

Hightower is the author of _Java_Tools_for_Extreme_Programming_, so he must have heard of the DRY (“Don’t Repeat Yourself”) principle. Quite often components will exhibit repeating patterns of use across an application’s various panels or pages, so the ease of respecting the DRY principle when building user interfaces will depend upon the application developer’s ease modifying and grouping standard components into new ad-hoc application-oriented components for re-use across the application. It is easy to do this in Swing — just create a subclass of an existing component and instantiate the subclass wherever you please. You can even make ad-hoc modifications through the use of anonymous subclasses. Only if you insist on using WYSIWYG tools must you concern yourself with implementing the tool-to-component interface.

With JSF, in contrast, respecting the DRY principle by building ad-hoc application-oriented components is laborious — whether or not you insist on using a WYSIWYG tool to build your pages.

This is why I prefer the Wicket framework. Though Wicket sacrifices the use of a WYSIWYG tool for application assembly, Wicket is component-oriented according to the first connotation of component orientation — the page is indeed assembled using pieces that each encapsulate highly sophisticated stateful behavior and interfaces. What I like about it is that creation of new ad-hoc application-oriented components is as easy as in Swing — just create a component subclass and instantiate it in one’s page just as one would instantiate any other Java class. Adding third-party components is as easy as adding a .jar to your classpath.

Reply



Leave a Reply.