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]
