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

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

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

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

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

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

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

I was trying to do the same thing and after fiddling with the OCL approach I came across the decorator service (see eclipse help and search for decorator service as this thing won't let me post the link cause I'm wet behind the ears per it's standard)

Works very nicely however I've run into a layering issue where the image doesn't behave as nicely as the one inside the node itself. By that I mean that it appears to be in the foreground in all cases (cutting links, etc) as opposed to blending.

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.