[news.eclipse.modeling.gmf] Re: Multiple editpart objects with numbers i

["Artem Tikhomirov" <artem.tikhomirov@xxxxxxxxxxx>]

> If there is general interest in this, and a chance to get this into
> the official GMF, I'm tempted to try.

I doubt GMF could accomodate to each and every requirement, so I won't 
strive to handle e.g. extends/implements clauses for particular edit parts 
in .gmfgen. To me, it's reasonable compromise for toolsmith to use his own 
set of templates, rather than keeping overwhelmingly complex (though 
flexible) genmodel.

Having said that, still, contributions are more than welcome :). 
Establishing discussion as a bugzilla report might be the best way to find 
out whether some improvement is generic enough to get into common codebase.

Artem

"Hallvard Tr?tteberg" <hal@xxxxxxxxxxx> wrote in message 
news:ibbbg2pmch4e8j2rc0log2ois4p8eihkih@xxxxxxxxxx
> On Sun, 10 Sep 2006 14:58:07 +0200, "Michael Golubev"
> <michael.golubev@xxxxxxxxxxx> wrote:
>
>>Hi,
>>
>>Consider the using of the changed templates.
>>Dynamic templates allows you to use, say, custom version of
>>NodeEditPart.javajet (with changed extends clause) but default versions 
>>for
>>other templates.
>>This way, you will need to merge only single template file with ongoing 
>>gmf
>>changes. Also it is very probable that in future, GMF will provide
>>significant amount of "template extension points" using conditional
>>includes. Please feel free to submit one for this particular conditional
>>include statement that specifies extend clause for edit parts.
>
> I've thought about replacing the template file.  I believe I would
> need to extend the generator model with another attribute for holding
> the name of the superclass, and use this in the template. I would also
> need to change the generator to also generate the superclass. There
> may also need to be some logic for deciding what to generate into the
> superclass, e.g. figure definition, and what to generate into the
> subclasses, e.g. policy creation.
>
> If there is general interest in this, and a chance to get this into
> the official GMF, I'm tempted to try.
>
> Hallvard
>
>>
>>Regards,
>>Michael
>>
>>"Hallvard Tr?tteberg" <hal@xxxxxxxxxxx> wrote in message
>>news:88s7g2puct9lhdnkoujeroi0f18shi6lci@xxxxxxxxxx
>>> On Fri, 08 Sep 2006 08:57:19 -0400, Jeffrey Ricker
>>> <ricker@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>>>It is not that I want to generate less classes; I want to have good
>>>>object-oriented code. And I want to make sure I am using GMF as it was
>>>>intended.
>>>>
>>>>If I have 12 objects named FooEditPart, Foo2EditPart, etc., it is
>>>>conceivable that I would want some uniform behavior from those objects.
>>>>I want to make a change one place, not 12. My approach is to have an
>>>>abstract class named FooEditPartBase and have the 12 inherit from that
>>>>class.
>>>>
>>>>Unless someone corrects me, I will assume that that is good GMF 
>>>>practice.
>>>
>>> I ended up using this approach. Unfortunately, I have to change the
>>> extends clause of each of the classes to refer to the common
>>> superclass, whenever I regenerate. Since I guess this is a common
>>> thing to do, It would be great to be able to specify the generation of
>>> this (empty) class. Perhaps a feature request: Specify the name of a
>>> class for common code for the EditParts generated for the same
>>> concept, when used in different parts of the hierarchy. The logical
>>> place to have this informaiton is in gmfgen and it must survive
>>> regeneration (of gmfgen from gmfmap).
>>>
>>> Hallvard
>>
>