IMHO, you have to be very careful with the XML/XSLT solution.
I worked on a project about two years ago (probably closer to three now actually) where we had as a requirement the ability to deliver a fairly simple web app via normal HTML, but also WAP-based browsers, and also the ability to download data lists as CSVs, and also have the ability to download some data to clients in XML but in a format of their choosing. In essence, the app itself never changed, nor did the "data" it spit out, but the delivery mechanism was highly varied and had to be flexible in the future too.
The solution we decided upon was to have the back end generate only XML, then use XSLT to transform it to suite the particular client (really a fairly obvious approach!). To this day it works fantastically well, and we continually add new delivery formats to the system for new clients, all using the exact same data.
While it does work great, it IS immensely complicated. XSLT is not a simple tool to use, by and large. When we did it we were coding it by hand, there are of course tools to help you along today. Even still, I cringe every time a junior developer calls me because they are trying to create a new delivery format and I have to remember all the intricacies of this thing. I mean, I hate remembering details of things I coded that I haven't touched in a long while in general, but this app in particular is painful to try and recall, and it's because of the overall complexity of XSLT. Power and flexibility always come at costs in this line of work, and XML/XSLT-based solutions I think are a prime example of this.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
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]
