Joe, see below
Joe Germuska schrieb: > At 7:54 AM +0200 3/30/06, <[EMAIL PROTECTED]> wrote: > >> Hi >> >> And now we have come full circle: You suggest to use Strings in forms, >> but if you do - do not blame Struts? >> >> So, lets stick with Struts, and use Double and Floats etc. We know >> that this does not work because of RequestUtils. So my statement >> stills stands: Struts does not do I18N properly. > > > If you use Strings in forms, then converting them to anything else is > nothing Struts has anything to do with -- RequestUtils populates > ActionForms, not your model objects. > > That said, I think this demonstrates the inaccuracy of Don's assertion > about how seriously Struts has always taken internationalization -- > clearly, no one has pressed the issue, but the implementation is > incomplete. Having ActionForms as objects implies that it's OK to use > non-String values, regardless of best practices, and those non-String > values aren't handled smoothly in some situations. > Just for my understanding: could it be that this is more about l10n than i18n? When it comes to validation/conversion, mostly l10n is an issue... > Martin makes a good point -- even my suggestion about how to populate > non-string properties of ActionForms doesn't address displaying them -- > the form tags don't know enough to apply any locale sensitive formatting > when refilling a field. This might be something which could be worked > out, but it makes this a bigger issue. > > I think it would be great to integrate FormDef into Struts. > > Can anyone explain how WebWork handles this? I've read about the > advanced conversion services, which look good, but I haven't quite seen > how it handles re-displaying values in the case of conversion errors, > and I've run out of time to trace through the code to figure it out for > myself at the moment. > In WebWork, validation and conversion errors are available in your valueStack after the needed mechanisms took place. Typically, the ui themed widgets will then feel responsible for bringing the messages to front. The standard ui themes provided with distro will render any error message beside the input field it belongs to, with a changeable css layout. Standard validation will validate the submitted form and redirect to redisplay the form view with rendered error messages, in a typical request-response manner. There is also the option to use client side validation (pure js) and AJAX validation, both leading to on-the-fly validation and error diplaying on onblur-events of your inputs. To activate eg. AJAX validation, you just need to use the ajax ui theme, and you're basically done. References: http://wiki.opensymphony.com/display/WW/Validation http://wiki.opensymphony.com/display/WW/Type+Conversion http://wiki.opensymphony.com/display/WW/Internationalization Regards, Rene > Joe > > > >> Hermod >> -- Rene Gielen | http://it-neering.net/ Aachen | PGP-ID: BECB785A Germany | gielen at it-neering.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
