[news.eclipse.tools.emf] Re: DataBinding + Validation Framework

[Ed Merks <Ed.Merks@xxxxxxxxx>]

Guys,

Comments below.

Will Horn wrote:
> "Matt Biggs" <zebbedi@xxxxxxxxx> wrote in message 
> news:08ca3e8b87dc55ffa55286e5166798ac$1@xxxxxxxxxxxxxxxxxx
> > Could someone point me in the right direction or advise if its 
> > possible to get EMF databinding to use the EMF validation framework 
> > as its source for determining validation failures etc?
> I've been looking into this recentely as well.
>
> > All of the examples explain how to write your own IValidator however 
> > this seems like im duplicating alot of code thats already within my 
> > model validator.
> Some types of databinding validation are not duplications of model 
> validation, e.g. if you bind a Text widget to a numeric attribute, you 
> need to validate that the string is numeric before you can event set 
> it on the model.
The factory methods for createAbcFromString needs to do this type of 
checking as well...
> But I agree that for most things like required attributes, valid 
> ranges, cross attribute constraints, it is nicer to implement them at 
> the model level where they can be reused outside of databinding.
One issue is that all the constraints require a value of the given type 
to apply the constraint.  So for data values, you have to convert the 
string to a data value (where the factory must check for lexical well 
formedness) and then you can check any additional constraints on the 
data value itself using the Diagnostician.  Of course for an EObject, 
the values must be set before you can check the constraints, so that's 
not something that can be checked before a change is applied to the object.
> > Similarly writing my own IValidator that calls a Diagnostician i 
> > guess would work, however i wondered if this could be quite heavyweight?
> I think this is the direction you have to go.  I'm considering using 
> the EMF Validation Framework (the other one 
> http://help.eclipse.org/ganymede/topic/org.eclipse.emf.validation.doc/references/overview/ValidationOverview.html) 
> instead of Diagnostician because it is more configurable and extensible.
The extended validation framework is intended to allow downstream 
clients of a model to impose additional constraints on instances that 
are not imposed directly by the core validation framework as intrinsic 
constraints on instances.
> It can do fine grained validation (against a single change 
> Notification) and reports problems as IStatus directly.
Of course BasicDiagnostic.toIStatus gives you an IStatus if you need one...
> I'm also thinking it may prove easier to work with a 
> ValidationStatusProvider rather than an IValidator.  For instance, 
> UpdateValueStrategy works with and afterGet, afterConvert, and 
> beforeSet validator, but doesn't have the notion (as far as I can 
> tell) of an afterSet/model level validator.  ValidationStatusProvider 
> (see MultiValidator for an example) looks like the way to handle 
> validation once the target->model update has finished.
It will be interesting to see what Tom thinks about support for 
validation.  It seems an important issue...
> I'll follow up if I make any more progress.
Thanks Will!
> -Will