Home » Modeling » EMF » containment attribute for references
| |
| Re: containment attribute for references [message #512806 is a reply to message #512791] |
Sun, 07 February 2010 16:58   |
 Martin Tauber
Messages: 122
Registered: July 2009 |
Senior Member |
|
|
Am 07.02.10 18:54, schrieb Ed Merks:
> Martin,
>
> Comments below.
>
> Martin Tauber wrote:
>> Good Day everybody,
>>
>> I am struggeling with the containment property for references. I have
>> a model with a cantainment relationship. So I added the containment
>> attribute in my annotated java. Everthing seams to be ok when I
>> generate the ecode model. The properties page shows me that the
>> reference is a containment reference.
>>
>> Now I want to use emf.edit to create a view to browse my model. I
>> created my content provider for that view extending
>> adapterFactoryContentPrivider. I overrode the hasChildren and
>> getChildren methods to add some structural nodes.
> Why did you need to do that?
My View contains grouping nodes which the model does not support. (I am
browsing a mib file with different definitions types like object
definintions and trap definitions. The mib object will maintain a list
of the superclass "definition" which itself has child classes Object
Definition and TrapType. Which all are children of the mib. Now for
navigating the view I added grouping nodes which are not part of the
model. All this comes from overwritting the treeContentProvider Methods.
When it then comes to showing the details in the treeView (the children
of TrapType and ObjectDeinifnition) I would like to use the emf
generated Methods again, so my implementation would call the superclass
methods. This is why I am doing it this way ... (Id there a better way
to achieve what I want to achieve.)
As I understand the emf code, the generated itemProvider code does not
contain methods for the treeContentProvider. I am thinking (and maybe
I'm wrong there) the AdapterFactoryContentProvider uses the emf
reflective api to implement the treeContenProvider methods.
>> Everthing works fine until these methods call the appropriate parent
>> method (as soon as my containment references should be called). They
>> just will always return without the expected result.
I was wondering why the children of TrapType and ObjectDefinition are
not shown. These are the first Objects in the view which should be
provided by emf and not by my overritten mwthods. This is why I set
breakpoints in the code. Well and there I saw that even though I would
expect the hasChildren and getChildren methods to return values, they
return false and an empty array ...
> I don't follow.
>>
>> What am I missing here?
> Note that if you created a GenModel before the reference was a
> containment reference the GenFeature properties for that reference will
> be set to default values based on that fact. If you later change it to
> be a containment reference, you'd also want to change the GenFeature's
> properties to modify the things you seem to be doing by hand. I.e.,
> you'll likely not want a properties editor for it, you'll likely want it
> to support Children and Child Creation, and to do notification...
Now have hard time following ... :-( I experianced problems changing the
containment property in the model. It only worked after I through away
the Factory and Package interfaces and classes as well as the genmode
and the ecore model ....
>> Regards
>> Martin
|
|
|
| Re: containment attribute for references [message #512936 is a reply to message #512806] |
Mon, 08 February 2010 11:41 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Martin,
Comments below.
Martin Tauber wrote:
> Am 07.02.10 18:54, schrieb Ed Merks:
>> Martin,
>>
>> Comments below.
>>
>> Martin Tauber wrote:
>>> Good Day everybody,
>>>
>>> I am struggeling with the containment property for references. I have
>>> a model with a cantainment relationship. So I added the containment
>>> attribute in my annotated java. Everthing seams to be ok when I
>>> generate the ecode model. The properties page shows me that the
>>> reference is a containment reference.
>>>
>>> Now I want to use emf.edit to create a view to browse my model. I
>>> created my content provider for that view extending
>>> adapterFactoryContentPrivider. I overrode the hasChildren and
>>> getChildren methods to add some structural nodes.
>> Why did you need to do that?
>
> My View contains grouping nodes which the model does not support. (I
> am browsing a mib file with different definitions types like object
> definintions and trap definitions. The mib object will maintain a list
> of the superclass "definition" which itself has child classes Object
> Definition and TrapType. Which all are children of the mib. Now for
> navigating the view I added grouping nodes which are not part of the
> model. All this comes from overwritting the treeContentProvider Methods.
I see. The book explains how to do that.
>
> When it then comes to showing the details in the treeView (the
> children of TrapType and ObjectDeinifnition) I would like to use the
> emf generated Methods again, so my implementation would call the
> superclass methods. This is why I am doing it this way ... (Id there a
> better way to achieve what I want to achieve.)
You'll definitely need to do some hand coding to modify how the
artificial children are shown under the parent, how the artificial
parent itself produces children, and how those children return the
artificial parent.
>
>
> As I understand the emf code, the generated itemProvider code does not
> contain methods for the treeContentProvider.
No, it implements ITreeItemContentProvider.
> I am thinking (and maybe I'm wrong there) the
> AdapterFactoryContentProvider uses the emf reflective api to implement
> the treeContenProvider methods.
No, but it looks that way by default and ReflectiveItemProviderAdapter
does exactly that.
>
>
>
>>> Everthing works fine until these methods call the appropriate parent
>>> method (as soon as my containment references should be called). They
>>> just will always return without the expected result.
>
> I was wondering why the children of TrapType and ObjectDefinition are
> not shown. These are the first Objects in the view which should be
> provided by emf and not by my overritten mwthods. This is why I set
> breakpoints in the code. Well and there I saw that even though I would
> expect the hasChildren and getChildren methods to return values, they
> return false and an empty array ...
Are any of those object'ss features defined to act as children in the
GenFeature properties for those features?
>
>
>> I don't follow.
>>>
>>> What am I missing here?
>> Note that if you created a GenModel before the reference was a
>> containment reference the GenFeature properties for that reference will
>> be set to default values based on that fact. If you later change it to
>> be a containment reference, you'd also want to change the GenFeature's
>> properties to modify the things you seem to be doing by hand. I.e.,
>> you'll likely not want a properties editor for it, you'll likely want it
>> to support Children and Child Creation, and to do notification...
>
> Now have hard time following ... :-( I experianced problems changing
> the containment property in the model. It only worked after I through
> away the Factory and Package interfaces and classes as well as the
> genmode and the ecore model ....
Hmmm. As if regeneration isn't working... But if regeneration generally
didn't work, all users would be complaining about that. I'm not sure
what might have gone wrong. Does regeneration work now? I.e., if you
delete a method marked @generated, and regenerate, does it come back?
Are there issues in the Error Log view?
>
>
>>> Regards
>>> Martin
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: containment attribute for references [message #513100 is a reply to message #512936] |
Mon, 08 February 2010 19:49 |
Martin Tauber
Messages: 122
Registered: July 2009 |
Senior Member |
|
|
Ed, see my comments below ...
Am 08.02.10 12:41, schrieb Ed Merks:
> Martin,
>
> Comments below.
>
> Martin Tauber wrote:
>> Am 07.02.10 18:54, schrieb Ed Merks:
>>> Martin,
>>>
>>> Comments below.
>>>
>>> Martin Tauber wrote:
>>>> Good Day everybody,
>>>>
>>>> I am struggeling with the containment property for references. I have
>>>> a model with a cantainment relationship. So I added the containment
>>>> attribute in my annotated java. Everthing seams to be ok when I
>>>> generate the ecode model. The properties page shows me that the
>>>> reference is a containment reference.
>>>>
>>>> Now I want to use emf.edit to create a view to browse my model. I
>>>> created my content provider for that view extending
>>>> adapterFactoryContentPrivider. I overrode the hasChildren and
>>>> getChildren methods to add some structural nodes.
>>> Why did you need to do that?
>>
>> My View contains grouping nodes which the model does not support. (I
>> am browsing a mib file with different definitions types like object
>> definintions and trap definitions. The mib object will maintain a list
>> of the superclass "definition" which itself has child classes Object
>> Definition and TrapType. Which all are children of the mib. Now for
>> navigating the view I added grouping nodes which are not part of the
>> model. All this comes from overwritting the treeContentProvider Methods.
> I see. The book explains how to do that.
I'll check ... I guess I have to reread chapters 3.2 and 10.1 ....
>>
>> When it then comes to showing the details in the treeView (the
>> children of TrapType and ObjectDeinifnition) I would like to use the
>> emf generated Methods again, so my implementation would call the
>> superclass methods. This is why I am doing it this way ... (Id there a
>> better way to achieve what I want to achieve.)
> You'll definitely need to do some hand coding to modify how the
> artificial children are shown under the parent, how the artificial
> parent itself produces children, and how those children return the
> artificial parent.
Would you recommand to add the "artificial" children to the model?
>>
>>
>> As I understand the emf code, the generated itemProvider code does not
>> contain methods for the treeContentProvider.
> No, it implements ITreeItemContentProvider.
>> I am thinking (and maybe I'm wrong there) the
>> AdapterFactoryContentProvider uses the emf reflective api to implement
>> the treeContenProvider methods.
> No, but it looks that way by default and ReflectiveItemProviderAdapter
> does exactly that.
>>
>>
>>
>>>> Everthing works fine until these methods call the appropriate parent
>>>> method (as soon as my containment references should be called). They
>>>> just will always return without the expected result.
>>
>> I was wondering why the children of TrapType and ObjectDefinition are
>> not shown. These are the first Objects in the view which should be
>> provided by emf and not by my overritten mwthods. This is why I set
>> breakpoints in the code. Well and there I saw that even though I would
>> expect the hasChildren and getChildren methods to return values, they
>> return false and an empty array ...
> Are any of those object'ss features defined to act as children in the
> GenFeature properties for those features?
>>
>>
>>> I don't follow.
>>>>
>>>> What am I missing here?
>>> Note that if you created a GenModel before the reference was a
>>> containment reference the GenFeature properties for that reference will
>>> be set to default values based on that fact. If you later change it to
>>> be a containment reference, you'd also want to change the GenFeature's
>>> properties to modify the things you seem to be doing by hand. I.e.,
>>> you'll likely not want a properties editor for it, you'll likely want it
>>> to support Children and Child Creation, and to do notification...
>>
>> Now have hard time following ... :-( I experianced problems changing
>> the containment property in the model. It only worked after I through
>> away the Factory and Package interfaces and classes as well as the
>> genmode and the ecore model ....
> Hmmm. As if regeneration isn't working... But if regeneration generally
> didn't work, all users would be complaining about that. I'm not sure
> what might have gone wrong. Does regeneration work now? I.e., if you
> delete a method marked @generated, and regenerate, does it come back?
> Are there issues in the Error Log view?
I have been working quite a while with emf and have ignored emf.edit
until now (which I am starting to regret ...) so I quite confident that
I have not done something completely wrong (well u never know ...) But I
can't reproduce it. The interesting thing was, that the getter methods
tried to access proxies. This caused compilation errors. After removinf
the packages, factory and model files as sead everything was fine.
Working with emf i experianced that this helps sorting out problems. I
sometimes ran into problems after refactoring where emf "remembered"
refactored features. Deleting the model was not enough I then had to
delete the files mentioned above as well.
Nevertheless I think we can ignore this, because I can't reproduce it
anyway ...
>>
>>
>>>> Regards
>>>> Martin
>>
|
|
|
| Re: containment attribute for references [message #513102 is a reply to message #513100] |
Mon, 08 February 2010 20:11 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Martin,
Comments below.
Martin Tauber wrote:
> Ed, see my comments below ...
>
> Am 08.02.10 12:41, schrieb Ed Merks:
>> Martin,
>>
>> Comments below.
>>
>> Martin Tauber wrote:
>>> Am 07.02.10 18:54, schrieb Ed Merks:
>>>> Martin,
>>>>
>>>> Comments below.
>>>>
>>>> Martin Tauber wrote:
>>>>> Good Day everybody,
>>>>>
>>>>> I am struggeling with the containment property for references. I have
>>>>> a model with a cantainment relationship. So I added the containment
>>>>> attribute in my annotated java. Everthing seams to be ok when I
>>>>> generate the ecode model. The properties page shows me that the
>>>>> reference is a containment reference.
>>>>>
>>>>> Now I want to use emf.edit to create a view to browse my model. I
>>>>> created my content provider for that view extending
>>>>> adapterFactoryContentPrivider. I overrode the hasChildren and
>>>>> getChildren methods to add some structural nodes.
>>>> Why did you need to do that?
>>>
>>> My View contains grouping nodes which the model does not support. (I
>>> am browsing a mib file with different definitions types like object
>>> definintions and trap definitions. The mib object will maintain a list
>>> of the superclass "definition" which itself has child classes Object
>>> Definition and TrapType. Which all are children of the mib. Now for
>>> navigating the view I added grouping nodes which are not part of the
>>> model. All this comes from overwritting the treeContentProvider
>>> Methods.
>> I see. The book explains how to do that.
>
> I'll check ... I guess I have to reread chapters 3.2 and 10.1 ....
>
>>>
>>> When it then comes to showing the details in the treeView (the
>>> children of TrapType and ObjectDeinifnition) I would like to use the
>>> emf generated Methods again, so my implementation would call the
>>> superclass methods. This is why I am doing it this way ... (Id there a
>>> better way to achieve what I want to achieve.)
>
>> You'll definitely need to do some hand coding to modify how the
>> artificial children are shown under the parent, how the artificial
>> parent itself produces children, and how those children return the
>> artificial parent.
>
> Would you recommand to add the "artificial" children to the model?
That's certainly easier, but it's important to have a nice simple model.
>
>
>>>
>>>
>>> As I understand the emf code, the generated itemProvider code does not
>>> contain methods for the treeContentProvider.
>> No, it implements ITreeItemContentProvider.
>>> I am thinking (and maybe I'm wrong there) the
>>> AdapterFactoryContentProvider uses the emf reflective api to implement
>>> the treeContenProvider methods.
>> No, but it looks that way by default and ReflectiveItemProviderAdapter
>> does exactly that.
>>>
>>>
>>>
>>>>> Everthing works fine until these methods call the appropriate parent
>>>>> method (as soon as my containment references should be called). They
>>>>> just will always return without the expected result.
>>>
>>> I was wondering why the children of TrapType and ObjectDefinition are
>>> not shown. These are the first Objects in the view which should be
>>> provided by emf and not by my overritten mwthods. This is why I set
>>> breakpoints in the code. Well and there I saw that even though I would
>>> expect the hasChildren and getChildren methods to return values, they
>>> return false and an empty array ...
>> Are any of those object'ss features defined to act as children in the
>> GenFeature properties for those features?
>>>
>>>
>>>> I don't follow.
>>>>>
>>>>> What am I missing here?
>>>> Note that if you created a GenModel before the reference was a
>>>> containment reference the GenFeature properties for that reference
>>>> will
>>>> be set to default values based on that fact. If you later change it to
>>>> be a containment reference, you'd also want to change the GenFeature's
>>>> properties to modify the things you seem to be doing by hand. I.e.,
>>>> you'll likely not want a properties editor for it, you'll likely
>>>> want it
>>>> to support Children and Child Creation, and to do notification...
>>>
>>> Now have hard time following ... :-( I experianced problems changing
>>> the containment property in the model. It only worked after I through
>>> away the Factory and Package interfaces and classes as well as the
>>> genmode and the ecore model ....
>> Hmmm. As if regeneration isn't working... But if regeneration generally
>> didn't work, all users would be complaining about that. I'm not sure
>> what might have gone wrong. Does regeneration work now? I.e., if you
>> delete a method marked @generated, and regenerate, does it come back?
>> Are there issues in the Error Log view?
>
> I have been working quite a while with emf and have ignored emf.edit
> until now (which I am starting to regret ...) so I quite confident
> that I have not done something completely wrong (well u never know
> ...) But I can't reproduce it. The interesting thing was, that the
> getter methods tried to access proxies. This caused compilation
> errors. After removinf the packages, factory and model files as sead
> everything was fine.
Very odd...
>
> Working with emf i experianced that this helps sorting out problems. I
> sometimes ran into problems after refactoring where emf "remembered"
> refactored features. Deleting the model was not enough I then had to
> delete the files mentioned above as well.
>
> Nevertheless I think we can ignore this, because I can't reproduce it
> anyway ...
I know if any file has syntax errors (i.e., if they fail to parse) that
it kills regeneration in general...
>
>
>
>>>
>>>
>>>>> Regards
>>>>> Martin
>>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 16:55:59 GMT 2024
Powered by FUDForum. Page generated in 0.03396 seconds |
] 
Search
Help
Register
Login
Home
