Thanks for the comments Shawn, > In general, JSTL requires that users know less, making its use easier. > For instance, users of JSTL tags don't need to understand the lifecycle > considerations associated with a JDBC Connection, Statement, or ResultSet;
Do you think it is better to encourage use of JDBC and SQL by users that know less, or, is it better to encourage users to know more before dealing with it? Which way do you think the JSTL is encouraging users to go? > if the applications performs sufficiently well without finer-grained > management of such resources, then development is easier with no loss > in quality of the code. I agree. Do you think the JSTL SQL and XML tags hurt future quality of code? For instance, a MVC pattern can keep all of its View components regardless of changes to the backend. This is due to a clean abstraction and good interface (e.g. custom JavaBean). With something such as the JSTL SQL or XML tags you are restricted to a datasource or XML, respectively. >>Probably? Is it quicker for you or any projects you have helped on? > > I can certainly say, from my own experience and anecdotal evidence, that > prototyped pages (and small applications) can be faster to develop in JSP > than in JSP + Java. How much faster and is it because JSP auto-compiles? Would you put a limit on when it would not be quicker to use JSTL SQL and XML tags? If so, what is the limit? >>About the URL components. The import action seems nice, but not really >>practical. Is there a good case where it would be desired to directly >>import external content in to a web app? > > Sure - consider importing a header from another web application. Would > you really want Java code to do this, instead of a single <c:import> > action element? Why would you want to do this? If I had to, I would want Java code to do this for cache reasons. But, I can't think of a good reason why a external header would be needed. > For importing data from a web service, I tend to agree that more > abstraction is useful; James Strachan and others like the idea of using > XPath to parse responses from web-services, but I'm not fully convinced of > the utility of that approach. However, displaying data from an XML > document that's retrieved from a database or URL is reasonably within the > realm of the presentation tier. What's the advantage of using Java, > versus JSTL, to loop over all <customer> elements of a document and print > the value of their <orderNumber> children? The advantage of using Java is getting everything Java supports. Namely, you can easily write up some validation and error handling code in Java. Both are unrelated to looping through some values but required when getting the information which is being looped through. Assuming the information is always correct is a stretch, especially if you are not responsible for generating the XML. >>e.g. <a href="<c:url/>">link text</a> versus >> <c:a url="http://...";>link text</a> > > But this then ties JSTL to HTML in particular (something we've > consistently avoided doing), and it also requires a separate JSTL tag for > each HTML element that might contain a URL -- including, at least, <a>, > <img>, <iframe>, <frame>, <form>, and <link>. Worse, every potential HTML > 4.0 attribute would need to be replicated by the JSTL tag; I believe <img> > has about two dozen attributes, for instance. Furthermore, this wouldn't > help when sending a URL as part of a block of scripting code (e.g., > JavaScript). I meant the url action would be unfavorable versus a HTML-like link action authored individually on a per project basis. So if HTML was the only thing used it would be HTML, likewise for other formats. The point of asking was to see if encouraging use of the url action would be better then encouraging use of the API that powers it. Some tags such as the JSTL forEach tag are great for most every use, however the url tag doesn't seem like one of these because of the awkward syntax. What do you think? >>What is a good use for the redirect tag? > > Forwarding to a resource that's not in the web application (and is thus > beyond the reach of <jsp:forward>). Right, but why would you want to do this? The jsp:forward action is not something which is helpful either. The API it uses is very helpful, but making a tag out of the API doesn't seem to be of use. Do you think this type of tag should be encouraged for use with JSP? Cheers, Jayson Falkner [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
