News from a Parallel Universe: JSF and Tapestry project leads agree on future course
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 TheServerSide.com.
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.