|
From: <jue...@we...> - 2004-04-22 13:17:41
|
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. 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. Juergen -----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 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. 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 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. 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. Rob ------------------------------------------------------- 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 |
|
From: Rob R. <rob...@ur...> - 2004-04-22 14:27:10
|
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 |
