Home » Modeling » Graphiti » Graphiti and Dependency Injection
|
| Re: Graphiti and Dependency Injection [message #929647 is a reply to message #929211] |
Mon, 01 October 2012 16:28   |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
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 07:09 |
Andreas Graf
Messages: 211
Registered: July 2009 |
Senior Member |
|
|
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 07:11] Report message to a moderator |
|
| |
| Re: Graphiti and Dependency Injection [message #933110 is a reply to message #932517] |
Thu, 04 October 2012 18:48 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
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
>
|
|
| | | | | | | | | |
Goto Forum:
Current Time: Fri Apr 19 22:02:13 GMT 2024
Powered by FUDForum. Page generated in 0.05825 seconds |
] 
Search
Help
Register
Login
Home
