Home » Modeling » GMF (Graphical Modeling Framework) » Multiple editpart objects with numbers in name
| Multiple editpart objects with numbers in name [message #42109] |
Thu, 07 September 2006 11:51  |
Eclipse User |
|
|
|
Originally posted by: jricker.progess.com
Why do I get multiple edit part objects with numbers in their names, as in
FooEditPart
Foo2EditPart
Foo3EditPart
Is there a place in the model to override this behavior?
|
|
| | | | | | |
| Re: Multiple editpart objects with numbers in name [message #43788 is a reply to message #42840] |
Sun, 10 September 2006 07:12  |
| Eclipse User |
|
|
|
On Fri, 08 Sep 2006 08:57:19 -0400, Jeffrey Ricker
<ricker@distributedinstruments.com> 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
|
|
|
| Re: Multiple editpart objects with numbers in name [message #43883 is a reply to message #43788] |
Sun, 10 September 2006 08:58 |
| Eclipse User |
|
|
|
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.
Regards,
Michael
"Hallvard Tr?tteberg" <hal@idi.ntnu.no> wrote in message
news:88s7g2puct9lhdnkoujeroi0f18shi6lci@4ax.com...
> On Fri, 08 Sep 2006 08:57:19 -0400, Jeffrey Ricker
> <ricker@distributedinstruments.com> 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
|
|
| | | |
| Re: Multiple editpart objects with numbers in name [message #45271 is a reply to message #43883] |
Mon, 11 September 2006 14:45 |
| Eclipse User |
|
|
|
On Sun, 10 Sep 2006 14:58:07 +0200, "Michael Golubev"
<michael.golubev@borland.com> 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@idi.ntnu.no> wrote in message
>news:88s7g2puct9lhdnkoujeroi0f18shi6lci@4ax.com...
>> On Fri, 08 Sep 2006 08:57:19 -0400, Jeffrey Ricker
>> <ricker@distributedinstruments.com> 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
>
|
|
|
| Re: Multiple editpart objects with numbers in name [message #45430 is a reply to message #43883] |
Mon, 11 September 2006 17:04 |
| Eclipse User |
|
|
|
On Sun, 10 Sep 2006 14:58:07 +0200, "Michael Golubev"
<michael.golubev@borland.com> 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.
I've now changed the NodeEditPart.javajet template so it generates the
desired "extends AbstractXXXEditPart" clause for XXXnnEditPart
classes. I introduced a helper method in the inner helper class, that
generated the name for the abstract class from the edit part's, i.e.
prefixed it with "Abstract" and removed the nn part. I also added a
different package prefix, to separate the abstract edit parts classes,
that must be made manually, and the generated edit part classes.
I'm satisified with the new NodeEditPart.javajet template, as it
solves my immediate problem, but to make it generally interesting, I
believe the gmfgen model must be augmented with additional attributes
for the abstract edit part name and perhaps logic for generating this
class, too.
Hallvard
>
>Regards,
>Michael
>
>"Hallvard Tr?tteberg" <hal@idi.ntnu.no> wrote in message
>news:88s7g2puct9lhdnkoujeroi0f18shi6lci@4ax.com...
>> On Fri, 08 Sep 2006 08:57:19 -0400, Jeffrey Ricker
>> <ricker@distributedinstruments.com> 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
>
|
|
| | |
| Re: Multiple editpart objects with numbers in name [message #46278 is a reply to message #45271] |
Tue, 12 September 2006 08:49 |
| Eclipse User |
|
|
|
> 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@idi.ntnu.no> wrote in message
news:ibbbg2pmch4e8j2rc0log2ois4p8eihkih@4ax.com...
> On Sun, 10 Sep 2006 14:58:07 +0200, "Michael Golubev"
> <michael.golubev@borland.com> 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@idi.ntnu.no> wrote in message
>>news:88s7g2puct9lhdnkoujeroi0f18shi6lci@4ax.com...
>>> On Fri, 08 Sep 2006 08:57:19 -0400, Jeffrey Ricker
>>> <ricker@distributedinstruments.com> 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
>>
>
|
|
|
Goto Forum:
Current Time: Tue Jul 22 02:01:06 EDT 2025
Powered by FUDForum. Page generated in 0.07343 seconds |
Home