Index: topia/doc/DevDoc.rst
diff -u /dev/null topia/doc/DevDoc.rst:1.1
--- /dev/null	Mon Jun  7 10:21:43 2004
+++ topia/doc/DevDoc.rst	Mon Jun  7 10:21:38 2004
@@ -0,0 +1,100 @@
+=========================
+Documentation développeur
+=========================
+
+Fichier de propriété du context
+===============================
+
+Sous classage d'entité ou de service
+------------------------------------
+
+Les services et les entités peuvent être étendu en sous classant les classes
+générées. Pour prendre en compte ces sous classes il faut les déclarer dans
+le fichier de propriété chargé par le context.
+
+Pour chaque classe il y a deux entrées, une pour l'interface et une pour la
+classe à utiliser.
+
+Pour les entities on a donc::
+
+  mapping.enitity.to.interface
+  mapping.enitity.to.class
+  mapping.enitity.do.interface
+  mapping.enitity.do.class
+
+Pour le service de persistence::
+
+  mapping.service.persistence.interface
+  mapping.service.persistence.to.class
+
+Normalement le développeur utilisant le framework ToPIA ne doit modifier
+si besoin que les valeurs de::
+
+  mapping.enitity.to.class
+  mapping.service.persistence.to.class
+
+Pour récupérer une interface ou une classe pour un service de persitence il
+faut utiliser la méthode du context **getPersistenceService(Class)**. La
+classe passé en argument est la classe de l'interface de l'entité.
+
+Pour récupérer un TO ou un DO, il faut utiliser la methode du context
+**createEntity(Class):TopiaEntityTO** et **createEntityDO(Class)**. L'argument
+est l'interface de l'entité.
+
+Chargement d'un service
+=======================
+
+Recherche d'un service
+----------------------
+
+Toutes les recherches d'un service ce fait au travers du context. On demande
+un service pour un entité. Le service retourné implante l'interface du
+service souhaité. L'interface du service est celle déclaré dans le fichier
+de propriété du context.
+
+L'encapsulation en Proxy
+------------------------
+
+Pour différentes raison les services retourné à l'utilisateur ne sont pas
+directement des objets services, mais des objets proxy qui encapsule le
+service. Cela permet d'ajouter des fonctionnalitées au service et de faire
+une abstraction entre le service qui répond réellement à l'utilisateur et
+l'objet service que l'utilisateur manipule.
+
+Les fonctionnalitées sont: les hooks, les appels distant, les méthodes
+privées
+
+Les hooks
+---------
+
+Les hooks est une fonctionnalité qui permet d'ajouter du code avant et après
+l'execution d'une méthode sans avoir besoin de le prendre en compte dans le
+code sur service.
+
+Pour cela les proxies retournés implante l'interface Hookable qui permet
+d'ajouter des objets *TopiaHook* dont la méthode *call* sera appelé soit
+avant, soit après l'appel à la méthode du service.
+
+Les appels distants
+-------------------
+
+Le framework masque complètement l'implantation réelle du service. Hors un
+service peut-être distant (serveur d'application (EJB, XML-RPC), ou local
+(JDO, JDBC). Mais l'utilisateur n'a rien a faire pour prendre en compte ces
+différence. Le proxy se charge de rediriger la demande au bonne endroit.
+
+Les méthodes privées au framework
+---------------------------------
+
+Les services sont utilisé par les utilisateurs, mais aussi par le framework.
+Pour que les utilisateurs ne voit pas les méthodes du framework dans les
+interfaces du service. Celle-ci ont été placées dans une autre interface.
+Qui porte le même nom que le service mais prefixé par Private. Par exemple
+pour le service de persistence::
+
+  TopiaPersistenceService
+  PrivateTopiaPersistenceService
+
+Le context lors de la recherche d'un service, regarde s'il y a une interface
+de ce nom si c'est le cas, alors il l'ajoute a la liste des interfaces
+instanciées par le proxy qui encapsule le service.