We use it all here. We had a big meeting and all agreed on one thing. Views tend not to be too reusable so... Use whatever medium you can to get something up fast. That usually means it depends on the type of data comming in. Here we get some data as XML (we do digial receipts and there is an XML standard). That data, we use XSLT. We have a lot of data also in a database. It is much faster to just code up some jdbc, put it in a value object (to allow for business processing) and then use struts tags to pump em out on the JSP. Basically how we got the data dictated the view. I've found XSLT to be 'wordy'. I think its just as easy to write another damned JSP and parse the Java Objects up there as it is to create another XSL page and use the same JSP. I consider views to be relatively non-reusable so time to market is my big concern. (I use lots of JSP tags and programs like struts to create the reusable aspects of the view). My 5 c Mike
----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, September 11, 2002 1:14 PM Subject: RE: Additional <logic:iterate> helper tags wanted > > Wow, good rhubarb here hiding under a misleading subject title ;-). > > I think XSLT based presentation architecture vs. JSP is highly interesting, > Donald, but I don't agree with many of your points. > > To me, the big strength of the XSLT approach would be the ability to > transform the model into a variety of views (not just one html view). I > know that I can create a JSP application that is layered well, keeping only > things like variable output and iteration in the JSPs and all other data > preparation work back in other Java layers. Believe me, programmers can > hash up any architecture. I can make a mess with XSLT just as readily as I > can with JSP. > > The strength of the JSP approach is it is faster to get going, particularly > if I'm starting with HTML prototypes of an application. If I only have one > transform (model data to one html), why do a lot of extra work? > > Jim Weaver > Software Developer - ThoughtWorks > > > > "Donald Ball" > <[EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] > om> cc: > Subject: RE: Additional <logic:iterate> helper tags wanted > 09/11/2002 09:36 > AM > Please respond to > "Struts Users > Mailing List" > > > > > > > On 9/11/2002 at 9:17 AM Craig R. McClanahan wrote: > > >At the high level: The JSTL tags are nice. The JSTL expression language > >(now adopted by JSP 2.0) is powerful enough to completely eliminate the > >need for scriptlets and runtime expressions in JSP pages. JSP 2.0 page > >compilers will also let you use EL expressions directly in template text, > >not just in tag attributes. > > So you _have_ rewritten Java in an xml-like language. :) except that you > break xml rules by allowing things like jsp elements in tag attributes. > > >At the low level: Given that you have to use *some* syntax for this > >stuff, picking a syntax that lots of people are already familiar with > >seems a lot smarter than making one up and having to teach it to all your > >page authors :-). > > I guess that's where we disagree. I don't think you have to have a > programming language for doing your view pages. I think you should keep the > programming logic back in your Java code where it belongs and the language > which does the transformation from model to view should not let you do > anything except transform input tree into output tree. > > I guess what I'm trying to point out is this: it seems to me that with JSTL > and its friends, JSP pages now share the drawbacks of XSLT (namely verbose > syntax) without gaining any of its benefits (side-effect free processing > model forces logic to stay back in the controller, strict adherence to xml > syntax makes it easy to validate xslt stylesheets as well as their output). > > - donald > > > -- > 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]>
