Thanks for pointing out that the JSTL has a similar feature-- I've been trying to get the front-end guys around here interested in JSTL, maybe this will help. Turn off JS? LOL ;)
My point was that the back-end developer should be in the business of providing a stable framework of data that the front-end developer can utilize in his scripting language when he can't find what he needs in the taglibs (which will happen sometime, no matter how good the JSTL is). Keeping apprised of the tools available in the taglibs is the front-end developer's job-- I just make sure he's got all the data he needs. It's worked out well for me and the front-end guys I work with, and what I know sometimes doesn't work well is the strategy of classifying just about everything as "business logic" which must be provided by the back-end developer. That's all... -JT -----Original Message----- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 8:38 AM To: [EMAIL PROTECTED] Subject: RE: Basic Issues Struts does not need a date formatting tag because the JSTL already has one. It's called (surprise) formatDate. What happens to your js date formatting when I turn off javascript? Dave >From: "Taylor, Jason" <[EMAIL PROTECTED]> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> >To: "'Struts Developers List'" <[EMAIL PROTECTED]> >Subject: RE: Basic Issues >Date: Fri, 11 Oct 2002 08:32:27 -0700 > >I disagree with the idea that JavaBeans should handle date formats, and I >think it is a good example of mixing view and model components-- of >confusing the roles of front- and back-end developers. > >Date formats and the like are better left to the front-end developer since >they are UI elements and are subject to change anytime the UI changes. The >back-end developer should supply all the data required to manipulate the >format in a convenient and comprehensive way, but the actual format is a >stylistic setting that should be controlled by the front-end developer. > >If you don't believe me, think of what happens every day: a client looks at >a table of data, says "hey we need to know (or don't need to know) what >time >the thing happened", and that along with a list of other nits goes back to >the back-end developer who complains that they should've gotten "solid >requirements" before starting the project and then makes a code change to >add "HH:MI pm" with the leading zero removed before 10:00 because it "looks >funny". Maybe others like coding ad hoc date routines, but in that >situation I tell my front-end guys to pick up a JS book and figure out what >to do with the date beans I pass them. > >The whole idea of Struts is to create logical separations between the front >end, which is UI-centric, and the back end, which is data-centric. The >role >of the back-end developer is to insulate the front-end developer from the >complexities of managing data, and the front-end developer insulates the >back-end developer from the complexities of managing the UI. Just as a >front-end developer shouldn't have to worry about miscellaneous changes the >DB admin/architect makes, the back-end developer shouldn't be pulled in >every time the UI changes, or every time the same application is reskinned. > >Date formatting should *definitely* be handled in a front-end script or >transformation, unless there is some solid requirement (like legal syntax) >that it *always* has to be the same-- in which case it's not really a date, >but more like a code. The Javascript Date object is pretty robust I hear, >and there are people out there who are JS artists that can help you if >you're having trouble. Struts tags have some deficiencies that it would be >good for front-end developers to identify, but by and large there are lots >of times where you need to have a front-end scripting language handle >things. JavaBeans can't do everything, neither can taglibs, nor >Javascript-- just use the right tool for the right job. > >-JT > >-----Original Message----- >From: Ted Husted [mailto:[EMAIL PROTECTED]] >Sent: Friday, October 11, 2002 6:30 AM >To: Struts Developers List >Subject: Re: Basic Issues > > >I would suggest that this type of functionality be placed in a JavaBean >rather than a tag. > >I idea is that it is really not up to the page to decide in what format >a date is displayed. That's really a business requirement that you would >want to enforce on the Web presentation tier, or a PDF presentation >tier, or in some type of Word Processing report. > >The page needs to decide whether the date property is displayed between ><TD> elements or <LI> elements, and so forth. But there's no reason for >the page to worry about formatting the date. Only how to markup the date >property for a HTML page. > >The tags provide the basic funcationality you need to expose JavaBean >properties to the page but are not intended to be used as part of a >Model 1 design where business logic and presentation markup are handled >as a single task. > >So, I would take whatever code you might otherwise put in Javascript or >a custom tag and make it part of the getDate() (or getDateDisplay()) >method on the JavaBean. Ideally, all the actual formatting should take >place in a business tier bean, and then the formatted string passed to >the ActionForm, ready to go. > >-T. > >edgar wrote: > > > I have found that the basic functionality of the tag library classes to > > be limited (I assume by design) , and I have found myself writing > > replacement tags for quite a number of things. I.E. In order to have a > > relatively simple date interface (avoid very complex javascript in every > > jsp) the logical place to put such code is in the tag libraries. > > > > Question 1: Am I missing something and is this code is actually being > > produced somewhere else? > > > > Question 2: Is there a desire for such code to be included in Struts or > > does this bring the user interface too much into the picture? > > > > Question 3: How complex will life be when moving from version to version > > of Struts if I continue to 'roll my own'? > > > > Thanks > > > > Edgar Dollin > > > > > > -- > > To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > > > > > >-- >Ted Husted, Husted dot Com, Fairport NY US >co-author, Java Web Development with Struts >Order it today: ><http://husted.com/struts/book.html> > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
