> -----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]
