[Figleaf-developer] Re: Validation and property descriptor

[Greg S. <ste...@on...>]

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