No pain no big bucks. Where'd you spend it Eddie? ;-) The "think" part is the part I like. I have never been enamored with the typing part of coding. The really powerful tools are the province of those who command some $$$$$$$. That is a GOOD reason to like the "think" part? LOL I also love an application that just purrs the way XSLT does when done well. Lovely!
Jack On Tue, 16 Nov 2004 22:10:31 -0600, Eddie Bush <[EMAIL PROTECTED]> wrote: > There are obvious benefits to using XSLT as cited earlier (taking one input > to multiple outputs - ie. different clients). I personally think that > debugging the transformations is a major pain. My primary exposure to this > has been through a a couple of ASP/COM apps at work. To me, the pages are > just entirely too "think". They definitely could have leveraged COM better. > Still, the problems I had debugging the XML/XSLT ... would never exist in > the MVC Java app :-) > > I do see the power in this approach though ... > > > > Peace All ;-) > > Eddie > > ----- Original Message ----- > From: "Bill Siggelkow" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, November 16, 2004 9:55 AM > Subject: Re: talking about paradigms > > > 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 > > > > 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 > >>>>> > >>>>> > >>>>>--------------------------------------------------------------------- > >>>>>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] > >>> > >>> > >> > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --- > avast! Antivirus: Outbound message clean. > Virus Database (VPS): 0447-0, 11/15/2004 > Tested on: 11/16/2004 10:10:32 PM > > > avast! - copyright (c) 2000-2004 ALWIL Software. > http://www.avast.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
