Skip to main content

News from a Parallel Universe: JSF and Tapestry project leads agree on future course

Posted by johnreynolds on February 15, 2005 at 8:23 PM PST

At the upcoming TheServerSide Java Symposium in a parallel universe, the doppelgangers of Howard Lewis Ship and Craig R. McClanahan will agree to base JSF 2 on Tapestry.

Meanwhile, back in our universe, I have begun preparing for TheServerSide Java Symposium in a few weeks by looking through the schedule.
There are two sessions that I really want to sit in on; Craig R. McClanahan’s JavaServer Faces: Dead on Arrival or Raging Success?
and Howard Lewis Ship’s Tapestry Case Study: Transforming

I have no doubts that the Java future for “pure” Browser-based HTML/JavaScript applications belongs to web component based approaches such as Tapestry, JSF and Echo. The ability to write component-based event-driven applications for standard browsers is simply too attractive for the approach to fail (but of course, the future for richer options such as applets, Flex, and Laszlo is also bright).

I have spent more time with Tapestry then JSF, and I admit bias. I like “the feel” of Tapestry better. For one thing, I prefer Tapestry’s use of an HTML template to JSF’s current JSP centric implementation; Tapestry seems cleaner to me, and there are fewer skill sets to master. I also feel that Tapestry is a more complete solution. Compared to JSF, Tapestry is an old-timer, and it has addressed many issues that JSF has yet to tackle.

My fondest wish (with respect to Java Web UIs) is that Craig and Howard will spend some quality time together. My understanding (gleaned from a session at a No Fluff Just Stuff presentation) is that some of the original JSF expert group members were not very familiar with Tapestry at the time that the specification was written. If that’s true, it’s a shame.

I want to see Howard welcomed to the JSF 2 expert group in the same way that Gavin King was welcomed to the EJB 3 expert group. I have browsed the draft specification for EJB 3 persistence, and it is obvious to me that Gavin's Hibernate experience has really helped the expert group set a better direction; a direction more in line with the likes and desires of rank-and-file Java developers. Lessons learned from popular Open Source projects can greatly enhance the utility of the official standards.

On a related note, Apache has just announced the formation of the JSF-oriented Struts Shale project. I came across the following paragraph in Craig McClanahan’s proposal regarding
the need for an IoC (Inversion of Control) container:

“Rather than building such a container ourselves, we should seek to incorporate an existing one that is license-compatible and which can be integrated into the JSF managed beans facilities (so that value binding and method binding expressions can leverage the facilities of this container transparently). From my research so far, I like Spring's capabilities in this area the best, but am open to other suggestions.”

I have no desire to disparage the Spring framework, but I would like to suggest that Craig adopt Hivemind as the IoC container for Shale. For one, Hivemind is also an Apache Software Foundation project, but of greater relevence, Hivemind is the IoC container for Tapestry 3.1. What better way to foster synergy between Tapestry and JSF then to share the same IoC container?

I doubt that JSF and Tapestry will ever merge in this universe, but surely they can benefit from each other.