Michael Slattery makes a good observation in a comment on my last JSF podcast.
I generally enjoy your podcasts. [...] I have some feedback. It seems like you are complaining mostly about an implementation of JSF rather than the spec itself.
Much of my chatter has centered around examples involving the actual implementation. Let me step back and summarize my podcast main points from the standpoint of the spec:
1. The JSF spec indicates exclusive use of POST. That breaks all kinds of RESTful idioms and paradigms that good websites are based on. Strike one.
2. The JSF spec itself attempts to create a component model with a lifecycle that obscures the underlying HTTP request-response cycle. It’s a Leaky Abstraction, and it does more harm than good. Strike two.
3. The JSF spec defines the concept of a RenderKit; a concept that places HTML far away from page content and creates an abstraction that most people won’t need but everyone must deal with. Oh, and it turns the page definition into an XML config file, forcing my view logic back into the controller area. Strike three.
Many of the annoyances I listed are stated in an implementation specific way, but my philosophical differences truly lie with the spec. Perhaps it’s a forest vs trees thing. In any case, it evidently wasn’t clear that the spec was to blame for the issues discussed in my podcasts.
Oh. I almost forgot. One more:
4. The JSF spec is a spec for a web framework(!?). So the rest of the problems I have with substandard implementations are indirectly caused because there’s a spec in the first place. If there was just a single, high-quality framework it would eliminate the chatter of choosing among several implementations and focus disucssion on the underlying merits of it’s approach to web development. Will the next web framework please step up to bat?
February 8th, 2006 at 10:06
>> 3. The JSF spec defines the concept of a RenderKit; a concept that places HTML far away from page content and creates an abstraction that most people won’t need but everyone must deal with. Oh, and it turns the page definition into an XML config file, forcing my view logic back into the controller area. Strike three.
- All components in JSF have a rendered attribute which is like c:if.
- MyFaces has a t:dataList component that will loop over a collection of objects, which is like c:forEach.
- MyFaces has a t:buffer component which will take a group of components and treat them as 1. This allows the group as a whole to be displayed or not with the rendered attribute of what outputs the buffer and it allows duplication of the same components on the rendered screen (output the same buffer twice).
The combination of the above three makes 99% of the view logic possible in the view layer, however it’s not as intuitive or as clean as JSTL IMHO.
– Nic