August 2010 - Wikitty-devel - mailman.cloud.codelutin.com

Comment hériter d'une classe non-décrite dans le modèle
by Brendan Le Ny 20 Sep '10

20 Sep '10

Je suis en train de travailler sur le support de l'héritage multiple dans Wikitty et j'ai un problème. Pour gérer l'héritage multiple entre deux business entity, je dois, pour une entité donnée, prendre toutes les opérations des entités mères pour les copier dans la fille. Jusqu'ici tout va bien, ça marche. Le problème survient dans le modèle de Vradi, il y a des entités qui héritent de TreeNode et de WikittyUser, deux classes que je ne génère pas et qui ne sont pas décrites dans le modèle de Vradi. Si je prend l'exemple de VradiUser (qui étend WikittyUser), je dois copier les opérations contenus dans WikittyUser dans VradiUser. Or, dans les scripts de génération je ne peux pas deviner les opérations de WikittyUser puisque elles ne sont pas décrites dans le modèle. Avant, avec les générateurs, on faisait "VradiUser extends WikittyUser" et ça marche mais du coup on ne peut pas faire d'héritage multiple si on hérite de plusieurs entités non-décrites dans le modèle. Comment faire pour implémenter l'héritage depuis une entité qui n'est pas décrite dans le modèle ? Y'a toujours la possibilité d'essayer de trouver la classe dans le class-path et de faire de la réflexion mais ça pose plusieurs problèmes. J'ajoute que dans le module generators, je n'ai pas la dépendance vers wikitty-API (où se trouve les classes WikittyUser et TreeNode) et je ne peux pas ajouter cette dépendance car on la dépendance inverse (du coup, on introduirait un cycle.

3 3

Branche pour migration sur les transformers d'EUGene
by fdesbois 21 Aug '10

21 Aug '10

Bonjour à tous, Quelques petits retours sur les transformers créés dans la branche : Sur ToPIA plutot que de décomposer les 3 parties d'une entité en trois transformeurs (Interface, Abstract, Impl), il nous a paru plus judicieux de fusionner les 3 dans un seul transformeur pour plus fortement couplé la génération, les méthodes sont les mêmes, des imports communs, ... Ici, rajouter une méthode impliquera un copier coller dans les 3 transformeurs... C'est sur que cela rajoute du contenu dans un seul transformeur mais cela me semble plus maintenable. Autre remarque, au sujet des imports, une bonne partie est automatisé au moment des appels au JavaBuilder en utilisant les fqn (full qualified name), seul les contenus des body ou valeur d'attribut statique doivent obligatoirement être importé à côté. Bon ce n'est juste une remarque, d'avoir tout les imports à un seul endroit reste assez visuel. Pour le coup du MétaTransformer, l'idée sur la liste EUGene me semble intéressante, d'ailleurs je vais aussi y répondre. Voilà, c'était des petites remarques en passant -- Florian Desbois <fdesbois(a)codelutin.com> SSLL Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 Réseau Libre-Entreprise

2 2

Specs de sécurité et de localisation wikitty
by Jean Couteau 09 Aug '10

09 Aug '10

Suite à une réflexion sur la sécurité et la localisation de wikitty, voici ce qui avait été prévu (ça fait un peu de temps que c'est sur le svn, mais mieux vaut tard que jamais). (Extrait de : http://svn.nuiton.org/svn/wikitty/trunk/src/site/rst/Spec.rst) Gestion des droits ================== Utilisateurs et groupes ----------------------- Les utilisateurs ont un nom et un mot de passe, les groupes contiennent des utilisateurs (d'autres groupes ?) Par dÃ©faut il existe un *WikittyGroup* portant le nom **WikittyAppAdmin**. Si ce groupe n'existe pas ou qu'il est vide, cela indique que tous les utilisateurs sont AppAdmin. Cela est nÃ©cessaire pour deux choses: - pour permettre d'avoir une authentification, mais que l'on ne souhaite pas de gestion d'autorisation. - pour servire de bootstrap au lancement de l'application seul les AppAdmin peuvent modifier le *WikittyGroup* portant le nom **WikittyAppAdmin**, or s'il est vide il faut pouvoir le remplir. Il ne doit donc exister un seul *WikittyGroup* portant le nom **WikittyAppAdmin** Tokens de sÃ©curitÃ© ------------------ Ã€ chaque login, un token de sÃ©curitÃ© est fourni Ã l'utilisateur. L'utilisateur doit fournir ce token Ã chaque opÃ©ration pour montrer qu'il a les droits. Pour un token donnÃ©, on peut savoir Ã quel utilisateur il appartient. Les tokens sont stockÃ©s en base et supprimÃ©s au logout de l'utilateur. Les SecurityToken ne sont supprimÃ©s de la base de donnÃ©es qu'au moment du logout Si les utilisateurs/applications quittent sans faire le logout le nombre de SecurityToken ne fera qu'augmenter. Pour Ã©viter cela, il faut prÃ©voir un petit job qui de temps en temps fait le mÃ©nage dans les SecurityToken trop vieux. Gestion des droits sur un Wikitty --------------------------------- Un wikitty a plusieurs extensions, pour chacune de ces extensions, on a plusieurs droits. On distinque quatre niveaux de droits : * owner (un utilisateur) donne tous les droits sur un wikitty * admin (zÃ©ro ou plusieurs utilisateurs / groupes) permet d'ajouter ou de supprimer des Ã©lÃ©ments dans writer et reader * writer (zÃ©ro ou plusieurs utilisateurs / groupes) permet, pour chacun des champs de cette extension, de modifier la valeur * reader (zÃ©ro ou plusieurs utilisateurs / groupes) permet, pour chacun des champs de cette extension, de lire la valeur Si on veut que tout le monde puisse lire un wikitty, il faut laisser vide la liste des readers (vide ou null). Si l'on souhaite indiquer que personne ne peut lire l'objet il faut mettre le owner en tant que reader. Car de toute faÃ§on l'owner aura toujours le droit en lecture. La granularitÃ© est donc au niveau des extensions. C'est Ã dire qu'avoir le droit reader de l'extension Ext permet de lire tous les champs de l'extension Ext de tous les wikitty qui ont l'extension Ext. Gestion des droits sur les extensions ------------------------------------- Pour chaque extension, on a la mÃªme hiÃ©rachie de droit qui donnent des possibilitÃ©s diffÃ©rentes : * owner : * admin : permet de changer les droits de l'extension. Donc, permet d'ajouter ou de supprimer des Ã©lÃ©ments dans writer et reader * writer : permet de modifier l'extension l'extension * reader : permet de lire l'extension pour en crÃ©er des instances. Si le reader est vide, tout le monde peut crÃ©er. Pour que seuls les AppAdmin et le owner puissent crÃ©er des instances, il faut mettre le owner en reader. Si une extension ne dispose pas de ces informations, seuls les AppAdmin peuvent crÃ©er les instances et modifier l'extension. Comment ces droits sont stockÃ©s ------------------------------- Pour chaque extension connue, il y aura donc un wikitty dont le seule extension sera WikittySecurity. Chacun de ces wikitty aura pour identifiant Â« WikittySecurity'ExtensionName' Â». Pour stoker les droits qui portent sur les extensions, on fait appel Ã des **meta-extensions**. Une Pseudo extension est portÃ©e par les extensions du wikitty. Exemple avec WikittySecurity sur un Wikitty Personne qui a une extension Employee et Customer. Il y a une extension Employee:WikittySecurity et une extension Customer:WikittySecurity. le sÃ©parateur de pseudo-extension = ':' comme css Localisation ============ On rajoute une pseudo extension WikittyI18n aux extensions du wikitty. Cette pseudo-extension a deux champs : langue et translation personne:wikittyI18n.langue=fr,en,es personne:wikittyI18n.translation=[fr:name=prÃ©nom,surname=nom],[en:name=name,surname=surname] personne.name=value ton extension : security dezs champs de sÃ©curitÃ© ton extension : i18n des champs i18n ton extension.champs=valeur dans la langue un wikitty ne peut exister que dans une langue Ã la fois, si tu veux plusieurs langues, tu charges plusieurs fois le wikitty. du coup ton wikitty a une version et une langue. On stocke dans la dÃ©finition de l'extension chargÃ©e la langue dans laquelle elle a Ã©tÃ© chargÃ©e. si pas de i18n, du coup c'est la langue par dÃ©faut Ã chaque fois. Au moins les writers peuvent crÃ©er une nouvelle langue. pas de sÃ©curitÃ© par langue, trop le bordel ! il serait agrÃ©able que seules les extensions demandÃ©es soient chargÃ©es. dans les restore il faut ajouter (extensions, id, + prÃ©chargement d'extensions) attention au moment de la migration au moment du chargement Pseudo extension ================ migration : mÃ©thode migrate(oldExtension, newExtension, Wikitty, Locale) Locale pouvant etre null.

1 0

Maintien des modules non-utilisés ?
by Brendan Le Ny 06 Aug '10

06 Aug '10

Certains modules de wikitty sont inutilisés et donc ignorés dans le build par défaut : <module>wikitty-hbase-impl</module> <module>wikitty-jpa-impl</module> <module>wikitty-jms-impl</module> <module>wikitty-multistorage-impl</module> De toute façon, ces modules ne build pas à cause de problèmes de dépendances non résolues. Le build Hudson, quant à lui, essaie de builder tous les modules, et donc le build casse à chaque fois. Je suis en train de faire de gros refactoring sur wikitty et y'a des impacts un peu partout. Du coup, je fait des mvn test avant de commiter mais niveau intégration continue, j'suis à l'aveuglette : comme avec Diswork... Donc faudrait décider - soit les modules doivent être maintenus, dans ce cas il faut régler les problèmes de dépendances pour Hudson et pour les devs de wikitty (moi en ce moment) - soit on décide de ne plus les maintenir, dans ce cas il faut que Hudson n'essaie pas de les builder, voire qu'on supprime les modules Brendan.

4 4

Modification de la generation des entites metier
by Benjamin POUSSIN 02 Aug '10

02 Aug '10

Salut, Les champs static des noms des champs des extensions ont ete renome. Donc avant de lancer une recompilation avec regeneration avec la version trunk de wikitty. Je vous suggere d'utiliser vos outils moderne pour faire du refactoring de masse. - aller dans le code genere de chaque interface des objets metier - demander a renomer le champs en utilisant celui qui sera utilise apres la nouvelle generation (votre super outil doit (sinon ce n'est pas un super outil :)) renommer partout ou il est utilise dans vos projets ouverts - modifier dans le pom.xml pour utiliser la nouvelle version wikitty - relancer une generation - tout devrait compiler et refonctionner normalement Voila, je pense que c'est le plus simple/sur/court. Sur ce bon week-end -- Benjamin

2 1