Now, now, Peter, you can't quite say that since you met me at the Struts user group at JavaOne. :) I've used stxx, an XML transformation Struts extension, for a production app and have been pretty happy with it. Performance is good, as long as one has memory resources available. The stylesheets can be cached when compiled, and using a decorator tool like sitemesh, the pages your XSL generates are quite small. The big disadvantage, as I see it, is it requires XSLT knowledge, which most web developers don't have. I probably wouldn't recommend it for apps that don't have their data in XML and don't need multiple views.
Don On Tue, 16 Nov 2004 17:59:48 -0000, Pilgrim, Peter <[EMAIL PROTECTED]> wrote: > > > > > > -----Original Message----- > > From: Dakota Jack [mailto:[EMAIL PROTECTED] > > Sent: 16 November 2004 17:46 > > To: Struts Users Mailing List > > Subject: Re: talking about paradigms > > > > > > Bill, > > > > Sounds like you don't need what XSLT provides. The important thing, I > > think, is to make sure that the framework leaves that option open for > > those that want it and does not require that option to those who do > > not want it. I am not privy to the details of your application, of > > course, but adding code to the controller to assist in the > > presentation seems to me to indicate a serious design flaw. That > > simply is not the business of the control layer, if you are using the > > control layer in an MVC pattern. Part of your bad experience with > > XSLT sounds like it is not related to the view issues but to some > > confusion in the architecture of the application? Not knowing much > > about the details, this is probably a harsh assessment, but it is what > > I would intuitively expect to find. My head keeps saying "What the > > heck is the controller doing generating XML?". The controller should > > be deciding what to do about user input given whatever strategy the > > application has adopted. > > > > Jack > > > > > > On Tue, 16 Nov 2004 10:55:52 -0500, Bill Siggelkow > > <[EMAIL PROTECTED]> wrote: > > > Jack, > > > > > > What I found was that alot of Java code to generate XML > > (using DOM API) > > > had to be added in the controller layer to facilitate the view; for > > > example, an odd/even indicator was added just to facilitate > > striping on > > > the generated HTML table; to me, this seems downright > > overkill for some > > > feature that is purely presentation (granted, the > > developers could have > > > avoided this through better use of XSLT). > > > > > > Personally, I've never warmed to the idea of using the > > XML/XSLT approach > > > when the data is already in the form of a Java object; it just seems > > > like an extra step that doesn't buy me a whole lot. > > > > > > -Bill Siggelkow > > > > > I have never come across anyone in a face-to-face who uses > the XML/XSLT approach at least with Struts. I met a straight-up > Cocoon fantastic a few years ago, but by then he was moving > away from XSLT to proprietary web application framework on > some app server. > > This biggest problem of the XML is the transformation phase, > and it sounds like that the original tabular XML was not > augmented with attributes to say this is hint "render > this row in green" and now "render that next row with > white background". Then an XSLT can be written to easily > transform things around (or not as the case may be). > > I think XML/XSLT pipeline is useful for static stuff that > mostly does not change frequently. How did you find the > XSLT transformation performance on your project? > Did you cache the XSLT results somewhere? > > > > > > > > > > > > Dakota Jack wrote: > > > > Yet, Bill, that is not the problem of the XML/XSLT model, > > is it? That > > > > model is really cool in separating the model from the > > view. Indeed, > > > > that model is great at separating the view data from the view > > > > presentation. I am not sure what the app you worked on did, but I > > > > think the idea behind the XML/XSLT model is terrific. > > Essentially, as > > > > I undestand it, the XML is sent and is in some "language" that the > > > > client may or may not understand. So, the XSLT contains a crash > > > > course in the language. That is way cool from my perspective. > > > > > > > > Jack > > > > > > > > P.S. I really liked Eddie Bush's Jedi Knight take on development. > > > > That is quite true in my experience. Usually these > > metaphors break > > > > down pretty fast. That one held up pretty good. > > Probably due to the > > > > master Campbell being behind the mythology of Star Wars. > > > > > > > > > > > > On Mon, 15 Nov 2004 09:43:19 -0500, Bill Siggelkow > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > >>Sorry, I haven't been following this thread, but I tend > > to agree with > > > >>you. I worked on an app that used XML/XSLT to achieve > > "purity" -- and > > > >>what resulted was a lot of this "view helper" data coded > > into the "pure" > > > >>XML document; defeating the premise behind separation of > > the model and view. > > > >> > > > >>-Bill Siggelkow > > > >> > > > >> > > > >> > > > >>Daniel Perry wrote: > > > >> > > > >>>I think the idea that MVC architecture should have a > > 'dumb view' is totally > > > >>>wrong. The view should be as smart as possible. > > > >>> > > > >>>MVC should separate the M, V and C. With a really smart > > view you dont have > > > >>>to do any preparation for the view in the controller. > > If you have a dumb > > > >>>view then you have to prepare the data in the > > model/controller so that the > > > >>>view can cope with it. Surely this is wrong as you are > > doing view > > > >>>processing outside of the view. Personally i think ALL > > view processing > > > >>>should be done in the view: the view code (be it jsps, > > java, xml/xsl, etc) > > > >>>should take model data, and produce a view of that data > > - and it should be > > > >>>flexible. > > > >>> > > > >>>The problem with a smarter (or better worded: more > > capable) view is that > > > >>>people start doing things in the view which shouldnt be > > done there, such as > > > >>>database access. I dont think this is down to a problem > > with the view > > > >>>technology, just a lack of education on the users part. > > Arguing that the > > > >>>view should dumbed down to stop this problem arising is > > like saying that > > > >>>cars should only be able to do 70mph because that's all > > they can legally do. > > > >>> > > > >>>For example, a poject i am responsible has a lot of code > > in the model beans > > > >>>that was put there pre jstl for formatting things like > > dates, or text. So > > > >>>you have getStartDate() which returns a date, and > > getFormattedStartDate() > > > >>>which returns a formatted string. This code should be > > in the view as it is > > > >>>purely for view purposes, but i made the decision to > > bodge it into the model > > > >>>as it was nicer than using java code in the jsps. There > > are various other > > > >>>methods - such as retrieving chunks of text with \n into > > <br>, which can now > > > >>>mostly be handled with jstl. > > > >>> > > > >>>Daniel. > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>-----Original Message----- > > > >>>>From: Rosenberg, Leon [mailto:[EMAIL PROTECTED] > > > >>>>Sent: 15 November 2004 13:44 > > > >>>>To: Struts Users Mailing List > > > >>>>Subject: AW: talking about paradigms > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>No, but what about > > > >>>>>> > > > >>>>>><c:out value="${library.books[25].page[5].title}" /> ? > > > >>>>>>(not sure about the syntax). > > > >>>>> > > > >>>>>whats the problem? > > > >>>>>MVC usually allows 'read-only access to model' for the view > > > >>>>>Also the question is, what you expose to the view. > > > >>>>>If you are afraid that somebody will misuse the > > library entries - > > > >>>> > > > >>>>don't > > > >>>> > > > >>>> > > > >>>>>expose them. > > > >>>>>I suppose MVC was the reason for JSP EL not to allow > > arbitrary method > > > >>>>>invocations. But I'd love to have such anyway ;) > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>... > > > >>>>>>And what about database access tags? > > > >>>>> > > > >>>>>You mean the jstl tags? They are there for quick and dirty. > > > >>>>>If you don't change anything in the database though, > > it still okay to > > > >>>> > > > >>>>MVC. > > > >>>> > > > >>>> > > > >>>>>If you don't want it, don't expose your database in > > the first place ;) > > > >>>>> > > > >>>>> > > > >>>> > > > >>>>The problem is, that if you give a user the possibility > > to misuse your > > > >>>>framework - he will. > > > >>>>And EL gives jsps more power than a dumb view should > > have. And if your > > > >>>>view isn't just layouting out the data, but performing > > nearly complex > > > >>>>operations, it's not dumb anymore, and a smart view > > doesn't fit into the > > > >>>>MVC. > > > >>>> > > > >>>>If the user is allowed to break the paradigm he will. > > > >>>>If you have an architecture, which is built on a > > paradigm (and any good > > > >>>>architecture is) you can't allow the developers to > > break the paradigm, > > > >>>>or > > > >>>>the architecture will stop working one day, without > > obvious reasons. > > > >>>>It's probably why there are no pointers in java, even > > pointers adds cool > > > >>>>features to the language. > > > >>>> > > > >>>>Regards > > > >>>>Leon > > > >>>> > > > >>>> > > ==////== > > -- > Peter Pilgrim > Operations/IT - Credit Suisse First Boston, > 10 South Colonnade, London E14 4QJ, United Kingdom > Tel: +44-(0)207-883-4497 > > ============================================================================== > This message is for the sole use of the intended recipient. If you received > this message in error please delete it and notify us. If this message was > misdirected, CSFB does not waive any confidentiality or privilege. CSFB > retains and monitors electronic communications sent through its network. > Instructions transmitted over this system are not binding on CSFB until they > are confirmed by us. Message transmission is not guaranteed to be secure. > ============================================================================== > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
