| 1 |
Services |
|---|
| 2 |
======== |
|---|
| 3 |
|
|---|
| 4 |
Gaphor should be modeled around the concept of Services. Each service can |
|---|
| 5 |
be registered on the application and be used by other services or other |
|---|
| 6 |
objects living within the application. |
|---|
| 7 |
|
|---|
| 8 |
Since Gaphor already uses the zope.component adapters, it seems like a good |
|---|
| 9 |
choise to use zope.interface too as starting point for services. |
|---|
| 10 |
|
|---|
| 11 |
Each service should implement the IService interface. This interface defines |
|---|
| 12 |
one method: |
|---|
| 13 |
|
|---|
| 14 |
init(application) |
|---|
| 15 |
|
|---|
| 16 |
where `application' is the Application object for Gaphor (which is a service |
|---|
| 17 |
itself and therefore implements IService too. |
|---|
| 18 |
|
|---|
| 19 |
Each service is allowed to define it's own interface, as long as IService is |
|---|
| 20 |
implemented too. |
|---|
| 21 |
|
|---|
| 22 |
Services should be defined as entry_points in the Egg info file (yes, Gaphor |
|---|
| 23 |
should be executable as egg some day). |
|---|
| 24 |
|
|---|
| 25 |
Typically a service does some work in the background. |
|---|
| 26 |
|
|---|
| 27 |
|
|---|
| 28 |
Example: ElementFactory |
|---|
| 29 |
*********************** |
|---|
| 30 |
|
|---|
| 31 |
A nice example is the ElementFactory. Currently it is tightly bound to the gaphor.UML module. A default factory is created in __init__.py. |
|---|
| 32 |
|
|---|
| 33 |
It depends on the undo_manager. However, on important events events are emited. |
|---|
| 34 |
(That is when an element is created/destroyed). |
|---|
| 35 |
|
|---|
| 36 |
What you want to do is create an event handler for ElementFactory that stores the add/remove signals in the undo system. |
|---|
| 37 |
|
|---|
| 38 |
The same goes for UML.Elements. Those classes (or more specific the properties) send notifications every time their state changes. |
|---|
| 39 |
|
|---|
| 40 |
But.. where to put such information? |
|---|
| 41 |
|
|---|
| 42 |
Plugins |
|---|
| 43 |
======= |
|---|
| 44 |
|
|---|
| 45 |
Currently a plugin is defined by an XML file. This will change as plugins |
|---|
| 46 |
should be distributable as Egg's too. A plugin will contain user interface |
|---|
| 47 |
information along with it's service definition. |
|---|
| 48 |
|
|---|
| 49 |
Plugins are managed by a PluginManager (which is a Service). |
|---|
| 50 |
|
|---|
