Home » Modeling » GMF (Graphical Modeling Framework) » How to replace the view of an existing element
| How to replace the view of an existing element [message #63909] |
Tue, 17 October 2006 07:27  |
Eclipse User |
|
|
|
Originally posted by: jan.herriger.gmx.de
Hello all,
I'd like to have an ObjectActionDelegate which replaces the view of the
selected element.
In the delegate, I use the following code to create a new view:
....
ObjectAdapter objAdapter = new ObjectAdapter();
objAdapter.setObject(PetrinetElementTypes.Transition_2002);
CreateViewRequest.ViewDescriptor viewDescriptor = new
CreateViewRequest.ViewDescriptor(
objAdapter, Node.class,
null,
PetrinetDiagramEditorPlugin.DIAGRAM_PREFERENCES_HINT);
CreateViewRequest cvRequest = new CreateViewRequest((viewDescriptor));
Command cmd = selectedElement.getParent().getCommand(cvRequest);
IDiagramEditDomain dEditingDomain =
selectedElement.getDiagramEditDomain();
dEditingDomain.getDiagramCommandStack().execute(cmd);
....
Is there a way to replace the selectedElement's view with the new one?
best regards
Jan
|
|
| |
| Re: How to replace the view of an existing element [message #64543 is a reply to message #64476] |
Tue, 17 October 2006 14:12  |
| Eclipse User |
|
|
|
Originally posted by: jan.herriger.gmx.de
Thanks Vlad,
but I think, I was on the wrong approach...
Basically I want to switch between two visual styles of one EditPart.
So, I think i will add a property to the semantic model, wich indicates
what style the EditPart should have and add a logic to the EditPart's
class accordingly. I don't know, if this is the right approach. But it
seems to work.
Vlad Ciubotariu schrieb:
> Look in CreationEditPolicy and ComponentEditPolicy for commands to create
> views and delete, respectively.
>
> On Tue, 17 Oct 2006 13:27:30 +0200, Jan Herriger wrote:
>
>> Hello all,
>>
>> I'd like to have an ObjectActionDelegate which replaces the view of the
>> selected element.
>>
>> In the delegate, I use the following code to create a new view:
>>
>> ...
>> ObjectAdapter objAdapter = new ObjectAdapter();
>> objAdapter.setObject(PetrinetElementTypes.Transition_2002);
>> CreateViewRequest.ViewDescriptor viewDescriptor = new
>> CreateViewRequest.ViewDescriptor(
>> objAdapter, Node.class,
>> null,
>> PetrinetDiagramEditorPlugin.DIAGRAM_PREFERENCES_HINT);
>> CreateViewRequest cvRequest = new CreateViewRequest((viewDescriptor));
>> Command cmd = selectedElement.getParent().getCommand(cvRequest);
>> IDiagramEditDomain dEditingDomain =
>> selectedElement.getDiagramEditDomain();
>> dEditingDomain.getDiagramCommandStack().execute(cmd);
>> ...
>>
>> Is there a way to replace the selectedElement's view with the new one?
>>
>> best regards
>> Jan
>
|
|
|
| Re: How to replace the view of an existing element [message #64588 is a reply to message #64543] |
Tue, 17 October 2006 14:47 |
| Eclipse User |
|
|
|
Originally posted by: vcciubot.uwaterloo.ca
Ok, in that case look at the code in ShapeEditPart to see how it
registers/listens to the notational model and refreshes when changes
occur. Do the same for your semantic model.
hope this helps
vlad
On Tue, 17 Oct 2006 20:12:49 +0200, Jan Herriger wrote:
> Thanks Vlad,
>
> but I think, I was on the wrong approach...
>
> Basically I want to switch between two visual styles of one EditPart.
> So, I think i will add a property to the semantic model, wich indicates
> what style the EditPart should have and add a logic to the EditPart's
> class accordingly. I don't know, if this is the right approach. But it
> seems to work.
>
> Vlad Ciubotariu schrieb:
>> Look in CreationEditPolicy and ComponentEditPolicy for commands to create
>> views and delete, respectively.
>>
>> On Tue, 17 Oct 2006 13:27:30 +0200, Jan Herriger wrote:
>>
>>> Hello all,
>>>
>>> I'd like to have an ObjectActionDelegate which replaces the view of the
>>> selected element.
>>>
>>> In the delegate, I use the following code to create a new view:
>>>
>>> ...
>>> ObjectAdapter objAdapter = new ObjectAdapter();
>>> objAdapter.setObject(PetrinetElementTypes.Transition_2002);
>>> CreateViewRequest.ViewDescriptor viewDescriptor = new
>>> CreateViewRequest.ViewDescriptor(
>>> objAdapter, Node.class,
>>> null,
>>> PetrinetDiagramEditorPlugin.DIAGRAM_PREFERENCES_HINT);
>>> CreateViewRequest cvRequest = new CreateViewRequest((viewDescriptor));
>>> Command cmd = selectedElement.getParent().getCommand(cvRequest);
>>> IDiagramEditDomain dEditingDomain =
>>> selectedElement.getDiagramEditDomain();
>>> dEditingDomain.getDiagramCommandStack().execute(cmd);
>>> ...
>>>
>>> Is there a way to replace the selectedElement's view with the new one?
>>>
>>> best regards
>>> Jan
>>
|
|
|
| Re: How to replace the view of an existing element [message #64679 is a reply to message #64588] |
Tue, 17 October 2006 16:16 |
| Eclipse User |
|
|
|
Originally posted by: jan.herriger.gmx.de
Thanks again Vlad,
keep on helping like that. Thats great.
For interested parties:
I'm creating a petrinet editor to become familiar with GMF. Transition
nodes (simple rectange figures) should be able to be switched between
vertical orientation and horizontal oriantation.
I added the following code to 'TransitionEditPart.java':
protected void handleNotificationEvent(Notification notification) {
Transition t = (Transition) this.resolveSemanticElement();
Object feature = notification.getFeature();
if (PetrinetPackage.eINSTANCE.getTransition_Vertical().equals(feature))
{
refreshBounds();
}
else
super.handleNotificationEvent(notification);
}
protected void refreshBounds() {
Dimension size = getPrimaryShapeDimension();
int x = ((Integer)
getStructuralFeatureValue(NotationPackage.eINSTANCE.getLocation_X())).intValue();
int y = ((Integer)
getStructuralFeatureValue(NotationPackage.eINSTANCE.getLocation_Y())).intValue();
Point loc = new Point(x, y);
((GraphicalEditPart) getParent()).setLayoutConstraint(
this,
getFigure(),
new Rectangle(loc, size));
}
protected Dimension getPrimaryShapeDimension() {
Transition t = (Transition) this.resolveSemanticElement();
if (t.isVertical())
return new Dimension(40, 10);
else
return new Dimension(10, 40);
}
Changing the 'vertical' EAttribute now results in switching between
vertical orientation and horizontal oriantation.
Vlad Ciubotariu schrieb:
> Ok, in that case look at the code in ShapeEditPart to see how it
> registers/listens to the notational model and refreshes when changes
> occur. Do the same for your semantic model.
>
> hope this helps
>
> vlad
>
>
> On Tue, 17 Oct 2006 20:12:49 +0200, Jan Herriger wrote:
>
>> Thanks Vlad,
>>
>> but I think, I was on the wrong approach...
>>
>> Basically I want to switch between two visual styles of one EditPart.
>> So, I think i will add a property to the semantic model, wich indicates
>> what style the EditPart should have and add a logic to the EditPart's
>> class accordingly. I don't know, if this is the right approach. But it
>> seems to work.
>>
>> Vlad Ciubotariu schrieb:
>>> Look in CreationEditPolicy and ComponentEditPolicy for commands to create
>>> views and delete, respectively.
>>>
>>> On Tue, 17 Oct 2006 13:27:30 +0200, Jan Herriger wrote:
>>>
>>>> Hello all,
>>>>
>>>> I'd like to have an ObjectActionDelegate which replaces the view of the
>>>> selected element.
>>>>
>>>> In the delegate, I use the following code to create a new view:
>>>>
>>>> ...
>>>> ObjectAdapter objAdapter = new ObjectAdapter();
>>>> objAdapter.setObject(PetrinetElementTypes.Transition_2002);
>>>> CreateViewRequest.ViewDescriptor viewDescriptor = new
>>>> CreateViewRequest.ViewDescriptor(
>>>> objAdapter, Node.class,
>>>> null,
>>>> PetrinetDiagramEditorPlugin.DIAGRAM_PREFERENCES_HINT);
>>>> CreateViewRequest cvRequest = new CreateViewRequest((viewDescriptor));
>>>> Command cmd = selectedElement.getParent().getCommand(cvRequest);
>>>> IDiagramEditDomain dEditingDomain =
>>>> selectedElement.getDiagramEditDomain();
>>>> dEditingDomain.getDiagramCommandStack().execute(cmd);
>>>> ...
>>>>
>>>> Is there a way to replace the selectedElement's view with the new one?
>>>>
>>>> best regards
>>>> Jan
>
|
|
| |
| Re: How to replace the view of an existing element [message #64796 is a reply to message #64702] |
Wed, 18 October 2006 04:38 |
| Eclipse User |
|
|
|
Hi Jan,
Another possibility could be to register two different mappings and
differentiate between them using MappingEntry.domainSpecialization
constraint. An example of this approach can be found in the MindMap project
used in tutorial (three different link mappings are used for the domain
element Relationship).
The advantages of having two distinct elements are the following:
1. You may associate completely unrelated figures with these two elements
(this may not bee needed in your scenario, although you might use figures
with fixed sizes 10x40 and 40x10, respectively);
2. You might associate different creation tools with these elements (but
still have one creation tool if you don't need two);
3. You might associate element initializers with these elements, so as to
initialize your orientation based on the element you are creating.
4. This approach can be easily adapted to the situation when the visual
aspects of an element depend on multiple features, all you need is to modify
the OCL expression in the *.gmfmap.
Disadvantages are:
1. You have more code generated. This may be a problem as the number of
@generated NOT's increases;
2. If the visual aspects depend solely on a single attribute of the semantic
element, OCL may seem an overkill;
3. There is a known problem in the generated diagram editor that a
XXXCanonicalEditPpolicy might fail to always update the ElementType on a
change in the domain model that affects the element type. (this problem is
not present in the lite runtime, where ANY such change is guaranteed to be
processed correctly).
Best regards,
Boris
"Jan Herriger" <jan.herriger@gmx.de> wrote in message
news:eh3eng$7q1$1@utils.eclipse.org...
> forget about the first line of handleNotificationEvent method...
>
> Jan Herriger schrieb:
>> Thanks again Vlad,
>>
>> keep on helping like that. Thats great.
>>
>> For interested parties:
>>
>> I'm creating a petrinet editor to become familiar with GMF. Transition
>> nodes (simple rectange figures) should be able to be switched between
>> vertical orientation and horizontal oriantation.
>>
>> I added the following code to 'TransitionEditPart.java':
>>
>>
>> protected void handleNotificationEvent(Notification notification) {
>> Transition t = (Transition) this.resolveSemanticElement();
>> Object feature = notification.getFeature();
>> if
>> (PetrinetPackage.eINSTANCE.getTransition_Vertical().equals(feature))
>> {
>> refreshBounds();
>> }
>> else
>> super.handleNotificationEvent(notification);
>> }
>> protected void refreshBounds() {
>>
>> Dimension size = getPrimaryShapeDimension();
>> int x = ((Integer)
>> getStructuralFeatureValue(NotationPackage.eINSTANCE.getLocation_X())).intValue();
>> int y = ((Integer)
>> getStructuralFeatureValue(NotationPackage.eINSTANCE.getLocation_Y())).intValue();
>> Point loc = new Point(x, y);
>> ((GraphicalEditPart) getParent()).setLayoutConstraint(
>> this,
>> getFigure(),
>> new Rectangle(loc, size));
>> }
>>
>> protected Dimension getPrimaryShapeDimension() {
>> Transition t = (Transition) this.resolveSemanticElement();
>> if (t.isVertical())
>> return new Dimension(40, 10);
>> else
>> return new Dimension(10, 40);
>> }
>>
>>
>> Changing the 'vertical' EAttribute now results in switching between
>> vertical orientation and horizontal oriantation.
|
|
|
| Re: How to replace the view of an existing element [message #65210 is a reply to message #64796] |
Wed, 18 October 2006 09:39 |
| Eclipse User |
|
|
|
Originally posted by: jan.herriger.gmx.de
Hi Boris,
having two different mappings was my very first approach. It seems to be
the most logic way, having two independent visual elements, which can be
associated to an element. But I just can't see how to change the visual
component of an existing element (in a way different to how I mentioned
before). Maybe I'm just a blockhead right now ;-)
Best regards
Jan
Boris Blajer schrieb:
> Hi Jan,
>
> Another possibility could be to register two different mappings and
> differentiate between them using MappingEntry.domainSpecialization
> constraint. An example of this approach can be found in the MindMap project
> used in tutorial (three different link mappings are used for the domain
> element Relationship).
>
> The advantages of having two distinct elements are the following:
> 1. You may associate completely unrelated figures with these two elements
> (this may not bee needed in your scenario, although you might use figures
> with fixed sizes 10x40 and 40x10, respectively);
> 2. You might associate different creation tools with these elements (but
> still have one creation tool if you don't need two);
> 3. You might associate element initializers with these elements, so as to
> initialize your orientation based on the element you are creating.
> 4. This approach can be easily adapted to the situation when the visual
> aspects of an element depend on multiple features, all you need is to modify
> the OCL expression in the *.gmfmap.
>
> Disadvantages are:
> 1. You have more code generated. This may be a problem as the number of
> @generated NOT's increases;
> 2. If the visual aspects depend solely on a single attribute of the semantic
> element, OCL may seem an overkill;
> 3. There is a known problem in the generated diagram editor that a
> XXXCanonicalEditPpolicy might fail to always update the ElementType on a
> change in the domain model that affects the element type. (this problem is
> not present in the lite runtime, where ANY such change is guaranteed to be
> processed correctly).
>
> Best regards,
> Boris
>
>
> "Jan Herriger" <jan.herriger@gmx.de> wrote in message
> news:eh3eng$7q1$1@utils.eclipse.org...
>> forget about the first line of handleNotificationEvent method...
>>
>> Jan Herriger schrieb:
>>> Thanks again Vlad,
>>>
>>> keep on helping like that. Thats great.
>>>
>>> For interested parties:
>>>
>>> I'm creating a petrinet editor to become familiar with GMF. Transition
>>> nodes (simple rectange figures) should be able to be switched between
>>> vertical orientation and horizontal oriantation.
>>>
>>> I added the following code to 'TransitionEditPart.java':
>>>
>>>
>>> protected void handleNotificationEvent(Notification notification) {
>>> Transition t = (Transition) this.resolveSemanticElement();
>>> Object feature = notification.getFeature();
>>> if
>>> (PetrinetPackage.eINSTANCE.getTransition_Vertical().equals(feature))
>>> {
>>> refreshBounds();
>>> }
>>> else
>>> super.handleNotificationEvent(notification);
>>> }
>>> protected void refreshBounds() {
>>>
>>> Dimension size = getPrimaryShapeDimension();
>>> int x = ((Integer)
>>> getStructuralFeatureValue(NotationPackage.eINSTANCE.getLocation_X())).intValue();
>>> int y = ((Integer)
>>> getStructuralFeatureValue(NotationPackage.eINSTANCE.getLocation_Y())).intValue();
>>> Point loc = new Point(x, y);
>>> ((GraphicalEditPart) getParent()).setLayoutConstraint(
>>> this,
>>> getFigure(),
>>> new Rectangle(loc, size));
>>> }
>>>
>>> protected Dimension getPrimaryShapeDimension() {
>>> Transition t = (Transition) this.resolveSemanticElement();
>>> if (t.isVertical())
>>> return new Dimension(40, 10);
>>> else
>>> return new Dimension(10, 40);
>>> }
>>>
>>>
>>> Changing the 'vertical' EAttribute now results in switching between
>>> vertical orientation and horizontal oriantation.
>
>
|
|
|
| Re: How to replace the view of an existing element [message #65356 is a reply to message #65210] |
Wed, 18 October 2006 10:28 |
| Eclipse User |
|
|
|
Hi Jan,
In fact, this should be automatic (provided that the node is canonical). The
fact that it does not update is due to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=150257.
Best regards,
Boris
"Jan Herriger" <jan.herriger@gmx.de> wrote in message
news:eh5aqo$3er$1@utils.eclipse.org...
> Hi Boris,
>
> having two different mappings was my very first approach. It seems to be
> the most logic way, having two independent visual elements, which can be
> associated to an element. But I just can't see how to change the visual
> component of an existing element (in a way different to how I mentioned
> before). Maybe I'm just a blockhead right now ;-)
>
> Best regards
> Jan
>
> Boris Blajer schrieb:
>> Hi Jan,
>>
>> Another possibility could be to register two different mappings and
>> differentiate between them using MappingEntry.domainSpecialization
>> constraint. An example of this approach can be found in the MindMap
>> project used in tutorial (three different link mappings are used for the
>> domain element Relationship).
>>
>> The advantages of having two distinct elements are the following:
>> 1. You may associate completely unrelated figures with these two elements
>> (this may not bee needed in your scenario, although you might use figures
>> with fixed sizes 10x40 and 40x10, respectively);
>> 2. You might associate different creation tools with these elements (but
>> still have one creation tool if you don't need two);
>> 3. You might associate element initializers with these elements, so as to
>> initialize your orientation based on the element you are creating.
>> 4. This approach can be easily adapted to the situation when the visual
>> aspects of an element depend on multiple features, all you need is to
>> modify the OCL expression in the *.gmfmap.
>>
>> Disadvantages are:
>> 1. You have more code generated. This may be a problem as the number of
>> @generated NOT's increases;
>> 2. If the visual aspects depend solely on a single attribute of the
>> semantic element, OCL may seem an overkill;
>> 3. There is a known problem in the generated diagram editor that a
>> XXXCanonicalEditPpolicy might fail to always update the ElementType on a
>> change in the domain model that affects the element type. (this problem
>> is not present in the lite runtime, where ANY such change is guaranteed
>> to be processed correctly).
>>
>> Best regards,
>> Boris
>>
>>
>> "Jan Herriger" <jan.herriger@gmx.de> wrote in message
>> news:eh3eng$7q1$1@utils.eclipse.org...
>>> forget about the first line of handleNotificationEvent method...
>>>
>>> Jan Herriger schrieb:
>>>> Thanks again Vlad,
>>>>
>>>> keep on helping like that. Thats great.
>>>>
>>>> For interested parties:
>>>>
>>>> I'm creating a petrinet editor to become familiar with GMF. Transition
>>>> nodes (simple rectange figures) should be able to be switched between
>>>> vertical orientation and horizontal oriantation.
>>>>
>>>> I added the following code to 'TransitionEditPart.java':
>>>>
>>>>
>>>> protected void handleNotificationEvent(Notification notification) {
>>>> Transition t = (Transition) this.resolveSemanticElement();
>>>> Object feature = notification.getFeature();
>>>> if
>>>> (PetrinetPackage.eINSTANCE.getTransition_Vertical().equals(feature))
>>>> {
>>>> refreshBounds();
>>>> }
>>>> else
>>>> super.handleNotificationEvent(notification);
>>>> }
>>>> protected void refreshBounds() {
>>>>
>>>> Dimension size = getPrimaryShapeDimension();
>>>> int x = ((Integer)
>>>> getStructuralFeatureValue(NotationPackage.eINSTANCE.getLocation_X())).intValue();
>>>> int y = ((Integer)
>>>> getStructuralFeatureValue(NotationPackage.eINSTANCE.getLocation_Y())).intValue();
>>>> Point loc = new Point(x, y);
>>>> ((GraphicalEditPart) getParent()).setLayoutConstraint(
>>>> this,
>>>> getFigure(),
>>>> new Rectangle(loc, size));
>>>> }
>>>>
>>>> protected Dimension getPrimaryShapeDimension() {
>>>> Transition t = (Transition) this.resolveSemanticElement();
>>>> if (t.isVertical())
>>>> return new Dimension(40, 10);
>>>> else
>>>> return new Dimension(10, 40);
>>>> }
>>>>
>>>>
>>>> Changing the 'vertical' EAttribute now results in switching between
>>>> vertical orientation and horizontal oriantation.
>>
|
|
|
Goto Forum:
Current Time: Mon Apr 28 00:38:46 EDT 2025
Powered by FUDForum. Page generated in 0.03385 seconds |
Home