Home » Modeling » GMF (Graphical Modeling Framework) » top-level vs. inner edit parts
| top-level vs. inner edit parts [message #37782] |
Mon, 04 September 2006 04:24  |
Eclipse User |
|
|
|
Hi,
I'm working on an editor for a hierarchical diagram, similar to a
process diagram. In the mapping model, I've declared the top-level
node references and mappings and the child node references refer to
the top-level ones. I think the model is correct, since the editor
logic seems to work well. I'm really impressed with what the generator
gives for free, once the models are worked out. It's a lot more fun
modelling than programming.
I do, however, need som custom code for both shapes and edit parts,
and this leads to some problems. Since there are essentially two
definitions of most nodes types, both as top-level objects and as
children, most node types result in two edit part classes, e.g.
ComputationEditPart and Computation2EditPart. Whenever I introduce
custom code, I have to insert it into two classes. In addition,
provider kind of classes, like ModelingAssistantProvider, refer to
these and become fairly complex although the model isn't that complex.
What I would like is to express some place that there is no need for
two versions of the same concept, e.g. ComputationEditPart ==
Computation2EditPart for all practical purposes. My current strategy
is to edit Computation2EditPart so that it extends ComputationEditPart
and adds little extra logic, but I'm not sure if this results in other
problems. This does not solve the problem with the generated
ModelingAssistantProvider, which refers to both ComputationEditPart
and Computation2EditPart.
Comments? Suggestions?
Hallvard
|
|
|
| Re: top-level vs. inner edit parts [message #38098 is a reply to message #37782] |
Mon, 04 September 2006 07:01  |
| Eclipse User |
|
|
|
> I do, however, need som custom code for both shapes and edit parts,
You can avoid code duplication for shapes if you generate them into
standalone plug-in (i.e. not placing them as inner classes of EditPart, as
it happens by default).
For EditParts, you could try to have your own subclass between generated
code and runtime code, so you'll need to update only 'extends' clause for
both ComputationEditPart and Computation2EditPart
Artem
"Hallvard Tr?tteberg" <hal@idi.ntnu.no> wrote in message
news:6llnf29sf90vfd5p8kf1gd2s3g985eoc1o@4ax.com...
> Hi,
>
> I'm working on an editor for a hierarchical diagram, similar to a
> process diagram. In the mapping model, I've declared the top-level
> node references and mappings and the child node references refer to
> the top-level ones. I think the model is correct, since the editor
> logic seems to work well. I'm really impressed with what the generator
> gives for free, once the models are worked out. It's a lot more fun
> modelling than programming.
>
> I do, however, need som custom code for both shapes and edit parts,
> and this leads to some problems. Since there are essentially two
> definitions of most nodes types, both as top-level objects and as
> children, most node types result in two edit part classes, e.g.
> ComputationEditPart and Computation2EditPart. Whenever I introduce
> custom code, I have to insert it into two classes. In addition,
> provider kind of classes, like ModelingAssistantProvider, refer to
> these and become fairly complex although the model isn't that complex.
>
> What I would like is to express some place that there is no need for
> two versions of the same concept, e.g. ComputationEditPart ==
> Computation2EditPart for all practical purposes. My current strategy
> is to edit Computation2EditPart so that it extends ComputationEditPart
> and adds little extra logic, but I'm not sure if this results in other
> problems. This does not solve the problem with the generated
> ModelingAssistantProvider, which refers to both ComputationEditPart
> and Computation2EditPart.
>
> Comments? Suggestions?
>
> Hallvard
|
|
|
| Re: top-level vs. inner edit parts [message #38168 is a reply to message #38098] |
Mon, 04 September 2006 07:34 |
| Eclipse User |
|
|
|
On Mon, 4 Sep 2006 13:01:28 +0200, "Artem Tikhomirov"
<artem.tikhomirov@borland.com> wrote:
>> I do, however, need som custom code for both shapes and edit parts,
>
>You can avoid code duplication for shapes if you generate them into
>standalone plug-in (i.e. not placing them as inner classes of EditPart, as
>it happens by default).
>
>For EditParts, you could try to have your own subclass between generated
>code and runtime code, so you'll need to update only 'extends' clause for
>both ComputationEditPart and Computation2EditPart
>
>Artem
You're thinking of introducing an AbstractComputationEditPart and make
both ComputationEditPart and Computation2EditPart inherit from this
class. Good idea, at least it solves the problem of code sharing for
non-generated methods, like refreshing and anchor handling.
Still, the distinction between ComputationEditPart and
Computation2EditPart seems meaningless in my specific case (not in
general, I agree).
Hallvard
>
>"Hallvard Tr?tteberg" <hal@idi.ntnu.no> wrote in message
>news:6llnf29sf90vfd5p8kf1gd2s3g985eoc1o@4ax.com...
>> Hi,
>>
>> I'm working on an editor for a hierarchical diagram, similar to a
>> process diagram. In the mapping model, I've declared the top-level
>> node references and mappings and the child node references refer to
>> the top-level ones. I think the model is correct, since the editor
>> logic seems to work well. I'm really impressed with what the generator
>> gives for free, once the models are worked out. It's a lot more fun
>> modelling than programming.
>>
>> I do, however, need som custom code for both shapes and edit parts,
>> and this leads to some problems. Since there are essentially two
>> definitions of most nodes types, both as top-level objects and as
>> children, most node types result in two edit part classes, e.g.
>> ComputationEditPart and Computation2EditPart. Whenever I introduce
>> custom code, I have to insert it into two classes. In addition,
>> provider kind of classes, like ModelingAssistantProvider, refer to
>> these and become fairly complex although the model isn't that complex.
>>
>> What I would like is to express some place that there is no need for
>> two versions of the same concept, e.g. ComputationEditPart ==
>> Computation2EditPart for all practical purposes. My current strategy
>> is to edit Computation2EditPart so that it extends ComputationEditPart
>> and adds little extra logic, but I'm not sure if this results in other
>> problems. This does not solve the problem with the generated
>> ModelingAssistantProvider, which refers to both ComputationEditPart
>> and Computation2EditPart.
>>
>> Comments? Suggestions?
>>
>> Hallvard
>
|
|
|
Goto Forum:
Current Time: Thu May 29 01:55:07 EDT 2025
Powered by FUDForum. Page generated in 0.29980 seconds |
Home