Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » DataBinding + Validation Framework
DataBinding + Validation Framework [message #430785] Wed, 10 June 2009 10:41 Go to next message
Matt Biggs is currently offline Matt BiggsFriend
Messages: 71
Registered: July 2009
Member
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?

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.

Similarly writing my own IValidator that calls a Diagnostician i guess
would work, however i wondered if this could be quite heavyweight?
Re: DataBinding + Validation Framework [message #430805 is a reply to message #430785] Wed, 10 June 2009 21:31 Go to previous messageGo to next message
Will Horn is currently offline Will HornFriend
Messages: 265
Registered: July 2009
Senior Member
"Matt Biggs" <zebbedi@gmail.com> wrote in message
news:08ca3e8b87dc55ffa55286e5166798ac$1@www.eclipse.org...
> 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. 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.

> 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.valid ation.doc/references/overview/ValidationOverview.html)
instead of Diagnostician because it is more configurable and extensible. It
can do fine grained validation (against a single change Notification) and
reports problems as IStatus directly. 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.

I'll follow up if I make any more progress.

-Will
Re: DataBinding + Validation Framework [message #430813 is a reply to message #430805] Thu, 11 June 2009 08:53 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33137
Registered: July 2009
Senior Member
Guys,

Comments below.

Will Horn wrote:
> "Matt Biggs" <zebbedi@gmail.com> wrote in message
> news:08ca3e8b87dc55ffa55286e5166798ac$1@www.eclipse.org...
>> 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.valid ation.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
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: DataBinding + Validation Framework [message #430875 is a reply to message #430813] Mon, 15 June 2009 09:53 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
[...]

>> 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 have to admit that this something I didn't deal today directly in
databinding but I do the validation when the users wants to save the
changes.

There's an interesting JSR 303 which deals with validation and there's a
request to implement such support for Eclipse-Databinding [1].

Maybe it is a good time to get together and think about how we should
implement the stuff in Eclipse-Databinding so that people can easily
plug in their own model validation (like people can plug in currently
their property validation).

Though the question is whether such a model validation should happen
really at the databinding level which works at the level of model
properties and not a complete model graph. Does this make sense?

>> I'll follow up if I make any more progress.
> Thanks Will!

Please do so :-)

>>
>> -Will
>>

[1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=279166
Re: DataBinding + Validation Framework [message #430879 is a reply to message #430875] Mon, 15 June 2009 16:31 Go to previous messageGo to next message
Matt Biggs is currently offline Matt BiggsFriend
Messages: 71
Registered: July 2009
Member
For me, my main target was to provide a decorator on the control based on
the validation of the model.

After looking into the extended validation framework, i have to agree with
Ed in that the core validation should still reside inside the model.

I played around with various UpdateValueStrategy attempts and hit a snag
in most of them.

For each of these the databinding validation is called throughout the
setting of the value. There is nothing that can be used for AFTER the
value has been set onto the model. (that im aware of).

I tried overriding the doSet() method, however whenever undo / redo were
applied, this method isn't called, and you end up with a stale validation.
You can of course add another UpdateValueStrategy to the modelToTarget
side of things, but you have no real direct reference to the emf model and
you end up duplicating alot of things.

The only way i can successfully achieve my goal (and it may be different
for others) was to add a ValuechangeListener to the
EMFObservable/EMFEditObservable.

This gets called whenever undo/redo and set is invoked.

Im not entirely convinced ive done the correct thing (I'm sure Ed or Tom
will probably tell me otherwise) but here is a copy of the listener that i
add which in turn calls the standard EMF validation:


public class EMFValueChangeListener implements IValueChangeListener {
private final int code;
private final ControlDecoration decoration;

public EMFValueChangeListener(int code, ControlDecoration decoration) {
this.code = code;
this.decoration = decoration;
Assert.isNotNull(decoration, "ControlDecoration must not be null");
}

@Override
public void handleValueChange(ValueChangeEvent event) {
final IObservable observable = event.getObservable();
if( observable instanceof IObserving ) {
final IObserving observing = (IObserving)observable;
if( observing.getObserved() instanceof EObject ) {
final EObject eObject = (EObject) observing.getObserved();

final Diagnostic diagnostic =
Diagnostician.INSTANCE.validate(eObject);
final Diagnostic child =
DiagnosticHelper.getDiagnosticWithCode(diagnostic, code);
if( child != null && child.getCode() == code && child.getSeverity() ==
Diagnostic.WARNING ) {
this.decoration.setImage(DiagnosticHelper.WARNING_IMAGE);
this.decoration.setDescriptionText(child.getMessage());
this.decoration.show();
} else if ( child != null && child.getCode() == code &&
child.getSeverity() == Diagnostic.ERROR ) {
this.decoration.setImage(DiagnosticHelper.ERROR_IMAGE);
this.decoration.setDescriptionText(child.getMessage());
this.decoration.show();
} else {
this.decoration.hide();
}
}
}
}
}
Re: DataBinding + Validation Framework [message #431177 is a reply to message #430879] Wed, 01 July 2009 17:03 Go to previous messageGo to next message
Benjamin Cabé is currently offline Benjamin CabéFriend
Messages: 201
Registered: July 2009
Location: Toulouse, France
Senior Member

Matt,

You may want to have a look at the work being done in PDE incubator, and
intended to use EMF/Forms and EMF Validation to edit Declarative
Services XML files...
The pde-incubator/modeling/plugins/org.eclipse.pde.emfforms module of
/cvsroot/eclipse, in particular, contains a generic framework to create
a FormsEditor of an EObject, using databinding. The generic framework
proposes an UpdateValueStrategy which triggers an EMF validation each
time an EObject is being changed. If this UpdateValueStrategy is
installed on a binding *and* you link the MessageManager of your Forms
to the validationStatusProviders map of your binding context, then the
Forms will automatically show decorators in front of the "guilty"
editing control (i.e. the one bound to the EStructuralFeature retrieved
in the Diagnostic' data returned by the Diagnostician...)

Feel free to give it a try (the simplest way is probably to checkout
both the generic framework and the exemplary implementation -Declarative
Service Editor- that's to say all the bundles available in
pde-incubator/modeling)

On a side note, and AFAICT, my current approach works well even if you
want use undo/redo :)

Cheers,
Benjamin

Matt Biggs a écrit :
> For me, my main target was to provide a decorator on the control based
> on the validation of the model.
> After looking into the extended validation framework, i have to agree
> with Ed in that the core validation should still reside inside the model.
>
> I played around with various UpdateValueStrategy attempts and hit a snag
> in most of them.
> For each of these the databinding validation is called throughout the
> setting of the value. There is nothing that can be used for AFTER the
> value has been set onto the model. (that im aware of).
> I tried overriding the doSet() method, however whenever undo / redo were
> applied, this method isn't called, and you end up with a stale
> validation. You can of course add another UpdateValueStrategy to the
> modelToTarget side of things, but you have no real direct reference to
> the emf model and you end up duplicating alot of things.
>
> The only way i can successfully achieve my goal (and it may be different
> for others) was to add a ValuechangeListener to the
> EMFObservable/EMFEditObservable.
> This gets called whenever undo/redo and set is invoked.
> Im not entirely convinced ive done the correct thing (I'm sure Ed or Tom
> will probably tell me otherwise) but here is a copy of the listener that
> i add which in turn calls the standard EMF validation:
>
>
> public class EMFValueChangeListener implements IValueChangeListener {
> private final int code;
> private final ControlDecoration decoration;
>
> public EMFValueChangeListener(int code, ControlDecoration decoration) {
> this.code = code;
> this.decoration = decoration;
> Assert.isNotNull(decoration, "ControlDecoration must not be null");
> }
>
> @Override
> public void handleValueChange(ValueChangeEvent event) {
> final IObservable observable = event.getObservable();
> if( observable instanceof IObserving ) {
> final IObserving observing = (IObserving)observable;
> if( observing.getObserved() instanceof EObject ) {
> final EObject eObject = (EObject) observing.getObserved();
>
> final Diagnostic diagnostic =
> Diagnostician.INSTANCE.validate(eObject);
> final Diagnostic child =
> DiagnosticHelper.getDiagnosticWithCode(diagnostic,
> code);
> if( child != null && child.getCode() == code &&
> child.getSeverity() == Diagnostic.WARNING ) {
>
> this.decoration.setImage(DiagnosticHelper.WARNING_IMAGE);
> this.decoration.setDescriptionText(child.getMessage());
> this.decoration.show();
> } else if ( child != null && child.getCode() == code &&
> child.getSeverity() == Diagnostic.ERROR ) {
> this.decoration.setImage(DiagnosticHelper.ERROR_IMAGE);
> this.decoration.setDescriptionText(child.getMessage());
> this.decoration.show();
> } else {
> this.decoration.hide();
> }
> }
> }
> }
> }
>
>
>
>


Re: DataBinding + Validation Framework [message #431180 is a reply to message #431177] Wed, 01 July 2009 17:15 Go to previous messageGo to next message
Matt Biggs is currently offline Matt BiggsFriend
Messages: 71
Registered: July 2009
Member
Benjamin,

Thanks for the helpful pointers, very much appreciated. ill be sure to
check that out and report back. I actually revisted my previous solution
as the listener simply didn't fit in with other aspects of the databinding
validation such as WizardPageSupport.

I knocked up a quick EMF generator plugin which is heavily based on the
standard EMF validation framework, but allows you to pass in the
EStructuralFeature and an object representing the value that you propose
to be set onto the model.

The generator determines if the EStrucuralFeature is of a type long or
string etc, and applies various standard checks such as making sure the
proposed value is of the correct type. Then you can add in checks for not
null or greater than / less than etc etc.

Finally you call this from an UpdateValueStrategy. Only down side, is to
support undo/redo you have to add the same strategy to both modelToTarget
and targetToModel binding as when you undo the EMF model is telling the
control which value to use and therefore any decorators set weren't being
re-evaluated.

It appears to work quite well so far, but a proper solution would be much
better.

once again, thanks for the pointers!

Matt
Re: DataBinding + Validation Framework [message #431184 is a reply to message #431180] Wed, 01 July 2009 18:55 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Hi,

Just a short heads up from my side on validation. I discussed some
interesting things with Matt Hall lately when it comes to
Model-Graph-Validation (Cross-Attribute Validation) opposed to
Attribute-Validation.

The current exploration I'm doing in a private project is to register my
own org.eclipse.core.databinding.validation.MultiValidator in the
DatabindingContext and use the EMF-Validation-Framework to validate the
state of my object graph.

I hope I can shade some more light into this soon.

Tom

Matt Biggs schrieb:
> Benjamin,
>
> Thanks for the helpful pointers, very much appreciated. ill be sure to
> check that out and report back. I actually revisted my previous solution
> as the listener simply didn't fit in with other aspects of the
> databinding validation such as WizardPageSupport.
> I knocked up a quick EMF generator plugin which is heavily based on the
> standard EMF validation framework, but allows you to pass in the
> EStructuralFeature and an object representing the value that you propose
> to be set onto the model.
>
> The generator determines if the EStrucuralFeature is of a type long or
> string etc, and applies various standard checks such as making sure the
> proposed value is of the correct type. Then you can add in checks for
> not null or greater than / less than etc etc.
> Finally you call this from an UpdateValueStrategy. Only down side, is to
> support undo/redo you have to add the same strategy to both
> modelToTarget and targetToModel binding as when you undo the EMF model
> is telling the control which value to use and therefore any decorators
> set weren't being re-evaluated.
> It appears to work quite well so far, but a proper solution would be
> much better.
> once again, thanks for the pointers!
>
> Matt
>
Re: DataBinding + Validation Framework [message #431186 is a reply to message #431184] Wed, 01 July 2009 19:13 Go to previous messageGo to next message
Matt Biggs is currently offline Matt BiggsFriend
Messages: 71
Registered: July 2009
Member
Tom,

I would be very interested in hearing about your project and seeing the
results. I was following your blog entries, hoping you may mention
something.

In geneeral I have been playing around with this for a few months now, and
not made a huge amount of progress. If i can contribute in any way, let me
know.

I've also just had a quick look at Bens work and it looks very promising
and has given me a few ideas.

cheers

Matt
Re: DataBinding + Validation Framework [message #512329 is a reply to message #431184] Thu, 04 February 2010 16:56 Go to previous message
Cyril Jaquier is currently offline Cyril JaquierFriend
Messages: 80
Registered: July 2009
Member
Hi Tom,

Sorry to resurrect an old post but I had a look at
Snippet027ExternalValidator from org.eclipse.jface.examples.databinding
and wanted to give it a try with EMF/DB.

In Snippet027ExternalValidator, the value is first set in the model and
the MultiValidator#validate method get called, allowing the delegation
of the validation to the model.

In my attempt at doing something similar with EMF.Edit,
MultiValidator#validate is first called and then the command is created
and executed.

....
IEMFValueProperty prop= EMFEditProperties.value(ed, A__ATTR);
IObservableValue masterObs= prop.observe(getMaster());
final IObservableValue tf= createTextObservable(nameField);
dbc.bindValue(tf, masterObs);

MultiValidator validator= new MultiValidator() {
@Override
protected IStatus validate () {
tf.getValue();
return ValidationStatus.error("Nicht gut...");
}
};
dbc.addValidationStatusProvider(validator);
....

Am I doing something wrong? Is this related to EMFDataBindingContext?

What is the best way to delegate the validation to the EMF validation
framework (core)?

Thank you.

Cyril



Tom Schindl wrote:
> Hi,
>
> Just a short heads up from my side on validation. I discussed some
> interesting things with Matt Hall lately when it comes to
> Model-Graph-Validation (Cross-Attribute Validation) opposed to
> Attribute-Validation.
>
> The current exploration I'm doing in a private project is to register my
> own org.eclipse.core.databinding.validation.MultiValidator in the
> DatabindingContext and use the EMF-Validation-Framework to validate the
> state of my object graph.
>
> I hope I can shade some more light into this soon.
>
> Tom
>
> Matt Biggs schrieb:
>> Benjamin,
>>
>> Thanks for the helpful pointers, very much appreciated. ill be sure to
>> check that out and report back. I actually revisted my previous solution
>> as the listener simply didn't fit in with other aspects of the
>> databinding validation such as WizardPageSupport.
>> I knocked up a quick EMF generator plugin which is heavily based on the
>> standard EMF validation framework, but allows you to pass in the
>> EStructuralFeature and an object representing the value that you propose
>> to be set onto the model.
>>
>> The generator determines if the EStrucuralFeature is of a type long or
>> string etc, and applies various standard checks such as making sure the
>> proposed value is of the correct type. Then you can add in checks for
>> not null or greater than / less than etc etc.
>> Finally you call this from an UpdateValueStrategy. Only down side, is to
>> support undo/redo you have to add the same strategy to both
>> modelToTarget and targetToModel binding as when you undo the EMF model
>> is telling the control which value to use and therefore any decorators
>> set weren't being re-evaluated.
>> It appears to work quite well so far, but a proper solution would be
>> much better.
>> once again, thanks for the pointers!
>>
>> Matt
>>
Previous Topic:[DataBinding] FeaturePath for "many" features?
Next Topic:ITreeItemContentProvider vs ITreeContentProvider
Goto Forum:
  


Current Time: Sat Apr 20 04:18:46 GMT 2024

Powered by FUDForum. Page generated in 0.04493 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top