+1. I have to agree with Daniel. JSTL has allowed me to move a lot of view formatting code outside of my page prep tasks.
In J2EE, .jsp pages are ViewComponents and custom tags are ViewHelpers. I think that JSTL gives you enought rope to hang yourself with as well, especially with the <sql: ../>. But I understand the business/marketing motivation behind them...CFML competition. I mean, look at CFML applications, the use of the database access ViewHelper is pervasive. But their business model is to enable page authors to easily create business applications using a tag based model. I'm sure many of you already are aware that there are large numbers of enterprise applications written entirely in CFML. Personally, I would never want to develop nor maintain such applications. Anyhow, I digress... I think the point is that the ViewHelpers used with regard for best practices help move view logic into the ViewComponents and out of the controller and that disciplined use of such technologies can provide better architectural separation. robert > -----Original Message----- > From: Daniel Perry [mailto:[EMAIL PROTECTED] > Sent: Monday, November 15, 2004 9:14 AM > To: Struts Users Mailing List > Subject: RE: talking about paradigms > > > 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]
