Home » Modeling » EMF » [Validation] Dynamic constraints?
|
| Re: [Validation] Dynamic constraints? [message #515040 is a reply to message #514961] |
Wed, 17 February 2010 14:31   |
|
Hi, Patrick,
I'm glad that the example was helpful.
I can think of two possible avenues for you to try. Constraints can be
dynamically removed from the registry (which is where the preference
page finds them), so if your provider detects some condition that
obsoletes a constraint, it can remove that constraint's descriptor from
the registry. It would be possible, then, to add it back later should
the need arise, and possibly with a different implementation.
I suspect, though, that probably your constraints are more dynamic than
this and don't need to be exposed to the user through the registry and
the preference page. In that case, a constraint provider can offer up
entirely new unregistered constraints every time that it is called upon.
These would be transient, and need only exist for the duration of the
validation operation.
I am assuming, of course, that (a) the framework didn't assume that
constraints were registered when last I worked on it, and (b) nobody has
changed that in the mean-time. It shouldn't be too hard to test this
theory by modifying the OCL example that uses a dynamic constraint
provider to load a *.ocl document. See if you can re-parse the OCL on
each invocation, creating throw-away (unregistered) constraint objects.
HTH,
Christian
On 17/02/10 05:17 AM, Patrick Könemann wrote:
> Hi newsgroup,
>
> I found the EMF Validation example (using OCL) in the Eclipse help.
> Very useful, thank you!
>
> All constraints are specified during design time AFAIK.
> But I would like to define additional (and maybe modify existing)
> constraints during runtime!
> Is that possible with EMF Validation?
>
> The problem is, if I understood it correctly, that all constraints are
> loaded from constraint providers (which are defined as extensions) and
> loaded only once.
> In other words, I cannot see how I could add a new constraint after the
> first validation was executed.
>
> Any ideas whether that is possible at all?
>
> Cheers
> Patrick
|
|
|
| Re: [Validation] Dynamic constraints? [message #515260 is a reply to message #515040] |
Thu, 18 February 2010 09:49 |
 Patrick Konemann
Messages: 116
Registered: July 2009 |
Senior Member |
|
|
Thank you Christian!
Comments inline.
Patrick
On 17-02-2010 15:31, Christian W. Damus wrote:
> Hi, Patrick,
>
> I'm glad that the example was helpful.
>
> I can think of two possible avenues for you to try. Constraints can be
> dynamically removed from the registry (which is where the preference
> page finds them), so if your provider detects some condition that
> obsoletes a constraint, it can remove that constraint's descriptor from
> the registry. It would be possible, then, to add it back later should
> the need arise, and possibly with a different implementation.
I didn't even know about the preference page ;-)
>
> I suspect, though, that probably your constraints are more dynamic than
> this and don't need to be exposed to the user through the registry and
> the preference page. In that case, a constraint provider can offer up
> entirely new unregistered constraints every time that it is called upon.
> These would be transient, and need only exist for the duration of the
> validation operation.
That sounds great! You're right, I probably do not need the registry.
In my case, the OCL constraints are not stored in some file but the user maintains them in a list during runtime.
So my first guess was to override AbstractConstraintProvider.getBatchConstraints. But then it happens that getBatchConstraints is called only once for the first validation. The validation framework apparently caches the constraints.
Making a constraint transient... how?
I just figured out that I can also remove constraints from the category, is that what you mean?
I tried adding all my constraints to a category, so the validation considers them (like in the example).
Then I removed them by calling Category.removeConstraint and started the validation again. Unfortunately the constraints are still checked. :-(
Could you maybe be more specific on how I can create these transient constraints or how I can remove constraints?
>
> I am assuming, of course, that (a) the framework didn't assume that
> constraints were registered when last I worked on it, and (b) nobody has
> changed that in the mean-time. It shouldn't be too hard to test this
> theory by modifying the OCL example that uses a dynamic constraint
> provider to load a *.ocl document. See if you can re-parse the OCL on
> each invocation, creating throw-away (unregistered) constraint objects.
>
> HTH,
>
> Christian
>
>
> On 17/02/10 05:17 AM, Patrick Könemann wrote:
>> Hi newsgroup,
>>
>> I found the EMF Validation example (using OCL) in the Eclipse help.
>> Very useful, thank you!
>>
>> All constraints are specified during design time AFAIK.
>> But I would like to define additional (and maybe modify existing)
>> constraints during runtime!
>> Is that possible with EMF Validation?
>>
>> The problem is, if I understood it correctly, that all constraints are
>> loaded from constraint providers (which are defined as extensions) and
>> loaded only once.
>> In other words, I cannot see how I could add a new constraint after the
>> first validation was executed.
>>
>> Any ideas whether that is possible at all?
>>
>> Cheers
>> Patrick
>
|
|
|
| Re: [Validation] Dynamic constraints? [message #515351 is a reply to message #515260] |
Thu, 18 February 2010 09:52 |
|
Hi, Patrick,
Sorry, I had forgotten about the cache. By default, the constraints
produced by providers are cached, but that can be disabled. The
<constraintProvider> element in the extension point schema has a "cache"
attribute which I see is still documented in the SDK as "for internal
use only." You should ignore that and set it to "false". :-)
You don't actually need to assign constraints to any categories,
especially if you don't need them to appear in the preference page.
If you use the default implementation of the IConstraintDescriptor
interface (AbstractConstraintDescriptor) then you will find that it adds
itself to the registry. You can avoid that by implementing the
interface, yourself. Or, you might be able to just remove the
descriptor from the registry post facto. The latter approach seems
somehow sloppy to me.
HTH,
Christian
On 18/02/10 04:49 AM, Patrick Könemann wrote:
> Thank you Christian!
>
> Comments inline.
>
> Patrick
>
>
> On 17-02-2010 15:31, Christian W. Damus wrote:
>> Hi, Patrick,
>>
>> I'm glad that the example was helpful.
>>
>> I can think of two possible avenues for you to try. Constraints can be
>> dynamically removed from the registry (which is where the preference
>> page finds them), so if your provider detects some condition that
>> obsoletes a constraint, it can remove that constraint's descriptor from
>> the registry. It would be possible, then, to add it back later should
>> the need arise, and possibly with a different implementation.
>
> I didn't even know about the preference page ;-)
>
>>
>> I suspect, though, that probably your constraints are more dynamic than
>> this and don't need to be exposed to the user through the registry and
>> the preference page. In that case, a constraint provider can offer up
>> entirely new unregistered constraints every time that it is called upon.
>> These would be transient, and need only exist for the duration of the
>> validation operation.
>
> That sounds great! You're right, I probably do not need the registry.
> In my case, the OCL constraints are not stored in some file but the user
> maintains them in a list during runtime.
> So my first guess was to override
> AbstractConstraintProvider.getBatchConstraints. But then it happens that
> getBatchConstraints is called only once for the first validation. The
> validation framework apparently caches the constraints.
>
> Making a constraint transient... how?
> I just figured out that I can also remove constraints from the category,
> is that what you mean?
> I tried adding all my constraints to a category, so the validation
> considers them (like in the example).
> Then I removed them by calling Category.removeConstraint and started the
> validation again. Unfortunately the constraints are still checked. :-(
>
> Could you maybe be more specific on how I can create these transient
> constraints or how I can remove constraints?
>
>
>>
>> I am assuming, of course, that (a) the framework didn't assume that
>> constraints were registered when last I worked on it, and (b) nobody has
>> changed that in the mean-time. It shouldn't be too hard to test this
>> theory by modifying the OCL example that uses a dynamic constraint
>> provider to load a *.ocl document. See if you can re-parse the OCL on
>> each invocation, creating throw-away (unregistered) constraint objects.
>>
>> HTH,
>>
>> Christian
>>
>>
>> On 17/02/10 05:17 AM, Patrick Könemann wrote:
>>> Hi newsgroup,
>>>
>>> I found the EMF Validation example (using OCL) in the Eclipse help.
>>> Very useful, thank you!
>>>
>>> All constraints are specified during design time AFAIK.
>>> But I would like to define additional (and maybe modify existing)
>>> constraints during runtime!
>>> Is that possible with EMF Validation?
>>>
>>> The problem is, if I understood it correctly, that all constraints are
>>> loaded from constraint providers (which are defined as extensions) and
>>> loaded only once.
>>> In other words, I cannot see how I could add a new constraint after the
>>> first validation was executed.
>>>
>>> Any ideas whether that is possible at all?
>>>
>>> Cheers
>>> Patrick
>>
>
|
|
|
| Re: [Validation] Dynamic constraints? [message #515373 is a reply to message #515351] |
Thu, 18 February 2010 15:31 |
Patrick Konemann
Messages: 116
Registered: July 2009 |
Senior Member |
|
|
Christian, thank you again!
I came across the cache-attribute quite some time ago but I forgot about it because I indeed thought it is "for internal use only" ;-)
Now I can implement IConstraintDescriptor.getBatchConstraints and I have all the flexibility I need.
There I should probably also do some caching for performance reasons :-)
One last question about categories and validation result presentation:
I saw it somewhere (can't remember where) that the validation results are structured as a tree (with two levels only) in the validation dialog. How can I do that? With categories? I saw that there are different ways of showing validation results:
- ErrorDialog.openError - taking IStatus as parameter
- DiagnosticDialog.openProblem - taking Diagnostic as parameter
I would like to have 3 constraint providers. Then the results of each provider should be grouped in the validation dialog.
Is that possible with both, IStatus and Diagnostics?
Maybe someone knows the answer right away, otherwise I'll have to try both ways...
Cheers
Patrick
On 18-02-2010 15:28, Christian W. Damus wrote:
> Hi, Patrick,
>
> Sorry, I had forgotten about the cache. By default, the constraints
> produced by providers are cached, but that can be disabled. The
> <constraintProvider> element in the extension point schema has a "cache"
> attribute which I see is still documented in the SDK as "for internal
> use only." You should ignore that and set it to "false". :-)
>
> You don't actually need to assign constraints to any categories,
> especially if you don't need them to appear in the preference page.
>
> If you use the default implementation of the IConstraintDescriptor
> interface (AbstractConstraintDescriptor) then you will find that it adds
> itself to the registry. You can avoid that by implementing the
> interface, yourself. Or, you might be able to just remove the descriptor
> from the registry post facto. The latter approach seems somehow sloppy
> to me.
>
> HTH,
>
> Christian
>
>
> On 18/02/10 04:49 AM, Patrick Könemann wrote:
>> Thank you Christian!
>>
>> Comments inline.
>>
>> Patrick
>>
>>
>> On 17-02-2010 15:31, Christian W. Damus wrote:
>>> Hi, Patrick,
>>>
>>> I'm glad that the example was helpful.
>>>
>>> I can think of two possible avenues for you to try. Constraints can be
>>> dynamically removed from the registry (which is where the preference
>>> page finds them), so if your provider detects some condition that
>>> obsoletes a constraint, it can remove that constraint's descriptor from
>>> the registry. It would be possible, then, to add it back later should
>>> the need arise, and possibly with a different implementation.
>>
>> I didn't even know about the preference page ;-)
>>
>>>
>>> I suspect, though, that probably your constraints are more dynamic than
>>> this and don't need to be exposed to the user through the registry and
>>> the preference page. In that case, a constraint provider can offer up
>>> entirely new unregistered constraints every time that it is called upon.
>>> These would be transient, and need only exist for the duration of the
>>> validation operation.
>>
>> That sounds great! You're right, I probably do not need the registry.
>> In my case, the OCL constraints are not stored in some file but the user
>> maintains them in a list during runtime.
>> So my first guess was to override
>> AbstractConstraintProvider.getBatchConstraints. But then it happens that
>> getBatchConstraints is called only once for the first validation. The
>> validation framework apparently caches the constraints.
>>
>> Making a constraint transient... how?
>> I just figured out that I can also remove constraints from the category,
>> is that what you mean?
>> I tried adding all my constraints to a category, so the validation
>> considers them (like in the example).
>> Then I removed them by calling Category.removeConstraint and started the
>> validation again. Unfortunately the constraints are still checked. :-(
>>
>> Could you maybe be more specific on how I can create these transient
>> constraints or how I can remove constraints?
>>
>>
>>>
>>> I am assuming, of course, that (a) the framework didn't assume that
>>> constraints were registered when last I worked on it, and (b) nobody has
>>> changed that in the mean-time. It shouldn't be too hard to test this
>>> theory by modifying the OCL example that uses a dynamic constraint
>>> provider to load a *.ocl document. See if you can re-parse the OCL on
>>> each invocation, creating throw-away (unregistered) constraint objects.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>>
>>> On 17/02/10 05:17 AM, Patrick Könemann wrote:
>>>> Hi newsgroup,
>>>>
>>>> I found the EMF Validation example (using OCL) in the Eclipse help.
>>>> Very useful, thank you!
>>>>
>>>> All constraints are specified during design time AFAIK.
>>>> But I would like to define additional (and maybe modify existing)
>>>> constraints during runtime!
>>>> Is that possible with EMF Validation?
>>>>
>>>> The problem is, if I understood it correctly, that all constraints are
>>>> loaded from constraint providers (which are defined as extensions) and
>>>> loaded only once.
>>>> In other words, I cannot see how I could add a new constraint after the
>>>> first validation was executed.
>>>>
>>>> Any ideas whether that is possible at all?
>>>>
>>>> Cheers
>>>> Patrick
>>>
>>
>
|
|
|
| Re: [Validation] Dynamic constraints? [message #515405 is a reply to message #515373] |
Thu, 18 February 2010 16:47 |
|
Hi, Patrick,
Categories are only grouping metadata for constraints. The preference
page organizes constraints by categories, but you can also use them for
your own purposes. Nothing provided "in the box" organizes validation
results by category.
Your constraints can, if you wish, provide complex status results by
creating multi-statuses using the appropriate ConstraintStatus factory
methods. Whatever kind of status is return by a constraint is glommed
into a multi-status by the validator, for another level of aggregation.
So, I wouldn't expect only one level of nesting in the ErrorDialog's
rendering of the validation result.
If you need to group results by provider, then you will need to
rearrange the children of the validator's multi-status result, yourself.
As each individual result implements the IConstraintStatus interface,
you can trace results to their originating constraints. Presumably you
will be able to trace your constraints to their providers (since your
providers are creating them) to accomplish your sort.
Cheers,
Christian
On 18/02/10 10:31 AM, Patrick Könemann wrote:
> Christian, thank you again!
>
> I came across the cache-attribute quite some time ago but I forgot about
> it because I indeed thought it is "for internal use only" ;-)
> Now I can implement IConstraintDescriptor.getBatchConstraints and I have
> all the flexibility I need.
> There I should probably also do some caching for performance reasons :-)
>
> One last question about categories and validation result presentation:
> I saw it somewhere (can't remember where) that the validation results
> are structured as a tree (with two levels only) in the validation
> dialog. How can I do that? With categories? I saw that there are
> different ways of showing validation results:
> - ErrorDialog.openError - taking IStatus as parameter
> - DiagnosticDialog.openProblem - taking Diagnostic as parameter
>
> I would like to have 3 constraint providers. Then the results of each
> provider should be grouped in the validation dialog.
> Is that possible with both, IStatus and Diagnostics?
> Maybe someone knows the answer right away, otherwise I'll have to try
> both ways...
>
> Cheers
> Patrick
>
--------8<--------
|
|
|
| Re: [Validation] Dynamic constraints? [message #515766 is a reply to message #515405] |
Sat, 20 February 2010 16:02 |
Patrick Konemann
Messages: 116
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Thank you very much!
That was very helpful.
Have a nice weekend
Patrick
On 18-02-2010 17:47, Christian W. Damus wrote:
> Hi, Patrick,
>
> Categories are only grouping metadata for constraints. The preference
> page organizes constraints by categories, but you can also use them for
> your own purposes. Nothing provided "in the box" organizes validation
> results by category.
>
> Your constraints can, if you wish, provide complex status results by
> creating multi-statuses using the appropriate ConstraintStatus factory
> methods. Whatever kind of status is return by a constraint is glommed
> into a multi-status by the validator, for another level of aggregation.
> So, I wouldn't expect only one level of nesting in the ErrorDialog's
> rendering of the validation result.
>
> If you need to group results by provider, then you will need to
> rearrange the children of the validator's multi-status result, yourself.
> As each individual result implements the IConstraintStatus interface,
> you can trace results to their originating constraints. Presumably you
> will be able to trace your constraints to their providers (since your
> providers are creating them) to accomplish your sort.
>
> Cheers,
>
> Christian
>
>
> On 18/02/10 10:31 AM, Patrick Könemann wrote:
>> Christian, thank you again!
>>
>> I came across the cache-attribute quite some time ago but I forgot about
>> it because I indeed thought it is "for internal use only" ;-)
>> Now I can implement IConstraintDescriptor.getBatchConstraints and I have
>> all the flexibility I need.
>> There I should probably also do some caching for performance reasons :-)
>>
>> One last question about categories and validation result presentation:
>> I saw it somewhere (can't remember where) that the validation results
>> are structured as a tree (with two levels only) in the validation
>> dialog. How can I do that? With categories? I saw that there are
>> different ways of showing validation results:
>> - ErrorDialog.openError - taking IStatus as parameter
>> - DiagnosticDialog.openProblem - taking Diagnostic as parameter
>>
>> I would like to have 3 constraint providers. Then the results of each
>> provider should be grouped in the validation dialog.
>> Is that possible with both, IStatus and Diagnostics?
>> Maybe someone knows the answer right away, otherwise I'll have to try
>> both ways...
>>
>> Cheers
>> Patrick
>>
>
> --------8<--------
|
|
|
| Re: [Validation] Dynamic constraints? [message #519336 is a reply to message #515351] |
Mon, 08 March 2010 09:46 |
Patrick Konemann
Messages: 116
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020803070707050400010101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Christian,
I'm sorry to bother you again. But for some unknown reason, without categories, I cannot get the validation working at all.
Attached is a minimalistic example of a ConstraintProvider creating one dummy constraint registered for Ecore models.
IConstraintProvider.getBatchConstraints is called as expected (also multiple times if cache = false) :-)
IModelConstraint.validate, on the other hand, is never called.
Any idea of what is missing?
Best regards
Patrick
On 18-02-2010 15:28, Christian W. Damus wrote:
> You don't actually need to assign constraints to any categories,
> especially if you don't need them to appear in the preference page.
>
> If you use the default implementation of the IConstraintDescriptor
> interface (AbstractConstraintDescriptor) then you will find that it adds
> itself to the registry. You can avoid that by implementing the
> interface, yourself. Or, you might be able to just remove the descriptor
> from the registry post facto. The latter approach seems somehow sloppy
> to me.
>
> HTH,
>
> Christian
--------------020803070707050400010101
Content-Type: application/octet-stream;
name="ValidationTest.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="ValidationTest.zip"
UEsDBBQACAAIAC58aDwAAAAAAAAAAAAAAAAZAAAAVmxpYWRhdGlvblRlc3Qv LmNsYXNzcGF0
aJWQwWoCMRCGzxX6DkvuztZCoYfdSikrVKiKbr2WmAzrtHESJ4no21dLpaUH obf5h28+hr8a
7jeu2KFE8lyrAdyoAtl4S9zV6rUd9e/V8OG6VxmnYww6rY/h6ichJzkUH8S2 VsazKk7LWnnp
AI2jEBHebQKnM5v10QnjefP2NJ20j8+TZl7+5YgTCmsHFle5g0zflyiwSJqt Frt8aQ8By/Ht
oukP4E6V/34oWATjBUFwm0nQzlzuiOMlVRRzVp3GC6TPKeR0hlfEX3BV/i7w E1BLBwhPww7k
zwAAAHYBAABQSwMEFAAIAAgALnxoPAAAAAAAAAAAAAAAABcAAABWbGlhZGF0 aW9uVGVzdC8u
cHJvamVjdL2ST08DIRDFz5r4HZq9C3rzQLeJNr1pTFq9jzCuNDAQYBs/voCs ZrMx8WC8zXsz
jx//xObdmtUJQ9SO1t01u+pWSNIpTcO6ezrsLm+6TX9xLnxwR5Rpi1EG7VOe zu6ZILDYPxsN
Cop3wJgEr2bpSmctUuoFn6ritqViFXymXkZt1N6jLKrJuxwFUtVpQBcGhtJo H5EdVWLShVzA
CWoAw/cWcgLCMBZ2bJrPDcEXlF9xvUJ2D6Rf85Fv/xe7l29o4U+gzZmuPPPS GLBNf4oF/tGM
g6aH2iz0OvRTYPY8tMhMdSF+/YX5J/sAUEsHCPVhsWHpAAAAowIAAFBLAwQU AAgACAAufGg8
AAAAAAAAAAAAAAAAHwAAAFZsaWFkYXRpb25UZXN0L2J1aWxkLnByb3BlcnRp ZXMrzi8tSk7V
01OwVSguStbn5covLSkoLQELJGXmAQWApF5mXnJOaUpqMVDQ1zXEUdfTz01f J4aXSwEV6GER
K8gpTQeaUJGbw8sFAFBLBwgjePZ6SgAAAG0AAABQSwMEFAAIAAgALnxoPAAA AAAAAAAAAAAA
ABkAAABWbGlhZGF0aW9uVGVzdC9wbHVnaW4ueG1spVRNj9MwEL0j8R8i37HL wgGhZCsWLUeo
xO4PcJ1pa0hsy3b68e8ZJ25rJ+mugJxaz8ybN+/ZUy6PbVPswTqpVUXe0wUp QAldS7WtyPPT
t3efyPL+7ZtyCaKRxsE19wP9OIRM022lwl9FUZRw9KBCQv93+GRdEQ/Or6ze yxosSWKKt5BH
v+NJmmG0VL4i2m5p5ECh3dA9b2TNPXaiQivnLce0M4Yj92eEchpNwPETXOyQ woY3LusbQg13
riJJqyck+nUCOCprdY2AD9yL3ZVHoGK4+M23kGdHERwG4dnKiuy8N58ZOxwO l4FxeIZDs7vF
4o49Cm0hB2YR+To1m44dHWIXi8aWzUndSeo8t74ziaTxZEafnzGX3Wh264rM dA5TUjgaCy4k
O2qsNmD9KXiQW5xHXvPw8cf6F4ggS1I0sjBc2b8suZiYVfKam2luJCwBmcFq 8G6U4k8Gprce
elUinUQBlkvw/+rffGIPUoXlkMq/Ho5Gul8qhuf96qvBAo/kZtVLBo3Nkvfd SFABPlS/6OIE
rddD8XUDLUKkx0UZOE8earHRVsCqX3hfhJf7HhgHtN3Yv8Tm0xwLesP38GF2 B/+yCFCfwDvf
DTMT4npIVZu7Lnilznv9D1BLBwijHAvH2AEAACUGAABQSwMEFAAIAAgALnxo PAAAAAAAAAAA
AAAAACMAAABWbGlhZGF0aW9uVGVzdC9NRVRBLUlORi9NQU5JRkVTVC5NRm2O uwrCQBBF+3xF
PsAsGrCJ2AhpBC2M2MfkRgb2YWZ3g/6962ODBpluzrkzd1dr6mBddgJbMrpI F2KebLxuJbLd
B44sj2RfKxTpqZbU1i6gY7Aiq+7qbCQ1/5yVJX2RcOHY2rFHzHx/D9P7kOoI HPkBvSdGW97Q
+OexUg/ERitoV6TbvCqzhVgmHy17p4rU8EWgkXS1EFCdGMYys+QHNoYh2GtH ChPkSVA7Xb58
3K4M++xtkwdQSwcIgVM9sbUAAABIAQAAUEsDBBQACAAIAC58aDwAAAAAAAAA AAAAAAA4AAAA
VmxpYWRhdGlvblRlc3Qvc3JjL3ZhbGlkYXRpb24vRU9iamVjdFByb3BlcnR5 VGVzdGVyLmph
dmGFUEtLAzEQPqfQ/zD2UBIo6Q8oPYkHL1p8XcRDmp1d06ZJzKNUxP9uspst VAQvecx8rxkn
5F50CEehVSOismY1nUwn6uCsj2B9x1Fq5QJyaT1yPDmPIWRY4BtvHfr4+YQh ol/9ScJDm9+F
eXO/3aGM/8I2Q6A+hUtbrSRILUKAKnDpCniKaJoAv8pfhU4qf2utRmEg5h4d VMCjRHVEv4DH
6JXpwFWBBQyI1zcQvgvjNxu5fGHzInRCVgwIGYXzSpKOsIZW6DBEJ0S1QGdY x5lx/Ei5SUcb
ViVIq4zQMI4NQsaMy1KU1oHZOSvjeF1WQRnvMI4UyqohWS5BvqPcQ2s9mKQ1 7FKIoAxIEbCH
nJPSanS17pEM5vPqXbTvwvPDbbapoS9nXxWl78HTY0x+XEBp9PV8/ABQSwcI rOuZSjUBAABY
AgAAUEsDBBQACAAIAC58aDwAAAAAAAAAAAAAAAA0AAAAVmxpYWRhdGlvblRl c3Qvc3JjL3Zh
bGlkYXRpb24vRVZhbGlkYXRvckFkYXB0ZXIuamF2Ya1Ya2/byBX9TP2KWWAB U4FCZQsUBeIk
iONsUSFxHKzd/VIUxYi8kmZDcYgZUqq60H/vufMgqZedRWvAlji878e5dzx9 8WIkXog3ua53
Ri1XzTs88sltPBBpPhZ/evXqzxP++xcx+3CHl6bWRjZKV0JWhdDNiozNmO+m LIXjs8KQJbOh
IhNCPK6UFbXRSyPXjgUcQua5Xtey2qlqKdayIaNkaVmKNISDAiQbqUo5L0m0 VUHGsYFubYVe
uIef81LVlsTXdl6qXHxWOVV43PyUvWJB25XKV50iRRZMsKRQtjFq3rIHE2cP DntdsmHeVdPU
r6fT7XabkdeSabOclrSU5ZTq8uXmp1fZqlmXXcgqL1Qb+5oPhAvWSzGrVAPP xM3Xmde1rkta
U9W4CAbuN9OTHPw4K37E53Q0GtUy/yaX8EuWqnBs16MR5GjTiN9geAZXyuxO 1v0xbO3szrWh
zLRVo9aUzR6guLXXzxJ+acvyK+eMrL3TcEKb55meEE7rBWjXa115cz9Iq/KP Si4rbRuVfxdP
T367kqq6yEPOqJ9vS2kvGxOIPspGPu5qeo7ufv4b5c0zVM7KQPqrzxaH7RJT n9BsrQsCK05a
d3CH54vKTvhmKD8UNWLSPJOCASs3KDomm32QTb4amPv9rGxl+Wt3/uCP4fBo 6rHlBhhRyLpx
3SsbUZft0vrevfurcOyi5xdBgGsW+KKZksX8/r5U1bdLqelM3zNj5rqm9pCQ cwmInuLGGzNK
6N8NVQVeHSVL/D4aJWx8ArUX7YNtZBYS3xZgmXP8Bt3J8MTukW90YGPCJiW1 URsAnVioCoBw
FHYvZZCFpLcjYIj6DyAMXRbFeRdPnEvHcCJJbFvzdwiCpORQungrzqcuW1Iz QynJKqd0nFW0
7XhSSEmSwwrNPtw83v7N6ThUgAqBnLxsC/qsNtSXp00b09IFjl+IC++hzXOA DvWke+Tk/f2G
jFEFdY7PtS5JVjHwlIZcCvKfE3GEF0D++Gwn7A0g802k9Z/vRA4gR3H4GBpq WjPQECRn5KAl
HU96XUPZnZBge5fHiP12WC3znUAqMFjcky96Vz8DmgVGJ221+RaT/z3hcEYK b+tEHEeHA/BU
gMSz0ZlOUcrGsvMawxY6N2FKzxncMZ7Rnn3NFZpsrMusD2kw79lAchWH6SWs /3gr/HN2/+lf
D483j39/CHSwrNKi1ig49GoXSGwaaiG2JHJZXTXYURzOYcK1ZcOm4WU6UC9+ eCsqjEHvLQtV
iw63zsGCLA3JYgerEQjye45t5y8bQzQJIvDj9xLVuIg4BKHFQuUKhSF4V2mb frtCkvHeWwr7
B1IgHAnTwRECuKasr0+pkpXXwMeG8tZY3jg6AQyBBkhU7sbY0mZupcLqhWUI sQuBxyJWT7yq
GLZewIrKGm7wAUfuh5W02Bhc7xZpl8+YwhDFpMvdUf93FeGokmGZJgmASJzZ SNKxqwyX8wT4
ekn5JFTMkFrWNSZAHy6bepqDCvQM+5H/7RHBk2bK3n9Kj7v8ozLcZ4fzIEyw bt3YWx/oBgVS
c3JRLgCC0PpOzrn2v2aKnVuRY7ywUlaFU1nuxEZJNzOTfmiGvt9bP4FXunSF qQxLaMn+EUSJ
1guK3yI0eGH/B1CJAT5CiV6fV/QE3g4Hp+v2ldygNw9L2vDuUPgLgXZ2XFm+ CRX0zueWV3I8
MHxwiUOY1T6CkLhVuOl8q/RWlLLbbaKmrgy5xd3KD7yPMOCiLdyf97XkC1Go VVDGheFQXJfn
IVP0heslfk/XcifmFLxg4Ao+jIecof2YMai7OphG/v3RxrLRquj9Oh20T2R1 Ig5B22eZ8SLa
fYiy4TQDCvZtPOje/VGKPxJfCVUFnNuuiCHsTCJcmn1cgsyY3jkBf7luIQr9 J3GBw2UUxd8B
ZnfZfGJhzcIlV7nACV2hFWttreILpR85hZ5woxIVk6OC/L6S0JzavudTdlKj EwEh4/+1MkLP
+de8dHXFvziQExDrRAxXuZMU5tL5UGOO6Yo4nNwQLBPoQMYiHLYbnXOiqhPV uXstgsiFLG20
buL/9bBVlo7KNQLXwUD6I0XrazGK8QsCJpbTHlaMyxWM4dj4YhD36ZdSL7+M xbxt/Hi9ctOV
J6fbRtzwxD6AMonVfiRtqCgLQbOfaBfJu7madGZyBq8PpqjwIv3hHkVlKXL1 FP1yG1OThnm5
Pz8EvcJjzAU3BgkyLCPWBMMWRq/P7bbhMsklPgD1064YINd5CVf2UOOQebjW ycGTyN2Mgm6Z
5+26ZTyPG6HQ1TkcPF0cDhHuyXtHD3/dCnEHXcpLSGM2g8R//BP2qbIw2L/e xqUDV7TbcBgS
xL+8RnaGRNR43bHHKjk1PtBeWnt8sfQGA8T89RB9fPJvh6BlmEZZFClvb0f/ 70kHuyB79MB3
B9XscKc6evO1bJeqOj2/BQacnt6h2eWye5GmZ2wM04TJf3GZ/qxzjn3W6Btj JGwY96NmtB/9
F1BLBwgEkyZkRAcAACgVAABQSwMEFAAIAAgALnxoPAAAAAAAAAAAAAAAACoA AABWbGlhZGF0
aW9uVGVzdC9zcmMvdmFsaWRhdGlvbi9TdGFydHVwLmphdmGFUk1v2zAMPUe/ gocekqCV0wG7
NMWArMjBwFYEa9E7I7O2MFkSKDlGMPS/j7bzMWADdrHMx/fIR0rFcqlgCY8m xCPbuslfJByQ
pzMAc7OAT6vVZyi/fheYY2DMNnhAX0HIDXHSg2LjHIyKBEyJ+ECVBoDXxiaI HGrGdpSIAtCY
0Eb0R+traDETW3RpqIJMAlRCOaB1uHcEna+IR5nw2gThfQy2xtmYCHbd3lkD 36whL+HhXq+G
Qn1jTXNpZCmJSJxUNmW2+26Y4Hb0I+C1F+ZB2+QcH4qi73tNUxcduC4c1egK iu7ucL/STW7d
ZVl+Kho4PQwAjMu6g9LbLJPBZldOvdroqCWfxw2e1I/FX9u/KasbOQulIpqf WMtY6Gw1qtZK
SZnAGcTTxR+17/IfmPT2baIGXv+HOHx3U/1/Ujury5eMnLsoTeO0Z+MwJTjB 14ESnKnwS6nZ
iXwItgJCdsdTcr6Q9Gx29ah/UD1cyVGXzy+vm+enrY5dnv/pTdM5dQueeriK NxVGeRPzxWKt
Zh/qQ/0GUEsHCOKy8GGTAQAAzwIAAFBLAwQUAAgACAAufGg8AAAAAAAAAAAA AAAAOQAAAFZs
aWFkYXRpb25UZXN0L3NyYy92YWxpZGF0aW9uL1Rlc3RDb25zdHJhaW50UHJv dmlkZXIuamF2
Ya1W34/TOBB+LhL/w1yfUsEZCfHE7sLtlp6uErCrbXUviAfXmXYNiR3ZTmiF +N9v7CRN2qS/
0ElV6tjzfTP+ZsZOxsV3vkIoeCJj7qRWV8+fPX8m00wbB994wVnuZMJujeGb j9K6q57FsU4S
FBX4yKrtW56ha7vUZsVQJDKzyIQ2yEyunEyRTWeOu7xF0bbEdEnWaaoVU9rJ 5YZ99n9S8N2o
9jEYXEzGCbdHmCur+8U32sdhs0ZDNv13Ox5r5XB9HizVMZJg3OFKm80lEBLX GS6Vm2GBRrpL
wBOaycPEJ3q/ADj19knj+wLo7yAtmkIKZLcLjxKugT8YXcgYzUU00wb/Aa0w MnPahFLM8kUi
BQhfFTBH2+MJKKWoYguHg4Gfnmvw1z0lxNAEjSvipiOu9yV8Byt0d9yJp2bO RlXpAZb/L48z
iAY58kEMBrONdZgynTuWGZpPVDTs8QOCE20MUsEQXoB7knZ0Ba9ehRHI7bpW AiESXDwh3IAz
OY5IcEjzxMksQfD9ahuDJU8sWbz9c+RjkUtaafm8uQGVJ0lYG+wsgMIfsD14 uhuNRlce1MIw
HsdRnKfpZs82GpW2Bl1uVFshP/0rJIqUKajzYN8P9BOWylaEPtJ9iwDrlgWF UlXGoK6H6mir
D2GMuscHCLeuXPans0FUWXobcuhhIYXKnwvV0h+Ui6ikqgVxayYMku+/uUxy g2VEkd9XWXNf
vsJPGDpqBnjzesvNqIrm3NAzGjEMxygN6PUzT5E0+lXK7hWmR4/WfT0IB5Xr aN6LjzoCL7RO
kCtwIVQ732R4v9zvqqPyrtfr4TlCVlzUQtZxahO9hO3tUupwJK5JgVQ37ZsL VOvlfwkwNGNv
ML7UKYoy82Mq5mjrsMK+ed0L7F4+gacad1i65mzy+Hj/2Ms9c7TBled7SPKV VNO4w9cqfX9W
D0/wVJW5xzHOrdMpVPV9iuMTWktfTQ/cOTSqyxZomkPmDMa+fXmWQ8jdO/v6 fbg3dic7hLvL
7O52Pv7nRFh1UxGmG9/tgiow3I9nbPBOx91SGIZq7IcWWsZA53n9NRTVAyrt clCz7ftEd13b
BlmqF4m2pxa336b0mZC5zcyfZL3xzJ+M/sEXdL15pdcC+1Xxd9nRXpc2XLsd oL9GTwAnyvvv
Vso5UGO0+R3gR1l0K+nwIRKyZjDVBV6cuIC1JG61zToILN9PocIOmyxhnaIW rrmD6PcfUEsH
CPGKHUeSAwAA+wwAAFBLAQIUABQACAAIAC58aDxPww7kzwAAAHYBAAAZAAAA AAAAAAAAAAAA
AAAAAABWbGlhZGF0aW9uVGVzdC8uY2xhc3NwYXRoUEsBAhQAFAAIAAgALnxo PPVhsWHpAAAA
owIAABcAAAAAAAAAAAAAAAAAFgEAAFZsaWFkYXRpb25UZXN0Ly5wcm9qZWN0 UEsBAhQAFAAI
AAgALnxoPCN49npKAAAAbQAAAB8AAAAAAAAAAAAAAAAARAIAAFZsaWFkYXRp b25UZXN0L2J1
aWxkLnByb3BlcnRpZXNQSwECFAAUAAgACAAufGg8oxwLx9gBAAAlBgAAGQAA AAAAAAAAAAAA
AADbAgAAVmxpYWRhdGlvblRlc3QvcGx1Z2luLnhtbFBLAQIUABQACAAIAC58 aDyBUz2xtQAA
AEgBAAAjAAAAAAAAAAAAAAAAAPoEAABWbGlhZGF0aW9uVGVzdC9NRVRBLUlO Ri9NQU5JRkVT
VC5NRlBLAQIUABQACAAIAC58aDys65lKNQEAAFgCAAA4AAAAAAAAAAAAAAAA AAAGAABWbGlh
ZGF0aW9uVGVzdC9zcmMvdmFsaWRhdGlvbi9FT2JqZWN0UHJvcGVydHlUZXN0 ZXIuamF2YVBL
AQIUABQACAAIAC58aDwEkyZkRAcAACgVAAA0AAAAAAAAAAAAAAAAAJsHAABW bGlhZGF0aW9u
VGVzdC9zcmMvdmFsaWRhdGlvbi9FVmFsaWRhdG9yQWRhcHRlci5qYXZhUEsB AhQAFAAIAAgA
LnxoPOKy8GGTAQAAzwIAACoAAAAAAAAAAAAAAAAAQQ8AAFZsaWFkYXRpb25U ZXN0L3NyYy92
YWxpZGF0aW9uL1N0YXJ0dXAuamF2YVBLAQIUABQACAAIAC58aDzxih1HkgMA APsMAAA5AAAA
AAAAAAAAAAAAACwRAABWbGlhZGF0aW9uVGVzdC9zcmMvdmFsaWRhdGlvbi9U ZXN0Q29uc3Ry
YWludFByb3ZpZGVyLmphdmFQSwUGAAAAAAkACQD4AgAAJRUAAAAA
--------------020803070707050400010101--
|
|
|
| Re: [Validation] Dynamic constraints? [message #519481 is a reply to message #519336] |
Mon, 08 March 2010 23:24 |
|
Hi, Patrick,
Sorry, I don't really have the time (or the set-up) to look at code
attachments.
However, this does sound like the classic "client context" problem. I
think your constraints are being filtered out by the validator because
it can't find a client-context matching the model elements to be
validated with the constraints that it found. I think categories are a
common way to bind constraints to client-contexts (my memory is fading),
but the binding can be done on a per-constraint basis, too ... see
whether you can set up those bindings in your constraint provider.
You might also search back in the newsgroup archive to see other cases
where the client-context bindings (lack thereof) have tripped people up.
There may be more than one solution.
HTH,
Christian
On 08/03/10 09:40 AM, Patrick Könemann wrote:
> Hi Christian,
>
> I'm sorry to bother you again. But for some unknown reason, without
> categories, I cannot get the validation working at all.
> Attached is a minimalistic example of a ConstraintProvider creating one
> dummy constraint registered for Ecore models.
>
> IConstraintProvider.getBatchConstraints is called as expected (also
> multiple times if cache = false) :-)
> IModelConstraint.validate, on the other hand, is never called.
>
> Any idea of what is missing?
>
> Best regards
> Patrick
>
>
> On 18-02-2010 15:28, Christian W. Damus wrote:
>> You don't actually need to assign constraints to any categories,
>> especially if you don't need them to appear in the preference page.
>>
>> If you use the default implementation of the IConstraintDescriptor
>> interface (AbstractConstraintDescriptor) then you will find that it adds
>> itself to the registry. You can avoid that by implementing the
>> interface, yourself. Or, you might be able to just remove the descriptor
>> from the registry post facto. The latter approach seems somehow sloppy
>> to me.
>>
>> HTH,
>>
>> Christian
|
|
|
| Re: [Validation] Dynamic constraints? [message #519523 is a reply to message #519481] |
Tue, 09 March 2010 08:31 |
Patrick Konemann
Messages: 116
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Thanks a lot, I got it working!
Comments below.
On 09-03-2010 00:24, Christian W. Damus wrote:
> Hi, Patrick,
>
> Sorry, I don't really have the time (or the set-up) to look at code
> attachments.
Sure, that's totally ok!
>
> However, this does sound like the classic "client context" problem. I
> think your constraints are being filtered out by the validator because
> it can't find a client-context matching the model elements to be
> validated with the constraints that it found.
I had the client context working, the problem was the binding - see below.
> I think categories are a
> common way to bind constraints to client-contexts (my memory is fading),
> but the binding can be done on a per-constraint basis, too ...
True, the binding can be defined for a *constraint* or for a *category*.
However, since I have dynamic constraints, their ids are unknown during design time. Hence, I cannot define these ids in the binding definition in the plugin.xml.
What I would have needed is a binding for a *ConstraintProvider* - and that is apparently not possible.
So what I did is to add a Category again for each constraint provider.
Defining the bindings for each category finally worked! :-) :-) :-)
Thank you again!
Patrick
|
|
|
| Re: [Validation] Dynamic constraints? [message #519626 is a reply to message #519523] |
Tue, 09 March 2010 14:20 |
|
Hi, Patrick,
I'm glad you got this working. I hope, though, that the necessity of
categories isn't a problem for you (that they won't get in your way or
clutter your UI). Really, though, they shouldn't be necessary:
categories are supposed to be optional. Probably, you have found a bug.
Being able to define context bindings to constraint providers would add
an undesirable coupling: consumers of constraints (applications that
identify themselves via client-contexts) shouldn't care who supplies the
constraints.
cW
On 09/03/10 03:31 AM, Patrick Könemann wrote:
> Hi Christian,
>
> Thanks a lot, I got it working!
> Comments below.
--------8<--------
|
|
|
Goto Forum:
Current Time: Thu Apr 25 08:36:45 GMT 2024
Powered by FUDForum. Page generated in 0.04257 seconds |
] 
Search
Help
Register
Login
Home
