From: "Jayson Falkner" <[EMAIL PROTECTED]> > > 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?
Huh? > 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. If your development team wish to go the whole hog and put custom bean wrappers around every piece of information in your enterprise, then you can happily use the core JSTL tags to work with that data. If you have some SQL or XML data available you need to present in a web page, you can use the SQL or XML tags - it gets the job done quickly. One size does not fit all, choose the best tool for the job. Also there's value in an XP approach, only refactor code to add layers and abstractions if you really need to do so, don't do unnecessary development work unless there is a real need to do so.. Sure in an ideal world, we'll always wrap things in beans and have a full MVC model II or hierarchial pull model and would probably have session facades over session beans which would uses entity beans internally with maybe data-access objects with value objects passing from the back end to the front. Though implementing all of the various J2EE patterns can take a very long time and can often be a very large sledgehammer to crack a tiny little nut. In the real world, sometimes all we need to do is extract some information from an SQL database or an XML source and display it on a web page. No huge requirement for a java middle tier, just a simple 2 tier architecture. Sure one day that might get refactored into beans if it is required. Maybe not though. Indeed if Web Services take off, I can see extracting information from XML much more popular than having to deal with the massive complexity of working with EJBs, session beans, session facades, value objects, JNDI, JTS and all the rest, just to get some information to display in a web page. > > 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. But we're talking about page designers here, so Java is not relevant as page designers typically are not Java developers. Maybe you're suggesting we dispense with page designers altogether and just have Java developers write Java Servlets for everything? James _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
