Dakota,
You are assessment is correct -- this was an app that I was involved with a few years back; I am not actively working with it now. The architecture of the system used a hand-rolled front controller to access pluggable "actions"; these "actions" accessed EJBs, then marshalled the returned object(s) into XML, adding in the "presentation-enabling" data.
By the way, in the recent past I played around with stxx (http://stxx.sourceforge.net). If I wanted to go the Struts/XSLT route I would certaninly consider this framework. I haven't used StrutsCX.
-Bill Siggelkow
Dakota Jack wrote:
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
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
