[Figleaf-developer] Re: Validation and property descriptor
Status: Alpha
Brought to you by:
steckman
|
From: Greg S. <ste...@on...> - 2004-07-09 04:14:01
|
For some reason I'm not getting list e-mails in a timely manner...I had to go to Sourceforge to read them! At any rate, the last you mention on this topic was: "If we edit an object using a changeSet which transparently handles validation, an object will never become invalid. It also lets us handle validation of a group of properties, and still supports the user just defining simple validation rules if required. If this is the only way for figleaf to change properties, we also do not need to worry about proxying the properties. A ChangeSet can also be easily sent over the wire if required. My example using ChangeSets is coming on nicely - hopefully once I can show it working it will better show the advantages of the approach." I think this is an interesting approach to the problem. There's one question about desired behavior that we need to consider. Do we want Figleaf to augment the behavior of POJO's in such a way that if Class A calls a setter on Class B, Class B will guard itself or prevent itself from being saved because of validation logic added by the Figleaf augmentation process? Considering a concrete example, say ClassB has a property "void setMyInteger(int x)". Now with Figleaf the developer causes it to get augmented such that it is invalid for the property "MyInteger" to be negative. The GUI will now prevent negative values from being entered on its form by using whatever validation system we come up with. But if an instance of ClassB is accessed by ClassA, which knows nothing of Figleaf, do we still want ClassB to be unsavable/unsettable with a negative value? If the answer is yes, then it would seem there is no alternative than to intercept all calls to the methods that are identified as properties (with a PropertyDescriptor). But it also raises interesting questions such as what should be done if an invalid property is attempted to be set? Ignore it, throw an exception? That leads me to another thought. What if I want to program my classes explicitly with validation logic? I want the Figleaf GUI to also be able to use it as well as the other "semi POJO's" in my domain model. Yes it makes my class dependent on Figleaf API's, but if I don't use the Figleaf API then I'd have to write my own, which is more work. The point would be to force Class A to know that ClassB.setMyInteger has a limit of acceptable values and might throw an exception (or do something else) if it is attempted to set an invalid value. Greg |