Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 323360

Summary:

Ease of programming model - introducing stateful patterns in the form of draw patterns

Product:

[Modeling] Graphiti

Reporter:

Michael Wenz <michael.wenz>

Component:

Core

Assignee:

Project Inbox <graphiti-inbox>

Status:

ASSIGNED ---

QA Contact:

Severity:

enhancement

Priority:

CC:

rhett.hudson, tim.kaiser

Version:

0.7.0

Flags:

michael.wenz: indigo-

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
The prototypical implementation of the draw pattern	none

Description Michael Wenz

2010-08-23 04:10:57 EDT

It is quite complex to define and update a complex shape in a diagram. An approach that is for the tool developer easier to build and to maintain is a kind of "stateful pattern approach". One would only define a kind of placeholder in the diagram (ContainerShape), that defines the position and size of the representation; at rendering time the framework would request the actual representation dynamically from the tool (could be e.g. via a "DrawFeature"). Inside that feature the tool builder would create the current Pictogram- adn GraphicsAlgorithm tree as usual in Graphiti; that tree would be rendered by the framework, but it would not be persisted in the diagram.
The last thing is of course breaking with the paradigm that diagrams always contain the complete information needed for rendering.

Comment 1 Michael Wenz

2011-01-24 08:32:12 EST

Some experiments with a prototypical implementation of  a draw pattern showed that the benefit for tool developers are indeed big. It is really simple to create a visual representation for a domain object and to update it. On the other hand there a quite some downsides to this approach:
- Different handling for garphiti objects: inside the draw feature all created objects must not be stored in a EMF resource. While this is easy to handle for the "normal" graphical objects liek ContainerShapes, rectangles etc., this gets quite difficult for shared objects like colors and links.
- The approach is feasible for releatively easy and small representation (consisting of not too many single Graphiti objects); otherwise to automatic comparision that is triggered by the pattern for various operations will get really slow.
- The result of that comparision might be interpreted differently for different scenarios. Can this be handled generically?
- The small representation that this approach can really handle with good performance can also quite easily implemented by hand. So, this approach would introduce a lot of complexity and overhead in the framework just to solve easy scenarios. Is this really worth investing?
How should the integration with other objects work? Open points are the interaction which child objects also implemented as draw patterns but also the interaction with other objects implemented in the standard way.

Conclusion is to postpone this to same later point in time.

Comment 2 Michael Wenz

2011-01-24 11:08:50 EST

Created attachment 187438 [details]
The prototypical implementation of the draw pattern

Comment 3 Michael Wenz

2011-07-18 07:23:13 EDT

Out-of-scope for Juno, unless there are contributions in this area