Home » Modeling » EMF » Model Integrity in EMF with MDT OCL
| | |
| Re: Model Integrity in EMF with MDT OCL [message #424564 is a reply to message #424549] |
Thu, 30 October 2008 02:12   |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Cristina,
In addition to Gary's note, I should add that no attempt has been made
(that I know of) to port the templates in the article to EMF 2.4 (the
Ganymede version). The article was originally written for EMF 2.2 and
was later updated for 2.3. It is quite likely that the EMF templates
extended by the article were changed in the 2.4 release such that the
extensions no longer work.
So, if you can get it working with the Europa (2.3) version, then you
might enjoy contributing an update of the article. :-)
Can you guess why this example is a one-off article and not an official
OCL SDK Example plug-in? ;-)
Cheers,
Christian
Cristina wrote:
> Hi again,
> I have just realized something when tracing the errors I mentioned in my
> previous post (e.g. "Company cannot be resolved as a type")...
> The classes implementing the metamodel concepts (Employee, Department,
> and Company) ARE EMPTY!!
>
> /org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/(*)
>
>
> (*) Employee.java, Department.java, Company.java => EMPTY
>
> /org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/impl/(**)
>
>
> (**) EmployeeImpl.java, DepartmentImpl.java, CompanyImpl.java => EMPTY
> Thus, I think it is a generatino problem with the JET templates!! :S
>
> Any idea?
>
|
|
| | | | | |
| Re: Model Integrity in EMF with MDT OCL [message #424709 is a reply to message #424701] |
Mon, 03 November 2008 12:35 |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Tristan,
I'm not really quite sure what you're asking. Many folks like to use
OCL to express constraints so I imagine a good solution would make that
easy, but would be extensible so that any expression language could be
used... The extended Validation Framework already has all kinds of
support for this stuff, but it's more focused on contributing
constraints that are external to the model and can be individually
turned on and off, whereas in EMF core we're focused on constraints that
are intrinsic to the model and must always be satisfied...
Tristan FAURE wrote:
> Hi Ed
>
> I have been visited your links and i agree with your solutions
> but why can't we imagine a solution using EMF validation framework
>
> Don't you think it could be simpler to design a solution using it ?
> (or maybe i didn't evaluate all the problems)
>
> Ed Merks a écrit :
>> Tristan,
>>
>> There's https://bugs.eclipse.org/bugs/show_bug.cgi?id=191689 so I
>> agree it would be useful, but nobody has copious spare time. In an
>> ideal world, the design might be more like
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701 where downstream
>> plugins could contribute their "validation language" extensions much
>> like this bugzilla does for derived features. A potential advantage
>> of that is that it could then be applied for dynamic as well as
>> generated models. So many good ideas, so little time...
>>
>>
>> Tristan FAURE wrote:
>>> Hi everybody
>>>
>>> I've followed the discussion and i often visit the tutorial from Mr
>>> Damus on Eclipse wiki.
>>> And every time i answering why this kind of behaviour (putting ocl
>>> constraints in eAnnotations) is not by default integrated in emf/ocl ?
>>> it could be good to have an option in eclipse preferences : activate
>>> JET templates for OCL
>>> and getting the behavior described in the tutorial ?
>>> what do you think about ?
>>>
>>> Regards
>>>
>>> Ed Merks a écrit :
>>>> Cristina/Christian
>>>>
>>>> It wold probably be helpful to maintain something on the wiki
>>>> <http://wiki.eclipse.org/MDT-OCL>
>>>>
>>>> http://wiki.eclipse.org/MDT-OCL
>>>>
>>>> Or maybe folks are more likely to find it among the EMF recipes:
>>>> <http://wiki.eclipse.org/EMF/Recipes>
>>>>
>>>> http://wiki.eclipse.org/EMF/Recipes
>>>>
>>>>
>>>> Cristina wrote:
>>>>> Thank you very much for your answers !!
>>>>>
>>>>> If I manage to adapt/implement a solution for EMF 2.4 (Ganymede
>>>>> version), I will post it for anyone having the same problem!! :D
>>>>>
>>>>> Cheers!
>>>>>
>>>>> Cristina
>>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #424719 is a reply to message #424709] |
Mon, 03 November 2008 13:12 |
Tristan Faure
Messages: 460
Registered: July 2009 |
Senior Member |
|
|
Ed,
Okay you answered my question thank you
i will check my current tasks and I will see if it is possible for me to
contribute for this request (but i'm not very familiar with eclipse process)
Ed Merks a écrit :
> Tristan,
>
> I'm not really quite sure what you're asking. Many folks like to use
> OCL to express constraints so I imagine a good solution would make that
> easy, but would be extensible so that any expression language could be
> used... The extended Validation Framework already has all kinds of
> support for this stuff, but it's more focused on contributing
> constraints that are external to the model and can be individually
> turned on and off, whereas in EMF core we're focused on constraints that
> are intrinsic to the model and must always be satisfied...
>
>
> Tristan FAURE wrote:
>> Hi Ed
>>
>> I have been visited your links and i agree with your solutions
>> but why can't we imagine a solution using EMF validation framework
>>
>> Don't you think it could be simpler to design a solution using it ?
>> (or maybe i didn't evaluate all the problems)
>>
>> Ed Merks a écrit :
>>> Tristan,
>>>
>>> There's https://bugs.eclipse.org/bugs/show_bug.cgi?id=191689 so I
>>> agree it would be useful, but nobody has copious spare time. In an
>>> ideal world, the design might be more like
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701 where downstream
>>> plugins could contribute their "validation language" extensions much
>>> like this bugzilla does for derived features. A potential advantage
>>> of that is that it could then be applied for dynamic as well as
>>> generated models. So many good ideas, so little time...
>>>
>>>
>>> Tristan FAURE wrote:
>>>> Hi everybody
>>>>
>>>> I've followed the discussion and i often visit the tutorial from Mr
>>>> Damus on Eclipse wiki.
>>>> And every time i answering why this kind of behaviour (putting ocl
>>>> constraints in eAnnotations) is not by default integrated in emf/ocl ?
>>>> it could be good to have an option in eclipse preferences : activate
>>>> JET templates for OCL
>>>> and getting the behavior described in the tutorial ?
>>>> what do you think about ?
>>>>
>>>> Regards
>>>>
>>>> Ed Merks a écrit :
>>>>> Cristina/Christian
>>>>>
>>>>> It wold probably be helpful to maintain something on the wiki
>>>>> <http://wiki.eclipse.org/MDT-OCL>
>>>>>
>>>>> http://wiki.eclipse.org/MDT-OCL
>>>>>
>>>>> Or maybe folks are more likely to find it among the EMF recipes:
>>>>> <http://wiki.eclipse.org/EMF/Recipes>
>>>>>
>>>>> http://wiki.eclipse.org/EMF/Recipes
>>>>>
>>>>>
>>>>> Cristina wrote:
>>>>>> Thank you very much for your answers !!
>>>>>>
>>>>>> If I manage to adapt/implement a solution for EMF 2.4 (Ganymede
>>>>>> version), I will post it for anyone having the same problem!! :D
>>>>>>
>>>>>> Cheers!
>>>>>>
>>>>>> Cristina
>>>>>>
|
|
| | | | |
| Re: Model Integrity in EMF with MDT OCL [message #425155 is a reply to message #425147] |
Mon, 17 November 2008 17:57 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Tristan,
The article that is the subject of this thread addresses only generated
Ecore models, as it extends the code generation process.
For early access to (and feed-back) on some ideas that will support
dynamic models, have a look at:
http://bugs.eclipse.org/216701
http://bugs.eclipse.org/255469
Cheers,
Christian
Tristan FAURE wrote:
> Hi !
>
> I've been watched and executed EMF code for a long time. And i don't
> really know how to implement the constraint mechanisms if I follow the
> OCL tutorial I think this mechanism only works with EMF generated code
> and not for dynamic instance
> And when i see Dynamic instance mechanism I don't understand how it can
> work with Generated code
>
> In fact are the mechanisms duplicated to work with the two mechanisms ?
>
> Ed Merks a écrit :
>> Tristan,
>>
>> Comments below.
-----8<-----
|
|
| |
| Re: Model Integrity in EMF with MDT OCL [message #425179 is a reply to message #425175] |
Tue, 18 November 2008 14:20 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Tristan,
The enhancements that I referenced in bugzilla are extensions to the
Ecore modeling capability. The core EMF run-time provides on-demand
validation through EValidators but never evaluates constraints
on-the-fly in setter methods, if that is what you mean.
The code-generation approach of the article fits within the same bounds
of the core run-time and the Ecore metamodel.
Of course, the constraints defined in an Ecore model that are recognized
by the EValidator API can also be evaluated in "live" or "batch" mode
validation in the EMF Validation Framework. It's a simple matter to
delegate from the constraint providers of that system to EValidators.
Cheers,
Christian
Tristan FAURE wrote:
> Thank you for answer
>
> i have a question we talk about providing feature for Model constraints
>
> Are we talking about defining constraints validated during Validation
> process or Integrity constraints where the constraints are checked for
> each model notification ?
>
> Christian W. Damus a écrit :
>> Hi, Tristan,
>>
>> The article that is the subject of this thread addresses only
>> generated Ecore models, as it extends the code generation process.
>>
>> For early access to (and feed-back) on some ideas that will support
>> dynamic models, have a look at:
>>
>> http://bugs.eclipse.org/216701
>> http://bugs.eclipse.org/255469
>>
>> Cheers,
>>
>> Christian
>>
>> Tristan FAURE wrote:
>>> Hi !
>>>
>>> I've been watched and executed EMF code for a long time. And i don't
>>> really know how to implement the constraint mechanisms if I follow
>>> the OCL tutorial I think this mechanism only works with EMF generated
>>> code and not for dynamic instance
>>> And when i see Dynamic instance mechanism I don't understand how it
>>> can work with Generated code
>>>
>>> In fact are the mechanisms duplicated to work with the two mechanisms ?
>>>
>>> Ed Merks a écrit :
>>>> Tristan,
>>>>
>>>> Comments below.
>>
>> -----8<-----
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #425181 is a reply to message #425175] |
Tue, 18 November 2008 14:28 |
Tristan Faure
Messages: 460
Registered: July 2009 |
Senior Member |
|
|
Hi all
i didn't wait for your answer but if i go to the wrong direction i can
study other solution.
I have designed for my solution where models constraints are checked
with validate menu
the developer :
- creates a factory designed to create its validator
the validator has to implement a validate method :
"boolean validate(String value, EObject object, DiagnosticChain
theDiagnostics, Map<Object, Object> context)"
the parameter value is the string provided by the user it can be OCL
rule, class name, it's just a String and the method knows how to manage it
- adds an extension point referencing its factory and the uri associated
to it
the user :
- designs its metamodel
- puts its constraints with eannotations and the factory used (here for
example OCL)
- Ecore
+ constraints
-> constraint1 constraint2 constraint3
+ factory
-> org.eclipse.ocl#OCL
// org.eclipse.ocl : the factory uri
// OCL the key for defining the constraints
- OCL
+ constraint1
-> self....
To implement this i add behaviour to EObjectvalidator which
1) will check constraints
2) registers the factory and the key
3) check if there is key
4) check if there is constraints defining previously
5) ask the factory to create a validator and validate the current object
The factories are loaded with emf.ecore plugin with all other facotries
(factory_override for example)
I started to test and it seems it works with dynamic instance and
generated EMF code. Maybe i don't see limitations to my solutions
particularly i don't know if it is always possible to resolve EAnnotations
what do you think about ?
Tristan FAURE a écrit :
> Thank you for answer
>
> i have a question we talk about providing feature for Model constraints
>
> Are we talking about defining constraints validated during Validation
> process or Integrity constraints where the constraints are checked for
> each model notification ?
>
> Christian W. Damus a écrit :
>> Hi, Tristan,
>>
>> The article that is the subject of this thread addresses only
>> generated Ecore models, as it extends the code generation process.
>>
>> For early access to (and feed-back) on some ideas that will support
>> dynamic models, have a look at:
>>
>> http://bugs.eclipse.org/216701
>> http://bugs.eclipse.org/255469
>>
>> Cheers,
>>
>> Christian
>>
>> Tristan FAURE wrote:
>>> Hi !
>>>
>>> I've been watched and executed EMF code for a long time. And i don't
>>> really know how to implement the constraint mechanisms if I follow
>>> the OCL tutorial I think this mechanism only works with EMF generated
>>> code and not for dynamic instance
>>> And when i see Dynamic instance mechanism I don't understand how it
>>> can work with Generated code
>>>
>>> In fact are the mechanisms duplicated to work with the two mechanisms ?
>>>
>>> Ed Merks a écrit :
>>>> Tristan,
>>>>
>>>> Comments below.
>>
>> -----8<-----
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #425193 is a reply to message #424725] |
Wed, 19 November 2008 08:22 |
Tristan Faure
Messages: 460
Registered: July 2009 |
Senior Member |
|
|
sorry i double post my answer if anybody noticed my work
Hi all
i didn't wait for your answer but if i go to the wrong direction i can
study other solution.
I have designed for my solution where models constraints are checked
with validate menu
the developer :
- creates a factory designed to create its validator
the validator has to implement a validate method :
"boolean validate(String value, EObject object, DiagnosticChain
theDiagnostics, Map<Object, Object> context)"
the parameter value is the string provided by the user it can be OCL
rule, class name, it's just a String and the method knows how to manage it
- adds an extension point referencing its factory and the uri associated
to it
the user :
- designs its metamodel
- puts its constraints with eannotations and the factory used (here for
example OCL)
- Ecore
+ constraints
-> constraint1 constraint2 constraint3
+ factory
-> org.eclipse.ocl#OCL
// org.eclipse.ocl : the factory uri
// OCL the key for defining the constraints
- OCL
+ constraint1
-> self....
To implement this i add behaviour to EObjectvalidator which
1) will check constraints
2) registers the factory and the key
3) check if there is key
4) check if there is constraints defining previously
5) ask the factory to create a validator and validate the current object
The factories are loaded with emf.ecore plugin with all other facotries
(factory_override for example)
I started to test and it seems it works with dynamic instance and
generated EMF code. Maybe i don't see limitations to my solutions
particularly i don't know if it is always possible to resolve EAnnotations
what do you think about ?
Ed Merks a écrit :
> Tristan,
>
> Patches in bugzillas or even helpful experience descriptions in the FAQ
> or the EMF Recipes are always appreciated. :-)
>
> http://wiki.eclipse.org/EMF/Recipes
> http://wiki.eclipse.org/EMF/Getting_Source
>
>
> Tristan FAURE wrote:
>> Ed,
>>
>> Okay you answered my question thank you
>> i will check my current tasks and I will see if it is possible for me
>> to contribute for this request (but i'm not very familiar with eclipse
>> process)
>>
>> Ed Merks a écrit :
>>> Tristan,
>>>
>>> I'm not really quite sure what you're asking. Many folks like to use
>>> OCL to express constraints so I imagine a good solution would make
>>> that easy, but would be extensible so that any expression language
>>> could be used... The extended Validation Framework already has all
>>> kinds of support for this stuff, but it's more focused on
>>> contributing constraints that are external to the model and can be
>>> individually turned on and off, whereas in EMF core we're focused on
>>> constraints that are intrinsic to the model and must always be
>>> satisfied...
>>>
>>>
>>> Tristan FAURE wrote:
>>>> Hi Ed
>>>>
>>>> I have been visited your links and i agree with your solutions
>>>> but why can't we imagine a solution using EMF validation framework
>>>>
>>>> Don't you think it could be simpler to design a solution using it ?
>>>> (or maybe i didn't evaluate all the problems)
>>>>
>>>> Ed Merks a écrit :
>>>>> Tristan,
>>>>>
>>>>> There's https://bugs.eclipse.org/bugs/show_bug.cgi?id=191689 so I
>>>>> agree it would be useful, but nobody has copious spare time. In an
>>>>> ideal world, the design might be more like
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701 where
>>>>> downstream plugins could contribute their "validation language"
>>>>> extensions much like this bugzilla does for derived features. A
>>>>> potential advantage of that is that it could then be applied for
>>>>> dynamic as well as generated models. So many good ideas, so little
>>>>> time...
>>>>>
>>>>>
>>>>> Tristan FAURE wrote:
>>>>>> Hi everybody
>>>>>>
>>>>>> I've followed the discussion and i often visit the tutorial from
>>>>>> Mr Damus on Eclipse wiki.
>>>>>> And every time i answering why this kind of behaviour (putting ocl
>>>>>> constraints in eAnnotations) is not by default integrated in
>>>>>> emf/ocl ?
>>>>>> it could be good to have an option in eclipse preferences :
>>>>>> activate JET templates for OCL
>>>>>> and getting the behavior described in the tutorial ?
>>>>>> what do you think about ?
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Ed Merks a écrit :
>>>>>>> Cristina/Christian
>>>>>>>
>>>>>>> It wold probably be helpful to maintain something on the wiki
>>>>>>> <http://wiki.eclipse.org/MDT-OCL>
>>>>>>>
>>>>>>> http://wiki.eclipse.org/MDT-OCL
>>>>>>>
>>>>>>> Or maybe folks are more likely to find it among the EMF recipes:
>>>>>>> <http://wiki.eclipse.org/EMF/Recipes>
>>>>>>>
>>>>>>> http://wiki.eclipse.org/EMF/Recipes
>>>>>>>
>>>>>>>
>>>>>>> Cristina wrote:
>>>>>>>> Thank you very much for your answers !!
>>>>>>>>
>>>>>>>> If I manage to adapt/implement a solution for EMF 2.4 (Ganymede
>>>>>>>> version), I will post it for anyone having the same problem!! :D
>>>>>>>>
>>>>>>>> Cheers!
>>>>>>>>
>>>>>>>> Cristina
>>>>>>>>
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #425198 is a reply to message #425193] |
Wed, 19 November 2008 10:13 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Tristan,
It sounds cool. :-)
Tristan FAURE wrote:
> sorry i double post my answer if anybody noticed my work
>
> Hi all
>
> i didn't wait for your answer but if i go to the wrong direction i can
> study other solution.
>
> I have designed for my solution where models constraints are checked
> with validate menu
>
> the developer :
>
> - creates a factory designed to create its validator
> the validator has to implement a validate method :
>
> "boolean validate(String value, EObject object, DiagnosticChain
> theDiagnostics, Map<Object, Object> context)"
>
> the parameter value is the string provided by the user it can be OCL
> rule, class name, it's just a String and the method knows how to
> manage it
>
> - adds an extension point referencing its factory and the uri
> associated to it
>
> the user :
>
> - designs its metamodel
> - puts its constraints with eannotations and the factory used (here
> for example OCL)
> - Ecore
> + constraints
> -> constraint1 constraint2 constraint3
> + factory
> -> org.eclipse.ocl#OCL
> // org.eclipse.ocl : the factory uri
> // OCL the key for defining the constraints
> - OCL
> + constraint1
> -> self....
>
> To implement this i add behaviour to EObjectvalidator which
> 1) will check constraints
> 2) registers the factory and the key
> 3) check if there is key
> 4) check if there is constraints defining previously
> 5) ask the factory to create a validator and validate the current object
>
> The factories are loaded with emf.ecore plugin with all other
> facotries (factory_override for example)
>
> I started to test and it seems it works with dynamic instance and
> generated EMF code. Maybe i don't see limitations to my solutions
> particularly i don't know if it is always possible to resolve
> EAnnotations
>
> what do you think about ?
>
> Ed Merks a écrit :
>> Tristan,
>>
>> Patches in bugzillas or even helpful experience descriptions in the
>> FAQ or the EMF Recipes are always appreciated. :-)
>>
>> http://wiki.eclipse.org/EMF/Recipes
>> http://wiki.eclipse.org/EMF/Getting_Source
>>
>>
>> Tristan FAURE wrote:
>>> Ed,
>>>
>>> Okay you answered my question thank you
>>> i will check my current tasks and I will see if it is possible for
>>> me to contribute for this request (but i'm not very familiar with
>>> eclipse process)
>>>
>>> Ed Merks a écrit :
>>>> Tristan,
>>>>
>>>> I'm not really quite sure what you're asking. Many folks like to
>>>> use OCL to express constraints so I imagine a good solution would
>>>> make that easy, but would be extensible so that any expression
>>>> language could be used... The extended Validation Framework
>>>> already has all kinds of support for this stuff, but it's more
>>>> focused on contributing constraints that are external to the model
>>>> and can be individually turned on and off, whereas in EMF core
>>>> we're focused on constraints that are intrinsic to the model and
>>>> must always be satisfied...
>>>>
>>>>
>>>> Tristan FAURE wrote:
>>>>> Hi Ed
>>>>>
>>>>> I have been visited your links and i agree with your solutions
>>>>> but why can't we imagine a solution using EMF validation framework
>>>>>
>>>>> Don't you think it could be simpler to design a solution using it
>>>>> ? (or maybe i didn't evaluate all the problems)
>>>>>
>>>>> Ed Merks a écrit :
>>>>>> Tristan,
>>>>>>
>>>>>> There's https://bugs.eclipse.org/bugs/show_bug.cgi?id=191689 so I
>>>>>> agree it would be useful, but nobody has copious spare time. In
>>>>>> an ideal world, the design might be more like
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701 where
>>>>>> downstream plugins could contribute their "validation language"
>>>>>> extensions much like this bugzilla does for derived features. A
>>>>>> potential advantage of that is that it could then be applied for
>>>>>> dynamic as well as generated models. So many good ideas, so
>>>>>> little time...
>>>>>>
>>>>>>
>>>>>> Tristan FAURE wrote:
>>>>>>> Hi everybody
>>>>>>>
>>>>>>> I've followed the discussion and i often visit the tutorial from
>>>>>>> Mr Damus on Eclipse wiki.
>>>>>>> And every time i answering why this kind of behaviour (putting
>>>>>>> ocl constraints in eAnnotations) is not by default integrated in
>>>>>>> emf/ocl ?
>>>>>>> it could be good to have an option in eclipse preferences :
>>>>>>> activate JET templates for OCL
>>>>>>> and getting the behavior described in the tutorial ?
>>>>>>> what do you think about ?
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Ed Merks a écrit :
>>>>>>>> Cristina/Christian
>>>>>>>>
>>>>>>>> It wold probably be helpful to maintain something on the wiki
>>>>>>>> <http://wiki.eclipse.org/MDT-OCL>
>>>>>>>>
>>>>>>>> http://wiki.eclipse.org/MDT-OCL
>>>>>>>>
>>>>>>>> Or maybe folks are more likely to find it among the EMF recipes:
>>>>>>>> <http://wiki.eclipse.org/EMF/Recipes>
>>>>>>>>
>>>>>>>> http://wiki.eclipse.org/EMF/Recipes
>>>>>>>>
>>>>>>>>
>>>>>>>> Cristina wrote:
>>>>>>>>> Thank you very much for your answers !!
>>>>>>>>>
>>>>>>>>> If I manage to adapt/implement a solution for EMF 2.4
>>>>>>>>> (Ganymede version), I will post it for anyone having the same
>>>>>>>>> problem!! :D
>>>>>>>>>
>>>>>>>>> Cheers!
>>>>>>>>>
>>>>>>>>> Cristina
>>>>>>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #425206 is a reply to message #425181] |
Wed, 19 November 2008 13:40 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Tristan,
This looks like a clean design, a good approach. This sounds like it
would make a good contribution to complement the enhancements I
referenced, earlier.
What do you mean by your worry about always being able to resolve
annotations? Annotations cannot be cross-resource-contained, so they
can be expected never to be proxies. Also, AFAIK, only the GenModel
annotations can be suppressed from the generated package metadata
(because they are only needed by the generator, not the run-time). Or,
do you mean that the provider of the constraint factory may not be
available at run-time, depending on the Eclipse configuration?
Cheers,
Christian
Tristan FAURE wrote:
> Hi all
>
> i didn't wait for your answer but if i go to the wrong direction i can
> study other solution.
>
> I have designed for my solution where models constraints are checked
> with validate menu
>
> the developer :
>
> - creates a factory designed to create its validator
> the validator has to implement a validate method :
>
> "boolean validate(String value, EObject object, DiagnosticChain
> theDiagnostics, Map<Object, Object> context)"
>
> the parameter value is the string provided by the user it can be OCL
> rule, class name, it's just a String and the method knows how to manage it
>
> - adds an extension point referencing its factory and the uri associated
> to it
>
> the user :
>
> - designs its metamodel
> - puts its constraints with eannotations and the factory used (here for
> example OCL)
> - Ecore
> + constraints
> -> constraint1 constraint2 constraint3
> + factory
> -> org.eclipse.ocl#OCL
> // org.eclipse.ocl : the factory uri
> // OCL the key for defining the constraints
> - OCL
> + constraint1
> -> self....
>
> To implement this i add behaviour to EObjectvalidator which
> 1) will check constraints
> 2) registers the factory and the key
> 3) check if there is key
> 4) check if there is constraints defining previously
> 5) ask the factory to create a validator and validate the current object
>
> The factories are loaded with emf.ecore plugin with all other facotries
> (factory_override for example)
>
> I started to test and it seems it works with dynamic instance and
> generated EMF code. Maybe i don't see limitations to my solutions
> particularly i don't know if it is always possible to resolve EAnnotations
>
> what do you think about ?
>
-----8<-----
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #425208 is a reply to message #425206] |
Wed, 19 November 2008 14:02 |
Tristan Faure
Messages: 460
Registered: July 2009 |
Senior Member |
|
|
Hi
bug created : https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
for EAnnotations yes i would like to know if there is some limitations
I'm quite sure that I don't realize EMF complexity and it's difficult to
say "hey the feature works in all case" :) Particularly when we see the
huge work made by Ed for delegate features
Christian W. Damus a écrit :
> Hi, Tristan,
>
> This looks like a clean design, a good approach. This sounds like it
> would make a good contribution to complement the enhancements I
> referenced, earlier.
>
> What do you mean by your worry about always being able to resolve
> annotations? Annotations cannot be cross-resource-contained, so they
> can be expected never to be proxies. Also, AFAIK, only the GenModel
> annotations can be suppressed from the generated package metadata
> (because they are only needed by the generator, not the run-time). Or,
> do you mean that the provider of the constraint factory may not be
> available at run-time, depending on the Eclipse configuration?
>
> Cheers,
>
> Christian
>
> Tristan FAURE wrote:
>> Hi all
>>
>> i didn't wait for your answer but if i go to the wrong direction i can
>> study other solution.
>>
>> I have designed for my solution where models constraints are checked
>> with validate menu
>>
>> the developer :
>>
>> - creates a factory designed to create its validator
>> the validator has to implement a validate method :
>>
>> "boolean validate(String value, EObject object, DiagnosticChain
>> theDiagnostics, Map<Object, Object> context)"
>>
>> the parameter value is the string provided by the user it can be OCL
>> rule, class name, it's just a String and the method knows how to
>> manage it
>>
>> - adds an extension point referencing its factory and the uri
>> associated to it
>>
>> the user :
>>
>> - designs its metamodel
>> - puts its constraints with eannotations and the factory used (here
>> for example OCL)
>> - Ecore
>> + constraints
>> -> constraint1 constraint2 constraint3
>> + factory
>> -> org.eclipse.ocl#OCL
>> // org.eclipse.ocl : the factory uri
>> // OCL the key for defining the constraints
>> - OCL
>> + constraint1
>> -> self....
>>
>> To implement this i add behaviour to EObjectvalidator which
>> 1) will check constraints
>> 2) registers the factory and the key
>> 3) check if there is key
>> 4) check if there is constraints defining previously
>> 5) ask the factory to create a validator and validate the current object
>>
>> The factories are loaded with emf.ecore plugin with all other
>> facotries (factory_override for example)
>>
>> I started to test and it seems it works with dynamic instance and
>> generated EMF code. Maybe i don't see limitations to my solutions
>> particularly i don't know if it is always possible to resolve
>> EAnnotations
>>
>> what do you think about ?
>>
>
> -----8<-----
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #425458 is a reply to message #425208] |
Wed, 26 November 2008 17:00 |
Tristan Faure
Messages: 460
Registered: July 2009 |
Senior Member |
|
|
no feedbacks :( ?
does somebody checked ? do i need to provide an implementation ?
Tristan FAURE a écrit :
> Hi
>
> bug created : https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
>
> for EAnnotations yes i would like to know if there is some limitations
> I'm quite sure that I don't realize EMF complexity and it's difficult to
> say "hey the feature works in all case" :) Particularly when we see the
> huge work made by Ed for delegate features
>
> Christian W. Damus a écrit :
>> Hi, Tristan,
>>
>> This looks like a clean design, a good approach. This sounds like it
>> would make a good contribution to complement the enhancements I
>> referenced, earlier.
>>
>> What do you mean by your worry about always being able to resolve
>> annotations? Annotations cannot be cross-resource-contained, so they
>> can be expected never to be proxies. Also, AFAIK, only the GenModel
>> annotations can be suppressed from the generated package metadata
>> (because they are only needed by the generator, not the run-time).
>> Or, do you mean that the provider of the constraint factory may not be
>> available at run-time, depending on the Eclipse configuration?
>>
>> Cheers,
>>
>> Christian
>>
>> Tristan FAURE wrote:
>>> Hi all
>>>
>>> i didn't wait for your answer but if i go to the wrong direction i
>>> can study other solution.
>>>
>>> I have designed for my solution where models constraints are checked
>>> with validate menu
>>>
>>> the developer :
>>>
>>> - creates a factory designed to create its validator
>>> the validator has to implement a validate method :
>>>
>>> "boolean validate(String value, EObject object, DiagnosticChain
>>> theDiagnostics, Map<Object, Object> context)"
>>>
>>> the parameter value is the string provided by the user it can be OCL
>>> rule, class name, it's just a String and the method knows how to
>>> manage it
>>>
>>> - adds an extension point referencing its factory and the uri
>>> associated to it
>>>
>>> the user :
>>>
>>> - designs its metamodel
>>> - puts its constraints with eannotations and the factory used (here
>>> for example OCL)
>>> - Ecore
>>> + constraints
>>> -> constraint1 constraint2 constraint3
>>> + factory
>>> -> org.eclipse.ocl#OCL
>>> // org.eclipse.ocl : the factory uri
>>> // OCL the key for defining the constraints
>>> - OCL
>>> + constraint1
>>> -> self....
>>>
>>> To implement this i add behaviour to EObjectvalidator which
>>> 1) will check constraints
>>> 2) registers the factory and the key
>>> 3) check if there is key
>>> 4) check if there is constraints defining previously
>>> 5) ask the factory to create a validator and validate the current object
>>>
>>> The factories are loaded with emf.ecore plugin with all other
>>> facotries (factory_override for example)
>>>
>>> I started to test and it seems it works with dynamic instance and
>>> generated EMF code. Maybe i don't see limitations to my solutions
>>> particularly i don't know if it is always possible to resolve
>>> EAnnotations
>>>
>>> what do you think about ?
>>>
>>
>> -----8<-----
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #425459 is a reply to message #425458] |
Wed, 26 November 2008 17:32 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Tristan,
Sorry, I've been rather busy and lost track of this ... I'll try to make
time for a closer review of your patch, especially with an eye to how it
would be implemented in OCL.
cW
Tristan FAURE wrote:
> no feedbacks :( ?
> does somebody checked ? do i need to provide an implementation ?
>
> Tristan FAURE a écrit :
>> Hi
>>
>> bug created : https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
>>
>> for EAnnotations yes i would like to know if there is some limitations
>> I'm quite sure that I don't realize EMF complexity and it's difficult
>> to say "hey the feature works in all case" :) Particularly when we see
>> the huge work made by Ed for delegate features
>>
>> Christian W. Damus a écrit :
>>> Hi, Tristan,
>>>
>>> This looks like a clean design, a good approach. This sounds like it
>>> would make a good contribution to complement the enhancements I
>>> referenced, earlier.
>>>
>>> What do you mean by your worry about always being able to resolve
>>> annotations? Annotations cannot be cross-resource-contained, so they
>>> can be expected never to be proxies. Also, AFAIK, only the GenModel
>>> annotations can be suppressed from the generated package metadata
>>> (because they are only needed by the generator, not the run-time).
>>> Or, do you mean that the provider of the constraint factory may not
>>> be available at run-time, depending on the Eclipse configuration?
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>> Tristan FAURE wrote:
>>>> Hi all
>>>>
>>>> i didn't wait for your answer but if i go to the wrong direction i
>>>> can study other solution.
>>>>
>>>> I have designed for my solution where models constraints are checked
>>>> with validate menu
>>>>
>>>> the developer :
>>>>
>>>> - creates a factory designed to create its validator
>>>> the validator has to implement a validate method :
>>>>
>>>> "boolean validate(String value, EObject object, DiagnosticChain
>>>> theDiagnostics, Map<Object, Object> context)"
>>>>
>>>> the parameter value is the string provided by the user it can be OCL
>>>> rule, class name, it's just a String and the method knows how to
>>>> manage it
>>>>
>>>> - adds an extension point referencing its factory and the uri
>>>> associated to it
>>>>
>>>> the user :
>>>>
>>>> - designs its metamodel
>>>> - puts its constraints with eannotations and the factory used (here
>>>> for example OCL)
>>>> - Ecore
>>>> + constraints
>>>> -> constraint1 constraint2 constraint3
>>>> + factory
>>>> -> org.eclipse.ocl#OCL
>>>> // org.eclipse.ocl : the factory uri
>>>> // OCL the key for defining the constraints
>>>> - OCL
>>>> + constraint1
>>>> -> self....
>>>>
>>>> To implement this i add behaviour to EObjectvalidator which
>>>> 1) will check constraints
>>>> 2) registers the factory and the key
>>>> 3) check if there is key
>>>> 4) check if there is constraints defining previously
>>>> 5) ask the factory to create a validator and validate the current
>>>> object
>>>>
>>>> The factories are loaded with emf.ecore plugin with all other
>>>> facotries (factory_override for example)
>>>>
>>>> I started to test and it seems it works with dynamic instance and
>>>> generated EMF code. Maybe i don't see limitations to my solutions
>>>> particularly i don't know if it is always possible to resolve
>>>> EAnnotations
>>>>
>>>> what do you think about ?
>>>>
>>>
>>> -----8<-----
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #425482 is a reply to message #425459] |
Thu, 27 November 2008 08:23 |
Tristan Faure
Messages: 460
Registered: July 2009 |
Senior Member |
|
|
Thank's christian
i just was a little bit worry about missing some steps in the Eclipse
process
Christian W. Damus a écrit :
> Hi, Tristan,
>
> Sorry, I've been rather busy and lost track of this ... I'll try to make
> time for a closer review of your patch, especially with an eye to how it
> would be implemented in OCL.
>
> cW
>
> Tristan FAURE wrote:
>> no feedbacks :( ?
>> does somebody checked ? do i need to provide an implementation ?
>>
>> Tristan FAURE a écrit :
>>> Hi
>>>
>>> bug created : https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
>>>
>>> for EAnnotations yes i would like to know if there is some
>>> limitations I'm quite sure that I don't realize EMF complexity and
>>> it's difficult to say "hey the feature works in all case" :)
>>> Particularly when we see the huge work made by Ed for delegate features
>>>
>>> Christian W. Damus a écrit :
>>>> Hi, Tristan,
>>>>
>>>> This looks like a clean design, a good approach. This sounds like
>>>> it would make a good contribution to complement the enhancements I
>>>> referenced, earlier.
>>>>
>>>> What do you mean by your worry about always being able to resolve
>>>> annotations? Annotations cannot be cross-resource-contained, so
>>>> they can be expected never to be proxies. Also, AFAIK, only the
>>>> GenModel annotations can be suppressed from the generated package
>>>> metadata (because they are only needed by the generator, not the
>>>> run-time). Or, do you mean that the provider of the constraint
>>>> factory may not be available at run-time, depending on the Eclipse
>>>> configuration?
>>>>
>>>> Cheers,
>>>>
>>>> Christian
>>>>
>>>> Tristan FAURE wrote:
>>>>> Hi all
>>>>>
>>>>> i didn't wait for your answer but if i go to the wrong direction i
>>>>> can study other solution.
>>>>>
>>>>> I have designed for my solution where models constraints are
>>>>> checked with validate menu
>>>>>
>>>>> the developer :
>>>>>
>>>>> - creates a factory designed to create its validator
>>>>> the validator has to implement a validate method :
>>>>>
>>>>> "boolean validate(String value, EObject object, DiagnosticChain
>>>>> theDiagnostics, Map<Object, Object> context)"
>>>>>
>>>>> the parameter value is the string provided by the user it can be
>>>>> OCL rule, class name, it's just a String and the method knows how
>>>>> to manage it
>>>>>
>>>>> - adds an extension point referencing its factory and the uri
>>>>> associated to it
>>>>>
>>>>> the user :
>>>>>
>>>>> - designs its metamodel
>>>>> - puts its constraints with eannotations and the factory used (here
>>>>> for example OCL)
>>>>> - Ecore
>>>>> + constraints
>>>>> -> constraint1 constraint2 constraint3
>>>>> + factory
>>>>> -> org.eclipse.ocl#OCL
>>>>> // org.eclipse.ocl : the factory uri
>>>>> // OCL the key for defining the constraints
>>>>> - OCL
>>>>> + constraint1
>>>>> -> self....
>>>>>
>>>>> To implement this i add behaviour to EObjectvalidator which
>>>>> 1) will check constraints
>>>>> 2) registers the factory and the key
>>>>> 3) check if there is key
>>>>> 4) check if there is constraints defining previously
>>>>> 5) ask the factory to create a validator and validate the current
>>>>> object
>>>>>
>>>>> The factories are loaded with emf.ecore plugin with all other
>>>>> facotries (factory_override for example)
>>>>>
>>>>> I started to test and it seems it works with dynamic instance and
>>>>> generated EMF code. Maybe i don't see limitations to my solutions
>>>>> particularly i don't know if it is always possible to resolve
>>>>> EAnnotations
>>>>>
>>>>> what do you think about ?
>>>>>
>>>>
>>>> -----8<-----
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #427011 is a reply to message #425482] |
Wed, 28 January 2009 07:58 |
Tristan Faure
Messages: 460
Registered: July 2009 |
Senior Member |
|
|
I've added an OCL implementation. It is easier to check the functionality
Tristan FAURE a écrit :
> Thank's christian
> i just was a little bit worry about missing some steps in the Eclipse
> process
>
> Christian W. Damus a écrit :
>> Hi, Tristan,
>>
>> Sorry, I've been rather busy and lost track of this ... I'll try to
>> make time for a closer review of your patch, especially with an eye to
>> how it would be implemented in OCL.
>>
>> cW
>>
>> Tristan FAURE wrote:
>>> no feedbacks :( ?
>>> does somebody checked ? do i need to provide an implementation ?
>>>
>>> Tristan FAURE a écrit :
>>>> Hi
>>>>
>>>> bug created : https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
>>>>
>>>> for EAnnotations yes i would like to know if there is some
>>>> limitations I'm quite sure that I don't realize EMF complexity and
>>>> it's difficult to say "hey the feature works in all case" :)
>>>> Particularly when we see the huge work made by Ed for delegate features
>>>>
>>>> Christian W. Damus a écrit :
>>>>> Hi, Tristan,
>>>>>
>>>>> This looks like a clean design, a good approach. This sounds like
>>>>> it would make a good contribution to complement the enhancements I
>>>>> referenced, earlier.
>>>>>
>>>>> What do you mean by your worry about always being able to resolve
>>>>> annotations? Annotations cannot be cross-resource-contained, so
>>>>> they can be expected never to be proxies. Also, AFAIK, only the
>>>>> GenModel annotations can be suppressed from the generated package
>>>>> metadata (because they are only needed by the generator, not the
>>>>> run-time). Or, do you mean that the provider of the constraint
>>>>> factory may not be available at run-time, depending on the Eclipse
>>>>> configuration?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Christian
>>>>>
>>>>> Tristan FAURE wrote:
>>>>>> Hi all
>>>>>>
>>>>>> i didn't wait for your answer but if i go to the wrong direction i
>>>>>> can study other solution.
>>>>>>
>>>>>> I have designed for my solution where models constraints are
>>>>>> checked with validate menu
>>>>>>
>>>>>> the developer :
>>>>>>
>>>>>> - creates a factory designed to create its validator
>>>>>> the validator has to implement a validate method :
>>>>>>
>>>>>> "boolean validate(String value, EObject object, DiagnosticChain
>>>>>> theDiagnostics, Map<Object, Object> context)"
>>>>>>
>>>>>> the parameter value is the string provided by the user it can be
>>>>>> OCL rule, class name, it's just a String and the method knows how
>>>>>> to manage it
>>>>>>
>>>>>> - adds an extension point referencing its factory and the uri
>>>>>> associated to it
>>>>>>
>>>>>> the user :
>>>>>>
>>>>>> - designs its metamodel
>>>>>> - puts its constraints with eannotations and the factory used
>>>>>> (here for example OCL)
>>>>>> - Ecore
>>>>>> + constraints
>>>>>> -> constraint1 constraint2 constraint3
>>>>>> + factory
>>>>>> -> org.eclipse.ocl#OCL
>>>>>> // org.eclipse.ocl : the factory uri
>>>>>> // OCL the key for defining the constraints
>>>>>> - OCL
>>>>>> + constraint1
>>>>>> -> self....
>>>>>>
>>>>>> To implement this i add behaviour to EObjectvalidator which
>>>>>> 1) will check constraints
>>>>>> 2) registers the factory and the key
>>>>>> 3) check if there is key
>>>>>> 4) check if there is constraints defining previously
>>>>>> 5) ask the factory to create a validator and validate the current
>>>>>> object
>>>>>>
>>>>>> The factories are loaded with emf.ecore plugin with all other
>>>>>> facotries (factory_override for example)
>>>>>>
>>>>>> I started to test and it seems it works with dynamic instance and
>>>>>> generated EMF code. Maybe i don't see limitations to my solutions
>>>>>> particularly i don't know if it is always possible to resolve
>>>>>> EAnnotations
>>>>>>
>>>>>> what do you think about ?
>>>>>>
>>>>>
>>>>> -----8<-----
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #427022 is a reply to message #427011] |
Wed, 28 January 2009 13:47 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Tristan,
Good stuff! You've been truckin' :-)
Are you going to EclipseCon, by any chance? Perhaps we should meet with
Ed to see about closing this deal.
Christian
Tristan FAURE wrote:
> I've added an OCL implementation. It is easier to check the functionality
>
> Tristan FAURE a écrit :
>> Thank's christian
>> i just was a little bit worry about missing some steps in the Eclipse
>> process
>>
>> Christian W. Damus a écrit :
>>> Hi, Tristan,
>>>
>>> Sorry, I've been rather busy and lost track of this ... I'll try to
>>> make time for a closer review of your patch, especially with an eye
>>> to how it would be implemented in OCL.
>>>
>>> cW
>>>
>>> Tristan FAURE wrote:
>>>> no feedbacks :( ?
>>>> does somebody checked ? do i need to provide an implementation ?
>>>>
-----8<-----
|
|
| |
| Re: Model Integrity in EMF with MDT OCL [message #427054 is a reply to message #427011] |
Fri, 30 January 2009 05:09 |
Andrew H
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
FWIW I for one would be quite interested in this or similar functionality
built into EMF. I tend to add a fair bit of OCL in comment boxes to Ecore
Diagrams, but this of course then is only doco and I'd have to duplicate
this when we get to the phase of the project where we will do OCL for real.
Ideally Ecore Diagrams would add explicit support for OCL constraints and
derived features expressed as OCL.
Tristan FAURE wrote:
> I've added an OCL implementation. It is easier to check the functionality
> Tristan FAURE a écrit :
>> Thank's christian
>> i just was a little bit worry about missing some steps in the Eclipse
>> process
>>
>> Christian W. Damus a écrit :
>>> Hi, Tristan,
>>>
>>> Sorry, I've been rather busy and lost track of this ... I'll try to
>>> make time for a closer review of your patch, especially with an eye to
>>> how it would be implemented in OCL.
>>>
>>> cW
>>>
>>> Tristan FAURE wrote:
>>>> no feedbacks :( ?
>>>> does somebody checked ? do i need to provide an implementation ?
>>>>
>>>> Tristan FAURE a écrit :
>>>>> Hi
>>>>>
>>>>> bug created : https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
>>>>>
>>>>> for EAnnotations yes i would like to know if there is some
>>>>> limitations I'm quite sure that I don't realize EMF complexity and
>>>>> it's difficult to say "hey the feature works in all case" :)
>>>>> Particularly when we see the huge work made by Ed for delegate features
>>>>>
>>>>> Christian W. Damus a écrit :
>>>>>> Hi, Tristan,
>>>>>>
>>>>>> This looks like a clean design, a good approach. This sounds like
>>>>>> it would make a good contribution to complement the enhancements I
>>>>>> referenced, earlier.
>>>>>>
>>>>>> What do you mean by your worry about always being able to resolve
>>>>>> annotations? Annotations cannot be cross-resource-contained, so
>>>>>> they can be expected never to be proxies. Also, AFAIK, only the
>>>>>> GenModel annotations can be suppressed from the generated package
>>>>>> metadata (because they are only needed by the generator, not the
>>>>>> run-time). Or, do you mean that the provider of the constraint
>>>>>> factory may not be available at run-time, depending on the Eclipse
>>>>>> configuration?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> Tristan FAURE wrote:
>>>>>>> Hi all
>>>>>>>
>>>>>>> i didn't wait for your answer but if i go to the wrong direction i
>>>>>>> can study other solution.
>>>>>>>
>>>>>>> I have designed for my solution where models constraints are
>>>>>>> checked with validate menu
>>>>>>>
>>>>>>> the developer :
>>>>>>>
>>>>>>> - creates a factory designed to create its validator
>>>>>>> the validator has to implement a validate method :
>>>>>>>
>>>>>>> "boolean validate(String value, EObject object, DiagnosticChain
>>>>>>> theDiagnostics, Map<Object, Object> context)"
>>>>>>>
>>>>>>> the parameter value is the string provided by the user it can be
>>>>>>> OCL rule, class name, it's just a String and the method knows how
>>>>>>> to manage it
>>>>>>>
>>>>>>> - adds an extension point referencing its factory and the uri
>>>>>>> associated to it
>>>>>>>
>>>>>>> the user :
>>>>>>>
>>>>>>> - designs its metamodel
>>>>>>> - puts its constraints with eannotations and the factory used
>>>>>>> (here for example OCL)
>>>>>>> - Ecore
>>>>>>> + constraints
>>>>>>> -> constraint1 constraint2 constraint3
>>>>>>> + factory
>>>>>>> -> org.eclipse.ocl#OCL
>>>>>>> // org.eclipse.ocl : the factory uri
>>>>>>> // OCL the key for defining the constraints
>>>>>>> - OCL
>>>>>>> + constraint1
>>>>>>> -> self....
>>>>>>>
>>>>>>> To implement this i add behaviour to EObjectvalidator which
>>>>>>> 1) will check constraints
>>>>>>> 2) registers the factory and the key
>>>>>>> 3) check if there is key
>>>>>>> 4) check if there is constraints defining previously
>>>>>>> 5) ask the factory to create a validator and validate the current
>>>>>>> object
>>>>>>>
>>>>>>> The factories are loaded with emf.ecore plugin with all other
>>>>>>> facotries (factory_override for example)
>>>>>>>
>>>>>>> I started to test and it seems it works with dynamic instance and
>>>>>>> generated EMF code. Maybe i don't see limitations to my solutions
>>>>>>> particularly i don't know if it is always possible to resolve
>>>>>>> EAnnotations
>>>>>>>
>>>>>>> what do you think about ?
>>>>>>>
>>>>>>
>>>>>> -----8<-----
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #427057 is a reply to message #427054] |
Fri, 30 January 2009 11:01 |
Tristan Faure
Messages: 460
Registered: July 2009 |
Senior Member |
|
|
Hi
i would ask for (maybe) modifying the design
Currently :
for each ECLass
Eclass A
EAnnotation : Ecore
constraints -> constraint1 constraint2
factory -> factoryID
EAnnotation : factoryID
constraint1 -> String interpreted by constraint delegator
EAnnotation : factoryID
constraint2 -> String interpreted by constraint delegator
Eclass B
EAnnotation : Ecore
constraints -> constraint1 constraint2
factory -> factoryID
EAnnotation : factoryID
constraint1 -> String interpreted by constraint delegator
EAnnotation : factoryID
constraint2 -> String interpreted by constraint delegator
Do you think filling factory for each ECLass is irritating ? maybe we
should consider an EAnnotation in EPackage defining Factory example :
EPackage
Eannotation : Ecore
factory -> factoryID#Key
Eclass A
EAnnotation : Ecore
constraints -> constraint1 constraint2
EAnnotation : Key
constraint1 -> String interpreted by constraint delegator
EAnnotation : Key
constraint2 -> String interpreted by constraint delegator
Eclass B
EAnnotation : Ecore
constraints -> constraint1 constraint2
EAnnotation : Key
constraint1 -> String interpreted by constraint delegator
EAnnotation : Key
constraint2 -> String interpreted by constraint delegator
In this example I used the notation with the Key but we keep the factory id
what is your opinion ?
Andrew H a écrit :
> FWIW I for one would be quite interested in this or similar
> functionality built into EMF. I tend to add a fair bit of OCL in comment
> boxes to Ecore Diagrams, but this of course then is only doco and I'd
> have to duplicate this when we get to the phase of the project where we
> will do OCL for real.
>
> Ideally Ecore Diagrams would add explicit support for OCL constraints
> and derived features expressed as OCL.
>
> Tristan FAURE wrote:
>
>> I've added an OCL implementation. It is easier to check the functionality
>
>> Tristan FAURE a écrit :
>>> Thank's christian
>>> i just was a little bit worry about missing some steps in the Eclipse
>>> process
>>>
>>> Christian W. Damus a écrit :
>>>> Hi, Tristan,
>>>>
>>>> Sorry, I've been rather busy and lost track of this ... I'll try to
>>>> make time for a closer review of your patch, especially with an eye
>>>> to how it would be implemented in OCL.
>>>>
>>>> cW
>>>>
>>>> Tristan FAURE wrote:
>>>>> no feedbacks :( ?
>>>>> does somebody checked ? do i need to provide an implementation ?
>>>>>
>>>>> Tristan FAURE a écrit :
>>>>>> Hi
>>>>>>
>>>>>> bug created : https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
>>>>>>
>>>>>> for EAnnotations yes i would like to know if there is some
>>>>>> limitations I'm quite sure that I don't realize EMF complexity and
>>>>>> it's difficult to say "hey the feature works in all case" :)
>>>>>> Particularly when we see the huge work made by Ed for delegate
>>>>>> features
>>>>>>
>>>>>> Christian W. Damus a écrit :
>>>>>>> Hi, Tristan,
>>>>>>>
>>>>>>> This looks like a clean design, a good approach. This sounds
>>>>>>> like it would make a good contribution to complement the
>>>>>>> enhancements I referenced, earlier.
>>>>>>>
>>>>>>> What do you mean by your worry about always being able to resolve
>>>>>>> annotations? Annotations cannot be cross-resource-contained, so
>>>>>>> they can be expected never to be proxies. Also, AFAIK, only the
>>>>>>> GenModel annotations can be suppressed from the generated package
>>>>>>> metadata (because they are only needed by the generator, not the
>>>>>>> run-time). Or, do you mean that the provider of the constraint
>>>>>>> factory may not be available at run-time, depending on the
>>>>>>> Eclipse configuration?
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>> Tristan FAURE wrote:
>>>>>>>> Hi all
>>>>>>>>
>>>>>>>> i didn't wait for your answer but if i go to the wrong direction
>>>>>>>> i can study other solution.
>>>>>>>>
>>>>>>>> I have designed for my solution where models constraints are
>>>>>>>> checked with validate menu
>>>>>>>>
>>>>>>>> the developer :
>>>>>>>>
>>>>>>>> - creates a factory designed to create its validator
>>>>>>>> the validator has to implement a validate method :
>>>>>>>>
>>>>>>>> "boolean validate(String value, EObject object, DiagnosticChain
>>>>>>>> theDiagnostics, Map<Object, Object> context)"
>>>>>>>>
>>>>>>>> the parameter value is the string provided by the user it can be
>>>>>>>> OCL rule, class name, it's just a String and the method knows
>>>>>>>> how to manage it
>>>>>>>>
>>>>>>>> - adds an extension point referencing its factory and the uri
>>>>>>>> associated to it
>>>>>>>>
>>>>>>>> the user :
>>>>>>>>
>>>>>>>> - designs its metamodel
>>>>>>>> - puts its constraints with eannotations and the factory used
>>>>>>>> (here for example OCL)
>>>>>>>> - Ecore
>>>>>>>> + constraints
>>>>>>>> -> constraint1 constraint2 constraint3
>>>>>>>> + factory
>>>>>>>> -> org.eclipse.ocl#OCL
>>>>>>>> // org.eclipse.ocl : the factory uri
>>>>>>>> // OCL the key for defining the constraints
>>>>>>>> - OCL
>>>>>>>> + constraint1
>>>>>>>> -> self....
>>>>>>>>
>>>>>>>> To implement this i add behaviour to EObjectvalidator which
>>>>>>>> 1) will check constraints
>>>>>>>> 2) registers the factory and the key
>>>>>>>> 3) check if there is key
>>>>>>>> 4) check if there is constraints defining previously
>>>>>>>> 5) ask the factory to create a validator and validate the
>>>>>>>> current object
>>>>>>>>
>>>>>>>> The factories are loaded with emf.ecore plugin with all other
>>>>>>>> facotries (factory_override for example)
>>>>>>>>
>>>>>>>> I started to test and it seems it works with dynamic instance
>>>>>>>> and generated EMF code. Maybe i don't see limitations to my
>>>>>>>> solutions particularly i don't know if it is always possible to
>>>>>>>> resolve EAnnotations
>>>>>>>>
>>>>>>>> what do you think about ?
>>>>>>>>
>>>>>>>
>>>>>>> -----8<-----
>
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #427094 is a reply to message #427057] |
Mon, 02 February 2009 03:37 |
Andrew H
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
To be honest I'm not familiar with how things work behind the scenes here
with factories and extension points. From a users point of view though I
would say the less I would need to do the better.
Could you get away with simply something like the following?
EAnnotation : <some uri for ocl>
constraint1 -> books.authors.age > 20
constraint2 -> books.authors.name <> "fred"
etc.
i.e. can we put many constraints in one annotation and can we avoid
needing to list them (like in constraints -> constraint1 constraint2)?
I guess the problem with that though is it limits other data that may need
to be attached to the constraint. e.g. severity etc.
In that case you might be better then to go for something like:
EAnnotation : <some uri for ocl>
name -> authorsAge
constraint -> books.authors.age > 20
severity -> ERROR
message -> author's must be at least 20 years old
Note these fields should align with the validation frameworks fields.
This is more powerful and useful in the long run and if tool support is
added to Ecore Diagrams for this then it won't matter to users that it is
long winded.
my 2c worth
cheers
Andrew
Tristan FAURE wrote:
> Hi
> i would ask for (maybe) modifying the design
> Currently :
> for each ECLass
> Eclass A
> EAnnotation : Ecore
> constraints -> constraint1 constraint2
> factory -> factoryID
> EAnnotation : factoryID
> constraint1 -> String interpreted by constraint delegator
> EAnnotation : factoryID
> constraint2 -> String interpreted by constraint delegator
> Eclass B
> EAnnotation : Ecore
> constraints -> constraint1 constraint2
> factory -> factoryID
> EAnnotation : factoryID
> constraint1 -> String interpreted by constraint delegator
> EAnnotation : factoryID
> constraint2 -> String interpreted by constraint delegator
> Do you think filling factory for each ECLass is irritating ? maybe we
> should consider an EAnnotation in EPackage defining Factory example :
> EPackage
> Eannotation : Ecore
> factory -> factoryID#Key
> Eclass A
> EAnnotation : Ecore
> constraints -> constraint1 constraint2
> EAnnotation : Key
> constraint1 -> String interpreted by constraint delegator
> EAnnotation : Key
> constraint2 -> String interpreted by constraint delegator
> Eclass B
> EAnnotation : Ecore
> constraints -> constraint1 constraint2
> EAnnotation : Key
> constraint1 -> String interpreted by constraint delegator
> EAnnotation : Key
> constraint2 -> String interpreted by constraint delegator
> In this example I used the notation with the Key but we keep the factory id
> what is your opinion ?
> Andrew H a écrit :
>> FWIW I for one would be quite interested in this or similar
>> functionality built into EMF. I tend to add a fair bit of OCL in comment
>> boxes to Ecore Diagrams, but this of course then is only doco and I'd
>> have to duplicate this when we get to the phase of the project where we
>> will do OCL for real.
>>
>> Ideally Ecore Diagrams would add explicit support for OCL constraints
>> and derived features expressed as OCL.
>>
>> Tristan FAURE wrote:
>>
>>> I've added an OCL implementation. It is easier to check the functionality
>>
>>> Tristan FAURE a écrit :
>>>> Thank's christian
>>>> i just was a little bit worry about missing some steps in the Eclipse
>>>> process
>>>>
>>>> Christian W. Damus a écrit :
>>>>> Hi, Tristan,
>>>>>
>>>>> Sorry, I've been rather busy and lost track of this ... I'll try to
>>>>> make time for a closer review of your patch, especially with an eye
>>>>> to how it would be implemented in OCL.
>>>>>
>>>>> cW
>>>>>
>>>>> Tristan FAURE wrote:
>>>>>> no feedbacks :( ?
>>>>>> does somebody checked ? do i need to provide an implementation ?
>>>>>>
>>>>>> Tristan FAURE a écrit :
>>>>>>> Hi
>>>>>>>
>>>>>>> bug created : https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
>>>>>>>
>>>>>>> for EAnnotations yes i would like to know if there is some
>>>>>>> limitations I'm quite sure that I don't realize EMF complexity and
>>>>>>> it's difficult to say "hey the feature works in all case" :)
>>>>>>> Particularly when we see the huge work made by Ed for delegate
>>>>>>> features
>>>>>>>
>>>>>>> Christian W. Damus a écrit :
>>>>>>>> Hi, Tristan,
>>>>>>>>
>>>>>>>> This looks like a clean design, a good approach. This sounds
>>>>>>>> like it would make a good contribution to complement the
>>>>>>>> enhancements I referenced, earlier.
>>>>>>>>
>>>>>>>> What do you mean by your worry about always being able to resolve
>>>>>>>> annotations? Annotations cannot be cross-resource-contained, so
>>>>>>>> they can be expected never to be proxies. Also, AFAIK, only the
>>>>>>>> GenModel annotations can be suppressed from the generated package
>>>>>>>> metadata (because they are only needed by the generator, not the
>>>>>>>> run-time). Or, do you mean that the provider of the constraint
>>>>>>>> factory may not be available at run-time, depending on the
>>>>>>>> Eclipse configuration?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>> Tristan FAURE wrote:
>>>>>>>>> Hi all
>>>>>>>>>
>>>>>>>>> i didn't wait for your answer but if i go to the wrong direction
>>>>>>>>> i can study other solution.
>>>>>>>>>
>>>>>>>>> I have designed for my solution where models constraints are
>>>>>>>>> checked with validate menu
>>>>>>>>>
>>>>>>>>> the developer :
>>>>>>>>>
>>>>>>>>> - creates a factory designed to create its validator
>>>>>>>>> the validator has to implement a validate method :
>>>>>>>>>
>>>>>>>>> "boolean validate(String value, EObject object, DiagnosticChain
>>>>>>>>> theDiagnostics, Map<Object, Object> context)"
>>>>>>>>>
>>>>>>>>> the parameter value is the string provided by the user it can be
>>>>>>>>> OCL rule, class name, it's just a String and the method knows
>>>>>>>>> how to manage it
>>>>>>>>>
>>>>>>>>> - adds an extension point referencing its factory and the uri
>>>>>>>>> associated to it
>>>>>>>>>
>>>>>>>>> the user :
>>>>>>>>>
>>>>>>>>> - designs its metamodel
>>>>>>>>> - puts its constraints with eannotations and the factory used
>>>>>>>>> (here for example OCL)
>>>>>>>>> - Ecore
>>>>>>>>> + constraints
>>>>>>>>> -> constraint1 constraint2 constraint3
>>>>>>>>> + factory
>>>>>>>>> -> org.eclipse.ocl#OCL
>>>>>>>>> // org.eclipse.ocl : the factory uri
>>>>>>>>> // OCL the key for defining the constraints
>>>>>>>>> - OCL
>>>>>>>>> + constraint1
>>>>>>>>> -> self....
>>>>>>>>>
>>>>>>>>> To implement this i add behaviour to EObjectvalidator which
>>>>>>>>> 1) will check constraints
>>>>>>>>> 2) registers the factory and the key
>>>>>>>>> 3) check if there is key
>>>>>>>>> 4) check if there is constraints defining previously
>>>>>>>>> 5) ask the factory to create a validator and validate the
>>>>>>>>> current object
>>>>>>>>>
>>>>>>>>> The factories are loaded with emf.ecore plugin with all other
>>>>>>>>> facotries (factory_override for example)
>>>>>>>>>
>>>>>>>>> I started to test and it seems it works with dynamic instance
>>>>>>>>> and generated EMF code. Maybe i don't see limitations to my
>>>>>>>>> solutions particularly i don't know if it is always possible to
>>>>>>>>> resolve EAnnotations
>>>>>>>>>
>>>>>>>>> what do you think about ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> -----8<-----
>>
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #427095 is a reply to message #427094] |
Mon, 02 February 2009 03:39 |
Andrew H
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
One more thing. To be useful to me it would need to work standalone.
Andrew H wrote:
> To be honest I'm not familiar with how things work behind the scenes here
> with factories and extension points. From a users point of view though I
> would say the less I would need to do the better.
> Could you get away with simply something like the following?
> EAnnotation : <some uri for ocl>
> constraint1 -> books.authors.age > 20
> constraint2 -> books.authors.name <> "fred"
> etc.
> i.e. can we put many constraints in one annotation and can we avoid
> needing to list them (like in constraints -> constraint1 constraint2)?
> I guess the problem with that though is it limits other data that may need
> to be attached to the constraint. e.g. severity etc.
> In that case you might be better then to go for something like:
> EAnnotation : <some uri for ocl>
> name -> authorsAge
> constraint -> books.authors.age > 20
> severity -> ERROR
> message -> author's must be at least 20 years old
> Note these fields should align with the validation frameworks fields.
> This is more powerful and useful in the long run and if tool support is
> added to Ecore Diagrams for this then it won't matter to users that it is
> long winded.
> my 2c worth
> cheers
> Andrew
> Tristan FAURE wrote:
>> Hi
>> i would ask for (maybe) modifying the design
>> Currently :
>> for each ECLass
>> Eclass A
>> EAnnotation : Ecore
>> constraints -> constraint1 constraint2
>> factory -> factoryID
>> EAnnotation : factoryID
>> constraint1 -> String interpreted by constraint delegator
>> EAnnotation : factoryID
>> constraint2 -> String interpreted by constraint delegator
>> Eclass B
>> EAnnotation : Ecore
>> constraints -> constraint1 constraint2
>> factory -> factoryID
>> EAnnotation : factoryID
>> constraint1 -> String interpreted by constraint delegator
>> EAnnotation : factoryID
>> constraint2 -> String interpreted by constraint delegator
>> Do you think filling factory for each ECLass is irritating ? maybe we
>> should consider an EAnnotation in EPackage defining Factory example :
>> EPackage
>> Eannotation : Ecore
>> factory -> factoryID#Key
>> Eclass A
>> EAnnotation : Ecore
>> constraints -> constraint1 constraint2
>> EAnnotation : Key
>> constraint1 -> String interpreted by constraint delegator
>> EAnnotation : Key
>> constraint2 -> String interpreted by constraint delegator
>> Eclass B
>> EAnnotation : Ecore
>> constraints -> constraint1 constraint2
>> EAnnotation : Key
>> constraint1 -> String interpreted by constraint delegator
>> EAnnotation : Key
>> constraint2 -> String interpreted by constraint delegator
>> In this example I used the notation with the Key but we keep the factory id
>> what is your opinion ?
>> Andrew H a écrit :
>>> FWIW I for one would be quite interested in this or similar
>>> functionality built into EMF. I tend to add a fair bit of OCL in comment
>>> boxes to Ecore Diagrams, but this of course then is only doco and I'd
>>> have to duplicate this when we get to the phase of the project where we
>>> will do OCL for real.
>>>
>>> Ideally Ecore Diagrams would add explicit support for OCL constraints
>>> and derived features expressed as OCL.
>>>
>>> Tristan FAURE wrote:
>>>
>>>> I've added an OCL implementation. It is easier to check the functionality
>>>
>>>> Tristan FAURE a écrit :
>>>>> Thank's christian
>>>>> i just was a little bit worry about missing some steps in the Eclipse
>>>>> process
>>>>>
>>>>> Christian W. Damus a écrit :
>>>>>> Hi, Tristan,
>>>>>>
>>>>>> Sorry, I've been rather busy and lost track of this ... I'll try to
>>>>>> make time for a closer review of your patch, especially with an eye
>>>>>> to how it would be implemented in OCL.
>>>>>>
>>>>>> cW
>>>>>>
>>>>>> Tristan FAURE wrote:
>>>>>>> no feedbacks :( ?
>>>>>>> does somebody checked ? do i need to provide an implementation ?
>>>>>>>
>>>>>>> Tristan FAURE a écrit :
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> bug created : https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
>>>>>>>>
>>>>>>>> for EAnnotations yes i would like to know if there is some
>>>>>>>> limitations I'm quite sure that I don't realize EMF complexity and
>>>>>>>> it's difficult to say "hey the feature works in all case" :)
>>>>>>>> Particularly when we see the huge work made by Ed for delegate
>>>>>>>> features
>>>>>>>>
>>>>>>>> Christian W. Damus a écrit :
>>>>>>>>> Hi, Tristan,
>>>>>>>>>
>>>>>>>>> This looks like a clean design, a good approach. This sounds
>>>>>>>>> like it would make a good contribution to complement the
>>>>>>>>> enhancements I referenced, earlier.
>>>>>>>>>
>>>>>>>>> What do you mean by your worry about always being able to resolve
>>>>>>>>> annotations? Annotations cannot be cross-resource-contained, so
>>>>>>>>> they can be expected never to be proxies. Also, AFAIK, only the
>>>>>>>>> GenModel annotations can be suppressed from the generated package
>>>>>>>>> metadata (because they are only needed by the generator, not the
>>>>>>>>> run-time). Or, do you mean that the provider of the constraint
>>>>>>>>> factory may not be available at run-time, depending on the
>>>>>>>>> Eclipse configuration?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Christian
>>>>>>>>>
>>>>>>>>> Tristan FAURE wrote:
>>>>>>>>>> Hi all
>>>>>>>>>>
>>>>>>>>>> i didn't wait for your answer but if i go to the wrong direction
>>>>>>>>>> i can study other solution.
>>>>>>>>>>
>>>>>>>>>> I have designed for my solution where models constraints are
>>>>>>>>>> checked with validate menu
>>>>>>>>>>
>>>>>>>>>> the developer :
>>>>>>>>>>
>>>>>>>>>> - creates a factory designed to create its validator
>>>>>>>>>> the validator has to implement a validate method :
>>>>>>>>>>
>>>>>>>>>> "boolean validate(String value, EObject object, DiagnosticChain
>>>>>>>>>> theDiagnostics, Map<Object, Object> context)"
>>>>>>>>>>
>>>>>>>>>> the parameter value is the string provided by the user it can be
>>>>>>>>>> OCL rule, class name, it's just a String and the method knows
>>>>>>>>>> how to manage it
>>>>>>>>>>
>>>>>>>>>> - adds an extension point referencing its factory and the uri
>>>>>>>>>> associated to it
>>>>>>>>>>
>>>>>>>>>> the user :
>>>>>>>>>>
>>>>>>>>>> - designs its metamodel
>>>>>>>>>> - puts its constraints with eannotations and the factory used
>>>>>>>>>> (here for example OCL)
>>>>>>>>>> - Ecore
>>>>>>>>>> + constraints
>>>>>>>>>> -> constraint1 constraint2 constraint3
>>>>>>>>>> + factory
>>>>>>>>>> -> org.eclipse.ocl#OCL
>>>>>>>>>> // org.eclipse.ocl : the factory uri
>>>>>>>>>> // OCL the key for defining the constraints
>>>>>>>>>> - OCL
>>>>>>>>>> + constraint1
>>>>>>>>>> -> self....
>>>>>>>>>>
>>>>>>>>>> To implement this i add behaviour to EObjectvalidator which
>>>>>>>>>> 1) will check constraints
>>>>>>>>>> 2) registers the factory and the key
>>>>>>>>>> 3) check if there is key
>>>>>>>>>> 4) check if there is constraints defining previously
>>>>>>>>>> 5) ask the factory to create a validator and validate the
>>>>>>>>>> current object
>>>>>>>>>>
>>>>>>>>>> The factories are loaded with emf.ecore plugin with all other
>>>>>>>>>> facotries (factory_override for example)
>>>>>>>>>>
>>>>>>>>>> I started to test and it seems it works with dynamic instance
>>>>>>>>>> and generated EMF code. Maybe i don't see limitations to my
>>>>>>>>>> solutions particularly i don't know if it is always possible to
>>>>>>>>>> resolve EAnnotations
>>>>>>>>>>
>>>>>>>>>> what do you think about ?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----8<-----
>>>
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #427099 is a reply to message #427095] |
Mon, 02 February 2009 07:57 |
Tristan Faure
Messages: 460
Registered: July 2009 |
Senior Member |
|
|
you opinion doesn't disturb me, we just need to see if this satisfy
everybody. For my design i copy the OCL tutorial presented on the web
with the list of constraints.
I can use your syntax but i think it could be better to keep a root
eannotation static like "Ecore" to not check for each root if it is a
factory
to be conform to your idea we can have
EAnnotation : Ecore
factory -> factoryName
name -> authorsAge
constraint -> books.authors.age > 20
severity -> ERROR
message -> author's must be at least 20 years old
or like i said previously factory declared in Epackage
factory -> keydeclaredInEPackage
Andrew H a écrit :
> One more thing. To be useful to me it would need to work standalone.
>
> Andrew H wrote:
>
>> To be honest I'm not familiar with how things work behind the scenes
>> here with factories and extension points. From a users point of view
>> though I would say the less I would need to do the better.
>
>> Could you get away with simply something like the following?
>
>> EAnnotation : <some uri for ocl>
>> constraint1 -> books.authors.age > 20
>> constraint2 -> books.authors.name <> "fred"
>> etc.
>
>> i.e. can we put many constraints in one annotation and can we avoid
>> needing to list them (like in constraints -> constraint1 constraint2)?
>
>> I guess the problem with that though is it limits other data that may
>> need to be attached to the constraint. e.g. severity etc.
>
>> In that case you might be better then to go for something like:
>
>> EAnnotation : <some uri for ocl>
>> name -> authorsAge
>> constraint -> books.authors.age > 20
>> severity -> ERROR
>> message -> author's must be at least 20 years old
>
>> Note these fields should align with the validation frameworks fields.
>
>> This is more powerful and useful in the long run and if tool support
>> is added to Ecore Diagrams for this then it won't matter to users that
>> it is long winded.
>
>> my 2c worth
>
>> cheers
>
>> Andrew
>
>> Tristan FAURE wrote:
>
>>> Hi
>
>>> i would ask for (maybe) modifying the design
>>> Currently :
>>> for each ECLass
>>> Eclass A
>>> EAnnotation : Ecore
>>> constraints -> constraint1 constraint2
>>> factory -> factoryID
>>> EAnnotation : factoryID
>>> constraint1 -> String interpreted by constraint delegator
>>> EAnnotation : factoryID
>>> constraint2 -> String interpreted by constraint delegator
>>> Eclass B
>>> EAnnotation : Ecore
>>> constraints -> constraint1 constraint2
>>> factory -> factoryID
>>> EAnnotation : factoryID
>>> constraint1 -> String interpreted by constraint delegator
>>> EAnnotation : factoryID
>>> constraint2 -> String interpreted by constraint delegator
>
>>> Do you think filling factory for each ECLass is irritating ? maybe we
>>> should consider an EAnnotation in EPackage defining Factory example :
>
>>> EPackage
>>> Eannotation : Ecore
>>> factory -> factoryID#Key
>>> Eclass A
>>> EAnnotation : Ecore
>>> constraints -> constraint1 constraint2
>>> EAnnotation : Key
>>> constraint1 -> String interpreted by constraint
>>> delegator
>>> EAnnotation : Key
>>> constraint2 -> String interpreted by constraint
>>> delegator
>>> Eclass B
>>> EAnnotation : Ecore
>>> constraints -> constraint1 constraint2
>>> EAnnotation : Key
>>> constraint1 -> String interpreted by
>>> constraint delegator
>>> EAnnotation : Key
>>> constraint2 -> String interpreted by
>>> constraint delegator
>
>>> In this example I used the notation with the Key but we keep the
>>> factory id
>
>>> what is your opinion ?
>
>
>>> Andrew H a écrit :
>>>> FWIW I for one would be quite interested in this or similar
>>>> functionality built into EMF. I tend to add a fair bit of OCL in
>>>> comment boxes to Ecore Diagrams, but this of course then is only
>>>> doco and I'd have to duplicate this when we get to the phase of the
>>>> project where we will do OCL for real.
>>>>
>>>> Ideally Ecore Diagrams would add explicit support for OCL
>>>> constraints and derived features expressed as OCL.
>>>>
>>>> Tristan FAURE wrote:
>>>>
>>>>> I've added an OCL implementation. It is easier to check the
>>>>> functionality
>>>>
>>>>> Tristan FAURE a écrit :
>>>>>> Thank's christian
>>>>>> i just was a little bit worry about missing some steps in the
>>>>>> Eclipse process
>>>>>>
>>>>>> Christian W. Damus a écrit :
>>>>>>> Hi, Tristan,
>>>>>>>
>>>>>>> Sorry, I've been rather busy and lost track of this ... I'll try
>>>>>>> to make time for a closer review of your patch, especially with
>>>>>>> an eye to how it would be implemented in OCL.
>>>>>>>
>>>>>>> cW
>>>>>>>
>>>>>>> Tristan FAURE wrote:
>>>>>>>> no feedbacks :( ?
>>>>>>>> does somebody checked ? do i need to provide an implementation ?
>>>>>>>>
>>>>>>>> Tristan FAURE a écrit :
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> bug created : https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
>>>>>>>>>
>>>>>>>>> for EAnnotations yes i would like to know if there is some
>>>>>>>>> limitations I'm quite sure that I don't realize EMF complexity
>>>>>>>>> and it's difficult to say "hey the feature works in all case"
>>>>>>>>> :) Particularly when we see the huge work made by Ed for
>>>>>>>>> delegate features
>>>>>>>>>
>>>>>>>>> Christian W. Damus a écrit :
>>>>>>>>>> Hi, Tristan,
>>>>>>>>>>
>>>>>>>>>> This looks like a clean design, a good approach. This sounds
>>>>>>>>>> like it would make a good contribution to complement the
>>>>>>>>>> enhancements I referenced, earlier.
>>>>>>>>>>
>>>>>>>>>> What do you mean by your worry about always being able to
>>>>>>>>>> resolve annotations? Annotations cannot be
>>>>>>>>>> cross-resource-contained, so they can be expected never to be
>>>>>>>>>> proxies. Also, AFAIK, only the GenModel annotations can be
>>>>>>>>>> suppressed from the generated package metadata (because they
>>>>>>>>>> are only needed by the generator, not the run-time). Or, do
>>>>>>>>>> you mean that the provider of the constraint factory may not
>>>>>>>>>> be available at run-time, depending on the Eclipse configuration?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> Christian
>>>>>>>>>>
>>>>>>>>>> Tristan FAURE wrote:
>>>>>>>>>>> Hi all
>>>>>>>>>>>
>>>>>>>>>>> i didn't wait for your answer but if i go to the wrong
>>>>>>>>>>> direction i can study other solution.
>>>>>>>>>>>
>>>>>>>>>>> I have designed for my solution where models constraints are
>>>>>>>>>>> checked with validate menu
>>>>>>>>>>>
>>>>>>>>>>> the developer :
>>>>>>>>>>>
>>>>>>>>>>> - creates a factory designed to create its validator
>>>>>>>>>>> the validator has to implement a validate method :
>>>>>>>>>>>
>>>>>>>>>>> "boolean validate(String value, EObject object,
>>>>>>>>>>> DiagnosticChain theDiagnostics, Map<Object, Object> context)"
>>>>>>>>>>>
>>>>>>>>>>> the parameter value is the string provided by the user it can
>>>>>>>>>>> be OCL rule, class name, it's just a String and the method
>>>>>>>>>>> knows how to manage it
>>>>>>>>>>>
>>>>>>>>>>> - adds an extension point referencing its factory and the uri
>>>>>>>>>>> associated to it
>>>>>>>>>>>
>>>>>>>>>>> the user :
>>>>>>>>>>>
>>>>>>>>>>> - designs its metamodel
>>>>>>>>>>> - puts its constraints with eannotations and the factory used
>>>>>>>>>>> (here for example OCL)
>>>>>>>>>>> - Ecore
>>>>>>>>>>> + constraints
>>>>>>>>>>> -> constraint1 constraint2 constraint3
>>>>>>>>>>> + factory
>>>>>>>>>>> -> org.eclipse.ocl#OCL
>>>>>>>>>>> // org.eclipse.ocl : the factory uri
>>>>>>>>>>> // OCL the key for defining the constraints
>>>>>>>>>>> - OCL
>>>>>>>>>>> + constraint1
>>>>>>>>>>> -> self....
>>>>>>>>>>>
>>>>>>>>>>> To implement this i add behaviour to EObjectvalidator which
>>>>>>>>>>> 1) will check constraints
>>>>>>>>>>> 2) registers the factory and the key
>>>>>>>>>>> 3) check if there is key
>>>>>>>>>>> 4) check if there is constraints defining previously
>>>>>>>>>>> 5) ask the factory to create a validator and validate the
>>>>>>>>>>> current object
>>>>>>>>>>>
>>>>>>>>>>> The factories are loaded with emf.ecore plugin with all other
>>>>>>>>>>> facotries (factory_override for example)
>>>>>>>>>>>
>>>>>>>>>>> I started to test and it seems it works with dynamic instance
>>>>>>>>>>> and generated EMF code. Maybe i don't see limitations to my
>>>>>>>>>>> solutions particularly i don't know if it is always possible
>>>>>>>>>>> to resolve EAnnotations
>>>>>>>>>>>
>>>>>>>>>>> what do you think about ?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----8<-----
>>>>
>
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #427659 is a reply to message #427099] |
Wed, 25 February 2009 14:54 |
Tristan Faure
Messages: 460
Registered: July 2009 |
Senior Member |
|
|
Tristan FAURE a écrit :
> you opinion doesn't disturb me, we just need to see if this satisfy
> everybody. For my design i copy the OCL tutorial presented on the web
> with the list of constraints.
>
> I can use your syntax but i think it could be better to keep a root
> eannotation static like "Ecore" to not check for each root if it is a
> factory
>
> to be conform to your idea we can have
>
> EAnnotation : Ecore
> factory -> factoryName
> name -> authorsAge
> constraint -> books.authors.age > 20
> severity -> ERROR
> message -> author's must be at least 20 years old
>
> or like i said previously factory declared in Epackage
> factory -> keydeclaredInEPackage
>
> Andrew H a écrit :
>> One more thing. To be useful to me it would need to work standalone.
>>
>> Andrew H wrote:
>>
>>> To be honest I'm not familiar with how things work behind the scenes
>>> here with factories and extension points. From a users point of view
>>> though I would say the less I would need to do the better.
>>
>>> Could you get away with simply something like the following?
>>
>>> EAnnotation : <some uri for ocl>
>>> constraint1 -> books.authors.age > 20
>>> constraint2 -> books.authors.name <> "fred"
>>> etc.
>>
>>> i.e. can we put many constraints in one annotation and can we avoid
>>> needing to list them (like in constraints -> constraint1 constraint2)?
>>
>>> I guess the problem with that though is it limits other data that may
>>> need to be attached to the constraint. e.g. severity etc.
>>
>>> In that case you might be better then to go for something like:
>>
>>> EAnnotation : <some uri for ocl>
>>> name -> authorsAge
>>> constraint -> books.authors.age > 20
>>> severity -> ERROR
>>> message -> author's must be at least 20 years old
>>
>>> Note these fields should align with the validation frameworks fields.
>>
>>> This is more powerful and useful in the long run and if tool support
>>> is added to Ecore Diagrams for this then it won't matter to users
>>> that it is long winded.
>>
>>> my 2c worth
>>
>>> cheers
>>
>>> Andrew
>>
>>> Tristan FAURE wrote:
>>
>>>> Hi
>>
>>>> i would ask for (maybe) modifying the design
>>>> Currently :
>>>> for each ECLass
>>>> Eclass A
>>>> EAnnotation : Ecore
>>>> constraints -> constraint1 constraint2
>>>> factory -> factoryID
>>>> EAnnotation : factoryID
>>>> constraint1 -> String interpreted by constraint
>>>> delegator
>>>> EAnnotation : factoryID
>>>> constraint2 -> String interpreted by constraint
>>>> delegator
>>>> Eclass B
>>>> EAnnotation : Ecore
>>>> constraints -> constraint1 constraint2
>>>> factory -> factoryID
>>>> EAnnotation : factoryID
>>>> constraint1 -> String interpreted by constraint
>>>> delegator
>>>> EAnnotation : factoryID
>>>> constraint2 -> String interpreted by constraint
>>>> delegator
>>
>>>> Do you think filling factory for each ECLass is irritating ? maybe
>>>> we should consider an EAnnotation in EPackage defining Factory
>>>> example :
>>
>>>> EPackage
>>>> Eannotation : Ecore
>>>> factory -> factoryID#Key
>>>> Eclass A
>>>> EAnnotation : Ecore
>>>> constraints -> constraint1 constraint2
>>>> EAnnotation : Key
>>>> constraint1 -> String interpreted by
>>>> constraint delegator
>>>> EAnnotation : Key
>>>> constraint2 -> String interpreted by
>>>> constraint delegator
>>>> Eclass B
>>>> EAnnotation : Ecore
>>>> constraints -> constraint1 constraint2
>>>> EAnnotation : Key
>>>> constraint1 -> String interpreted by
>>>> constraint delegator
>>>> EAnnotation : Key
>>>> constraint2 -> String interpreted by
>>>> constraint delegator
>>
>>>> In this example I used the notation with the Key but we keep the
>>>> factory id
>>
>>>> what is your opinion ?
>>
>>
>>>> Andrew H a écrit :
>>>>> FWIW I for one would be quite interested in this or similar
>>>>> functionality built into EMF. I tend to add a fair bit of OCL in
>>>>> comment boxes to Ecore Diagrams, but this of course then is only
>>>>> doco and I'd have to duplicate this when we get to the phase of the
>>>>> project where we will do OCL for real.
>>>>>
>>>>> Ideally Ecore Diagrams would add explicit support for OCL
>>>>> constraints and derived features expressed as OCL.
>>>>>
>>>>> Tristan FAURE wrote:
>>>>>
>>>>>> I've added an OCL implementation. It is easier to check the
>>>>>> functionality
>>>>>
>>>>>> Tristan FAURE a écrit :
>>>>>>> Thank's christian
>>>>>>> i just was a little bit worry about missing some steps in the
>>>>>>> Eclipse process
>>>>>>>
>>>>>>> Christian W. Damus a écrit :
>>>>>>>> Hi, Tristan,
>>>>>>>>
>>>>>>>> Sorry, I've been rather busy and lost track of this ... I'll try
>>>>>>>> to make time for a closer review of your patch, especially with
>>>>>>>> an eye to how it would be implemented in OCL.
>>>>>>>>
>>>>>>>> cW
>>>>>>>>
>>>>>>>> Tristan FAURE wrote:
>>>>>>>>> no feedbacks :( ?
>>>>>>>>> does somebody checked ? do i need to provide an implementation ?
>>>>>>>>>
>>>>>>>>> Tristan FAURE a écrit :
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> bug created :
>>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
>>>>>>>>>>
>>>>>>>>>> for EAnnotations yes i would like to know if there is some
>>>>>>>>>> limitations I'm quite sure that I don't realize EMF complexity
>>>>>>>>>> and it's difficult to say "hey the feature works in all case"
>>>>>>>>>> :) Particularly when we see the huge work made by Ed for
>>>>>>>>>> delegate features
>>>>>>>>>>
>>>>>>>>>> Christian W. Damus a écrit :
>>>>>>>>>>> Hi, Tristan,
>>>>>>>>>>>
>>>>>>>>>>> This looks like a clean design, a good approach. This sounds
>>>>>>>>>>> like it would make a good contribution to complement the
>>>>>>>>>>> enhancements I referenced, earlier.
>>>>>>>>>>>
>>>>>>>>>>> What do you mean by your worry about always being able to
>>>>>>>>>>> resolve annotations? Annotations cannot be
>>>>>>>>>>> cross-resource-contained, so they can be expected never to be
>>>>>>>>>>> proxies. Also, AFAIK, only the GenModel annotations can be
>>>>>>>>>>> suppressed from the generated package metadata (because they
>>>>>>>>>>> are only needed by the generator, not the run-time). Or, do
>>>>>>>>>>> you mean that the provider of the constraint factory may not
>>>>>>>>>>> be available at run-time, depending on the Eclipse
>>>>>>>>>>> configuration?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> Christian
>>>>>>>>>>>
>>>>>>>>>>> Tristan FAURE wrote:
>>>>>>>>>>>> Hi all
>>>>>>>>>>>>
>>>>>>>>>>>> i didn't wait for your answer but if i go to the wrong
>>>>>>>>>>>> direction i can study other solution.
>>>>>>>>>>>>
>>>>>>>>>>>> I have designed for my solution where models constraints are
>>>>>>>>>>>> checked with validate menu
>>>>>>>>>>>>
>>>>>>>>>>>> the developer :
>>>>>>>>>>>>
>>>>>>>>>>>> - creates a factory designed to create its validator
>>>>>>>>>>>> the validator has to implement a validate method :
>>>>>>>>>>>>
>>>>>>>>>>>> "boolean validate(String value, EObject object,
>>>>>>>>>>>> DiagnosticChain theDiagnostics, Map<Object, Object> context)"
>>>>>>>>>>>>
>>>>>>>>>>>> the parameter value is the string provided by the user it
>>>>>>>>>>>> can be OCL rule, class name, it's just a String and the
>>>>>>>>>>>> method knows how to manage it
>>>>>>>>>>>>
>>>>>>>>>>>> - adds an extension point referencing its factory and the
>>>>>>>>>>>> uri associated to it
>>>>>>>>>>>>
>>>>>>>>>>>> the user :
>>>>>>>>>>>>
>>>>>>>>>>>> - designs its metamodel
>>>>>>>>>>>> - puts its constraints with eannotations and the factory
>>>>>>>>>>>> used (here for example OCL)
>>>>>>>>>>>> - Ecore
>>>>>>>>>>>> + constraints
>>>>>>>>>>>> -> constraint1 constraint2 constraint3
>>>>>>>>>>>> + factory
>>>>>>>>>>>> -> org.eclipse.ocl#OCL
>>>>>>>>>>>> // org.eclipse.ocl : the factory uri
>>>>>>>>>>>> // OCL the key for defining the constraints
>>>>>>>>>>>> - OCL
>>>>>>>>>>>> + constraint1
>>>>>>>>>>>> -> self....
>>>>>>>>>>>>
>>>>>>>>>>>> To implement this i add behaviour to EObjectvalidator which
>>>>>>>>>>>> 1) will check constraints
>>>>>>>>>>>> 2) registers the factory and the key
>>>>>>>>>>>> 3) check if there is key
>>>>>>>>>>>> 4) check if there is constraints defining previously
>>>>>>>>>>>> 5) ask the factory to create a validator and validate the
>>>>>>>>>>>> current object
>>>>>>>>>>>>
>>>>>>>>>>>> The factories are loaded with emf.ecore plugin with all
>>>>>>>>>>>> other facotries (factory_override for example)
>>>>>>>>>>>>
>>>>>>>>>>>> I started to test and it seems it works with dynamic
>>>>>>>>>>>> instance and generated EMF code. Maybe i don't see
>>>>>>>>>>>> limitations to my solutions particularly i don't know if it
>>>>>>>>>>>> is always possible to resolve EAnnotations
>>>>>>>>>>>>
>>>>>>>>>>>> what do you think about ?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----8<-----
>>>>>
>>
|
|
|
| Re: Model Integrity in EMF with MDT OCL [message #427660 is a reply to message #427659] |
Wed, 25 February 2009 14:55 |
Tristan Faure
Messages: 460
Registered: July 2009 |
Senior Member |
|
|
Sorry for triple post
i've taken in consideration feedbacks and modify in consequence please
consult bug for more information
https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
Tristan FAURE a écrit :
> Tristan FAURE a écrit :
>> you opinion doesn't disturb me, we just need to see if this satisfy
>> everybody. For my design i copy the OCL tutorial presented on the web
>> with the list of constraints.
>>
>> I can use your syntax but i think it could be better to keep a root
>> eannotation static like "Ecore" to not check for each root if it is a
>> factory
>>
>> to be conform to your idea we can have
>>
>> EAnnotation : Ecore
>> factory -> factoryName
>> name -> authorsAge
>> constraint -> books.authors.age > 20
>> severity -> ERROR
>> message -> author's must be at least 20 years old
>>
>> or like i said previously factory declared in Epackage
>> factory -> keydeclaredInEPackage
>>
>> Andrew H a écrit :
>>> One more thing. To be useful to me it would need to work standalone.
>>>
>>> Andrew H wrote:
>>>
>>>> To be honest I'm not familiar with how things work behind the scenes
>>>> here with factories and extension points. From a users point of view
>>>> though I would say the less I would need to do the better.
>>>
>>>> Could you get away with simply something like the following?
>>>
>>>> EAnnotation : <some uri for ocl>
>>>> constraint1 -> books.authors.age > 20
>>>> constraint2 -> books.authors.name <> "fred"
>>>> etc.
>>>
>>>> i.e. can we put many constraints in one annotation and can we avoid
>>>> needing to list them (like in constraints -> constraint1 constraint2)?
>>>
>>>> I guess the problem with that though is it limits other data that
>>>> may need to be attached to the constraint. e.g. severity etc.
>>>
>>>> In that case you might be better then to go for something like:
>>>
>>>> EAnnotation : <some uri for ocl>
>>>> name -> authorsAge
>>>> constraint -> books.authors.age > 20
>>>> severity -> ERROR
>>>> message -> author's must be at least 20 years old
>>>
>>>> Note these fields should align with the validation frameworks fields.
>>>
>>>> This is more powerful and useful in the long run and if tool support
>>>> is added to Ecore Diagrams for this then it won't matter to users
>>>> that it is long winded.
>>>
>>>> my 2c worth
>>>
>>>> cheers
>>>
>>>> Andrew
>>>
>>>> Tristan FAURE wrote:
>>>
>>>>> Hi
>>>
>>>>> i would ask for (maybe) modifying the design
>>>>> Currently :
>>>>> for each ECLass
>>>>> Eclass A
>>>>> EAnnotation : Ecore
>>>>> constraints -> constraint1 constraint2
>>>>> factory -> factoryID
>>>>> EAnnotation : factoryID
>>>>> constraint1 -> String interpreted by constraint
>>>>> delegator
>>>>> EAnnotation : factoryID
>>>>> constraint2 -> String interpreted by constraint
>>>>> delegator
>>>>> Eclass B
>>>>> EAnnotation : Ecore
>>>>> constraints -> constraint1 constraint2
>>>>> factory -> factoryID
>>>>> EAnnotation : factoryID
>>>>> constraint1 -> String interpreted by constraint
>>>>> delegator
>>>>> EAnnotation : factoryID
>>>>> constraint2 -> String interpreted by constraint
>>>>> delegator
>>>
>>>>> Do you think filling factory for each ECLass is irritating ? maybe
>>>>> we should consider an EAnnotation in EPackage defining Factory
>>>>> example :
>>>
>>>>> EPackage
>>>>> Eannotation : Ecore
>>>>> factory -> factoryID#Key
>>>>> Eclass A
>>>>> EAnnotation : Ecore
>>>>> constraints -> constraint1 constraint2
>>>>> EAnnotation : Key
>>>>> constraint1 -> String interpreted by
>>>>> constraint delegator
>>>>> EAnnotation : Key
>>>>> constraint2 -> String interpreted by
>>>>> constraint delegator
>>>>> Eclass B
>>>>> EAnnotation : Ecore
>>>>> constraints -> constraint1 constraint2
>>>>> EAnnotation : Key
>>>>> constraint1 -> String interpreted by
>>>>> constraint delegator
>>>>> EAnnotation : Key
>>>>> constraint2 -> String interpreted by
>>>>> constraint delegator
>>>
>>>>> In this example I used the notation with the Key but we keep the
>>>>> factory id
>>>
>>>>> what is your opinion ?
>>>
>>>
>>>>> Andrew H a écrit :
>>>>>> FWIW I for one would be quite interested in this or similar
>>>>>> functionality built into EMF. I tend to add a fair bit of OCL in
>>>>>> comment boxes to Ecore Diagrams, but this of course then is only
>>>>>> doco and I'd have to duplicate this when we get to the phase of
>>>>>> the project where we will do OCL for real.
>>>>>>
>>>>>> Ideally Ecore Diagrams would add explicit support for OCL
>>>>>> constraints and derived features expressed as OCL.
>>>>>>
>>>>>> Tristan FAURE wrote:
>>>>>>
>>>>>>> I've added an OCL implementation. It is easier to check the
>>>>>>> functionality
>>>>>>
>>>>>>> Tristan FAURE a écrit :
>>>>>>>> Thank's christian
>>>>>>>> i just was a little bit worry about missing some steps in the
>>>>>>>> Eclipse process
>>>>>>>>
>>>>>>>> Christian W. Damus a écrit :
>>>>>>>>> Hi, Tristan,
>>>>>>>>>
>>>>>>>>> Sorry, I've been rather busy and lost track of this ... I'll
>>>>>>>>> try to make time for a closer review of your patch, especially
>>>>>>>>> with an eye to how it would be implemented in OCL.
>>>>>>>>>
>>>>>>>>> cW
>>>>>>>>>
>>>>>>>>> Tristan FAURE wrote:
>>>>>>>>>> no feedbacks :( ?
>>>>>>>>>> does somebody checked ? do i need to provide an implementation ?
>>>>>>>>>>
>>>>>>>>>> Tristan FAURE a écrit :
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> bug created :
>>>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
>>>>>>>>>>>
>>>>>>>>>>> for EAnnotations yes i would like to know if there is some
>>>>>>>>>>> limitations I'm quite sure that I don't realize EMF
>>>>>>>>>>> complexity and it's difficult to say "hey the feature works
>>>>>>>>>>> in all case" :) Particularly when we see the huge work made
>>>>>>>>>>> by Ed for delegate features
>>>>>>>>>>>
>>>>>>>>>>> Christian W. Damus a écrit :
>>>>>>>>>>>> Hi, Tristan,
>>>>>>>>>>>>
>>>>>>>>>>>> This looks like a clean design, a good approach. This
>>>>>>>>>>>> sounds like it would make a good contribution to complement
>>>>>>>>>>>> the enhancements I referenced, earlier.
>>>>>>>>>>>>
>>>>>>>>>>>> What do you mean by your worry about always being able to
>>>>>>>>>>>> resolve annotations? Annotations cannot be
>>>>>>>>>>>> cross-resource-contained, so they can be expected never to
>>>>>>>>>>>> be proxies. Also, AFAIK, only the GenModel annotations can
>>>>>>>>>>>> be suppressed from the generated package metadata (because
>>>>>>>>>>>> they are only needed by the generator, not the run-time).
>>>>>>>>>>>> Or, do you mean that the provider of the constraint factory
>>>>>>>>>>>> may not be available at run-time, depending on the Eclipse
>>>>>>>>>>>> configuration?
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>
>>>>>>>>>>>> Christian
>>>>>>>>>>>>
>>>>>>>>>>>> Tristan FAURE wrote:
>>>>>>>>>>>>> Hi all
>>>>>>>>>>>>>
>>>>>>>>>>>>> i didn't wait for your answer but if i go to the wrong
>>>>>>>>>>>>> direction i can study other solution.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have designed for my solution where models constraints
>>>>>>>>>>>>> are checked with validate menu
>>>>>>>>>>>>>
>>>>>>>>>>>>> the developer :
>>>>>>>>>>>>>
>>>>>>>>>>>>> - creates a factory designed to create its validator
>>>>>>>>>>>>> the validator has to implement a validate method :
>>>>>>>>>>>>>
>>>>>>>>>>>>> "boolean validate(String value, EObject object,
>>>>>>>>>>>>> DiagnosticChain theDiagnostics, Map<Object, Object> context)"
>>>>>>>>>>>>>
>>>>>>>>>>>>> the parameter value is the string provided by the user it
>>>>>>>>>>>>> can be OCL rule, class name, it's just a String and the
>>>>>>>>>>>>> method knows how to manage it
>>>>>>>>>>>>>
>>>>>>>>>>>>> - adds an extension point referencing its factory and the
>>>>>>>>>>>>> uri associated to it
>>>>>>>>>>>>>
>>>>>>>>>>>>> the user :
>>>>>>>>>>>>>
>>>>>>>>>>>>> - designs its metamodel
>>>>>>>>>>>>> - puts its constraints with eannotations and the factory
>>>>>>>>>>>>> used (here for example OCL)
>>>>>>>>>>>>> - Ecore
>>>>>>>>>>>>> + constraints
>>>>>>>>>>>>> -> constraint1 constraint2 constraint3
>>>>>>>>>>>>> + factory
>>>>>>>>>>>>> -> org.eclipse.ocl#OCL
>>>>>>>>>>>>> // org.eclipse.ocl : the factory uri
>>>>>>>>>>>>> // OCL the key for defining the constraints
>>>>>>>>>>>>> - OCL
>>>>>>>>>>>>> + constraint1
>>>>>>>>>>>>> -> self....
>>>>>>>>>>>>>
>>>>>>>>>>>>> To implement this i add behaviour to EObjectvalidator which
>>>>>>>>>>>>> 1) will check constraints
>>>>>>>>>>>>> 2) registers the factory and the key
>>>>>>>>>>>>> 3) check if there is key
>>>>>>>>>>>>> 4) check if there is constraints defining previously
>>>>>>>>>>>>> 5) ask the factory to create a validator and validate the
>>>>>>>>>>>>> current object
>>>>>>>>>>>>>
>>>>>>>>>>>>> The factories are loaded with emf.ecore plugin with all
>>>>>>>>>>>>> other facotries (factory_override for example)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I started to test and it seems it works with dynamic
>>>>>>>>>>>>> instance and generated EMF code. Maybe i don't see
>>>>>>>>>>>>> limitations to my solutions particularly i don't know if it
>>>>>>>>>>>>> is always possible to resolve EAnnotations
>>>>>>>>>>>>>
>>>>>>>>>>>>> what do you think about ?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----8<-----
>>>>>>
>>>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 08:34:10 GMT 2024
Powered by FUDForum. Page generated in 0.06405 seconds |
] 
Search
Help
Register
Login
Home
