Home » Modeling » EMF » [Databinding] [Validation] Handling OCL validation within databinding
| [Databinding] [Validation] Handling OCL validation within databinding [message #424507] |
Tue, 28 October 2008 18:45  |
Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
I want to use the OCL Live validation constraints associated with the
model, to validate my ui databinding values. Haven't noticed this nuance
in the various discussions in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=203492
So am using an EMFUpdateValueStrategy as my targetToModelStrategy for
binding EMF model elements to ui controls, but I need either
to 1. validate using the constraint before the set or 2. perform the set
take the error and via the transaction facility roll the model back to a
previous value reseting the user interface as well.
It is the second approach that I have been attempting. Am doing this by
overriding the EMFUpdateValueStrategy doSet(IObservableValue
observableValue, Object value), and tying in a
ModelValidationService.getInstance().addValidationListener() prior to
the doSet.
Then if the ValidationListener records a failure result I return the
failed results from the doSet. This at least shows it on the status
label, but my ui control keeps the old invalid value displayed. In other
words the ui control shows a value now out of sync with the model.
Two questions -
Is there an alternative to this hack approach?
If not how can I resync the ui with the model after the rollback?
thanks for any ideas,
John
|
|
|
| Re: [Databinding] [Validation] Handling OCL validation within databinding [message #424513 is a reply to message #424507] |
Tue, 28 October 2008 20:23  |
 Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
John,
Comments below.
John E. Conlon wrote:
> I want to use the OCL Live validation constraints associated with the
> model, to validate my ui databinding values. Haven't noticed this
> nuance in the various discussions in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=203492
Wow, that's a long one.
>
> So am using an EMFUpdateValueStrategy as my targetToModelStrategy for
> binding EMF model elements to ui controls, but I need either
>
> to 1. validate using the constraint before the set or
That's tricky. Certainly with intrinsic constraints it's possible to
validate a data value say, but often constraints span multiple features
and can't be checked until the state has changed.
> 2. perform the set take the error and via the transaction facility
> roll the model back to a previous value reseting the user interface as
> well.
Unfortunately I'm not all that familiar with the transaction APIs. If
worst comes to worst, I imagine you can hook your way into
EditingDomainEObjectObservableList.execute but I also imagine the
transaction enabled stack might already do good things...
>
> It is the second approach that I have been attempting. Am doing this by
> overriding the EMFUpdateValueStrategy doSet(IObservableValue
> observableValue, Object value), and tying in a
> ModelValidationService.getInstance().addValidationListener() prior to
> the doSet.
Christian will know what that means, but he probably doesn't know much
about data binding...
>
>
> Then if the ValidationListener records a failure result I return the
> failed results from the doSet. This at least shows it on the status
> label, but my ui control keeps the old invalid value displayed. In
> other words the ui control shows a value now out of sync with the model.
The rollback type of approach would produce notifications...
>
> Two questions -
>
> Is there an alternative to this hack approach?
Good questions.
>
> If not how can I resync the ui with the model after the rollback?
It should just do that based on notifications...
>
> thanks for any ideas,
> John
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [Databinding] [Validation] Handling OCL validation within databinding [message #424523 is a reply to message #424513] |
Wed, 29 October 2008 00:21 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Ed,
see comments...
Ed Merks wrote:
> John,
>
> Comments below.
>
>
> John E. Conlon wrote:
>> I want to use the OCL Live validation constraints associated with the
>> model, to validate my ui databinding values. Haven't noticed this
>> nuance in the various discussions in
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=203492
> Wow, that's a long one.
scary too.
>>
>> So am using an EMFUpdateValueStrategy as my targetToModelStrategy for
>> binding EMF model elements to ui controls, but I need either
>>
>> to 1. validate using the constraint before the set or
> That's tricky. Certainly with intrinsic constraints it's possible to
> validate a data value say, but often constraints span multiple features
> and can't be checked until the state has changed.
That the boat I'm in.
>> 2. perform the set take the error and via the transaction facility
>> roll the model back to a previous value reseting the user interface as
>> well.
> Unfortunately I'm not all that familiar with the transaction APIs. If
> worst comes to worst, I imagine you can hook your way into
> EditingDomainEObjectObservableList.execute but I also imagine the
> transaction enabled stack might already do good things...
Yes the transaction stack does the right thing even when using
databinding ui(s). It's on the ui side that keeping things coordinated
is the problem though. see below...
>
>>
>> It is the second approach that I have been attempting. Am doing this by
>> overriding the EMFUpdateValueStrategy doSet(IObservableValue
>> observableValue, Object value), and tying in a
>> ModelValidationService.getInstance().addValidationListener() prior to
>> the doSet.
> Christian will know what that means, but he probably doesn't know much
> about data binding...
That listerner is notified when the ValidationService does it's thing
public void validationOccurred(ValidationEvent event) {
if(event.getSeverity()!=IStatus.OK){
....
Fairly straight forward way to find out that something bad may have
happened and grab and react to the status.
>>
>>
>> Then if the ValidationListener records a failure result I return the
>> failed results from the doSet. This at least shows it on the status
>> label, but my ui control keeps the old invalid value displayed. In
>> other words the ui control shows a value now out of sync with the model.
> The rollback type of approach would produce notifications...
It does but does, but these do not change the ui.??
>>
>> Two questions -
>>
>> Is there an alternative to this hack approach?
> Good questions.
>>
>> If not how can I resync the ui with the model after the rollback?
> It should just do that based on notifications...
I would have thought so too.
As an example of this out-of-sync condition: One of my OCL Live
constraints, constrains an
attribute to only have a value from 0 to 9.99. Entering the value 55
into the bound
text box will show the user a Live Validation Dialog followed by a
Command Failed
Dialog showing the proper error messages from the OCL constraint to the
user. After the change would have expected the text control to revert to
the value the model rolled back to
which is 5.5. But no, the ui stays at 55.
puzzling,
John
|
|
|
| Re: [Databinding] [Validation] Handling OCL validation within databinding [message #424525 is a reply to message #424523] |
Wed, 29 October 2008 09:13 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
John E. Conlon schrieb:
> Ed,
>
> see comments...
>
> Ed Merks wrote:
>> John,
>>
>> Comments below.
>>
>>
>> John E. Conlon wrote:
>>> I want to use the OCL Live validation constraints associated with the
>>> model, to validate my ui databinding values. Haven't noticed this
>>> nuance in the various discussions in
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=203492
>> Wow, that's a long one.
> scary too.
>>>
>>> So am using an EMFUpdateValueStrategy as my targetToModelStrategy for
>>> binding EMF model elements to ui controls, but I need either
>>>
>>> to 1. validate using the constraint before the set or
>> That's tricky. Certainly with intrinsic constraints it's possible to
>> validate a data value say, but often constraints span multiple
>> features and can't be checked until the state has changed.
> That the boat I'm in.
>
>>> 2. perform the set take the error and via the transaction facility
>>> roll the model back to a previous value reseting the user interface
>>> as well.
>> Unfortunately I'm not all that familiar with the transaction APIs.
>> If worst comes to worst, I imagine you can hook your way into
>> EditingDomainEObjectObservableList.execute but I also imagine the
>> transaction enabled stack might already do good things...
> Yes the transaction stack does the right thing even when using
> databinding ui(s). It's on the ui side that keeping things coordinated
> is the problem though. see below...
>>
>>>
>>> It is the second approach that I have been attempting. Am doing this by
>>> overriding the EMFUpdateValueStrategy doSet(IObservableValue
>>> observableValue, Object value), and tying in a
>>> ModelValidationService.getInstance().addValidationListener() prior to
>>> the doSet.
>> Christian will know what that means, but he probably doesn't know much
>> about data binding...
> That listerner is notified when the ValidationService does it's thing
> public void validationOccurred(ValidationEvent event) {
> if(event.getSeverity()!=IStatus.OK){
> ...
>
> Fairly straight forward way to find out that something bad may have
> happened and grab and react to the status.
>>>
>>>
>>> Then if the ValidationListener records a failure result I return the
>>> failed results from the doSet. This at least shows it on the status
>>> label, but my ui control keeps the old invalid value displayed. In
>>> other words the ui control shows a value now out of sync with the model.
>> The rollback type of approach would produce notifications...
> It does but does, but these do not change the ui.??
>
Interesting because EMF-Observables work in both ways and I'm using this
successfully in my CDO-Applications.
A workaround might be to force an UI-Update after having done the
rollback with:
- Binding#updateTargetToModel()
- Viewer#refresh()
Still the really interesting thing is way the the UI is not kept in sync
when a rollback is issued.
To commonly deal with your use case it looks like you need something
like UpdateValueStrategy#setAfterSetValidator(IValidator), right? File a
bug and explain your use case and post the Bug-Id here.
Tom
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: [Databinding] [Validation] Handling OCL validation within databinding [message #424532 is a reply to message #424525] |
Wed, 29 October 2008 16:21 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Hi Tom,
See comments below...
Tom Schindl wrote:
> John E. Conlon schrieb:
>> Ed,
>>
>> see comments...
>>
>> Ed Merks wrote:
>>> John,
>>>
>>> Comments below.
>>>
>>>
>>> John E. Conlon wrote:
>>>> I want to use the OCL Live validation constraints associated with the
>>>> model, to validate my ui databinding values. Haven't noticed this
>>>> nuance in the various discussions in
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=203492
>>> Wow, that's a long one.
>> scary too.
>>>> So am using an EMFUpdateValueStrategy as my targetToModelStrategy for
>>>> binding EMF model elements to ui controls, but I need either
>>>>
>>>> to 1. validate using the constraint before the set or
>>> That's tricky. Certainly with intrinsic constraints it's possible to
>>> validate a data value say, but often constraints span multiple
>>> features and can't be checked until the state has changed.
>> That the boat I'm in.
>>
>>>> 2. perform the set take the error and via the transaction facility
>>>> roll the model back to a previous value reseting the user interface
>>>> as well.
>>> Unfortunately I'm not all that familiar with the transaction APIs.
>>> If worst comes to worst, I imagine you can hook your way into
>>> EditingDomainEObjectObservableList.execute but I also imagine the
>>> transaction enabled stack might already do good things...
>> Yes the transaction stack does the right thing even when using
>> databinding ui(s). It's on the ui side that keeping things coordinated
>> is the problem though. see below...
>>>> It is the second approach that I have been attempting. Am doing this by
>>>> overriding the EMFUpdateValueStrategy doSet(IObservableValue
>>>> observableValue, Object value), and tying in a
>>>> ModelValidationService.getInstance().addValidationListener() prior to
>>>> the doSet.
>>> Christian will know what that means, but he probably doesn't know much
>>> about data binding...
>> That listerner is notified when the ValidationService does it's thing
>> public void validationOccurred(ValidationEvent event) {
>> if(event.getSeverity()!=IStatus.OK){
>> ...
>>
>> Fairly straight forward way to find out that something bad may have
>> happened and grab and react to the status.
>>>>
>>>> Then if the ValidationListener records a failure result I return the
>>>> failed results from the doSet. This at least shows it on the status
>>>> label, but my ui control keeps the old invalid value displayed. In
>>>> other words the ui control shows a value now out of sync with the model.
>>> The rollback type of approach would produce notifications...
>> It does but does, but these do not change the ui.??
>>
>
> Interesting because EMF-Observables work in both ways and I'm using this
> successfully in my CDO-Applications.
Not so familiar with CDO, but do you have constraints the cause
rollbacks of your sets?
>
> A workaround might be to force an UI-Update after having done the
> rollback with:
> - Binding#updateTargetToModel()
> - Viewer#refresh()
Thanks for the hint.
My workaround is to pass the binding to my subclassed
EMFUpdateValueStrategy and in the overriden
doSet(IObservableValue observableValue, Object value)
and if the super.doSet causes a Live Validation error (resulting in a
rollback) perform a
binding.updateModelToTarget();
this does the trick of syncing the ui!
>
> Still the really interesting thing is way the the UI is not kept in sync
> when a rollback is issued.
Perhaps this is because there may be an area of the code in the doSet
that ignores model changes?
>
> To commonly deal with your use case it looks like you need something
> like UpdateValueStrategy#setAfterSetValidator(IValidator), right?
Actually would have expected sending an IStatus that was an Error (not
OK) would have triggered this behavior. WDYT?
File a
> bug and explain your use case and post the Bug-Id here.
Here it is...
252612
thanks for look at this Tom,
John
|
|
|
| Re: [Databinding] [Validation] Handling OCL validation within databinding [message #424561 is a reply to message #424532] |
Thu, 30 October 2008 00:32 |
Al B
Messages: 130
Registered: July 2009 |
Senior Member |
|
|
John,
Regarding you comment about there may be an area of the code in the
doSet that ignores model changes, you might want to look at Bugzilla 238222:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=238222
I might be wrong, but it seems to be related to the problem you are
having. Anyway, here a work-around is described.
http://dev.eclipse.org/newslists/news.eclipse.platform/msg75 775.html
HTH!
John E. Conlon wrote:
> Hi Tom,
>
> See comments below...
>
> Tom Schindl wrote:
>> John E. Conlon schrieb:
>>> Ed,
>>>
>>> see comments...
>>>
>>> Ed Merks wrote:
>>>> John,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> John E. Conlon wrote:
>>>>> I want to use the OCL Live validation constraints associated with the
>>>>> model, to validate my ui databinding values. Haven't noticed this
>>>>> nuance in the various discussions in
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=203492
>>>> Wow, that's a long one.
>>> scary too.
>>>>> So am using an EMFUpdateValueStrategy as my targetToModelStrategy for
>>>>> binding EMF model elements to ui controls, but I need either
>>>>>
>>>>> to 1. validate using the constraint before the set or
>>>> That's tricky. Certainly with intrinsic constraints it's possible to
>>>> validate a data value say, but often constraints span multiple
>>>> features and can't be checked until the state has changed.
>>> That the boat I'm in.
>>>
>>>>> 2. perform the set take the error and via the transaction facility
>>>>> roll the model back to a previous value reseting the user interface
>>>>> as well.
>>>> Unfortunately I'm not all that familiar with the transaction APIs.
>>>> If worst comes to worst, I imagine you can hook your way into
>>>> EditingDomainEObjectObservableList.execute but I also imagine the
>>>> transaction enabled stack might already do good things...
>>> Yes the transaction stack does the right thing even when using
>>> databinding ui(s). It's on the ui side that keeping things coordinated
>>> is the problem though. see below...
>>>>> It is the second approach that I have been attempting. Am doing
>>>>> this by
>>>>> overriding the EMFUpdateValueStrategy doSet(IObservableValue
>>>>> observableValue, Object value), and tying in a
>>>>> ModelValidationService.getInstance().addValidationListener() prior to
>>>>> the doSet.
>>>> Christian will know what that means, but he probably doesn't know much
>>>> about data binding...
>>> That listerner is notified when the ValidationService does it's thing
>>> public void validationOccurred(ValidationEvent event) {
>>> if(event.getSeverity()!=IStatus.OK){
>>> ...
>>>
>>> Fairly straight forward way to find out that something bad may have
>>> happened and grab and react to the status.
>>>>>
>>>>> Then if the ValidationListener records a failure result I return the
>>>>> failed results from the doSet. This at least shows it on the status
>>>>> label, but my ui control keeps the old invalid value displayed. In
>>>>> other words the ui control shows a value now out of sync with the
>>>>> model.
>>>> The rollback type of approach would produce notifications...
>>> It does but does, but these do not change the ui.??
>>>
>>
>> Interesting because EMF-Observables work in both ways and I'm using this
>> successfully in my CDO-Applications.
> Not so familiar with CDO, but do you have constraints the cause
> rollbacks of your sets?
>
>
>>
>> A workaround might be to force an UI-Update after having done the
>> rollback with:
>> - Binding#updateTargetToModel()
>> - Viewer#refresh()
> Thanks for the hint.
>
> My workaround is to pass the binding to my subclassed
> EMFUpdateValueStrategy and in the overriden
>
> doSet(IObservableValue observableValue, Object value)
>
> and if the super.doSet causes a Live Validation error (resulting in a
> rollback) perform a
> binding.updateModelToTarget();
>
> this does the trick of syncing the ui!
>
>
>>
>> Still the really interesting thing is way the the UI is not kept in sync
>> when a rollback is issued.
> Perhaps this is because there may be an area of the code in the doSet
> that ignores model changes?
>
>
>>
>> To commonly deal with your use case it looks like you need something
>> like UpdateValueStrategy#setAfterSetValidator(IValidator), right?
>
> Actually would have expected sending an IStatus that was an Error (not
> OK) would have triggered this behavior. WDYT?
>
> File a
>> bug and explain your use case and post the Bug-Id here.
> Here it is...
>
> 252612
>
> thanks for look at this Tom,
> John
|
|
|
| Re: [Databinding] [Validation] Handling OCL validation within databinding [message #424586 is a reply to message #424561] |
Thu, 30 October 2008 17:58 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Hi AJ,
See comments below.
AJ wrote:
> John,
>
> Regarding you comment about there may be an area of the code in the
> doSet that ignores model changes, you might want to look at Bugzilla
> 238222:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=238222
I think your right. I uploaded a testcase to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=252612
that basically changes the model during the doSet, and I get the same
behavior.
> I might be wrong, but it seems to be related to the problem you are
> having. Anyway, here a work-around is described.
>
> http://dev.eclipse.org/newslists/news.eclipse.platform/msg75 775.html
>
> HTH!
In that testcase I also show the workaround.
thanks AJ,
John
> John E. Conlon wrote:
>> Hi Tom,
>>
>> See comments below...
>>
>> Tom Schindl wrote:
>>> John E. Conlon schrieb:
>>>> Ed,
>>>>
>>>> see comments...
>>>>
>>>> Ed Merks wrote:
>>>>> John,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> John E. Conlon wrote:
>>>>>> I want to use the OCL Live validation constraints associated with the
>>>>>> model, to validate my ui databinding values. Haven't noticed this
>>>>>> nuance in the various discussions in
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=203492
>>>>> Wow, that's a long one.
>>>> scary too.
>>>>>> So am using an EMFUpdateValueStrategy as my targetToModelStrategy for
>>>>>> binding EMF model elements to ui controls, but I need either
>>>>>>
>>>>>> to 1. validate using the constraint before the set or
>>>>> That's tricky. Certainly with intrinsic constraints it's possible to
>>>>> validate a data value say, but often constraints span multiple
>>>>> features and can't be checked until the state has changed.
>>>> That the boat I'm in.
>>>>
>>>>>> 2. perform the set take the error and via the transaction facility
>>>>>> roll the model back to a previous value reseting the user interface
>>>>>> as well.
>>>>> Unfortunately I'm not all that familiar with the transaction APIs.
>>>>> If worst comes to worst, I imagine you can hook your way into
>>>>> EditingDomainEObjectObservableList.execute but I also imagine the
>>>>> transaction enabled stack might already do good things...
>>>> Yes the transaction stack does the right thing even when using
>>>> databinding ui(s). It's on the ui side that keeping things coordinated
>>>> is the problem though. see below...
>>>>>> It is the second approach that I have been attempting. Am doing
>>>>>> this by
>>>>>> overriding the EMFUpdateValueStrategy doSet(IObservableValue
>>>>>> observableValue, Object value), and tying in a
>>>>>> ModelValidationService.getInstance().addValidationListener() prior to
>>>>>> the doSet.
>>>>> Christian will know what that means, but he probably doesn't know much
>>>>> about data binding...
>>>> That listerner is notified when the ValidationService does it's thing
>>>> public void validationOccurred(ValidationEvent event) {
>>>> if(event.getSeverity()!=IStatus.OK){
>>>> ...
>>>>
>>>> Fairly straight forward way to find out that something bad may have
>>>> happened and grab and react to the status.
>>>>>>
>>>>>> Then if the ValidationListener records a failure result I return the
>>>>>> failed results from the doSet. This at least shows it on the status
>>>>>> label, but my ui control keeps the old invalid value displayed. In
>>>>>> other words the ui control shows a value now out of sync with the
>>>>>> model.
>>>>> The rollback type of approach would produce notifications...
>>>> It does but does, but these do not change the ui.??
>>>>
>>>
>>> Interesting because EMF-Observables work in both ways and I'm using this
>>> successfully in my CDO-Applications.
>> Not so familiar with CDO, but do you have constraints the cause
>> rollbacks of your sets?
>>
>>
>>>
>>> A workaround might be to force an UI-Update after having done the
>>> rollback with:
>>> - Binding#updateTargetToModel()
>>> - Viewer#refresh()
>> Thanks for the hint.
>>
>> My workaround is to pass the binding to my subclassed
>> EMFUpdateValueStrategy and in the overriden
>>
>> doSet(IObservableValue observableValue, Object value)
>>
>> and if the super.doSet causes a Live Validation error (resulting in a
>> rollback) perform a
>> binding.updateModelToTarget();
>>
>> this does the trick of syncing the ui!
>>
>>
>>>
>>> Still the really interesting thing is way the the UI is not kept in sync
>>> when a rollback is issued.
>> Perhaps this is because there may be an area of the code in the doSet
>> that ignores model changes?
>>
>>
>>>
>>> To commonly deal with your use case it looks like you need something
>>> like UpdateValueStrategy#setAfterSetValidator(IValidator), right?
>>
>> Actually would have expected sending an IStatus that was an Error (not
>> OK) would have triggered this behavior. WDYT?
>>
>> File a
>>> bug and explain your use case and post the Bug-Id here.
>> Here it is...
>>
>> 252612
>>
>> thanks for look at this Tom,
>> John
|
|
|
Goto Forum:
Current Time: Tue Apr 23 06:20:07 GMT 2024
Powered by FUDForum. Page generated in 0.02935 seconds |
] 
Search
Help
Register
Login
Home
