Eclipse Community Forums: GMF (Graphical Modeling Framework) » How to generate single EditPart class for different contexts of the same EObject?

Home » Modeling » GMF (Graphical Modeling Framework) » How to generate single EditPart class for different contexts of the same EObject?

Show: Today's Messages :: Show Polls :: Message Navigator

How to generate single EditPart class for different contexts of the same EObject? [message #543119]

Mon, 28 June 2010 13:07

emil salageanu

Messages: 94
Registered: June 2010
Location: Nice, France

Member

Hello,

Let's take this example:

              <professor> 
                      <identity>
                            .....
                       </identity> 
                  ... some other data
              </professor>
              <student>
                     <identity>
                            .....
                       </identity> 
                  ... some other data               
               </student>

We have the "identity" element as a possible child of "professor" or "student".
We define a digram node "identity" and two mappings: one for "identyty" as the child of "professor" and one as the child of "student".

GMF will generate 2 EditPart Classes: IdentityEditPart and Identity1EditPart corresponding to each context of the Identity (there is more that just EditPart classes: CanonicalEditPolicy, CreateCommand, ItemSemanticEditPolicy are created in duplicate).

Just say that I know that I neeed exactly the same behaviour for the "identity" element, independent of the context. Can I specify somewhere to only generate one EditPart class ?

Note: Modifying the name of the classes to be generated in the *.gmfgen model does not work, it generates code with errors.

Now let's imagine we have "identity" as child of 20 different elements. If I want to change something in the code that would affect "identity" in all the contexts, I'll have to copy-paste the same code 20 times ...

Thanks for any idea ...

Report message to a moderator

Re: How to generate single EditPart class for different contexts of the same EObject? [message #543188 is a reply to message #543119]

Mon, 28 June 2010 16:17

Aurélien Pupier

Messages: 637
Registered: July 2009
Location: Grenoble, FRANCE

Senior Member

Hi,

you can use Child Reference in gmfmap.

Regards,

Aurélien Pupier - Red Hat
Senior Software Engineer in Fuse Tooling team

[Updated on: Mon, 28 June 2010 16:17]

Report message to a moderator

Re: How to generate single EditPart class for different contexts of the same EObject? [message #543199 is a reply to message #543119]

Mon, 28 June 2010 16:44

emil salageanu

Messages: 94
Registered: June 2010
Location: Nice, France

Member

Hi Aurelien,

Of course, in the GMF map we have something like:

    Node Mapping <Professor/ProfesorNode> 
       ChildReference <id:Identity/IdentityNode>
           NodeMappping < Identity/IdentityNode>
    Node Mapping <Student/StudentNode> 
       ChildReference <id:Identity/IdentityNode>
           NodeMappping < Identity/IdentityNode>

This is what is generating 2 EditPart classes for the Identity element.

It is not very important for me at this time, just that I think it should be better to just generate one set of classes (so just one EditPart) in the diagram for the Identity element in this example if the Identity graphical/editable element has the same behaviour in the 2 contexts.

Thanks

Report message to a moderator

Re: How to generate single EditPart class for different contexts of the same EObject? [message #543381 is a reply to message #543119]

Tue, 29 June 2010 09:21

emil salageanu

Messages: 94
Registered: June 2010
Location: Nice, France

Member

Just wanted to say this:

In the example above, lets imagine that identity is a complex element, something like:

  <identity>
         <a> 
                 < a1/>
          </a>
          <b>
                  ...
          </b>
    </identity>

As we have identity in two contexts (child of professor and child of student), in the gmfmap we will have to define twice the mappings for the complex structure:

Node Mapping <Professor/ProfesorNode> 
       ChildReference <id:Identity/IdentityNode>
           NodeMappping < Identity/IdentityNode>
                  ChildReference <a/aNode>
                      NodeMapping <a:a ....>
                          ChildReferenece <a1/a1Node>
                             NodeMapping <...>  
    Node Mapping <Student/StudentNode> 
       ChildReference <id:Identity/IdentityNode>
           NodeMappping < Identity/IdentityNode>
                   ChildReference <a/aNode>
                      NodeMapping <a:a ....>
                          ChildReferenece <a1/a1Node>
                             NodeMapping <...>

We notice that this block is duplicated:

NodeMappping < Identity/IdentityNode>
                  ChildReference <a/aNode>
                      NodeMapping <a:a ....>
                          ChildReferenece <a1/a1Node>
                             NodeMapping <...>

... which generates duplicate classes.
There might be cases where we want such a modeling. But is there a way to define the above duplicate mappping only once ?

Report message to a moderator

Re: How to generate single EditPart class for different contexts of the same EObject? (BPMN exampl) [message #543489 is a reply to message #543119]

Tue, 29 June 2010 14:59

emil salageanu

Messages: 94
Registered: June 2010
Location: Nice, France

Member

If my example with professor/student identities did not captivate too many people (I admit I could have thought at something more interesting to illustrate my purpose), let's then take the well known bpmn example contributed by intalio (http://www.eclipse.org/bpmn/ with a tutorial here: http://wiki.eclipse.org/GMF_Tutorial_BPMN).

In the example we have an "Activity" EObject that can be child of a Pool or child of a Subprocess. (the subprocess itself is child of a pool).

In the gmfmap file they have something like:

  NodeMapping <Pool/Pool>
       ChildReference <vertices:Activity/Activity>
            NodeMapping <Activity/Activity>
       ChildReference <vertices:SubProcess/SubProcess>
            NodeMapping <SubProcess/SubProcess>
                  ChildReference <vertices:Activity/Activity>

Which generates the classes:

ActivityEditPart
ActivityCanonicalEditPolicy
ActivityCreateCommand
ActivityItemSemanticEditPolicy

and also

Activity2EditPart
Activity2CanonicalEditPolicy
Activity2CreateCommand
Activity2ItemSemanticEditPolicy

Now, If I need to change something in one of the EditParts or one of the policies (that shoud affect all the Activity figures), I have to do the same thing twice.

Is this the only way to model and generate a case like that in GMF?

[Updated on: Tue, 29 June 2010 15:00]

Report message to a moderator

Re: How to generate single EditPart class for different contexts of the same EObject? (BPMN exampl) [message #543504 is a reply to message #543489]

Tue, 29 June 2010 15:42

emil salageanu

Messages: 94
Registered: June 2010
Location: Nice, France

Member

Well, sometimes is good speaking to oneself, I got it clear right now:

In the GMF map, when writting a ChidReference, we dont have to add a NodeMapping child, but rather make a reference to an already defined NodeMapping.

So, in ly earlier example:

 
 <identity>
         <a> 
                 < a1/>
          </a>
          <b>
                  ...
          </b>
    </identity>

The mapping would rather be :

Node Mapping <Professor/ProfesorNode> 
       ChildReference <id:Identity/IdentityNode>
           NodeMappping < Identity/IdentityNode>
                  ChildReference <a/aNode>
                      NodeMapping <a:a ....>
                          ChildReferenece <a1/a1Node>
                             NodeMapping <...>  
    Node Mapping <Student/StudentNode> 
       ChildReference <id:Identity/IdentityNode>  <-- reference to the eralier defined NodeMapping

rather then the mapping I defiined in my previous message.

This will generate 2 EditParts for Identity (one as child of Professor and one as child of Student) but only one edit part for each sub-element of Identity. It seems correct right now, as Identity might have different behaviour depending on its parent, but children inside an Identity element should always have the same behaviour independently of the context of Identity.

Report message to a moderator

Re: How to generate single EditPart class for different contexts of the same EObject? (BPMN exampl) [message #638458 is a reply to message #543504]

Thu, 11 November 2010 11:17

Eclipse User

Originally posted by: marius.groeger.googlemail.com

Emil, Aurelien,

this is a bit late but anyway...

On 29.06.2010 17:42, emil salageanu wrote:
> The mapping would rather be :
>
>
> Node Mapping <Professor/ProfesorNode> ChildReference
> <id:Identity/IdentityNode>
> NodeMappping < Identity/IdentityNode>
> ChildReference <a/aNode>
> NodeMapping <a:a ....>
> ChildReferenece <a1/a1Node>
> NodeMapping <...> Node Mapping <Student/StudentNode> ChildReference
> <id:Identity/IdentityNode> <-- reference to the eralier defined NodeMapping
>
> rather then the mapping I defiined in my previous message.
> This will generate 2 EditParts for Identity (one as child of Professor
> and one as child of Student) but only one edit part for each sub-element
> of Identity. It seems correct right now, as Identity might have
> different behaviour depending on its parent, but children inside an
> Identity element should always have the same behaviour independently of
> the context of Identity.

With this mapping, are you able to move (drag&drop) a professor's
identity to a student? I have a similar setup, and I can't. Even though
the semantic element is moved, and even though the diagram element
*appears* to move, the diagram element is then somehow incomplete and
can't be moved at its new position. Its feature label is shows the
default value (<...>) instead of the name.

BTW, I'm on Eclipse Galileo. (Can't upgrade to Helios that easily since
the GMFTools don't work with Helios. [Last time I checked anyway.]).

Thanks for any inputs on this.

Marius

Report message to a moderator

Previous Topic:	Customizing compartment item labels
Next Topic:	OCL Constraint: Check if first node after start is of type initial validation

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 05:55:06 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter