Menu
▾
▴
springframework-developer
|
From: Seth L. <se...@eh...> - 2004-03-03 23:43:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (putting this reply on list because of some explanation that might others) Keith Donald wrote: | Seth, | | The way I look at it is this: | | The validation rules I want to apply to a domain object are generally very | specific to that domain object. For example, I may have a Pet class, like | in the Pet clinic. I want to validate that all Pet's have a name, all Pet's | have a unique name, and no Pet weighs less than 1 pound. I can either Yes, this is exactly the way Spring works now. It asks you to bind a certain validator to a certain controller class. The way my Attribute Validator works, is you place the validation attributes on the domain object. This way, the domain object has the validation meta data attached to it. All you need to bind is the generic AttributeValidator class to each controller. This way, one validator handles all domain objects (as long as they have the validation rules bound to them, of course :) More and more it sounds like we're coming from two opposite ends. No right or wrong here, just very different. | Or I can just go to my Pet.java source file and see them as source-level | attributes. Right, this is exactly what I do. No need for a resolver now. | commons-attributes? However, that still doesn't cut out the need to lookup | the validator for a bean (aka command in spring-web) in order to kick See above and my code. I should put an example on the web site I put up. That might explain everything. General Explanation: 1 (singleton) AttributeValidator for webapp, implements spring.Validator N controllers N command objects (the beans populated from the form) 1:1 controller:command object 1:1 controller:validator 1:M command object:attributes (validation rules) So the command object has the validation rules in form of attributes. The generic attributevalidator can look into the command object, get the attributes, and do the validation. Hope that helps. Seth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFARmpg5EIB1scRes8RAuGyAJ9VTMEJ8u8Ss+Vj/RtVvWwzyhpJ+ACePtgr HnkBdQsJSdJTWCrBQxsjUh8= =0TbM -----END PGP SIGNATURE----- |
|
From: Keith D. <kd...@cs...> - 2004-03-04 01:02:41
|
I think we're nearing agreement. Your 'AttributesValidator' is = analagous to my 'ValidatorRegistry', except your class has the capability to kick off validation for any command/bean, which is a great idea. This is what I'm proposing: 1. The user creates source-level-metadata describing property validation rules for their various bean classes. 2. Using the spring metadata API, the system auto-generates BeanValidator/PropertyValidator instances (the API we've been discussing with the good abstractions) for each validateable class. So you know = for each bean which properties are to be validated, and which validation = rules apply (and there is nice model for this.) Note: this step could require some Spring configuration to specify which validateable classes to introspect using the metadata API (or we = could do it like you do it, which is lazily introspect every command...either = way works for me...one is more explicit, the other is more flexible.) 3. Once the BeanValidator models are created, individual BeanValidators = are added to the ValidatorRegistry (we might need a better name than 'registry'.) (again this may happen in reverse if we go with on-demand 'validation-rule discovery' like you do now.) 4. The ValidatorRegistry is bound to each controller needing to validate commands. It provides a one stop shop for validating any bean. 5. Each controller simply calls 'registry.validate(command, results)', = and it kicks the validation process off, returning localized results = messages. The algorithm will proceed down through any object graph and validate = nested beans (this opens up some issues: what if a nested bean property is = null?) I can improve performance on this by having separate BeanValidators generated for each bean class, and then link them for the algorithm to traverse...) I can create a Errors adapter for the ValidationResultsCollector interface, since Errors is supported with jsp tags for rendering, right? Is that acceptable? Did I miss anything? =20 Do you prefer 'explicit' (beforehand) configuration of the validateable classes via the metadata API or do you think it is better for that to = happen lazily/implicity when the registry validate(command, results) method is invoked? In the latter case, we would cache the BeanValidator/PropertyValidator references in the registry once we = derive them from the source-metadata resulting in better performance. Keith -----Original Message----- From: Seth Ladd [mailto:se...@eh...]=20 Sent: Wednesday, March 03, 2004 6:30 PM To: Keith Donald; spr...@li... Subject: Re: validation stuff -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (putting this reply on list because of some explanation that might = others) Keith Donald wrote: | Seth, | | The way I look at it is this: | | The validation rules I want to apply to a domain object are generally=20 | very specific to that domain object. For example, I may have a Pet=20 | class, like in the Pet clinic. I want to validate that all Pet's have = | a name, all Pet's | have a unique name, and no Pet weighs less than 1 pound. I can either Yes, this is exactly the way Spring works now. It asks you to bind a certain validator to a certain controller class. The way my Attribute Validator works, is you place the validation = attributes on the domain object. This way, the domain object has the validation = meta data attached to it. All you need to bind is the generic = AttributeValidator class to each controller. This way, one validator handles all domain objects (as long as they have the validation rules bound to them, of = course :) More and more it sounds like we're coming from two opposite ends. No = right or wrong here, just very different. | Or I can just go to my Pet.java source file and see them as=20 | source-level attributes. Right, this is exactly what I do. No need for a resolver now. | commons-attributes? However, that still doesn't cut out the need to lookup | the validator for a bean (aka command in spring-web) in order to kick See above and my code. I should put an example on the web site I put = up. That might explain everything. General Explanation: 1 (singleton) AttributeValidator for webapp, implements spring.Validator = N controllers N command objects (the beans populated from the form) 1:1 controller:command object 1:1 controller:validator 1:M command object:attributes (validation rules) So the command object has the validation rules in form of attributes. = The generic attributevalidator can look into the command object, get the attributes, and do the validation. Hope that helps. Seth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFARmpg5EIB1scRes8RAuGyAJ9VTMEJ8u8Ss+Vj/RtVvWwzyhpJ+ACePtgr HnkBdQsJSdJTWCrBQxsjUh8=3D =3D0TbM -----END PGP SIGNATURE----- |
|
From: Seth L. <se...@eh...> - 2004-03-04 01:30:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | Do you prefer 'explicit' (beforehand) configuration of the validateable | classes via the metadata API or do you think it is better for that to happen | lazily/implicity when the registry validate(command, results) method is | invoked? In the latter case, we would cache the | BeanValidator/PropertyValidator references in the registry once we derive | them from the source-metadata resulting in better performance. That is a great idea. AttributeValidator should cache the validation rules it finds for each command class. Since AttributeValidator will usually be used as a singleton, this might help and cut down on the reflection and attribute discovery. Hopefully I'll be allowed to checkin the current Attribute Validator and we can start flushing it out. I'm not sure what we gain from all those levels of abstraction you have proposed. One of the nice things I like about the current attribute validator is that it doesn't introduce any new classes or interfaces; it tries to remain small and simple. But again, maybe those abstractions should remain only in the RCP project. Once they've proved themselves as useful to a more general validation API (the current Spring one) we can integrate them. I'm not anti-abstractions, I just haven't seen the need for them (yet). I don't want to lose the Errors interface from the validation API. It's integrated into Spring already and other APIs (like the JSP tags) already work with it. Seth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFARoNc5EIB1scRes8RAlNDAJ4h0aewSC4PGm8F06VBnvzFJ5u+4QCeOIMD FLOsi9/0fHkUAESpEbY+3Cc= =3/Qn -----END PGP SIGNATURE----- |
|
From: Keith D. <kd...@cs...> - 2004-03-04 04:20:16
|
Seth, Those abstractions I'm talking about actually do make the code simpler and decouple the validation processing with the metadata (configuration) API. Furthermore, they form the basis for the cache I'm talking about. They introduce a few new interfaces yet, but they're simple interfaces. And you don't have to deal with them, as I mentioned in my last email - your interface is exactly the same (aside from our two classname differences.) Another benefit of those abstractions is they make it easier for the validator be used in other contexts. For example, maybe I want a ValidationInterceptor which can take any bean, look up its validator, and invoke the validation methods -- maybe as part of a command framework. Or maybe I want to wrap a domain object in a AOP proxy that invokes a BeanValidator when set() methods are called. Maybe I want validation rules to come from another source other than attributes metadata. That's easier to do with the domain abstractions around than with the metadata stuff all coupled in with your validation processing logic... I agree completely we should use Errors. What I would like to do is take the best parts of your design and take the parts of mine I feel are strong and merge the two in the sandbox for review. Nothings going to be complicated, hopefully simplified. If something doesn't meet your requirements, let me know immediately! I'll work with you to get our stuff committed ASAP. Keith ----- Original Message ----- From: "Seth Ladd" <se...@eh...> To: <spr...@li...> Sent: Wednesday, March 03, 2004 8:16 PM Subject: Re: [Springframework-developer] RE: validation stuff > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > | Do you prefer 'explicit' (beforehand) configuration of the validateable > | classes via the metadata API or do you think it is better for that to > happen > | lazily/implicity when the registry validate(command, results) method is > | invoked? In the latter case, we would cache the > | BeanValidator/PropertyValidator references in the registry once we derive > | them from the source-metadata resulting in better performance. > > > That is a great idea. AttributeValidator should cache the validation > rules it finds for each command class. Since AttributeValidator will > usually be used as a singleton, this might help and cut down on the > reflection and attribute discovery. > > Hopefully I'll be allowed to checkin the current Attribute Validator and > we can start flushing it out. I'm not sure what we gain from all those > levels of abstraction you have proposed. One of the nice things I like > about the current attribute validator is that it doesn't introduce any > new classes or interfaces; it tries to remain small and simple. > > But again, maybe those abstractions should remain only in the RCP > project. Once they've proved themselves as useful to a more general > validation API (the current Spring one) we can integrate them. I'm not > anti-abstractions, I just haven't seen the need for them (yet). > > I don't want to lose the Errors interface from the validation API. It's > integrated into Spring already and other APIs (like the JSP tags) > already work with it. > > Seth > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFARoNc5EIB1scRes8RAlNDAJ4h0aewSC4PGm8F06VBnvzFJ5u+4QCeOIMD > FLOsi9/0fHkUAESpEbY+3Cc= > =3/Qn > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------- > 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_id=3638&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Seth L. <se...@eh...> - 2004-03-04 19:57:47
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | I agree completely we should use Errors. What I would like to do is take | the best parts of your design and take the parts of mine I feel are strong | and merge the two in the sandbox for review. Nothings going to be | complicated, hopefully simplified. If something doesn't meet your | requirements, let me know immediately! I'll work with you to get our stuff | committed ASAP. I agree, let's get something into sandbox soon. Here are some requirements: - - Be allowed to put MessageSourceResolvable into message args of messages (patch in JIRA to do this) - - attach validation rules to getters of objects - - use a singleton validator (of type AttributeValidator, or whatever) to validate all Command objects. In other words, remove requirement to write a Validator for each Command Object. - - Minimize any configurations. Since it deals w/ attributes, shouldn't be an issue. - - Validate object graphs (recurse through command object) - - Make it easy to add new rules - - Javascript generation from rules (we'll worry about that later :) - - Impact on Spring should be minimal Hope that helps. Looking forward to helping! Seth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAR4bk5EIB1scRes8RAkhjAKCSZZ/VTks2fgQ6uESOmSwMmvdX5QCeOGVb H0SyYuiT1LBpEFodafGfPjE= =1r71 -----END PGP SIGNATURE----- |
