| Derived Volatile Feature as Link [message #146035] |
Thu, 09 August 2007 18:08  |
Eclipse User |
|
|
|
Originally posted by: x.maysonnave.gmail.com
Hi,
I successfully defined a derived volatile feature as a link in a diagram.
However :
1.1 - How to avoid link deletion ?
1.2 - How to avoid source or target update (I sucessfully did it through
code modification) but it sounds a dirty hacking to me
1.3 is a there a better and cleaner way through gmfgen to generate the
necessary stuff ?
2 - When I modify the source non derived volatile feature through the
diagram property view, the diagram doesn't update the derived volatile
feature (link) accordingly.
Am I missing something ?
PS:
- the generated emf editor works well
- no transactional editing domain sharing
Thanks
|
|
|
|
| Re: Derived Volatile Feature as Link [message #146242 is a reply to message #146098] |
Fri, 10 August 2007 18:43  |
| Eclipse User |
|
|
|
Originally posted by: x.maysonnave.gmail.com
Alex Shatalin a écrit :
> Hello Xavier,
>
>> 1.1 - How to avoid link deletion ?
> looks like you have to remove corresponding popup menu action using
> plugin.xml.
in the plugin.xml file there are two kind of informations :
1 - The diagramEditorID register a delete global handler :
<ElementType
class=" org.eclipse.gmf.runtime.diagram.ui.editparts.IGraphicalEditP art ">
<GlobalActionId actionId="delete"/>
</ElementType>
I understand that all the objects who inherit this interface should be
deletable. keyboard delete and global delete are active.
is a there a way to inactivate that for my particular object ? perhaps
with gmfgen ?
2 - You are right, there is a popupmenuaction with a
deletefromdiagramaction registered with my particular link object.
However this generated hook is not necessary in my context as I generate
the diagram with synchronized true. 'Delete from model' is inactivated
>
>> 1.2 - How to avoid source or target update (I sucessfully did it through
>> code modification) but it sounds a dirty hacking to me
> What is the problem with source/target updates?
the link is defined with a Target Feature defined (no Containment
Feature, no Element and no Source Feature defined)
This feature is defined on an Abstract EClass Object.
it has changeable, derived, transient and volative set to false.
gmfgen generate in the according Create and Reorient Command setters
against this feature. In my case setters are not generated in my ecore
model. There is probably a bug in this area.
1.2.1 - There is another problem in this area. as an abstract eclass
object there is no default image generated by emf (default genmodel
behaviour). The generated navigator (Project Explorer) display an ugly
red square against this kind of link.
While debugging I noticed that abstract target feature cause a bad
default image resolution, Navigator and the tool palette are impacted.
>> 1.3 is a there a better and cleaner way through gmfgen to generate the
>> necessary stuff ?
> Looks like this is the best way to represent some "indirect"
> reletionship between two diagram nodes.
My question was not clear. In fact I was asking if it was possible to
defined some read only attributes for figures with gmfgen. I am a newbie
with GMF...
>
>> 2 - When I modify the source non derived volatile feature through the
>> diagram property view, the diagram doesn't update the derived volatile
>> feature (link) accordingly.
> Looks like you should provide corresponding notification from the source
> object notifying everybody that "volatile" feature value was changed
> (using notifications from the original feature).
This derived volatile feature is changeable. Through the EMF editor,
when I set a new value, the editor is well impacted. In my diagram I
expect a full redraw as link could potentially be reorganized. However
nothing happen, I need to close and reopen my diagram to see the update.
Here is a code snippet from the set feature :
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated NOT
*/
public void setSequence(int newSequence) {
if (newSequence < 0) {
return;
}
int oldSequence = getSequence();
if (newSequence == oldSequence) {
return;
}
EList<AbstractNode> nodes = null;
if (getParent() != null) {
NodeContainer parent = getParent();
if (parent.getChildren() != null) {
nodes = parent.getChildren();
}
} else if (getRoot() != null) {
Root root = getRoot();
if (root.getChildren() != null) {
nodes = root.getChildren();
}
}
if (nodes == null || newSequence >= nodes.size()) {
return;
}
nodes.move(newSequence, oldSequence);
if (eNotificationRequired())
eNotify(new ENotificationImpl(this, Notification.MOVE,
DslfactoryPackage.ABSTRACT_NODE__SEQUENCE, oldSequence, newSequence));
}
I noticed that the eNotify could be removed. the emf editor is updated
correctly.
I am still digging...
Thanks.
>
> -----------------
> Alex Shatalin
>
>
|
|
|
|
| Re: Derived Volatile Feature as Link [message #146580 is a reply to message #146367] |
Wed, 15 August 2007 07:52 |
| Eclipse User |
|
|
|
Originally posted by: x.maysonnave.gmail.com
Alex Shatalin a écrit :
Hi Alex,
> Hello Xavier,
>
>> 1 - The diagramEditorID register a delete global handler :
>> <ElementType
>> class=" org.eclipse.gmf.runtime.diagram.ui.editparts.IGraphicalEditP art
>> ">
>> <GlobalActionId actionId="delete"/>
>> </ElementType>
> In addition it has DiagramContributionItemProvider registered and
> providing whole default popup menu structure. I suggest you to read
> runtime documentation and filter-out delete action for your particular
> nodes (by default corresponding action is contributed to popup menu).
I found a good solution. I overload the shouldProcess(DestroyRequest) in
the according SemanticEditPolicy. This inactivate either the global
handler and the popup menu. The solution you suggest do not work with
the delete global handler.
>
>> is a there a way to inactivate that for my particular object ? perhaps
>> with gmfgen ?
> No, there is no such a place now.
>
>> model. There is probably a bug in this area.
> Yes, please file a request for it.
I am going to open a request.
>
>> behaviour). The generated navigator (Project Explorer) display an ugly
>> red square against this kind of link.
> You can override default icon by placing corresponding image into the
> image registry used by navigator.
I am going to investigate this. The other solution consists to turn
abstract off for such objects. I don't like this.
>
>> While debugging I noticed that abstract target feature cause a bad
>> default image resolution, Navigator and the tool palette are impacted.
> AFAIK, it is possible to specify palette image explicitly in .gmfgen model.
You're true, this is a workaround to avoid teh default behaviour.
>
>> This derived volatile feature is changeable. Through the EMF editor,
>> when I set a new value, the editor is well impacted. In my diagram I
>> expect a full redraw as link could potentially be reorganized. However
>> nothing happen, I need to close and reopen my diagram to see the
>> update.
> Looks like a known problem with link update - as a workaround I suggest
> to call CanonicalEditpolicy for the diagram from corresponding EditPart
> (link EditPart or link source EditPart) on receiving proper
> notificzation from the domain model.
Thanks it works. I found the trick.
Best Regards.
>
> -----------------
> Alex Shatalin
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.04187 seconds
] 
Search
Help
Register
Login
Home
