|
| Re: Restricting candidates of a feature. [message #1298727 is a reply to message #1298656] |
Wed, 16 April 2014 13:00   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Wilbert,
Comments below.
On 16/04/2014 2:07 PM, Wilbert Alberts wrote:
> Hi,
>
> I have a more or less general question. When editing a property, I
> would like to limit the collection candidates according to a specific
> subset. As explained in the EMF bible (EMF Eclipse Modeling Framework
> by Steinberg et al.), page 393: restricting reference targets, a
> modification of the generated item provider is required.
>
> My question is whether it would be possible to specify such
> restriction in a similar way as invariants, derived attributes etc. I
> know that it is not implemented at this moment but what would need to
> be changed?
It's not clear specifically what you have in mind... Something that
would allow you test each possible/reachable instance if it satisfies
some constraint...
>
> Assume that I have a model containing Components. Components are made
> of Parts and Parts can be connected by their Ports. However, the
> restriction is that connections need to remain within the Component
> (so not every Port is feasible candidate).
I see.
> The ecore meta model:
>
> package selectorexperiment : selectorexperiment =
> 'http://www.example.org/selectorexperiment'
> {
> class Model
> {
> property components : Component[*] { ordered composes };
> }
> class Component
> {
> property parts : Part[*] { ordered composes };
> }
> class Part
> {
> property ports : Port[*] { ordered composes };
> }
> class Port
> {
> invariant local: -- Connected port should be
> present in the same Component as this one.
> oclContainer().oclContainer() =
> other.oclContainer().oclContainer();
>
> property other : Port[?];
> }
> }
>
>
> The meta model presented above 'forbids' ports that are connected to
> ports living outside the containing Component.
>
> However, for 'editor' support it would be nice if a selection of
> feasible candidates could be specified. It might look like:
>
> class Port
> {
> invariant local: -- Connected port should be
> present in the same Component as this one.
> oclContainer().oclContainer() =
> other.oclContainer().oclContainer();
>
> property other : Port[?] { selector:
> ocl.Container().oclContainer().parts.parts; };
> }
>
> The genmodel could use this annotation to generate the appropriate
> modification for the PortItemProvider. I would be willing to give it a
> try myself if somebody with a little bit more insight would be so kind
> to validate whether this would be a fruitfull approach.
All the property descriptors are created by
org.eclipse.emf.edit.provider.ItemProviderAdapter.createItemPropertyDescriptor(AdapterFactory,
ResourceLocator, String, String, EStructuralFeature, boolean, boolean,
boolean, Object, String, String[]) and with the Provider Root Extends
Class property of the GenModel's Edit section you can generate
references to your own hand written derived ItemPropertyDescriptor. In
there you could override
org.eclipse.emf.edit.provider.ItemPropertyDescriptor.getChoiceOfValues(Object).
That override will be called for all of your model's generated
properties. In here you could inspect annotations on the eClass of the
argument, and you could use that to drive whatever behavior makes sense,
e.g., you might have an annotation that points at an EOperation in the
model and you could use eInvoke to call it and use the boolean result to
determine which objects to include in the choice of values and which to
reject.
In other words, I don't think it's necessary to generate specialized
code to achieve the goal of not hand modifying your generated item
providers...
>
> Greetings,
> Wilbert.
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.02923 seconds
] 
Search
Help
Register
Login
Home
