Home » Modeling » Graphiti » Graphiti and Dependency Injection
| Graphiti and Dependency Injection [message #929211] |
Mon, 01 October 2012 05:48  |
Eclipse User |
|
|
|
Dear all,
Graphiti uses Factory methods to instantiate its infrastructure. When overriding some behavior, that results in the necessity to re-implement some of the classes to override the factory methods.
Are there any thoughts on using dependency injection with Graphiti? To support standalone-tests, I have started to "branch" Graphiti and use Guice e.g. to instantiate the ExtensionManager.
But I would like to know if there are other efforts in that field, so as to avoid duplicate work.
Best Regards,
Andreas
|
|
|
| Re: Graphiti and Dependency Injection [message #929647 is a reply to message #929211] |
Mon, 01 October 2012 12:28  |
| Eclipse User |
|
|
|
On 01.10.12 02.48, Andreas Graf wrote:
>
> Graphiti uses Factory methods to instantiate its infrastructure. When
> overriding some behavior, that results in the necessity to re-implement
> some of the classes to override the factory methods.
>
> Are there any thoughts on using dependency injection with Graphiti? To
> support standalone-tests, I have started to "branch" Graphiti and use
> Guice e.g. to instantiate the ExtensionManager.
I've had similar thoughts, although I haven't tried implementing
anything. In general, all the services you can access through the
Graphiti class should be replaceable through injection. In this way you
could customize a lot of the standard behavior. In addition, it should
be possible to inject the logic for how to map from the diagram (shapes
and graphicalgorithms) to gef elements.
The first use case for this was supporting images referred to by URL's,
not just project files. To do this I would need to extend one service
and provide a different mapping to JFace's ImageDescriptor class.
The second use case was supporting custom gef shapes from my previous
projects. I would like to extend the diagram model and hence also the
factories and mapping to gef.
> But I would like to know if there are other efforts in that field, so as
> to avoid duplicate work.
I would like to cooperate on such an effort, hopefully with the support
of the Graphiti developers, to have any hope of merging suggested
changes back in.
Hallvard
|
|
| | | | | | | | | |
| Re: Graphiti and Dependency Injection [message #932517 is a reply to message #931916] |
Thu, 04 October 2012 03:09 |
| Eclipse User |
|
|
|
Hallvard Traetteberg wrote on Wed, 03 October 2012 12:47
Yes, I understand how this works. What I don't understand is how this is
useful if you cannot extend the logic for how Graphiti uses the model
e.g. the mapping to GEF.
I'm curious for what purposes you extend the model? Could you share some
experiences?
Hallvard
Hi Hallvard,
I use it on the shape level. As a simple example, consider e.g. the usual graphical element of a rectangle with a text label. Graphiti does not have the concept of more complex shapes, so if you want to modify the text label, you have to know that text is the n-th figure in the GA of the y-th shape.
So I extend the Graphiti MM by introducing something like a "LabeledRectangle" which has a dedicated EMF refernce to its label GA, so I just can call LabeldRectangle.getLabelGA() without navigating to the hierarchy.
Actually, I have something which is similar to the "Graphiti Pattern" : The shapes have methods that are called when being moved, layouted etc. and by the extension through EMF they can store some state. E.g., for ports that are on class' borders, I store an attribute on which border the port is located (left, right) and use that for aligning the connections.
And I use that to extend Graphiti functionality. E.g., Graphiti has no floating decorators for shapes (only for associations). But I want floating, draggable labels for port names. So I have a "SmartShape" that inherits from container shape. That stores the EMF reference to the label shape. When moving the port, SmartShape.move() is being called, which updates the position of the label shape. The label itself is an instance of SmartFloatingLabel, which in EMF stores the delta of coordinates to the port shape.....
Note that you can also store some state through Graphiti properties, but that is not as typesafe / resilient to refactoring.
There is no need for changing the Graphiti core for that approach, only my feature implementations are designed in a way that they know that I am using "SmartShapes".
Hope that clarified my approach.
Regards,
Andreas
[Updated on: Thu, 04 October 2012 03:11] by Moderator |
|
| |
| Re: Graphiti and Dependency Injection [message #933110 is a reply to message #932517] |
Thu, 04 October 2012 14:48 |
| Eclipse User |
|
|
|
Andreas,
Thank you very much for the explanation! You are right that managing
configurations of shapes and GAs is cumbersome and error-prone and that
extending the diagram model seems better. I currently use properties for
cases such as port position, but modelling it properly seems better.
I can imagine (derived) EReferences can be used for accessing business
objects in a nicer and type-safe manner, too, don't you think? E.g. (in
pesudo Xcore syntax):
class ModelShape<T> extends ContainerShape {
derived ref T model; // getModel must fetch the appropriate bo
}
class ProcessShape extends ModelShape<Process> { ... } etc.
There should be a great potential for reuse, since many diagram
languages have the same syntactic structure, e.g. labeled boxes with
ports on the side, compartment for content etc.
Is your code available for browsing and (re)use?
Hallvard
On 04.10.12 00.09, Andreas Graf wrote:
> Hallvard Traetteberg wrote on Wed, 03 October 2012 12:47
>> Yes, I understand how this works. What I don't understand is how this
>> is useful if you cannot extend the logic for how Graphiti uses the
>> model e.g. the mapping to GEF.
>>
>> I'm curious for what purposes you extend the model? Could you share
>> some experiences?
>>
>> Hallvard
>
>
> Hi Hallvard,
>
> I use it on the shape level. As a simple example, consider e.g. the
> usual graphical element of a rectangle with a text label. Graphiti does
> not have the concept of more complex shapes, so if you want to modify
> the text label, you have to know that text is the n-th figure in the GA
> of the y-th shape.
>
> So I extend the Graphiti MM by introducing something like a
> "LabeledRectangle" which has a dedicated EMF refernce to its label GA,
> so I just can call LabeldRectangle.getLabelGA() without navigating to
> the hierarchy.
> Actually, I have something which is similar to the "Graphiti Pattern" :
> The shapes have methods that are called when being moved, layouted etc.
> and by the extension through EMF they can store some state. E.g., for
> ports that are on class' borders, I store an attribute on which border
> the port is located (left, right) and use that for aligning the
> connections.
> And I use that to extend Graphiti functionality. E.g., Graphiti has no
> floating decorators for shapes (only for associations). But I want
> floating, draggable labels for port names. So I have a "SmartShape" that
> inherits from container shape. That stores the EMF reference to the
> label shape. When moving the port, SmartShape.move() is being called,
> which updates the position of the label shape. The label itself is an
> instance of SmartFloatingLabel, which in EMF stores the delta of
> coordinates to the port shape.....
>
> Note that you can also store some state through Graphiti properties, but
> that is not as typesafe / resilient to refactoring.
>
> Hope that clarified my approach.
>
> Regards,
>
> Andreas
>
|
|
| | | | | | | | |
| Re: Graphiti and Dependency Injection [message #984424 is a reply to message #981556] |
Wed, 14 November 2012 12:38 |
| Eclipse User |
|
|
|
On 12.11.12 06.09, Michael Wenz wrote:
>> make it difficult in general. E.g. the behavior objects are created by
>> DiagramEditor's constructor, so they can't be replaced without
>> subclassing. If they were initialized later, a subclass could at least
>> introduce DI by having its own inject fields, that could be used in
>> overridden createXXX methods. And the main services retrieved using
>> static Graphiti methods would also be nice to be able to replace/extend.
>
> Hallvard,
>
> this sounds like a small change with little side effect. Would you open
> a Bugzilla to track this?
Here it is: https://bugs.eclipse.org/bugs/show_bug.cgi?id=394315
Thanks in advance!
Hallvard
|
|
|
Goto Forum:
Current Time: Tue Jul 22 19:38:21 EDT 2025
Powered by FUDForum. Page generated in 0.07817 seconds |
Home