Eclipse Community Forums: GMF (Graphical Modeling Framework)

Help

Home

Home » Modeling » GMF (Graphical Modeling Framework) » The need for Compartments

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

The need for Compartments [message #181960]

Wed, 09 April 2008 15:45

Barbara Rosi-Schwartz

Messages: 448
Registered: July 2009

Senior Member

Hi everyone.

I have two quick questions related to Compartments:

1) If, in my editor, I have containment (i.e. one object drawn inside
of the other), and I want to be able to move and resize the contained
object at will, do I absolutely need to define a Compartment in my
container object or can I do without (if I do not require optional
collapse/expand behaviour etc.)?

2) If the answer to question 1) is no, I do not necessarily need a
Compartment, what are the pros and cons of having/not having it?

Any suggestion?

TIA,
B.

--
   Barbara Rosi-Schwartz
   Etish Limited [http://www.etish.org]
Blog: http://www.brs4etish.blogspot.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Report message to a moderator

Re: The need for Compartments [message #181980 is a reply to message #181960]

Wed, 09 April 2008 16:54

Lazar Codrut-Lucian

Messages: 91
Registered: July 2009

Member

You can, but there is no benefit, only drawbacks. You can configure the
compartment to be non-collapsible in gmfgraph, in case you don't want that.

Otherwise, you can alter the createContents method of the main EditPart
to have a figure (as a container) that allows a nested figure to be
moved around. However, you won't have a default mechanism to save the
position of the child figure, for a reload. And, basically, you will
re-invent the wheel, by re-implementing the container functionality.

Using the existing Compartment functionality is the best way to go.

Lucian

Report message to a moderator

Re: The need for Compartments [message #181987 is a reply to message #181980]

Wed, 09 April 2008 16:55

Barbara Rosi-Schwartz

Messages: 448
Registered: July 2009

Senior Member

On 2008-04-09 17:54:58 +0100, Lazar Codrut Lucian
<lcodrutlucian@yahoo.com> said:

> You can, but there is no benefit, only drawbacks. You can configure the
> compartment to be non-collapsible in gmfgraph, in case you don't want that.
>
> Otherwise, you can alter the createContents method of the main EditPart
> to have a figure (as a container) that allows a nested figure to be
> moved around. However, you won't have a default mechanism to save the
> position of the child figure, for a reload. And, basically, you will
> re-invent the wheel, by re-implementing the container functionality.
>
> Using the existing Compartment functionality is the best way to go.
>
> Lucian

Thanks Lucian,

A clear and definitive answer!... :-)
B.

--
   Barbara Rosi-Schwartz
   Etish Limited [http://www.etish.org]
Blog: http://www.brs4etish.blogspot.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Report message to a moderator

Re: The need for Compartments [message #182019 is a reply to message #181960]

Wed, 09 April 2008 17:11

Alexander Shatalin

Messages: 2928
Registered: July 2009

Senior Member

Hello Barbara Rosi-Schwartz,

> 1) If, in my editor, I have containment (i.e. one object drawn inside
> of the other), and I want to be able to move and resize the contained
> object at will, do I absolutely need to define a Compartment in my
> container object or can I do without (if I do not require optional
> collapse/expand behaviour etc.)?
GMF supports this use case to some etend. Try generating code for this situation
and you'll see..

-----------------
Alex Shatalin

Report message to a moderator

Re: The need for Compartments [message #182885 is a reply to message #182019]

Mon, 14 April 2008 10:30

Barbara Rosi-Schwartz

Messages: 448
Registered: July 2009

Senior Member

Hi Alex.

On 2008-04-09 18:11:19 +0100, Alex Shatalin <vano@borland.com> said:

> Hello Barbara Rosi-Schwartz,

> GMF supports this use case to some etend. Try generating code for this
> situation and you'll see..
>

Right now I was looking for the quick and non-experimental way out :-),
but I will certainly give it a go, out of curiosity, at some point.

Thanks!

B.
--
   Barbara Rosi-Schwartz
   Etish Limited [http://www.etish.org]
Blog: http://www.brs4etish.blogspot.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Report message to a moderator

Previous Topic:	Cannot generate inherited field
Next Topic:	polyline color doesn't change after moving figure to seperate plug-in

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 02:26:19 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter