[TransWarp] Call for requirements: Validation and Constraints

[Phillip J. Eby]

At 09:07 AM 1/2/03 +0200, Roché Compaan wrote:

>The idea of "deferred validation" is new to me but I feel one can get
>away without out. It sounds very complicated to implement and that it
>can really lead to debugging hell.

ZPatterns supports it, although that's not necessarily an argument in its 
favor.  :)

Deferred validation is important for two reasons...  1) Some object models 
are impossible to construct using only immediate validation, and 2) the MOF 
spec requires it.  So dropping it is not an option.

And what I'd call "extended deferred validation", which is to say 
validation which can be deferred beyond transaction boundaries, is a 
requirement for many applications, although it doesn't necessarily need to 
be supported by the core model framework.


>If one doesn't have deferred validation I think one can still achieve
>the same goal by working on some sort of proxy or copy of the real
>object until one needs to update the real object. This is almost like
>working on copy of the source in a cvs checkout. As soon as one is ready
>to check the code back in you might receive warnings and need to handle
>them before checkin is possible.

But that's still deferred validation.


>I do however feel that constraints (not deferred) on collections are
>needed. There are many use cases that show its importance:
>
>     The contacts of customer X should have the "Member" role if the
>     customer has purchased a license.
>
>     Components X,Y and Z of Product A should always be enabled.
>
>I think one can come up with a book of examples like the above.

Yes.  And if you have a kind of object A which must always have an 
associated B, and B's must always have an associated A, there's no way you 
can validate that on an "immediate" basis, because you can't just cause an 
A and a B to both spring into existence at once, already referring to each 
other.


> > One thing I'm not clear on is whether these methods should really raise
> > exceptions, or perhaps take some sort of visitor that accepts validation
> > info.  While this approach is more complex in some ways, the default
> > visitor could simply raise a validation error based on the
> > information.  The advantage would be for the scenarios where you want
> > validation data, but you don't want the object to break or be unable to
> > save it when it's invalid.  It would also be handy when you'd like to
> > possibly get multiple pieces of error information and consolidate them for
> > display.
>
>It "feels" right that validation methods should raise an exception. One
>can still catch the exceptions and consolidate the error information for
>display. It is then very explicit where validation failed and the
>developer is forced to be aware of it and handle it. If one uses the
>visitor pattern it seems possible that an exception might never be
>raised which can prove fatal for object state?

After thinking about it overnight, and also researching the patterns 
literature (e.g. Ward Cunningham's CHECKS pattern language of input 
validation), I'm inclined more towards the visitor approach.  It has a big 
advantage for interactive user interfaces, and for implementing MOF model 
validation.

One other issue that I've thought about since my posting is the subject of 
business rules.  Business rules shouldn't be coded into the domain model 
level, but should be able to be specified via configuration and/or other 
domain objects.  So there need to be hooks that allow domain objects to be 
monitored, constrained, or even have values computed by external 
components.  Currently, the only way to do this is to have a DM do it, and 
there the only way the DM can validate data is at save() time.

So there's a bit more to think about.  I suspect that we'll need something 
like the JavaBeans pattern of "property change listeners", but with 
subscribers at the DM level, rather than per individual object.