| [GMF Notation] Why reason ViewImpl.getElement() is customized [message #881384] |
Mon, 04 June 2012 08:47  |
Eclipse User |
|
|
|
Hi,
In our product which use GMF with CDO, we have encountered some issues
due to the customized methode ViewImpl.getElement(), what is the
historical reason of this customization? If I remove this customization,
I have many exceptions, especially NPE because the View corresponding to
label child of Node have always the ViewImpl.element at null, but not
failed with the customization because this last returns the
ViewImpl.element of the parent View.
Best Regards.
|
|
|
| Re: [GMF Notation] Why reason ViewImpl.getElement() is customized [message #881448 is a reply to message #881384] |
Mon, 04 June 2012 11:21  |
| Eclipse User |
|
|
|
Esteban,
I don't know the historical reason, but even with CDO you can customize
getters that need to do computations to return a result; you just can't
refer to fields because they don't exist. I don't have the source for
this class in my IDE. What does this method look like?
On 04/06/2012 2:47 PM, Esteban Dugueperoux wrote:
> Hi,
>
> In our product which use GMF with CDO, we have encountered some issues
> due to the customized methode ViewImpl.getElement(), what is the
> historical reason of this customization? If I remove this
> customization, I have many exceptions, especially NPE because the View
> corresponding to label child of Node have always the ViewImpl.element
> at null, but not failed with the customization because this last
> returns the ViewImpl.element of the parent View.
>
> Best Regards.
|
|
|
| Re: [GMF Notation] Why reason ViewImpl.getElement() is customized [message #881989 is a reply to message #881448] |
Tue, 05 June 2012 11:25 |
| Eclipse User |
|
|
|
Hi,
Thanks for the reply, i have forget to say that we use the Legacy mode
of CDO to use the GMF notation metamodel. The ViewImpl.getElement() is :
public EObject getElement() {
if (!isSetElement()) {
EObject container = eContainer();
if (container instanceof View) {
View view = (View) container;
element = view.getElement();
}
}
if (element != null && element.eIsProxy()) {
EObject oldElement = element;
element = eResolveProxy((InternalEObject) element);
if (element != oldElement) {
if (eNotificationRequired())
eNotify(new ENotificationImpl(this,
Notification.RESOLVE, NotationPackage.VIEW__ELEMENT, oldElement, element));
}
}
return element;
}
And in fact the NPE was due to another issue, but labels for my Nodes
are not displayed because the ViewImpl corresponding to the label child
of Node have ViewImpl.getElement() returning null without the
customization. I think that initializing ViewImpl.element field (in our
ViewFactory) for label to the same value of the parent Node will fix the
issue.
Thanks.
On 04/06/2012 17:21, Ed Merks wrote:
> Esteban,
>
> I don't know the historical reason, but even with CDO you can customize
> getters that need to do computations to return a result; you just can't
> refer to fields because they don't exist. I don't have the source for
> this class in my IDE. What does this method look like?
>
>
> On 04/06/2012 2:47 PM, Esteban Dugueperoux wrote:
>> Hi,
>>
>> In our product which use GMF with CDO, we have encountered some issues
>> due to the customized methode ViewImpl.getElement(), what is the
>> historical reason of this customization? If I remove this
>> customization, I have many exceptions, especially NPE because the View
>> corresponding to label child of Node have always the ViewImpl.element
>> at null, but not failed with the customization because this last
>> returns the ViewImpl.element of the parent View.
>>
>> Best Regards.
|
|
|
Powered by
FUDForum. Page generated in 0.05000 seconds
Home