Home » Modeling » GMF (Graphical Modeling Framework) » Changing shape on property change
| Changing shape on property change [message #176791] |
Wed, 12 March 2008 10:53  |
Eclipse User |
|
|
|
Originally posted by: nico.lammers.gmail.com
I've searched a bit on the newsgroups, but I couldn't really find an
answer to this:
I have a property that describes the 'type' of the shape. Depending on
the value of the property (set in the propertysheet OR programmatically)
the shape's background color should change.
I want to avoid adding things to generated code as much as possible.. I
feel I can do this with an EditPolicy extension, but I'm not sure.
Regards,
Nico Lammers
|
|
| |
| Re: Changing shape on property change [message #177156 is a reply to message #176899] |
Thu, 13 March 2008 15:25  |
| Eclipse User |
|
|
|
Originally posted by: nico.lammers.gmail.com
Hmm, I'm not sure what you mean..
Basically I have a shape.. that shape has a property, which is an
enumeration.
i.e. if the enumeration was OwnerNames, the shape should be blue when
'John' is selected, but red when 'Peter' is selected.
I managed to do something with handleNotificationEvent in a custom
CanonicalEditPolicy though, now to set it at creation time :-)
Boris Blajer wrote:
> Hi Nico,
>
> If the type<-->color mapping is static (and the types are predefined),
> you may define a separate NodeMapping for each value of type. This may
> be a bit cumbersome if there are many types, but you won't have to add a
> single line of code manually :).
>
> Best regards,
> Boris
>
> Nico Lammers wrote:
>> I've searched a bit on the newsgroups, but I couldn't really find an
>> answer to this:
>>
>> I have a property that describes the 'type' of the shape. Depending on
>> the value of the property (set in the propertysheet OR
>> programmatically) the shape's background color should change.
>>
>> I want to avoid adding things to generated code as much as possible..
>> I feel I can do this with an EditPolicy extension, but I'm not sure.
>>
>> Regards,
>> Nico Lammers
|
|
|
| Re: Changing shape on property change [message #177164 is a reply to message #177156] |
Thu, 13 March 2008 16:30 |
 Boris Blajer
Messages: 217
Registered: July 2009 |
Senior Member |
|
|
Hi Nico,
My suggestion was to create distinct NodeMappings for each of the values
in the enumeration, each with a feature sequence initializer and a
constraint. Something similar has been implemented for link mappings
representing relationships of different kinds in the mindmap sample. In
your example, there would be two (more if there's more people in the
enum) shapes with different colors declared in the gmfgraph, two
NodeMappings in the gmfmap (each will reference the same underlying
model element, define a FSInitializer, a specialization constraint and
they will reference the shapes from the gmfgraph model with their
respective color).
The main advantage of this approach is that you only modify gmf models,
not the generated code; the gmf model persists the knowledge about the
colors that represent each of the enumerated value.
The main disadvantage is that you end up with several edit part classes
which are almost identical (but after all, probably once they are
separated, they may start getting different behavior other than just
color?) The performance may slightly be affected, too: using ocl engine
to read the value of a single attribute seems suboptimal in terms of
performance.
Best regards,
Boris
Nico Lammers wrote:
>
> Hmm, I'm not sure what you mean..
>
> Basically I have a shape.. that shape has a property, which is an
> enumeration.
>
> i.e. if the enumeration was OwnerNames, the shape should be blue when
> 'John' is selected, but red when 'Peter' is selected.
>
> I managed to do something with handleNotificationEvent in a custom
> CanonicalEditPolicy though, now to set it at creation time :-)
>
>
> Boris Blajer wrote:
>> Hi Nico,
>>
>> If the type<-->color mapping is static (and the types are predefined),
>> you may define a separate NodeMapping for each value of type. This may
>> be a bit cumbersome if there are many types, but you won't have to add
>> a single line of code manually :).
>>
>> Best regards,
>> Boris
>>
>> Nico Lammers wrote:
>>> I've searched a bit on the newsgroups, but I couldn't really find an
>>> answer to this:
>>>
>>> I have a property that describes the 'type' of the shape. Depending
>>> on the value of the property (set in the propertysheet OR
>>> programmatically) the shape's background color should change.
>>>
>>> I want to avoid adding things to generated code as much as possible..
>>> I feel I can do this with an EditPolicy extension, but I'm not sure.
>>>
>>> Regards,
>>> Nico Lammers
|
|
|
| Re: Changing shape on property change [message #177186 is a reply to message #177156] |
Thu, 13 March 2008 16:38 |
Kristian O'Connor
Messages: 29
Registered: July 2009 |
Junior Member |
|
|
For creation time
use the XXXEditHelper...
protected ICommand getConfigureCommand(ConfigureRequest req)
{
return new ConfigureXXXCommand(req);
}
;o) I think.
Obviously XXX is the name of your class and ConfigureXXXCommand needs to
extend
org.eclipse.gmf.runtime.emf.type.core.commands.ConfigureElem entCommand
Hope that helps.
Laters
Kristian.
"Nico Lammers" <nico.lammers@gmail.com> wrote in message
news:frbh0s$nu2$1@build.eclipse.org...
>
> Hmm, I'm not sure what you mean..
>
> Basically I have a shape.. that shape has a property, which is an
> enumeration.
>
> i.e. if the enumeration was OwnerNames, the shape should be blue when
> 'John' is selected, but red when 'Peter' is selected.
>
> I managed to do something with handleNotificationEvent in a custom
> CanonicalEditPolicy though, now to set it at creation time :-)
>
>
> Boris Blajer wrote:
>> Hi Nico,
>>
>> If the type<-->color mapping is static (and the types are predefined),
>> you may define a separate NodeMapping for each value of type. This may be
>> a bit cumbersome if there are many types, but you won't have to add a
>> single line of code manually :).
>>
>> Best regards,
>> Boris
>>
>> Nico Lammers wrote:
>>> I've searched a bit on the newsgroups, but I couldn't really find an
>>> answer to this:
>>>
>>> I have a property that describes the 'type' of the shape. Depending on
>>> the value of the property (set in the propertysheet OR programmatically)
>>> the shape's background color should change.
>>>
>>> I want to avoid adding things to generated code as much as possible.. I
>>> feel I can do this with an EditPolicy extension, but I'm not sure.
>>>
>>> Regards,
>>> Nico Lammers
|
|
|
| Re: Changing shape on property change [message #177309 is a reply to message #177164] |
Fri, 14 March 2008 10:43 |
| Eclipse User |
|
|
|
Originally posted by: nico.lammers.gmail.com
Okay, this appears to work, but there's one problem with it; when I
change the 'ownerName' property in the PropertySheet, the other color
will only be shown after I refresh the diagram.. that's not really what
I want.. :| Do you have any thoughts on this?
Boris Blajer wrote:
> Hi Nico,
>
> My suggestion was to create distinct NodeMappings for each of the values
> in the enumeration, each with a feature sequence initializer and a
> constraint. Something similar has been implemented for link mappings
> representing relationships of different kinds in the mindmap sample. In
> your example, there would be two (more if there's more people in the
> enum) shapes with different colors declared in the gmfgraph, two
> NodeMappings in the gmfmap (each will reference the same underlying
> model element, define a FSInitializer, a specialization constraint and
> they will reference the shapes from the gmfgraph model with their
> respective color).
>
> The main advantage of this approach is that you only modify gmf models,
> not the generated code; the gmf model persists the knowledge about the
> colors that represent each of the enumerated value.
> The main disadvantage is that you end up with several edit part classes
> which are almost identical (but after all, probably once they are
> separated, they may start getting different behavior other than just
> color?) The performance may slightly be affected, too: using ocl engine
> to read the value of a single attribute seems suboptimal in terms of
> performance.
>
> Best regards,
> Boris
>
> Nico Lammers wrote:
>>
>> Hmm, I'm not sure what you mean..
>>
>> Basically I have a shape.. that shape has a property, which is an
>> enumeration.
>>
>> i.e. if the enumeration was OwnerNames, the shape should be blue when
>> 'John' is selected, but red when 'Peter' is selected.
>>
>> I managed to do something with handleNotificationEvent in a custom
>> CanonicalEditPolicy though, now to set it at creation time :-)
>>
>>
>> Boris Blajer wrote:
>>> Hi Nico,
>>>
>>> If the type<-->color mapping is static (and the types are
>>> predefined), you may define a separate NodeMapping for each value of
>>> type. This may be a bit cumbersome if there are many types, but you
>>> won't have to add a single line of code manually :).
>>>
>>> Best regards,
>>> Boris
>>>
>>> Nico Lammers wrote:
>>>> I've searched a bit on the newsgroups, but I couldn't really find an
>>>> answer to this:
>>>>
>>>> I have a property that describes the 'type' of the shape. Depending
>>>> on the value of the property (set in the propertysheet OR
>>>> programmatically) the shape's background color should change.
>>>>
>>>> I want to avoid adding things to generated code as much as
>>>> possible.. I feel I can do this with an EditPolicy extension, but
>>>> I'm not sure.
>>>>
>>>> Regards,
>>>> Nico Lammers
|
|
|
| Re: Changing shape on property change [message #177415 is a reply to message #177309] |
Fri, 14 March 2008 16:16 |
Boris Blajer
Messages: 217
Registered: July 2009 |
Senior Member |
|
|
Hi Nico,
This seems like a bug. I believe it used to be handled correctly some
time ago. I'm sorry my suggestion was misleading.
Best regards,
Boris
Nico Lammers wrote:
> Okay, this appears to work, but there's one problem with it; when I
> change the 'ownerName' property in the PropertySheet, the other color
> will only be shown after I refresh the diagram.. that's not really what
> I want.. :| Do you have any thoughts on this?
>
> Boris Blajer wrote:
>> Hi Nico,
>>
>> My suggestion was to create distinct NodeMappings for each of the
>> values in the enumeration, each with a feature sequence initializer
>> and a constraint. Something similar has been implemented for link
>> mappings representing relationships of different kinds in the mindmap
>> sample. In your example, there would be two (more if there's more
>> people in the enum) shapes with different colors declared in the
>> gmfgraph, two NodeMappings in the gmfmap (each will reference the same
>> underlying model element, define a FSInitializer, a specialization
>> constraint and they will reference the shapes from the gmfgraph model
>> with their respective color).
>>
>> The main advantage of this approach is that you only modify gmf
>> models, not the generated code; the gmf model persists the knowledge
>> about the colors that represent each of the enumerated value.
>> The main disadvantage is that you end up with several edit part
>> classes which are almost identical (but after all, probably once they
>> are separated, they may start getting different behavior other than
>> just color?) The performance may slightly be affected, too: using ocl
>> engine to read the value of a single attribute seems suboptimal in
>> terms of performance.
>>
>> Best regards,
>> Boris
>>
>> Nico Lammers wrote:
>>>
>>> Hmm, I'm not sure what you mean..
>>>
>>> Basically I have a shape.. that shape has a property, which is an
>>> enumeration.
>>>
>>> i.e. if the enumeration was OwnerNames, the shape should be blue when
>>> 'John' is selected, but red when 'Peter' is selected.
>>>
>>> I managed to do something with handleNotificationEvent in a custom
>>> CanonicalEditPolicy though, now to set it at creation time :-)
>>>
>>>
>>> Boris Blajer wrote:
>>>> Hi Nico,
>>>>
>>>> If the type<-->color mapping is static (and the types are
>>>> predefined), you may define a separate NodeMapping for each value of
>>>> type. This may be a bit cumbersome if there are many types, but you
>>>> won't have to add a single line of code manually :).
>>>>
>>>> Best regards,
>>>> Boris
>>>>
>>>> Nico Lammers wrote:
>>>>> I've searched a bit on the newsgroups, but I couldn't really find
>>>>> an answer to this:
>>>>>
>>>>> I have a property that describes the 'type' of the shape. Depending
>>>>> on the value of the property (set in the propertysheet OR
>>>>> programmatically) the shape's background color should change.
>>>>>
>>>>> I want to avoid adding things to generated code as much as
>>>>> possible.. I feel I can do this with an EditPolicy extension, but
>>>>> I'm not sure.
>>>>>
>>>>> Regards,
>>>>> Nico Lammers
|
|
|
| Re: Changing shape on property change [message #177603 is a reply to message #177415] |
Mon, 17 March 2008 10:45 |
| Eclipse User |
|
|
|
Originally posted by: nico.lammers.gmail.com
Don't worry about it :)
I seem to have find a runtime solution using the editpartProvider.
I can use this to extend my existing EditPart and make the needed
changes by doing some constructor magic and overriding the
handleNotificationEvent method.
Thanks for the help :)
Boris Blajer wrote:
> Hi Nico,
>
> This seems like a bug. I believe it used to be handled correctly some
> time ago. I'm sorry my suggestion was misleading.
>
> Best regards,
> Boris
>
>
> Nico Lammers wrote:
>> Okay, this appears to work, but there's one problem with it; when I
>> change the 'ownerName' property in the PropertySheet, the other color
>> will only be shown after I refresh the diagram.. that's not really
>> what I want.. :| Do you have any thoughts on this?
>>
>> Boris Blajer wrote:
>>> Hi Nico,
>>>
>>> My suggestion was to create distinct NodeMappings for each of the
>>> values in the enumeration, each with a feature sequence initializer
>>> and a constraint. Something similar has been implemented for link
>>> mappings representing relationships of different kinds in the mindmap
>>> sample. In your example, there would be two (more if there's more
>>> people in the enum) shapes with different colors declared in the
>>> gmfgraph, two NodeMappings in the gmfmap (each will reference the
>>> same underlying model element, define a FSInitializer, a
>>> specialization constraint and they will reference the shapes from the
>>> gmfgraph model with their respective color).
>>>
>>> The main advantage of this approach is that you only modify gmf
>>> models, not the generated code; the gmf model persists the knowledge
>>> about the colors that represent each of the enumerated value.
>>> The main disadvantage is that you end up with several edit part
>>> classes which are almost identical (but after all, probably once they
>>> are separated, they may start getting different behavior other than
>>> just color?) The performance may slightly be affected, too: using ocl
>>> engine to read the value of a single attribute seems suboptimal in
>>> terms of performance.
>>>
>>> Best regards,
>>> Boris
>>>
>>> Nico Lammers wrote:
>>>>
>>>> Hmm, I'm not sure what you mean..
>>>>
>>>> Basically I have a shape.. that shape has a property, which is an
>>>> enumeration.
>>>>
>>>> i.e. if the enumeration was OwnerNames, the shape should be blue
>>>> when 'John' is selected, but red when 'Peter' is selected.
>>>>
>>>> I managed to do something with handleNotificationEvent in a custom
>>>> CanonicalEditPolicy though, now to set it at creation time :-)
>>>>
>>>>
>>>> Boris Blajer wrote:
>>>>> Hi Nico,
>>>>>
>>>>> If the type<-->color mapping is static (and the types are
>>>>> predefined), you may define a separate NodeMapping for each value
>>>>> of type. This may be a bit cumbersome if there are many types, but
>>>>> you won't have to add a single line of code manually :).
>>>>>
>>>>> Best regards,
>>>>> Boris
>>>>>
>>>>> Nico Lammers wrote:
>>>>>> I've searched a bit on the newsgroups, but I couldn't really find
>>>>>> an answer to this:
>>>>>>
>>>>>> I have a property that describes the 'type' of the shape.
>>>>>> Depending on the value of the property (set in the propertysheet
>>>>>> OR programmatically) the shape's background color should change.
>>>>>>
>>>>>> I want to avoid adding things to generated code as much as
>>>>>> possible.. I feel I can do this with an EditPolicy extension, but
>>>>>> I'm not sure.
>>>>>>
>>>>>> Regards,
>>>>>> Nico Lammers
|
|
| | | |
| Re: Changing shape on property change [message #940869 is a reply to message #177164] |
Fri, 12 October 2012 02:48 |
Iqbal Hossain
Messages: 101
Registered: May 2011
Location: Bangladesh |
Senior Member |
|
|
Boris Blajer.... can u provide some screen shoot? what to white in constraint and feature seq initializer???
Hi Nico,
My suggestion was to create distinct NodeMappings for each of the values
in the enumeration, each with a feature sequence initializer and a
constraint. Something similar has been implemented for link mappings
representing relationships of different kinds in the mindmap sample. In
your example, there would be two (more if there's more people in the
enum) shapes with different colors declared in the gmfgraph, two
NodeMappings in the gmfmap (each will reference the same underlying
model element, define a FSInitializer, a specialization constraint and
they will reference the shapes from the gmfgraph model with their
respective color).
The main advantage of this approach is that you only modify gmf models,
not the generated code; the gmf model persists the knowledge about the
colors that represent each of the enumerated value.
The main disadvantage is that you end up with several edit part classes
which are almost identical (but after all, probably once they are
separated, they may start getting different behavior other than just
color?) The performance may slightly be affected, too: using ocl engine
to read the value of a single attribute seems suboptimal in terms of
performance.
Best regards,
Boris
[Updated on: Fri, 12 October 2012 02:50] Report message to a moderator |
|
|
Goto Forum:
Current Time: Fri Jan 17 18:41:57 GMT 2025
Powered by FUDForum. Page generated in 0.04772 seconds |
] 
Search
Help
Register
Login
Home
