But what about having another component that can be specified as an attribute to an input tag as the converters I mentioned in a previous post? This is more like what Jason is talking about. What's in the JSTL is probably useful for display only.
The converter concept can be made useful bi-directional in/out -Daniel -----Original Message----- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 11: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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
