Thanks Boris! Borislav Iordanov wrote: > Hi Jayson, > > Yes, I've used the JSTL SQL tags in a bioinformatics web application > (managing users, experiments, experiment results, protocols, publications, a > complex search on everything). There is a lot of UI logic related to > retrieving data from the database in the JSPs, done with the SQL tags. And > the JSPs are quite clean and maintainable. However, the situation is a bit > different than the common case because I used our UI component tag library > TICL, which you kindly added to the JspInsider listings a while ago and > which lets you place UI components (TableView, TreeView, forms etc..) > through tags in the JSP. In TICL, the tags deal only with the functional > aspect of a UI component, MVC is implemented at the component level and you > define the look&feel of the components (their HTML/DHTML rendering) > elsewhere. So the combination of that with JSTL with its expression > language, SQL and logic tags yielded JSPs with almost no HTML nor Java code > in them. A big part of this application simply did not need any beans on > top of the DB, the cost of doing that extra layer was not justified. And > it's not just a prototype and it's not that small, and the web design is > still separated from UI and business logic. > > Cheers, > Boris > > ----------------------------------------- > Borislav Iordanov > Kobrix Software http://www.kobrix.com > > ----- Original Message ----- > From: "Jayson Falkner" <[EMAIL PROTECTED]> > To: "Tag Libraries Users List" <[EMAIL PROTECTED]> > Sent: Tuesday, June 11, 2002 10:12 PM > Subject: Re: JSTL XML, URL, and SQL tags, does anyone use them? > > > >>Thanks Boris, that is a good insight. >> >>If you don't mind, have you personally found the JSTL SQL, XML, or URL >>tags (or equivalent other taglibs) helpful while working on a project? >>I.E. has there been a situation where you needed to get something done, >>and it worked out great to use those tags? If so what was the case(s)? >> >>Thanks, >> >>Jayson >> >>Borislav Iordanov wrote: >> >>>Hi guys, >>> >>>Just my two cents in this discussion.... >>> >>>JSP is as much a programming technology as it is a presentation >> > technology. > >>>It is useful precisely because of the coupling of presentation and >>>programming facilities. There is little or no point in using JSP if the >>>programming constructs it offers (essentially tags and the Java >> > language) > >>>are left aside. The web has become a true application development >> > platform > >>>because of such technologies. And when it comes to application >> > development, > >>>the term "presentation" seems a bit of a misnomer - it actually refers >> > to > >>>true UI programming. In that context, I have yet to see a "web designer" >>>writing JSPs that is not familiar with programming in one language or >>>another. The so called "web designer" is often quite familiar with the >>>business logic of the application also, because he/she is doing actual >>>programming on top of it. I see a web designer as a person how really >> > does > >>>not know how to write an "if" statement in any language, but that's >> > another > >>>discussion. Even large, page-level MVC (i.e. with central controller >>>servlet) projects have JSPs with quite a bit of programming code in >> > them. In > >>>short, at least in my experience, this presentation only layer where >> > data is > >>>only formatted to look nice is a myth. Or where it is not a myth, the >> > high > >>>decoupling is somewhat artificial and creates an unnecessary complexity >> > at > >>>least as difficult to maintain as the mixture of programming and >>>presentation constructs in a single file. It very much depends on the >>>application at hand, but quite often maintenance is easy not so much >> > when > >>>you have n layers of abstractions, but when the code is short (but not >> > to > >>>short), clean and readable, when decisions are made in a single place >> > (and > >>>the right place) and the overall structure of an application is >> > consistent > >>>and intuitive. It takes good programmers to do that, not lack of >>>functionality that may be misused. So even if we leave out the prototype >> > and > >>>very small apps cases, I don't think JSTL SQL and XML can hurt quality >> > of > >>>code. On the opposite, they will improve it for people directly >> > accessing > >>>DBs and doing XML parsing/tranforms from the JSPs anyway. >>> >>>Cheers, >>>Boris >>> >>>----------------------------------------- >>>Borislav Iordanov >>>Kobrix Software http://www.kobrix.com >>> >>>----- Original Message ----- >>>From: "Jayson Falkner" <[EMAIL PROTECTED]> >>>To: "Tag Libraries Users List" <[EMAIL PROTECTED]> >>>Sent: Tuesday, June 11, 2002 1:15 PM >>>Subject: Re: JSTL XML, URL, and SQL tags, does anyone use them? >>> >>> >>> >>> >>>>Thank James, this is some good feedback. >>>> >>>>James Strachan wrote: >>>> >>>> >>>>>>I agree. Do you think the JSTL SQL and XML tags hurt future quality of >>>>>>code? >>>>> >>>>> >>>>>Huh? >>>> >>>>Just meaning maintenance as you answered later on in the e-mail. >>>> >>>> >>>> >>>>>>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.. >>> >>> >>>>Right, the concept it clear and I agree. What would be helpful is >>>>personally have the SQL and XML tags helped you? Have you found them >>>>handy when working on JSP/Servlet related projects, if so what type of a >>>>project was it and how much time to you think it saved? >>>> >>>> >>>> >>>>>>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? >>>> >>>>I'm not suggesting page designers are to be dispensed with, but I do >>>>think someone who cares about XML and SQL related to the web app should >>>>be more then a page designer, e.g. they should understand Java. If you >>>>have people working on a project that are only page designers they >>>>should only focus on the page, not caring about where the dynamic >>>>content comes from or how it got there. >>>> >>>>Do you think it is a common to have a page designer fluent in HTML/XHTML >>>>and some client-side scripting also understand SQL or XML enough to be >>>>able to easily use the JSTL XML and SQL related tags? >>>> >>>>Cheers, >>>> >>>>Jayson Falkner >>>>[EMAIL PROTECTED] >>>> >>>> >>>>-- >>>>To unsubscribe, e-mail: >>> >>><mailto:[EMAIL PROTECTED]> >>> >>>>For additional commands, e-mail: >>> >>><mailto:[EMAIL PROTECTED]> >>> >>> >>> >>>-- >>>To unsubscribe, e-mail: >> > <mailto:[EMAIL PROTECTED]> > >>>For additional commands, e-mail: >> > <mailto:[EMAIL PROTECTED]> > >>> >>> >> >> >>-- >>To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > >> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > >
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
