Components: JSF or Tapestry

Based on comparisons between Tapestry and JSF, I've been trying to determine who is actually doing components the 'right' way.

The debate should probably start with defining HTML itself as a presentation layer. HTML is 'now' actually composed of two parts with the help of CSS: structure and presentation. For those who've read my previous blogs, this is old news.

Component development emphasizes reusability and modularity. Neither is clearly represented in normal HTML structure under the ownership of a designer. If you want to show a menu on 5 pages, then you must replicate the same menu structure on each page. Now introduce the concept of components such that a menu structure is described once and referenced on each of the 5 pages. Referencing cannot be accomplished in normal HTML-- so we seek out a framework such as Tapestry or JSF.

Tapestry mixes standard HTML and additional attributes ('jwcid' for example) to convey additional dynamic behavior with components. Where I feel Tapestry falls short is that it b*stardizes HTML. Also, the use of elements versus expressions for inserting runtime data is odd (<span value="ognl:...."/> vs. ${bean.name}). Finally, while Tapestry is expressive from a view standpoint, it doesn't offer as strong of a model 1 approach as JSF.

JSF instead uses JSP pages. This is both a negative and a positive. It's a negative in that JSP was never meant to do anything other than simply execute which raises issues that Hans wrote about. The positive is that the JSP document is more dynamic than straight HTML and accepted in most editors.

Maybe it's just because I haven't had much luck with having designers and programmers work in the same document. When a designer designs a page, they are basically creating mock ups with lots of content to play with. When a programmer structures a page, they aren't concerned with the design at all. This difference of concerns leads me to believe that the designer and programmer should develop in two completely different documents. This is why I have a slight distaste for Tapestry. Yes, Tapestry can offer a strong sense of seperation, but you are doing so within HTML which isn't as expressive as JSP.

Referencing a previous article of mine on seperating presentation and structure with CSS, I believe this is only where presentation comes into play with component development. Let the designer design in their document and let the programmer create in standard JSP.

For some reason, I'm not fully comfortable with that conclusion though. When it comes to rendering component structure, I do see the benefits of expressing output directly in HTML (a difficult task with JSF). But then again, maybe we should start looking at HTML simply as a structured XML document-- think of the structures we present with web services to other clients. For applications that require XML, why aren't there any popular templating frameworks-- everything is done in DOM or some other flavor of XML lib that I know of for generating documents. If document structure is agreed upon between the designer and the programmer (and the W3C in this case), why not give the programmer the ability to abstract that structure with components and leverage flexible JSP markup and other tags to express that structure, rather than limiting it to a specialized version of HTML.