Services
========

Gaphor is be modeled around the concept of Services. Each service can
be registered on the application and be used by other services or other
objects living within the application.

Since Gaphor already uses the `zope.component` adapters, it seems like a good
choise to use `zope.interface` too as starting point for services.

Each service should implement the IService interface. This interface defines
one method::

   init(application)

where `application` is the Application object for Gaphor (which is a service
itself and therefore implements `IService` too.

Each service is allowed to define it's own interface, as long as `IService` is
implemented too.

Services should be defined as `entry_points` in the Egg info file.

Typically a service does some work in the background.


Example: ElementFactory
***********************

A nice example is the ElementFactory. Currently it is tightly bound to the gaphor.UML module. A default factory is created in __init__.py.

It depends on the undo_manager. However, on important events events are emited.
(That is when an element is created/destroyed).

What you want to do is create an event handler for ElementFactory that stores the add/remove signals in the undo system.

The same goes for UML.Elements. Those classes (or more specific the properties) send notifications every time their state changes.

But.. where to put such information?

Plugins
=======

Currently a plugin is defined by an XML file. This will change as plugins
should be distributable as Egg's too. A plugin will contain user interface
information along with it's service definition.

