On Fri, 7 Jun 2002, Jayson Falkner wrote: > Does anyone seriously use the JSTL XML, URL, and SQL tags? I'm looking > for some reasons as to why they are helpful, but, I can't really find > any. Obviously they work, but the important point seems to be the > tag's functionality would best be placed elsewhere using Model 2 > (MVC). > > If anyone is seriously using them and has a good argument as to why > they are helpful, I'd like to discuss it with them further. Does > anyone?
There were a handful of different thoughts behind these libraries: - Not everyone writes applications using the "model 2" methodology. Some applications are small, for instance, and don't need rigidly separated components. Furthermore, while many of us appreciate the design behind "model 2," it is not universally accepted; JSP and JSTL do not require it to be. - The inclusion of URLs and the manipulation of XML are both arguably "presentation-tier" tasks. Consider <jsp:include>, which <c:import> merely generalizes. Consider also XSLT, which is clearly appropriate for the presentation tier but which engages in the manipulation of XML; JSTL's XML libraries can be seen as an imperative alternative to XSLT's functional approach. To play devil's advocate, how far would you suggest swinging the pendulum away from JSP back toward Java code in servlets? Would you argue for having a servlet (versus a JSP page) manage headers and footers? Both <c:import> and the XML tags are appropriate for retrieving and processing such inclusions. Separately, the other URL tags: <c:url>, <c:redirect>, and so forth seem much less cumbersome in JSTL than their analogues in servlets do. The servlet sees URLs in the "data model" as their literal values; the addition of a context path and session ID are arguably best left to the domain of presentation rather than business logic. I just suggested as a training session I gave that session IDs should be added to URLs from within a JSP page, not from a servlet, precisely because of this; <c:url> fills this role. And <c:redirect> is appropriate whenever a JSP page needs to initiate a redirect; it's an alternative to <jsp:forward> serving a different niche. - The SQL libraries are the hardest to defend to those who believe in "model 2," but it's nonetheless a requested feature and one where standardization is better than the lack of it (and the use of fragmentary database-access tags). However, even in applications where "business objects" are handled using a rigorous, thoughtful methodology, some data might be intended specifically for the presentation tier and might be easier to retrieve using JSTL's SQL tags. For example, is anything really gained by transfering a user's color or font preference through multiple tiers of business logic? Perhaps, just for consistency... but perhaps not. Note that the presence of a JSTL tag isn't the same as an endorsement by the JSR-052 group of any specific methodology. JSTL tags, in fact, were designed to be as tightly focused as possible, each serving a particular role; many of them can therefore be used irrespective of whether you use other JSTL tags or not. The goal of JSTL is simply to make JSP development easier -- for all JSP users, not just for those who adopt a specific organizational plan for their applications. -- Shawn Bayern "JSTL in Action" http://www.jstlbook.com (coming in July 2002 from Manning Publications) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
