I am using 0% JSTL right now so I can't introduce it now on this project unfortunately, too last minute. I guess the equivalent would be to write it out using the struts bean:write and manually write the INPUT html.
Thanks for the feedback...djsuarez -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 1:59 PM To: Struts Users Mailing List Subject: RE: textbox format date & i18n date handling I don't have time for a long response but have you considered the fmt:formatDate tag of JSTL? "David Suarez" <[EMAIL PROTECTED] corps.org> To <[EMAIL PROTECTED]> 10/05/2004 02:54 cc PM Subject RE: textbox format date & i18n date Please respond to handling "Struts Users Mailing List" <[EMAIL PROTECTED] he.org> Thanks for the quick responses! Is there anything more generic that can be done? Till now I have been setting the fields directly into the "real" bean classes so to do the below I would need to replicate the properties on the form and then move them over to the real bean classes afterwards (when I know the Locale). The custom DateConverter seems to be able to do this work behind-the-scenes for me in the little testing that I've done to set the date correctly in a deep been tree but I'd have to always use the same date format in this case because the locale can not be set in a per-request scope for beanutils. So the question is: Which is the more ideal of the two? Seems like there are two approaches: 1) Use one date format in the app and have the javascript handle presentation of dates for i18n? + Can do a property writes directly into Dates without having to later convert it from a String - javascript involved on the html view 2) Convert the Dates to Strings and then manually create proxies for each Date that would handle the localization + no javascript - Need to create redundant properties to allow the translation to occur for deep seated beans I guess for #2 I can create a postProcess(Locale) method to my base form and ensure it's always called in my base action so I don't have to ensure that it's in every individual action but I'd still need to write all the duplicate properties in my form. I'd appreciate your feedback. Any ideas on getting the Date to format correctly in a textbox using a formatKey like the bean:write tag has? Or do I need to manually write out the INPUT tag html and in the value section use the bean:write tag which does allow to format the date? Maybe that would be a nice enhancement to html:text to avoid having to do the manual write. For me, #1 seems like it may be less work right now (don't have to duplicate properties) but maybe there's a bigger flaw there that I haven't seen if I go forward with that approach. Thoughts? Unfortunately I need to pick a way by end of day today and go with it so I really do appreciate the fast responses! Thanks again!...djsuarez ~~~ Content-Type: text/plain; charset="iso-8859-1" Subject: textbox format date & i18n date handling Date: Tue, 5 Oct 2004 20:07:54 +0200 From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Hi, Tim. This is right. But also make sure the locale dependent date parsing is done in the action class then, since - I'm not sure whether the validator package can cover localized dateformats - only the controller classes know about the user's locale and therefore the dateformat that should be used Hiran ----------------------------------------- Hiran Chaudhuri SAG Systemhaus GmbH Elsenheimer Straße 11 80867 München Phone +49-89-54 74 21 34 Fax +49-89-54 74 21 99 > -----Original Message----- > From: Slattery, Tim - BLS [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 5. Oktober 2004 19:02 > To: 'Struts Users Mailing List' > Subject: RE: textbox format date & i18n date handling > > > 1) I have a java.util.Date field that needs to be displayed in a > > textbox. > > IMHO the way to do this is to have a read/write property in > your bean that delivers and accepts a string. Both can use > SimpleDateFormat class to convert between the string and the > underling Date class. > > -- > Tim Slattery > [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] --------------------------------------------------------------------- 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]
