Having the locale stuff is vital for some projects (especially in canada). JSF is on the horizon as well, but I don't know if it impacts formdef or not. I plan on playing with this one a bit.
sandeep -----Original Message----- From: Joe Hertz [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 1:14 PM To: 'Struts Users Mailing List' Subject: RE: Date validator and I18N Sandeep, That's more or less what I found as well. I gave up eons before you did though. Glad it wasn't just me. My "previous solution" was an utter kludge to BeanUtils.copyProperties and copyProperty. I created something called DateBeanUtils that had had both of these methods, with a DateFormat parameter added to them. It's utterly hideous but it works. Date->Anything first formats the Date into a String and proceeds as if it was a String all along. String->Date is handled directly and the only ->Date conversion that's handled at all, since Anything->Date gets is typically ignored by BeanUtils. Like I said, hideous. But it's interesting you should mention FormDef, because THAT's what I am using now, and I'm incredibly happy with it. Nevermind I don't need to to define many of the DynaBeans I otherwise would have, but it's current handling of Dates is loads better than anything else for my needs (I no longer have to deal with the date handling at all in my actions!!). It looks to be *almost* there for i18n (currently you can specify date formats to use as a default, and for various properties, but there's no way to specify a DateFormat to use per Locale. Curiously though the infrastructure in the code looks to be all in place to support this, so...Hubert Rabago and I have been talking, and to make a long story short, it looks like I'll be helping him out on this plugin. (This is very very early in the going here) I've already made some changes locally that will make it more usable for those using Hibernate and nested form beans (Me! Me! Me!). If I have my druthers, this issue will be getting soooo put to bed, I can tell you that. -Joe > -----Original Message----- > From: Takhar, Sandeep [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 14, 2004 7:39 AM > To: Struts Users Mailing List > Subject: RE: Date validator and I18N > > > I have coded LocaleBeanUtils, but had to subclass the whole > thing since it seems like it is a version behind. In the > subclass I changed a couple of lines in some methods to make > it work with some converters I created. > > Someone else has a solution that I haven't had time to look > at yet: http://www.rabago.net/struts/formdef that talks about > formatting. > > I had to have custom converters so the populate that struts > uses from BeanUtils removes some formatting as well so we > don't have to deal with this in the action. > > sandeep > > -----Original Message----- > From: Joe Hertz [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 13, 2004 10:51 PM > To: 'Struts Users Mailing List' > Subject: RE: Date validator and I18N > > > Yes, you can get the dates validated this way, but isn't > actually the tough hurdle. > > You've got Date objects being stored some place. > > You'll need them displayed as Strings in your Action Form. > You'll need them formatted by Locale. > > You'll want want the Strings converted back to Dates in the > processing Action. You'll need them parsed by Locale. > > Unless someone can offer a better explanation of the usage of > LocaleBeanUtils than I can, this may prove to be quite the > annoying little repeated task. > > -Joe > > > -----Original Message----- > > From: Jeff Caesar [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, April 13, 2004 7:04 PM > > To: Struts Users Mailing List > > Subject: RE: Date validator and I18N > > > > > > I haven't personally tried doing this, but according to the > > doc you can specify language/country/variant on the formset > > when defining your validation so that the validator will > > choose the best one available for the given user's locale. > > > > From the validator DTD: > > <!-- > > The "formset" element defines a set of forms for a > > locale. Formsets for > > specific locales can override only those fields that > change. The > > localization is properly scoped, so that a formset can > > override just the > > language, or just the country, or both. > > --> > > <!ELEMENT formset (constant*, form+)> > > <!ATTLIST formset language CDATA #IMPLIED> > > <!ATTLIST formset country CDATA #IMPLIED> > > <!ATTLIST formset variant CDATA #IMPLIED> > > > > So you would want to create four different <formset> defs > > (one for each of your languages plus a default) for the form. > > > > Jeff > > > > -----Original Message----- > > From: Stjepan Brbot [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, April 13, 2004 3:07 PM > > To: [EMAIL PROTECTED] > > Subject: Date validator and I18N > > > > > > In my web application I deal with three languages (Croatian, > > German and English). Application does have forms allowing > > user to input a date value. When english locale is active > > user must have the ability to insert date in english date > > format (mm/dd/yyyy), also croatian and german users must have > > the ability to insert dates in their own date format > > (dd.mm.yyyy). How to define a validation for such a > > situation? In mask for date validation (in validation.xml) I > > can define only one date format pattern! > > > > Stjepan Brbot > > > > > > > --------------------------------------------------------------------- > > 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] > > > --------------------------------------------------------------------- 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]
