Why not use the i18n tags in the JSTL? Make use of Java's wonderful i18n module.
-----Original Message----- From: Taylor, Jason [mailto:[EMAIL PROTECTED]] Sent: 11 October 2002 16:32 To: 'Struts Developers List' Subject: RE: Basic Issues 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]> *************************************************************************** This communication (including any attachments) contains confidential information. If you are not the intended recipient and you have received this communication in error, you should destroy it without copying, disclosing or otherwise using its contents. Please notify the sender immediately of the error. Internet communications are not necessarily secure and may be intercepted or changed after they are sent. Abbey National Treasury Services plc does not accept liability for any loss you may suffer as a result of interception or any liability for such changes. If you wish to confirm the origin or content of this communication, please contact the sender by using an alternative means of communication. This communication does not create or modify any contract and, unless otherwise stated, is not intended to be contractually binding. Abbey National Treasury Services plc. Registered Office: Abbey National House, 2 Triton Square, Regents Place, London NW1 3AN. Registered in England under Company Registration Number: 2338548. Regulated by the Financial Services Authority (FSA). *************************************************************************** -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
