Nasty stuff! Pain to maintain!
My team just gained a few folks the other day - part of us are hoping to re-write the old ASP/COM stuff in Java/JSP using Struts :-)
Oh happy day!
:-D
----- Original Message ----- From: "Dakota Jack" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 16, 2004 10:59 PM
Subject: Re: talking about paradigms
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]
--- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0447-0, 11/15/2004 Tested on: 11/16/2004 11:00:57 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]
