Is JSF really that bad?
Ignacio Coloma posted a long article detailing his unpleasant experience with JSF, and the MyFaces implementation in particular. First off, I agree with him on many of the points he raised. But, I think some of Ignacio's major complaints can be easily resolved if one is willing to look slightly outside of the "standard JSF". Well, you probably guessed it by now. I am talking about Seam. 
1. Ignacio mentioned that ORM (e.g., Hibernate) is difficult when an ORM backend is accessible by the stateful JSF presentation layer. I could not help but notice that he is using the stateless Spring framework to connect JSF and Hibernate. IMO, that is the problem. As we know, ORM lazy loading is a messy problem with any stateless architecture due to limited lifecycle of the persistence context. What you really need is a stateful framework that truly understands how to leverage the state information in the JSF tier and in the ORM tier, and then make them work together. JBoss Seam is such stateful framework for JSF and Hibenrate (or EJB3 JPA, which Hibbernate implements). Believe me, Seam and Hibernate work so well together, you'd think that they are made for each other (actually, they are both brain children of Gavin King). See more on this issue here.
2. Ignacio's second big complaint is that JSF is not friendly to HTTP GET (or REST) URLs as everything is instaniated from a postback. I agree that in plain JSF, it is a hassle to setup RESTful URLs. But with Seam, the HTTP GET parameter is simply injected into the backend component when the component initializes itself for every request. There is no manual pulling of request parameters. You can also start Seam conversations (a state management facility finer than HTTP session) from an HTTP GET operation. I have recently been working on a Seam-based web site that primarily uses GET URLs (and a ton of AJAX). It has been a breeze to write those RESTful pages in Seam!
3. It is somewhat trival, but MyFaces' use of JavaScript in hyperlinks can get very annoying when you want the link to behave like a regular web link (e.g., to right-click it etc.) Seam provides an easy solution via its own UI components like the <s:link> component. The Seam link / button components have the added benefit of support Seam conversation states out-of-the-box.
Example:
To illustrate the above points, let's look at a simple RESTful page with Seam. Suppose that you want to use a URL like product.seam?prodId=8 to retrieve and display a product from a database. The Product entity object might need to further lazy load some of its properties during rendering. Do we need complicated XML or data transfer objects? Not with Seam! Here is the Java component (JSF backing bean):
-
@Stateful
-
public class ProductActions implements ProductActionsInt {
-
-
// Extended PM with stateful component allows
-
// lazy loading during rendering phrase
-
@PersistenceContext(type=EXTENDED)
-
EntityManager em;
-
-
// Inject the HTTP GET parameter
-
@RequestParameter String prodId;
-
-
Product product;
-
// getter and setter for the product property
-
-
@Create
-
public void findProduct () {
-
if (prodId != null)
-
}
-
... ...
-
}
Then, on the product.xhtml page, you just display the product info.
-
Name: #{productActions.product.name} <br/>
-
Price: #{productActions.product.price} <br/>
-
... ...
That's it! All the lazy loading of product properties, if any, are automatically taken care of at the rendering time of the JSF page.
Of course, Seam is not yet a Java EE standard. Does that eliminates JSF's advantage of being a standard? Well, I think the answer is no. But that is for another post tomorrow.
October 24th, 2006 at 3:50 am
Hi Michael,
I agree that Seam fixes lots of the deficiencies of JSF (though it was not an option in my last project since we were restricted to 1.4), but I still doubt its scaling capability.
In my last life I had to avoid the Citrix paradigm of virtualizing the client workstations in the server, the same zombie that JSF is respawning: the server must remember the state of each client and that is a little too memory-consuming. While it should work for a medium-sized application, this approach will not escale easily for a typical enterprise application (+500 users with sessions of +10 hours).
Anyways, I suppose what we are talking about here is Seam, not JSF. We could as well be talking about RIFE. A great framework, but has little to do with the standard (unless they manage to push some of these features into the spec)
October 24th, 2006 at 7:12 am
In Seam 1.1 page actions and (new) page parameters make building restful sites even easier. In fact, the page parameters stuff makes it easier to build restful sites using JSF than it is in an action-oriented framework like Struts!
October 24th, 2006 at 7:14 am
The original blog also mentions problems propagating state across redirects. Seam provides two ways to solve this: page parameters, as I already mentioned, and conversations. The Seam conversation context is always propagated across a redirect, even if you don’t have a long-running conversation.
October 24th, 2006 at 7:18 am
He also mentions the use of GMT by default. Again, Seam 1.1 overrides this to use the server default timezone by default. LOL, I wonder what is next haha.
Oh, he mentions problems with injection … that are not problems with Seam bijections
October 24th, 2006 at 12:17 pm
Gavin,
Ignacio’s main concern is JSF, and not Seam. Seam is not JSF in the same way that Struts is not JSP.
The problem here, like many other Java standards, is that JSF lacks many things that are required to build enterprise class applications and then one has to use non-standard extensions like Facelets and Seam to solve these.
October 24th, 2006 at 2:03 pm
Hi Ignacio,
Thanks for the comments. Well, first, Seam is being stadardized.
Your point about JSF scalability (or more general, stateful framework scalability) is interesting. But I do not really think it is that bad — JSF maybe slower than stateless frameworks but should not be less scalable. Maybe I should write another blog to explain those points in more details …
cheers
Michael
October 24th, 2006 at 2:10 pm
Hi Behrang,
Yes you are exactly right. But the point I am arguing is that the underlying principles of JSF is not that bad. The current problems can hopefully be fixed when Facelets and Seam made their way into the standards (see this post for more on this).
cheers
Michael
December 13th, 2006 at 9:06 pm
[...] * If you are JSF developer, Seam have always provided great enhancements to JSF (e.g., RESTful pages, end-to-end validation with Hibernate validators). Now with Seam 1.1, Seam continues this tradition with more useful JSF components (especially for input validation and page cache) as well as an expanded JSF EL. [...]