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.
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.
posted by Jacob Hookom at
12:54 PM
2 Comments:
I think you're really missing the point of Tapestry. One of the things that really irks me about JSPs is the fact that in most environments I've worked in, the web page development is done by someone other than the Java developers, and the html prototypes have to be rewritten as JSPs. That's double work. In the real world I've worked in, changes invariably must take place on those html pages, which means some developer must waste time implementing those changes in JSPs too. You essentially end up with two sets of files for the same thing. That's just dumb to me. We all seem to know that it's best not to duplicate code in programming, or not to duplicate data in a database (normalization), how come we don't realize the same should hold true for web page development/integration? There should be essentially, one set of prototypes which automagically can be converted to dynamic pages which developers reference. Tapestry gives you the cleanest implementation of that, I've seen yet. To me, the ideal situation is one in which web designers make prototypes, put them into CVS (or whatever), developers check them out, mark them up every-so-slightly so as to not affect the designer's ongoing needs and tool preferences, and then integrate those pages whenever designers make changes. That's just about a win-win to me. I absolutely despise the thought of maintaining two versions of essentially the same pages, one set of html and another of JSPs. The only other solution I found that may is many ways, be even better for separation, is XMLC. Using that tool with regular expression replacements, it's possible (theoretically) to not touch the html prototypes AT ALL (although in reality, you'll probably want to at least ad some "id" args to key html elements, but one need not go any further than that).
By
Terry C. Martin, at 7:52 PM
Thhanks for posting this
By
Ariana, at 1:27 AM
Post a Comment
<< Home