Hi Jack and Dustin. >> Having only worked with Struts for a couple of months, I'm >> beginning to wonder about the costs and benefits of using Struts, >> or any other JSP tag library, for that matter. > > I'm glad you're bringing this up, since we're at a major > decision point right now concerning Struts and taglibs. I share > your opinion, but I would like to know more. > > I would add that custom tag libs aren't simple to write, and > in another thread about large apps and Struts, people were saying > that they might be slow. Since it all compiles down to a servlet > anyway, maybe a little bit of Java in there isn't a problem. >
I've had to come to some decisions recently in this area. I originally considered Velocity as an alternative to JSP. But I realized after awhile that really, they both force web designers (creative types that work with HTML and graphics in tools like DreamWeaver) and Java developers (not typically so good with HTML) to collaborate on a common artifact (either a JSP or a Velocity template) to combine their respective work. There is never _really_ a single handoff from one team to the other. My experience has been that the artifact tends to bounce back and forth between the two teams as changes occur to creative content, and yes, even requirements, that require either the web developer or the Java developer to update it. Since neither team is well versed in the proficiencies of the other, the Java developers tend to break the creative and the web developers tend to break the Java (be it scriptlets or taglibs). In the end, you have to throw in a couple "iterations" of this cycle just for bug fixing. That gets to be real troublesome when your customer insists on specifying the product in "web-time" -- even making changes the day before release to production. On the advice of some, I started looking at using XML and XSLT as a means for merging in dynamic content. Problem is, anecdotal evidence is that using XML nd XSLT for web presentation isn't particularly fast nor scalable. And XSLT isn't a technology that either web developer or Java developers seem to take to rapidly. Along the way, I came across the Enhydra project and a presentation technology developed by them called XMLC. This technology intends to fully separate the web developer from the Java developer by creating a Java class representing an HTML page as a DOM in a Java class. The web developer only deals with web presentation technologies like HTML, CSS, JavaScript, etc. The Java developer gets a JavaBean-like class that permits insertion of dynamic content in the DOM of the HTML at runtime. After the dynamic content is inserted, the final HTML stream can be generated. The only collaboration between the two development teams is on how to identify content insertion points. This is done using standard id and class attributes of HTML elements and the SPAN tag when necessary. You can get more information on this technology here: http://xmlc.enhydra.org/ My team is currently using XMLC with Struts. We use standard Action classes as the web-side controllers that process HTTP requests. Depending on the outcome of that processing, the controller Action forwards to another Action class that is responsible for generating the View. That Action class can receive some information in the request and session scope collections as well as perform any dynamic data retrieval necessary. It then instantiates an XMLObject representing the HTML page and calls methods to add/remove content elements as necessary, generating the response stream when done. Using XMLC technology, we intend to completely abandon JSP. Frankly, both sides of my development team are excited (still) about XMLC. I haven't had a chance yet to look at the VelServlet implementation or the ContextHelper object that Ted mentioned. Perhaps these will make use of XMLC even better/easier/more fulfilling than it has been already. Best regards, Jim Cakalic <font size="1">Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
