Re: [Springframework-developer] FieldError and nested properties

[Rob R. <rob...@ur...>]

Wow, how about that for timing. That's perfect, I'm getting the
1.0.1 release now.=20

Thanks,
Rob

---- On Thu, 22 Apr 2004,
=3D?iso-8859-1?Q?j=3DFCrgen_h=3DF6ller_=3D5Bwerk3AT=3D5D?=3D
(jue...@we...) wrote:

> In Spring 1.0.1 which has been just released a couple of hours
ago, you'll find a
> MessageCodesResolver interface with a
DefaultMessageCodesResolver implementation. DataBinder has a
> setMessageCodesResolver method that allows to specify a custom
resolver.
>=20
> FieldError no longer generates its own error codes; this is
delegated to the MessageCodesResolver.
> Your requirement to generate additional codes could be a
candidate for a custom MessageCodesResolver
> implementation.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
>
[mailto:spr...@li...]On
Behalf
> Of Rob Rudin
> Sent: Thursday, April 22, 2004 2:52 PM
> To: Choy Rim
> Subject: [Springframework-developer] FieldError and nested
properties
>=20
>=20
> Got a question about FieldError and validation. I know it's
> created by DataBinder, and the ctor for FieldError creates
three
> codes for message lookup, which is nice. However, we'd like
for
> additional codes to be generated in the case of nested
> properties.
>=20
> Our problem is that we have several different UI's where
> coordinate information is entered, but the coordinate
properties
> are at different nested paths, so we can't have something like
> "typeMismatch.latitude.degrees". Instead, we'd need to do
> "typeMismatch.someObject.someProperty.latitude.degrees" and so
> on for all of the different objects that have coordinate
> properties.=20
>=20
> We're going to write a NestedFieldError class that looks for
> nested properties in the "field" value when a FieldError is
> constructed. This will allow us to have a generic
> "typeMismatch.latitude.degrees", or even a
> "typeMismatch.degrees" error message, which will be very nice.
> Unfortunately, this will involve extending DataBinder as well
so
> that it uses our NestedFieldError class. We'll have to
override
> the bind method.
>=20
> I'm wondering - has anyone else needed this functionality?
Would
> it be too special-case to add it to the Spring validation
> package? What could at least be done is to factor out how
> DataBinder creates instances of FieldError - maybe toss it
into
> a protected method so that a subclass could easily override
it,
> or just refactor it into something pluggable and use the
current
> approach as the default.
>=20
> Rob
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and
CEO of
> GenToo technologies. Learn everything from fundamentals to
system
>
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and
CEO of
> GenToo technologies. Learn everything from fundamentals to
system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20