Home » Modeling » GMF (Graphical Modeling Framework) » Reordering attributes in a compartment
| Reordering attributes in a compartment [message #164809] |
Fri, 07 December 2007 23:13  |
Eclipse User |
|
|
|
Originally posted by: jdente.21technologies.com
Hi,
Does anybody know how to re-order the attributes inside of a compartment?
I have two classes, ClassA and ClassB. ClassA has an aggregation
relationship (lets call it Nodes) to ClassB in which ClassA can contain any
number of ClassB nodes. Thus, ClassA.getNodes() would return a List<ClassB>
containing all of ClassA's nodes. ClassA is drawn as a simple square with a
compartment, and the ClassB nodes inside ClassA are displayed as a list
inside of ClassA's compartment. I want to adjust the ordering of the ClassB
nodes inside the compratment of ClassA, by adding MoveUp and MoveDown
actions on ClassB nodes. This basically equates to re-ordering the list
returned by ClassA.getNodes().
I have implemented everything and everything works correctly except for the
diagram refresh. If I have a ClassA node with two ClassB nodes in it, and I
use the MoveUp action on one of the ClassB nodes, the ecore model gets
modified. In other words, if I then call ClassA.getNodes(), the correct new
ordering is returned. However, the compartment does not update. If I save
the diagram, close it, and re-open it, the new ordering will correctly
appear in the compartment. How do I tell this compartment to refresh after
I have modified the ordering of the ClassA.getNodes() list?
All edits to the list of ClassB nodes are made inside a TransactionalCommand
obtained through the active editor. I have tried simply swapping indices of
items in the ClassA.getNodes() list. I have tried removing everything from
the ClassA.getNodes() list and then re-adding everything in the correct
order. I have tried using eNotifications after I have made the edits to the
ClassB ordering. I have told all of the relevant EditParts to refresh. I
am out of ideas...
Also, I tried the following experiment. Say I have a ClassA node with
several ClassB nodes already contained in it. I created a new ClassB node.
Normally, to add ClassB nodes you do (pseudo code):
ClassA.getNodes().add(new ClassB());
This tacks the ClassB node onto the end of the compartment. Instead, I
tried the following:
ClassA.getNodes().add(0, new ClassB());
This should place the new ClassB node at the top of the compartment, or the
front of the ClassA.getNodes() list. Instead, it places the new ClassB node
at the end of the compartment (visually), but at the front of the
ClassA.getNodes() list in the ecore model. Thus, when I close and re-open
the diagram, the new ClassB node appears at the top of the compartment in
the correct position. How do I refresh this compartment without closing and
re-opening?
Thanks for the help,
Joe
|
|
|
| Re: Reordering attributes in a compartment [message #164961 is a reply to message #164809] |
Mon, 10 December 2007 23:05  |
| Eclipse User |
|
|
|
Originally posted by: jdente.21technologies.com
Hi again,
I managed to re-order the attributes inside of my compartment by creating
and executing two distinct transactions. First I copy all of my attributes
to a new list that I re-order with the correct new ordering of elements.
Then, inside of the first transaction, I clear the model's list of
attributes. After that, in a second transaction, I add all of the elements
from the re-ordered list back into the model. While this works, I'm afraid
it may cause lag issues in the future so I would like a more elegant
solution.
Re-ordering the nodes inside of my ClassA.getNodes() list caused my ecore
model to become dirty, as well as my diagram, but it was not recognized as a
modification that required a redraw. Calling refresh() on my EditParts and
repaint() on my IFigures did not have any effect on updating my diagram.
From what I understand from this behavior, it seems like the compartment is
initialized with an initial ordering taken from the order of the elements in
ClassA.getNodes(). However, from that point on, the compartment does not
care about order. Instead, it simply cares about content. Thus, operations
that remove and operations that add work correctly, which is why I was able
to solve the problem using only add / remove operations in two transactions.
However, operations that merely change the ordering without changing the
content were not recognized as operations that necessitated a redraw. This
is why call ClassA.getNodes().add(0, new ClassB()) updated the diagram with
a new ClassB node that was at the end of the container and not the
beginning. If the diagram is saved and re-opened, my new ClassB node
appears at the beginning of the diagram beause the compartment only cares
about the ClassA.getValues() list's order upon initialization.
So, is there a way in which I can achieve what I did using a single
transaction? Is there a way to tell the ClassA EditPart that modifications
involving the ClassA.getNodes() lists's ordering are as important as an add
or removal?
Thanks,
Joe
"Joe Dente" <jdente@21technologies.com> wrote in message
news:fjck2f$e3o$1@build.eclipse.org...
> Hi,
> Does anybody know how to re-order the attributes inside of a compartment?
>
> I have two classes, ClassA and ClassB. ClassA has an aggregation
> relationship (lets call it Nodes) to ClassB in which ClassA can contain
> any number of ClassB nodes. Thus, ClassA.getNodes() would return a
> List<ClassB> containing all of ClassA's nodes. ClassA is drawn as a
> simple square with a compartment, and the ClassB nodes inside ClassA are
> displayed as a list inside of ClassA's compartment. I want to adjust the
> ordering of the ClassB nodes inside the compratment of ClassA, by adding
> MoveUp and MoveDown actions on ClassB nodes. This basically equates to
> re-ordering the list returned by ClassA.getNodes().
>
> I have implemented everything and everything works correctly except for
> the diagram refresh. If I have a ClassA node with two ClassB nodes in it,
> and I use the MoveUp action on one of the ClassB nodes, the ecore model
> gets modified. In other words, if I then call ClassA.getNodes(), the
> correct new ordering is returned. However, the compartment does not
> update. If I save the diagram, close it, and re-open it, the new ordering
> will correctly appear in the compartment. How do I tell this compartment
> to refresh after I have modified the ordering of the ClassA.getNodes()
> list?
>
> All edits to the list of ClassB nodes are made inside a
> TransactionalCommand obtained through the active editor. I have tried
> simply swapping indices of items in the ClassA.getNodes() list. I have
> tried removing everything from the ClassA.getNodes() list and then
> re-adding everything in the correct order. I have tried using
> eNotifications after I have made the edits to the ClassB ordering. I have
> told all of the relevant EditParts to refresh. I am out of ideas...
>
> Also, I tried the following experiment. Say I have a ClassA node with
> several ClassB nodes already contained in it. I created a new ClassB
> node. Normally, to add ClassB nodes you do (pseudo code):
> ClassA.getNodes().add(new ClassB());
> This tacks the ClassB node onto the end of the compartment. Instead, I
> tried the following:
> ClassA.getNodes().add(0, new ClassB());
> This should place the new ClassB node at the top of the compartment, or
> the front of the ClassA.getNodes() list. Instead, it places the new
> ClassB node at the end of the compartment (visually), but at the front of
> the ClassA.getNodes() list in the ecore model. Thus, when I close and
> re-open the diagram, the new ClassB node appears at the top of the
> compartment in the correct position. How do I refresh this compartment
> without closing and re-opening?
>
> Thanks for the help,
> Joe
>
|
|
|
Goto Forum:
Current Time: Tue Apr 16 13:10:53 GMT 2024
Powered by FUDForum. Page generated in 0.23723 seconds |
] 
Search
Help
Register
Login
Home
