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]>
