Author: jcouteau Date: 2009-02-12 15:00:55 +0000 (Thu, 12 Feb 2009) New Revision: 1369 Modified: topia/trunk/topia-persistence/src/site/fr/rst/Devel.rst topia/trunk/topia-persistence/src/site/fr/rst/FAQ.rst topia/trunk/topia-persistence/src/site/fr/rst/HibernateMapping.rst topia/trunk/topia-persistence/src/site/fr/rst/Isolation.rst topia/trunk/topia-persistence/src/site/fr/rst/ModelGeneration.rst topia/trunk/topia-persistence/src/site/fr/rst/SchemaMigration.rst topia/trunk/topia-persistence/src/site/fr/rst/Todo.rst topia/trunk/topia-persistence/src/site/fr/rst/TopiaDocumentation.rst topia/trunk/topia-persistence/src/site/fr/rst/event.rst topia/trunk/topia-persistence/src/site/fr/rst/howto.rst topia/trunk/topia-persistence/src/site/fr/rst/project.rst topia/trunk/topia-persistence/src/site/fr/rst/security.rst Log: Spelling and grammatical corrections on documentation Modified: topia/trunk/topia-persistence/src/site/fr/rst/Devel.rst =================================================================== --- topia/trunk/topia-persistence/src/site/fr/rst/Devel.rst 2009-02-12 14:00:23 UTC (rev 1368) +++ topia/trunk/topia-persistence/src/site/fr/rst/Devel.rst 2009-02-12 15:00:55 UTC (rev 1369) @@ -1,16 +1,16 @@ TopiaContextFactory =================== -Le topia context est créé en fesant la demande sur le *TopiaContextFactory*. +Le topia context est créé en faisant la demande sur le *TopiaContextFactory*. On peut passer en paramètre au *TopiaContextFactory* un object *Property* qui -permet de configurer le context. Si on ne donne pas de fichier un fichier de +permet de configurer le context. Si aucun fichier est passé en paramètre, un fichier de propriété **TopiaContextImpl.properties** est recherché dans le classpath. Fichier de configuration ======================== Le fichier de configuration est un fichier lisible par un objet *Property*. -Il contient différente information: +Il contient différentes informations : - liste des entités à gérer - type de DAO à utiliser - option de connexion à la base de données @@ -19,43 +19,39 @@ Liste des entités à gérer ------------------------- -Il est possible de définir les entités soit directement un indiquant un +Il est possible de définir les entités soit directement en indiquant un répertoire contenant les mappings hibernate:: topia.persistence.directories=<path> -doit en indiquant une liste de classe séparé par des virgule:: +soit en indiquant une liste de classe séparé par des virgule:: topia.persistence.classes=<list de classe> Le mieux est d'utiliser la liste de classe qui est non spécifique à une -persistence ou à une plateform. +persistence ou à une plateforme. Type de DAO à utiliser ---------------------- -Par défaut si cette option n'est pas spécifiée, les entités sont géré par +Par défaut si cette option n'est pas spécifiée, les entités sont gérées par hibernate. On peut préciser d'utiliser le même type de DAO pour toutes les -entités en une seul fois avec:: +entités en une seule fois avec:: topia.dao.default.class=<DAO class name> On peut aussi préciser un DAO spécifique pour une entité particulière:: - topia.dao.<fully qualify class name>=<DAO class name> + topia.dao.<fully qualified class name>=<DAO class name> Pour simplifer un peu l'écriture, deux alias de DAO on été fait: - **hibernate** est remplacé par *org.codelutin.topia.persistence.hibernate.TopiaDAOHibernate* - **flatfile** est remplacé par *org.codelutin.topia.persistence.flatfile.TopiaDAOFlatFile* -La plupart du temps on ne spécifie dans ces options que le DAO de base -(hibernate, flatfile, ...) et non pas un DAO spécifique pour l'entité qui -aurait des méthodes de recherche supplémentaire, car la méthode **getDao** -du *TopiaContext* encapsule automatiquement ce DAO générique par un DAO -spécifique si celui-ci est trouvé. Le DAO spécifique doit avoir exactement -le même nom que l'entité avec DAO à la fin. Si vous souhaitez implanter ce -genre de DAO spécifique, il devra étendre la classe *TopiaDAODelegator*. +La plupart du temps, on ne spécifie, dans ces options, que le DAO de base (hibernate, flatfile, ...) et non pas un DAO spécifique pour l'entité qui aurait des méthodes de recherche supplémentaire. Ceci car la méthode **getDao** du *TopiaContext* encapsule automatiquement ce DAO générique par un DAO spécifique si celui-ci est trouvé. Le DAO spécifique doit avoir exactement +le même nom que l'entité avec DAO à la fin. +Si vous souhaitez implanter ce genre de DAO spécifique, il devra étendre la classe *TopiaDAODelegator*. Option de connexion à la base de données ---------------------------------------- @@ -63,7 +59,7 @@ Flatfile ~~~~~~~~ -La seul option à renseigner est le répertoire ou les entités doivent être +La seule option à renseigner est le répertoire ou les entités doivent être sauvées:: topia.dao.flatfile.directory=<path> @@ -71,13 +67,11 @@ Hibernate ~~~~~~~~~ -Les options pour hibernate peuvent être directement dans le fichier de -configuration principale ou dans un fichier de configuration secondaire dans -ce cas il faut indiquer dans le principale le chemin de ce fichier:: +Les options pour hibernate peuvent être directement dans le fichier de configuration principal ou dans un fichier de configuration secondaire. Dans ce cas il faut indiquer dans le fichier de configuration principal le chemin de ce fichier:: topia.persistence.properties.file=<filesystem or classpath path> -Les options hibernates sont les optiions hibernate classique: +Les options hibernates sont les options hibernate classique : - hibernate.connection.username - hibernate.connection.password @@ -88,15 +82,14 @@ Les services à activer ---------------------- -Il est possible d'indiqué les services à activer grâce aux options:: +Il est possible d'indiquer les services à activer grâce aux options:: topia.service.<service name>=<class> topia.service.security=org.codelutin.topia.security.TopiaSecurityServiceImpl topia.service.index=org.codelutin.topia.index.LuceneIndexer topia.service.history=org.codelutin.topia.history.TopiaHistoryServiceImpl -Le nom du service doit correspondre au nom de service que le service -retourne, sinon il est désactivé. +<service name> doit correspondre au nom de service que <class> retourne, sinon il est désactivé. Les services disponibles actuellement sont: @@ -112,8 +105,8 @@ en récupérant des nouveaux *TopiaContext* fils, de s'enregistrer en tant que listener pour recevoir les notifications de modification sur les entités. -Sur les *TopiaContext* fils on peut récupérer des DAO qui permettent de -créer, modifier, recherché les entités. +Sur les *TopiaContext* fils, on peut récupérer des DAO qui permettent de +créer, modifier, rechercher les entités. DAO === @@ -127,7 +120,7 @@ - hibernate - flatfile -Il est possible d'ajouter d'autre type de persistence en implantant +Il est possible d'ajouter d'autres types de persistence en implantant *TopiaDAOAbstract*. Il est possible de faire un DAO spécial pour un type d'entité, par exemple @@ -148,7 +141,7 @@ ====== Normalement **Topia** est fait pour pouvoir générer n'importe quel type de POJO -et les rendre persistent. Mais il est plus simple d'utiliser la génération +et les rendre persistants. Mais il est plus simple d'utiliser la génération de code fournit avec **Topia** pour générer les entités à partir d'un diagramme UML. Dans ce cas toutes les entités héritent de *TopiaEntity* qui contient des méthodes pour s'enregistrer sur les modifications des attributs @@ -182,7 +175,7 @@ public static final String SERVICE_NAME = "monservice"; -Un service peut avoir besoin de nouvelle entités pour fonctionner pour cela +Un service peut avoir besoin de nouvelles entités pour fonctionner. Pour cela il faut retourner la liste des entités grâce à la méthode **getPersistenceClasses**. Modified: topia/trunk/topia-persistence/src/site/fr/rst/FAQ.rst =================================================================== --- topia/trunk/topia-persistence/src/site/fr/rst/FAQ.rst 2009-02-12 14:00:23 UTC (rev 1368) +++ topia/trunk/topia-persistence/src/site/fr/rst/FAQ.rst 2009-02-12 15:00:55 UTC (rev 1369) @@ -1,18 +1,18 @@ -Probleme lors du chargement d'une entity +Problème lors du chargement d'une entity ======================================== -Le chargement utilise les methodes Set des proprietes, il faut donc faire +Le chargement utilise les méthodes Set des propriétés, il faut donc faire attention si on les surcharge. -Il faut faire attention lors de l'ajout de method sur l'entity qui ont la -meme signature que des methods Set de properties avec juste des arguments -different, car elles peuvent etre utilisées a la place de la vrai methode -pour quelque valeur (par exemple null) +Il faut faire attention lors de l'ajout, sur l'entity, de méthodes qui ont la +même signature que des méthods Set de propriétés avec juste des arguments +différents, car elles peuvent être utilisées à la place de la vrai méthode +pour quelque valeur (par exemple null). Faire fonctionner les Web Services Topia via RMI ================================================ -L'utilisation des Web Services sur RMI impose la generation de classes sauvées +L'utilisation des Web Services sur RMI impose la génération de classes sauvées sur disque. -Elle sont construite à la volée et sauvées dans le dossier "./topiagen". +Elle sont construites à la volée et sauvées dans le dossier "./topiagen". -Ce dossier doit donc se trouver dans le classpath. \ No newline at end of file +Ce dossier doit donc se trouver dans le classpath. Modified: topia/trunk/topia-persistence/src/site/fr/rst/HibernateMapping.rst =================================================================== --- topia/trunk/topia-persistence/src/site/fr/rst/HibernateMapping.rst 2009-02-12 14:00:23 UTC (rev 1368) +++ topia/trunk/topia-persistence/src/site/fr/rst/HibernateMapping.rst 2009-02-12 15:00:55 UTC (rev 1369) @@ -2,8 +2,8 @@ Mapping hibernate ================= -Ce document d'écrit les choix de mapping fait en fonction des différentes en -fonction du diagramme de classe UML. +Ce document décrit les choix de mapping faits en fonction +du diagramme de classe UML. JDBC ==== @@ -11,7 +11,7 @@ Généralité ---------- -- Tous les objets utilise le versionnement dans un champs version:: +- Tous les objets utilisent le versionnement dans un champs version:: <version name="topiaVersion" type="long" node="@topiaVersion"/> @@ -28,22 +28,22 @@ Identifiant ----------- -Lors de la description de la classe, on peut indiquer de ne pas généré de clé -technique dans ce cas, la cle metier est uitlisé (tagvalue: technicalKey=false). -Par défaut une clé technique est utilisé et est de la forme uuid.hex:: +Lors de la description de la classe, on peut indiquer de ne pas générer de clé +technique. Dans ce cas, la clé métier est utilisée (tagvalue: technicalKey=false). +Par défaut une clé technique est utilisée et est de la forme uuid.hex:: <id name="topiaId" column="topiaId" type="string"> <generator class="uuid.hex"/> </id> -La description de la cle metier est fait par un tagvalue sur la classe -(tagvalue: key=prop1,prop2,prop3). Si une cle technique est utilisée une -contrainte d'unicité est tout de même fait sur la cle métier. +La description de la clé métier est faite par un tagvalue sur la classe +(tagvalue: key=prop1,prop2,prop3). Si une clé technique est utilisée, une +contrainte d'unicité est tout de même faite sur la clé métier. -La cle metier sert aussi pour le toString, equals, hashCode. +La clé métier sert aussi pour le toString, equals, hashCode. Si l'id d'une entité est composé de plusieurs champs, ces champs doivent-être -rassemblé dans une classe indépendante de l'entité. Par contre le mapping +rassemblés dans une classe indépendante de l'entité. Par contre le mapping assemble l'entity et son id dans la même table:: <composite-id name="#field" class="#class"> @@ -52,7 +52,7 @@ <key-property name="#field3" column="#col3"/> </composite> -Si l'id est un objet simple il peut-être directement mis dans l'entité. +Si l'id est un objet simple il peut être directement mis dans l'entité. Relation 1-0 ------------ @@ -77,8 +77,8 @@ Composition ----------- -Le composant peut changer de proprietaire (set methode) mais le -proprietaire pert en meme temps le lien vers son composé. +Le composant peut changer de propriétaire (set méthode) mais le +propriétaire perd en même temps le lien vers son composé. Aggregation ----------- @@ -86,11 +86,11 @@ Si une classe est aggrégée avec une autre, alors elle suit la vie de l'entité à laquelle elle est aggrégée (cascade delete, update) -Elle ne peut pas etre affecté a une autre entité pas de set sur cette classe +Elle ne peut pas être affectée a une autre entité. Pas de set sur cette classe vers l'autre classe. XML === -Toutes les propriétés sont des éléments sauf la cle technique qui est un +Toutes les propriétés sont des éléments sauf la clé technique qui est un attribut. Modified: topia/trunk/topia-persistence/src/site/fr/rst/Isolation.rst =================================================================== --- topia/trunk/topia-persistence/src/site/fr/rst/Isolation.rst 2009-02-12 14:00:23 UTC (rev 1368) +++ topia/trunk/topia-persistence/src/site/fr/rst/Isolation.rst 2009-02-12 15:00:55 UTC (rev 1369) @@ -2,55 +2,55 @@ Isolation des TopiaContexts =========================== -remarque: les requetes ne sont pas bonne, mais sont la pour donner l'idée +Remarque: les requètes ne sont pas bonnes, mais sont là pour donner l'idée générale. -Pour mettre en place l'isolation entre les différents TopiaContexts créé par -begionTransaction, il faut ajouter un nouvelle propriété sur les +Pour mettre en place l'isolation entre les différents TopiaContexts créés par +beginTransaction, il faut ajouter un nouvelle propriété sur les TopiaEntity: TopiaContextId. Cette propriété prend la valeur de l'id du -TopiaContext qui a créé ou chargé l'objet. On voit donc que plusieurs objet +TopiaContext qui a créé ou chargé l'objet. On voit donc que plusieurs objets ayant le même id peuvent exister, le TopiaContextId doit donc faire partie -de la cle de l'objet. Il faut aussi ajouter un champs TopiaDeleted pour -savoir si un objet a ete effacé ou non. +de la clé de l'objet. Il faut aussi ajouter un champs TopiaDeleted pour +savoir si un objet a été effacé ou non. Dans le mapping hibernate pour chaque class d'entité, on a un filtre: where TopiaContextId == :id || (TopiaContextId > 0 && TopiaContextId <= :id) Ce filtre n'est pas suffisant car on a toutes les versions commités de l'objet jusqu'a :id, il faut un autre filtre apres les recherches pour -n'avoir que les dernieres versions des entites et supprimé dans ce groupe -les entites marquées effacées. +n'avoir que les dernieres versions des entites et supprimer dans ce groupe +les entitées marquées et effacées. where TopiaContextId = max(TopiaContextId) && isDeleted=false group by topiaId Lors d'un beginTransaction le nouveau TopiaContext active ce filtre pour son propre id. -De cette manière un TopiaContext ne voit que les objets qu'il a cree et/ou -modifié ou les objets plus ancien que lui. +De cette manière un TopiaContext ne voit que les objets qu'il a créé et/ou +modifié, ou les objets plus ancien que lui. Cet Id est: - System.nanoTime() et donc toujours négatif. Lors d'un commit d'un TopiaContext, on passe tous les TopiaContextId de -toutes les entités qui sont egal a l'id du TopiaContext en sa version +toutes les entités qui sont égales a l'id du TopiaContext en sa version positive: update <table> set TopiaContextId = -:id where TopiaContextId = :id -De plus le TopiaContext renouvelle sont id et modifie tous les filtres pour -qu'il ait la vision d'objet créé par d'autre TopiaContext avant son commit +De plus le TopiaContext renouvelle son id et modifie tous les filtres pour +qu'il aie la vision d'objets créés par d'autre TopiaContext avant son commit. -Lors d'un rollback il suffit de faire le renouvellement de l'id et la mise a +Lors d'un rollback il suffit de faire le renouvellement de l'id et la mise à jour des filtres. -Sous transaction +Sous-transaction ================ -La gestion des TopiaContextId pourrait offrire les sous-transactions, si -dans le filtre on ajoutait comme condition au lieu de TopiaContextId == :id +La gestion des TopiaContextId pourrait offrir les sous-transactions, si +dans le filtre on ajoutait comme condition, au lieu de TopiaContextId == :id, TopiaContextId in (:idList) ou idList serait la liste des ids du -TopiaContext courant ainsi que des TopiaContext parent. +TopiaContext courant ainsi que des TopiaContext parents. Historisation ============= -La gestion des TopiaContextId permet d'offire l'historisation de tous les +La gestion des TopiaContextId permet d'offrir l'historisation de tous les objets. Car tous les objets commités sont conservés avec un TopiaContextId différent pour chaque version. @@ -58,7 +58,7 @@ ============ - Mettre en place les champs supplémentaires: TopiaContextId, TopiaDeleted -- Modifier la cle primaire pour ajouter TopiaContextId +- Modifier la clé primaire pour ajouter TopiaContextId - Ajouter les filtres dans les mappings - Ajouter un id sur les TopiaContext - Modifier le comportement de DAO.delete pour qu'il marque juste l'objet Modified: topia/trunk/topia-persistence/src/site/fr/rst/ModelGeneration.rst =================================================================== --- topia/trunk/topia-persistence/src/site/fr/rst/ModelGeneration.rst 2009-02-12 14:00:23 UTC (rev 1368) +++ topia/trunk/topia-persistence/src/site/fr/rst/ModelGeneration.rst 2009-02-12 15:00:55 UTC (rev 1369) @@ -81,4 +81,4 @@ <!-- la version peut être plus récente --> <version>2.1.0</version> <scope>compile</scope> -</dependency> \ No newline at end of file +</dependency> Modified: topia/trunk/topia-persistence/src/site/fr/rst/SchemaMigration.rst =================================================================== --- topia/trunk/topia-persistence/src/site/fr/rst/SchemaMigration.rst 2009-02-12 14:00:23 UTC (rev 1368) +++ topia/trunk/topia-persistence/src/site/fr/rst/SchemaMigration.rst 2009-02-12 15:00:55 UTC (rev 1369) @@ -1,10 +1,10 @@ ===================================== -Comment migrer d'un schema a un autre +Comment migrer d'un schéma à un autre ===================================== Une application modifie et ajoute des objets. La persistence doit donc être adaptée à ces changements. Le problème est la migration des données -existants dans le nouveau schéma. +existantes dans le nouveau schéma. Voici quelques idées d'implantations. @@ -12,10 +12,10 @@ ======================== Hibernate permet de mapper les objets de la base de données dans des -dynamic-map. Nous n'avons donc pas besoin de pojo pour les représenter, ils +dynamic-map. Nous n'avons donc pas besoin de pojo pour les représenter, il nous suffit d'avoir le mapping hibernate. -L'idée est donc lors de la modification de schéma de regrouper tous les +L'idée est donc, lors de la modification de schéma, de regrouper tous les anciens mapping dans un seul fichier de mapping qui contiendra le numero de version du schema. @@ -28,23 +28,25 @@ Avantage -------- -Le changement de schema est fait en java +Le changement de schéma est fait en java Désavantage ----------- -Il faut dans la base une table qui indique dans quelle version de schema -actuelle est la base (Topia->schemaVersion), ou bien il faut faire une base -par version, le numero de version etant dans le nom de la base (inconveniant -le nom de la base change a chaque version), a moins qu'on ne puisse faire un -changement de schema dans une transaction, donc on peut lire les anciennes -données dans une transaction et on ecrit les nouvelles dans une autre -transaction sur la meme table mais qui aurait des schema differents. +Il faut dans la base une table qui indique dans quelle version de schéma +actuelle est la base (Topia->schemaVersion). +Une autre solution est de faire une base +par version, le numero de version étant dans le nom de la base (inconveniant : +le nom de la base change a chaque version). +Une autre solution possible est de faire un +changement de schéma dans une transaction, donc on peut lire les anciennes +données dans une transaction et on écrit les nouvelles dans une autre +transaction sur la même table mais qui aurait des schéma différents. -Il faut dans les noms des tables le numero de version du schema pour que les +Il faut, dans les noms des tables, le numéro de version du schéma pour que les les anciennes tables ne servent pas comme nom pour les nouvelles. -Il faut soit faire l'aggregation des mapping dans un seul fichier, soit +Il faut soit faire l'aggrégation des mapping dans un seul fichier, soit n'utiliser qu'un seul fichier pour les mappings, soit avoir un fichier par classe et par version, mais il est moins simple de retrouver tous les fichiers de mapping et surtout moins simple @@ -88,8 +90,8 @@ Il est aussi possible de lire une base en XML. On utiliserait donc la même technique que pour les dynamic-map, mais on utiliserait du XSL pour -convertir le XML vers le schema souhaité. De cette facon il n'y a pas besoin -de table intermédiaire ni de numero de version de schema dans les tables. +convertir le XML vers le schéma souhaité. De cette facon il n'y a pas besoin +de table intermédiaire ni de numéro de version de schéma dans les tables. - Export XML en utilisant le vieux mapping - converion en enchainant les transformations XSL @@ -98,13 +100,13 @@ Inconvéniant ------------ -si le volume est important il peut-etre long de tous transformer en XML. +si le volume est important il peut-etre long de tout transformer en XML. Kettle ====== Une autre idee est de ne pas utiliser hibernate mais kettle pour la migration des données. Nous aurions de la même façon dans le nom des tables -un numero de version de schema. Un fichier kettle decrirait la migration -d'une version à une autre. Et les différents fichier serait chainé pour -arrivé au schema souhaité. +un numero de version de schéma. Un fichier kettle decrirait la migration +d'une version à une autre. Et les différents fichiers serait chaînés pour +arriver au schéma souhaité. Modified: topia/trunk/topia-persistence/src/site/fr/rst/Todo.rst =================================================================== --- topia/trunk/topia-persistence/src/site/fr/rst/Todo.rst 2009-02-12 14:00:23 UTC (rev 1368) +++ topia/trunk/topia-persistence/src/site/fr/rst/Todo.rst 2009-02-12 15:00:55 UTC (rev 1369) @@ -1,4 +1,4 @@ -Recherche a faire: +Recherches à faire: - des persistences hibernates sur LDAP ou FlatFile - des outils de migration/evolution de schema @@ -11,7 +11,7 @@ .getGenericSuperclass()).getActualTypeArguments()[0]; -Regarder si TopiaContext ne pourrait pas etre remplacé par un PicoContainer +Regarder si TopiaContext ne pourrait pas être remplacé par un PicoContainer http://www.hibernate.org/180.html http://www.hibernate.org/182.html @@ -21,18 +21,18 @@ Generation ========== -- (2) import/export XML dans ToPIA, a mettre dans le mapping hibernate (en partie fait, mais très stable...) +- (2) import/export XML dans ToPIA, à mettre dans le mapping hibernate (en partie fait, mais très stable...) Gestion des versions des POJO ============================= -mettre en place serialVersionUID sur les entites +mettre en place serialVersionUID sur les entités Gestion des droits et de la sécurité ==================================== -Le createur de l'objet n'est pas dans l'objet lui meme mais dans une table a +Le créateur de l'objet n'est pas dans l'objet lui même mais dans une table a part. Owner: topiaId de l'entity, id du propriétaire @@ -40,8 +40,8 @@ Les droits des objets sont dans une table a part (voir http://www.hibernate.org/140.html). -Il serait bon que les droits s'applique sur un group ou un user. Et qu'un user -puisse apportenir a un group, et qu'un group puisse aussi appartenir a un group +Il serait bon que les droits s'appliquent sur un group ou un user. Et qu'un user +puisse appartenir a un group, et qu'un group puisse aussi appartenir a un group Il faut aussi modifier le Policy ou autre pour pouvoir lire les permissions dans hibernate lorsqu'on nous les demandes. Mettre des méthodes statique dans @@ -220,4 +220,4 @@ - TODO Check wether this method could be used to generate getter and setters -- Uniformiser et faire hériter les générateurs des interfaces et classe d'impl pour que le générateur de la classe d'impl soit capable de générer aussi l'interface \ No newline at end of file +- Uniformiser et faire hériter les générateurs des interfaces et classe d'impl pour que le générateur de la classe d'impl soit capable de générer aussi l'interface Modified: topia/trunk/topia-persistence/src/site/fr/rst/TopiaDocumentation.rst =================================================================== --- topia/trunk/topia-persistence/src/site/fr/rst/TopiaDocumentation.rst 2009-02-12 14:00:23 UTC (rev 1368) +++ topia/trunk/topia-persistence/src/site/fr/rst/TopiaDocumentation.rst 2009-02-12 15:00:55 UTC (rev 1369) @@ -7,14 +7,14 @@ - abstraction de la persistence - sauvegarde/restauration en XML -- securite sur les instances d'objets -- generation de code meme si non obligatoire pour utiliser ToPIA +- sécurité sur les instances d'objets +- génération de code même si non obligatoire pour utiliser ToPIA -Ce qu'il serait bien de recuperer par rapport a la version 2 +Ce qu'il serait bien de récuperer par rapport à la version 2 - support des sous-transactions -peut-etre plus tard +peut-être plus tard - gestion des services - distribution transparente @@ -23,22 +23,22 @@ =============== Un point d'entre le TopiaContext sur lequel on ouvre des transactions ce qui -retourne un autre TopiaContext a partir duquel on recupere les DAO des -differentes entités qui permettent de faire les traitements que l'on souhaite. +retourne un autre TopiaContext à partir duquel on récupère les DAO des +différentes entités qui permettent de faire les traitements que l'on souhaite. Ensuite on peut appeler la methode commit de ce sous TopiaContext pour mettre -a jour la base de données et permettre a d'autre TopiaContext d'avoir la +à jour la base de données et permettre à d'autres TopiaContext d'avoir la nouvelle vision de nos objets. -Chaque TopiaContext creer sur le TopiaContext root sont independant. +Chaque TopiaContext créé sur le TopiaContext root est indépendant. Lorsque l'on travaille avec un objet provenant d'un TopiaContext sur lequel -on a fait un rollback celui-ci n'est plus valide et il vaut mieux en recuperer -une version correct sur le TopiaContext. +on a fait un rollback, celui-ci n'est plus valide et il vaut mieux en recupérer +une version correcte sur le TopiaContext. -Apres avoir fait un commit ou un rollback sur un TopiaContext on peut continuer +Après avoir fait un commit ou un rollback sur un TopiaContext on peut continuer a l'utiliser et refaire des commits pour synchroniser de temps en temps les -modification fait sur la base. +modification faites sur la base. Un TopiaContext peu servir aussi longtemps que l'on souhaite, il ne maintient pas inutilement de transaction sur la base. Modified: topia/trunk/topia-persistence/src/site/fr/rst/event.rst =================================================================== --- topia/trunk/topia-persistence/src/site/fr/rst/event.rst 2009-02-12 14:00:23 UTC (rev 1368) +++ topia/trunk/topia-persistence/src/site/fr/rst/event.rst 2009-02-12 15:00:55 UTC (rev 1369) @@ -1,67 +1,67 @@ -Gestion des evenements +Gestion des évènements ====================== -On peut se mettre listener sur deux sortes d'evenement les TopiaEntityEvent et -les TopiaVetoableEntityEvent. La difference entre les deux est le moment de +On peut se mettre listener sur deux sortes d'évènements : les TopiaEntityEvent et +les TopiaVetoableEntityEvent. La difference entre les deux se situe sur le moment de l'appel. TopiaVetoableEntityEvent ------------------------ -Les TopiaVetoableEntityEvent sont appelé avant l'action, ce qui +Les TopiaVetoableEntityEvent sont appelés avant l'action, ce qui permet de l'interdire en levant une exception (par exemple pour gérer la sécurité). -Les TopiaVetoableEntityEvent contiennent la classe au quel se rapporte l'event +Les TopiaVetoableEntityEvent contiennent la classe à laquelle se rapporte l'event et si possible l'identifiant de l'objet qui sera impacté. Cela n'est pas -toujours, par exemple lors de la creation l'identifiant n'existe pas forcement +toujours le cas; par exemple lors de la creation, l'identifiant n'existe pas forcément et donc ne peut-etre donné. Propagation ~~~~~~~~~~~ -Les TopiaVetoableEntityEvent sont aussi leve pour tous les contexts pere -du context qui a produit l'event et ceci juste apres avoir prevenu les +Les TopiaVetoableEntityEvent sont aussi levés pour tous les contexts pères +du context qui a produit l'event et ceci juste apres avoir prévenu les listeners du context courant. TopiaEntityEvent ---------------- -Les TopiaEntityEvent sont appelé après l'action pour prévenir du changement. +Les TopiaEntityEvent sont appelés après l'action pour prévenir du changement. -Les TopiaEntityEvent contiennent l'entity au quel se rapporte l'event +Les TopiaEntityEvent contiennent l'entity à laquelle se rapporte l'event Propagation ~~~~~~~~~~~ Les TopiaEntityEvent sont propagé au context pere lors du commit du context. -Si un rollback est fait alors ce sont les listeners du context eux meme qui -sont prevenu du changement. +Si un rollback est fait, alors ce sont les listeners du context eux-même qui +sont prévenus du changement. Implantation ============ -Les DAO sont responsable de l'appel des methodes fire sur le context qui les -a créer lors de l'appel sur ceux-ci des methodes create, update, delete, find +Les DAO sont responsables de l'appel des méthodes fire sur le context qui les +a créés lors de l'appel sur ceux-ci des methodes create, update, delete, find (pour le chargement). Le cas Hibernate ---------------- -Dans le DAO hibernate le context est listener des différents evenements levés -par la session. Mais ces evenements ne sont levé que lors du commit. Dans Topia -on souhaite avoir directement un evenement lors d'un create, update ou delete -sur le DAO. Le DAO hibernate leve donc des evenements lorsque l'on appelle -ces methodes. +Dans le DAO hibernate le context est listener des différents évènements levés +par la session. Mais ces évènements ne sont levés que lors du commit. Dans Topia +on souhaite avoir directement un évènement lors d'un create, update ou delete +sur le DAO. Le DAO hibernate lève donc des évènements lorsque l'on appelle +ces méthodes. -On a aussi des evenements lors du commit, il est donc possible qu'on est le -par exemple le meme evenement Update deux fois envoyé au listener si on fait +On a aussi des évènements lors du commit. Il est donc possible qu'on aie, +par exemple, le même évènement Update envoyé deux fois au listener si on fait un update sur le DAO suivi du commit sur le context. -On conserve tout de meme le mecanisme d'evenement leve au moment du commit par -hibernate car il est beaucoup plus puissant, il permet d'etre prevenu aussi de -modification apporté au constituant d'une entite et non pas seulement des -evenement portant sur l'entite elle meme comme dans le mecanisme implante dans -les DAO. +On conserve tout de meme le mécanisme d'évènement levé au moment du commit par +hibernate car il est beaucoup plus puissant. Il permet aussi d'être prévenu de +modifications apportées aux constituants d'une entité et non pas seulement des +évènements portants sur l'entité elle-même comme c'est le cas dans le mecanisme +implanté dans les DAO. Modified: topia/trunk/topia-persistence/src/site/fr/rst/howto.rst =================================================================== --- topia/trunk/topia-persistence/src/site/fr/rst/howto.rst 2009-02-12 14:00:23 UTC (rev 1368) +++ topia/trunk/topia-persistence/src/site/fr/rst/howto.rst 2009-02-12 15:00:55 UTC (rev 1369) @@ -2,7 +2,7 @@ ====== Ce document a pour objectif de prendre en main le framework Topia. Le document -est constitué de 4 parties, la modèlisation, la génération, la configuration et +est constitué de 4 parties, la modélisation, la génération, la configuration et l'utilisation. Modélisation @@ -12,12 +12,12 @@ (http://argouml.tigris.org) soit avec Poséidon (http://www.gentleware.com). Le stérotype «entity» sur les classes permet de préciser que la classe est -persistée par Topia. D'autre stérotypes (extern, service, ...) sont disponiples +persistée par Topia. D'autre stérotypes (extern, service, ...) sont disponibles mais ne sont pas présentés. -Le fichier de modélisation peut être compléter par un fichier de configuration +Le fichier de modélisation peut être complété par un fichier de configuration nommé <nom fichier modélisation>.properties. Il contient des informations -techniques propres au librairie utilisé par Topia. +techniques propres aux librairies utilisé par Topia. Exemple : @@ -97,7 +97,7 @@ <scope>compile</scope> </dependency> -Pour une classe modélisé, nous retrouvons 6 fichiers : +Pour une classe modélisée, nous retrouvons 6 fichiers : * Une interface * Une classe abstraite * Une implantation @@ -123,7 +123,7 @@ # [true | false] hibernate.show_sql=false -# Permet de préciser les classes à persister +# Permet de préciser les classes a persister topia.persistence.classes=org.codelutin.Person, org.codelutin.Pet # Informations de connection : @@ -149,7 +149,7 @@ Implantation des méthodes ~~~~~~~~~~~~~~~~~~~~~~~~~ -Si des méthodes ont été définis dans le modèle de données il faut créer +Si des méthodes ont été définies dans le modèle de données, il faut créer l'implantation correspondante. Le paquetage doit porter le même nom que celui de la génération. @@ -199,7 +199,7 @@
Person person = personDAO.findByTopiaId(id);
-Les méthodes find permettent de récupérer une ou plusieurs selon différents +Les méthodes find permettent de récupérer une ou plusieures entités selon différents critères.
person.setName("tutu");
Modified: topia/trunk/topia-persistence/src/site/fr/rst/project.rst =================================================================== --- topia/trunk/topia-persistence/src/site/fr/rst/project.rst 2009-02-12 14:00:23 UTC (rev 1368) +++ topia/trunk/topia-persistence/src/site/fr/rst/project.rst 2009-02-12 15:00:55 UTC (rev 1369) @@ -1,5 +1,5 @@ -List de projet similaire ou se rapprochant -========================================== +Liste de projets similaires ou se rapprochant +============================================= subPersistence -------------- @@ -9,4 +9,4 @@ :url: http://subpersistence.sourceforge.net/ Librairie d'abstraction de libraire de mapping O/R -Supporte Hibernate pour l'instant semble vouloir supporter aussi Castor +Supporte Hibernate pour l'instant. Semble vouloir supporter aussi Castor. Modified: topia/trunk/topia-persistence/src/site/fr/rst/security.rst =================================================================== --- topia/trunk/topia-persistence/src/site/fr/rst/security.rst 2009-02-12 14:00:23 UTC (rev 1368) +++ topia/trunk/topia-persistence/src/site/fr/rst/security.rst 2009-02-12 15:00:55 UTC (rev 1369) @@ -1,24 +1,24 @@ -Implantation de la securite +Implantation de la sécurité =========================== -La securite est une simple objet java qui herite de TopiaHelper +La sécurité est un simple objet java qui hérite de TopiaHelper -Il se met alors listener sur tous les events vetoables et leve des exceptions -si la personne qui essai de charger/creer/modifier/supprimer l'objet n'en a pas +Il se met alors listener sur tous les events vetoables et lève des exceptions +si la personne qui essaie de charger/créer/modifier/supprimer l'objet n'en a pas le droit. -Le service de securite vient avec son fichier de configuration. Dans ce fichier -il y a les parametres utile au service pour retrouver les informations sur les +Le service de sécurité vient avec son fichier de configuration. Dans ce fichier +il y a les paramètres utiles au service pour retrouver les informations sur les droits. -TopiaHelper est en fait une interface qui contient la methode +TopiaHelper est en fait une interface qui contient la méthode init(TopiaContext, Properties) package ------- -:org.codelutin.topia.security: pour tout ce qui touche a la securite +:org.codelutin.topia.security: pour tout ce qui touche a la sécurité (TopiaAuthenticationHelper, TopiaAuthorisationHelper, LoginModule, Filter, ...) -:org.codelutin.topia.security.entities: pour les entities utiles a la definition - de la securite (user, group, permission) +:org.codelutin.topia.security.entities: pour les entities utiles à la définition + de la sécurité (user, group, permission)