> However, it's my observation that a custom tag library becomes almost a > third language that neither web developers nor Java developers > understand.
The popularity of Cold Fusion would disagree with this... ASP.NET is moving to this model as well (custom tag libs, minimal code inside the web page). > Now, if a Java developer does learn HTML, s/he's added a skill with wide > application. If a web developer learns a bit of Java, s/he's added a skill > with wide application. If both parties learn a custom tag API, they've > added a skill that's only useful with that particular custom tag API. > If one goes to a different project using different custom tag libraries, > one has to start learning a new custom tag API all over again. Certainly. However, think of the alternative: custom Java code embedded in a JSP page, written in a style that only the author of that page understands. IMHO, takes a lot more effort to understand a Java-encrusted JSP page that has gone through 6+ months of maintainence than learning a new tag library. Tag libraries come down to easily-read abstractions. One can abstract a JSP page with Model 1 code using beans and small scriptlets, but the fact remains there's a cognitive dissonance between the constant mental-mode-switching between tags and Java. There are lots of network toolkits out there... one for Win32, one for UNIX, one for Java, etc... There are subtle differences, but they all have the same intent. Ditto for taglibs. > I'm not interested in starting some kind of religious war by this post. > I'm just wondering how much the benefits outweigh the costs of using > Struts on a project. Certainly these questions are worthwhile. I've seen the dynamic-tag approach work wonders over the years, with WebObjects, Cold Fusion, Struts, and now ASP.NET. It's a workable approach... But as Ted said, Struts doesn't require the use of taglibs. It's just (very tasty) gravy... Cheers Stu Charlton Infusion Development http://www.infusiondev.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
