| 1 |
module: gaphor.diagram |
|---|
| 2 |
====================== |
|---|
| 3 |
|
|---|
| 4 |
This module contains the items that can be placed in gaphor.UML.Diagram's. |
|---|
| 5 |
Each diagram item represents one or more gaphor.UML.Element's (subclasses |
|---|
| 6 |
thereof). Diagram items are subclassed from Presentation. This is the base |
|---|
| 7 |
class for "presentation elements": items used to visualize an UML element. |
|---|
| 8 |
|
|---|
| 9 |
Also gaphor.UML.Element is inherited. This class contains logic for event |
|---|
| 10 |
notification among other utility functions (e.g. the __unlink__ signal). |
|---|
| 11 |
|
|---|
| 12 |
Presentation elements ("items") have a "subject" attribute, that refers to the |
|---|
| 13 |
(main-) model element class that is represented (e.g. a class representation |
|---|
| 14 |
has as subject a gaphor.UML.Class instance, other elements, such as |
|---|
| 15 |
gaphor.UML.Property and gaphor.UML.Operation are implicitly referenced. |
|---|
| 16 |
|
|---|
| 17 |
Signal handling |
|---|
| 18 |
--------------- |
|---|
| 19 |
|
|---|
| 20 |
As of this version, signal notification is done through zope.component. As a |
|---|
| 21 |
result all modification events originated from gaphor.UML classes are received |
|---|
| 22 |
by all items. (In the old days every item should register for specific events |
|---|
| 23 |
on specific model elements, which resulted in quite a complex administration of |
|---|
| 24 |
event handlers, since all those handlers should be unregistered when an item |
|---|
| 25 |
was removed). |
|---|
| 26 |
|
|---|
| 27 |
Connecting items |
|---|
| 28 |
---------------- |
|---|
| 29 |
|
|---|
| 30 |
Another change, due to the introduction of the Zope3 framework, is how items |
|---|
| 31 |
are connected to one another. This is done through adapters (multi-adapters to |
|---|
| 32 |
be more specific). An adapter is used to add additional behavior to an object. |
|---|
| 33 |
In this case the IConnect interface should be implemented for (element, line) |
|---|
| 34 |
tuples. For each possible connection an adapter should be written (CommentItem |
|---|
| 35 |
with any DiagramItem, AssociationItem with ClassifierItem, etc.). The big |
|---|
| 36 |
(huge) advantage is that complex connection stuff is removed from the diagram |
|---|
| 37 |
items (which resulted in cyclic dependencies in the past) and is put on a |
|---|
| 38 |
higher level: the adapter. |
|---|
| 39 |
|
|---|
| 40 |
See interfaces.py and adapter.py for implementations. |
|---|
| 41 |
|
|---|
| 42 |
Text editing |
|---|
| 43 |
------------ |
|---|
| 44 |
|
|---|
| 45 |
Like item connecting, text editing is also implemented through adapters. The IEditor interface is used for this. |
|---|
| 46 |
|
|---|
| 47 |
|
|---|
