| getContentPane and dealing with different sets of children [message #208187] |
Sun, 29 January 2006 02:33  |
Eclipse User |
|
|
|
Originally posted by: cravikiran.myrealbox.com
Hello,
So, I've been using GEF for a few weeks now and stumbled across an issue.
What I have is a model element that has 3 different sets of children - one
that should be displayed in a top layer of the model's figure, another set
that should be displayed in a middle layer and a third set displayed in a
bottom layer. Now, what I want to be able to do is override my Edit
Part's getContentPane() to return the appropriate layer depending on which
set a particular child belongs to. However, since getContentPane does not
take any parameters (to suggest a hint), this seems unduly complicated to
do. I can think of several approaches - one is to make the model have
three child placeholder model elements that each holds one set of
children. But this seems to break default selection behavior... or at
least makes it more complicated to do it right. I am thinking of
overriding some methods from AbstractGraphicalEditPart that would normally
call getContentPane() but make it call some custom getContentPane(Object
hint) instead. Problem with this is I don't like messing with
implementation of libraries - if the methods I override in
AbstractGraphicalEditPart change, I have to maintain those as well. Is
there some way to do this that would offer the ease of the latter method
but not require me to change implementation of library code? If not, I
guess this is mostly a suggestion to change getContentPane() to include a
hint about what child the content pane is for (maybe passing the model
element directly).
Thanks,
Ravi
|
|
|
| Re: getContentPane and dealing with different sets of children [message #208281 is a reply to message #208187] |
Mon, 30 January 2006 21:13  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
The change to getContentsPane would not be sufficient because there is still
the issue of figure index.
The recommended way to do this is to introduce grouping editparts at each
layer. If this complicates selection issues, then you should open bugs with
a description of the selection problem.
You can easily prevent your layers from being selected by overriding
isSelectable.
You could investigate a 3rd mechanism. You could create editpolicies for the
2nd and 3rd sets of children, and have them perform the figure
addition/removal, and determination of content pane. There is probably
common code that could be abstracted and even contributed back to GEF.
"Ravi Chodavarapu" <cravikiran@myrealbox.com> wrote in message
news:a049fb11a36c4eedb3ee694931542e50$1@www.eclipse.org...
> Hello,
>
> So, I've been using GEF for a few weeks now and stumbled across an issue.
> What I have is a model element that has 3 different sets of children - one
> that should be displayed in a top layer of the model's figure, another set
> that should be displayed in a middle layer and a third set displayed in a
> bottom layer. Now, what I want to be able to do is override my Edit
> Part's getContentPane() to return the appropriate layer depending on which
> set a particular child belongs to. However, since getContentPane does not
> take any parameters (to suggest a hint), this seems unduly complicated to
> do. I can think of several approaches - one is to make the model have
> three child placeholder model elements that each holds one set of
> children. But this seems to break default selection behavior... or at
> least makes it more complicated to do it right. I am thinking of
> overriding some methods from AbstractGraphicalEditPart that would normally
> call getContentPane() but make it call some custom getContentPane(Object
> hint) instead. Problem with this is I don't like messing with
> implementation of libraries - if the methods I override in
> AbstractGraphicalEditPart change, I have to maintain those as well. Is
> there some way to do this that would offer the ease of the latter method
> but not require me to change implementation of library code? If not, I
> guess this is mostly a suggestion to change getContentPane() to include a
> hint about what child the content pane is for (maybe passing the model
> element directly).
>
> Thanks,
> Ravi
>
|
|
|
Powered by
FUDForum. Page generated in 0.03442 seconds
] 
Search
Help
Register
Login
Home
