Discussion :

[Maerlyn31]

Bonjour,

Je cherche des renseignements sur les limites du système de behaviors de Doctrine, et bien qu'il existe quantité de tutos sur la création de templates "basiques" (des templates "publishable", en veux-tu en voilà ^^), je ne trouve que peu d'information sur des templates plus évolués ...

Imaginons que je veuille créer un template "Categorizable", permettant de lier un objet à une catégorie. Fonctionnellement, chaque objet d'un modèle "categorizable" doit pouvoir être rattaché à une catégorie, mais uniquement à une catégorie liée à son modèle propre.
Exemple :
- des news peuvent être rattachés à une catégorie "évenement" ou "conférence"
- des produits peuvent être rattachés à une catégorie "informatique" ou "électro-ménager"
- une news ne doit surtout pas appartenir à la catégorie "informatique", sinon c'est le drame !

Je vois pour l'instant deux genre d'implémentation possible, c'est sur la deuxième que je cherche des renseignements :

1 - Créer tout d'abord une table "Categorie", qui contiendra un champ "origin". Ainsi par exemple mon objet news ne pourrait être rattaché qu'aux catégories présentant un attribut "origin = news".
Dans ce cas là, le template est tout simple et ne créé qu'une relation vers la table catégorie et quelques méthodes. Le problème est que sémantiquement, une grosse table "catégorie" regroupant toutes les catégories de tous les modèles, ça m'a pas l'air très propre.


2 - Chaque modèle "categorizable" possède sa propre table MONDELE_categorie.
Dans ce cas de figure, le template doit alors :
- gérer la création de la table MODELE_categorie
- ajotuer un champ id_categorie à la table MODELE
- ajouter les méthodes qui vont bien

Je ne sais pas si l'exemple est très parlant (très bizarrement, dans ma tête ça avait l'air mieux :p) mais la question est cependant simple : un template Doctrine peut-il créer une nouvelle table, et si oui comment ?
A priori je pense que oui, le behaviour i18n le fait, mais la lecture du code de ce dernier ne m'a absolument pas éclairé ...

Merci d'avance !

[Michel Rotta]

Certains behavior le peuvent (il n'y a pas de template dans doctrine). Ils ont été écrits pour. Il est possible d'ajouter des behavior personnalisés, mais c'est un truc un peu compliqué...

Pour ton schéma, cela va dépendre avant tout du MLD. S'il est logique qu'ils partagent la même table, tu seras dans le cas 1 et tu vas gérer l'attribution dans ton code. S'il est logique qu'ils soient dans deux tables indépendantes, tu sera dans le cas 2 et tu auras deux CRUD à gérer...

[Maerlyn31]

Pour reprendre un peu la chronologie qui m'amène à ces question, je travaille sur un projet de surcouche à l'admin generator, qui permettrait de générer "en live" certains modèles "basiques", ainsi que leur admin dédiée.

Pour l'instant je suis encore sur de la pré-(pré pré pré)-conception, et je glane des infos de faisabilité au fur et à mesure : j'ai pas mal avancé avec les tâches personnalisées, les thèmes de l'admin generator, les listeners, et pas mal de détails, mais il me manque des infos sur ces foutus behaviors ...

Or, c'est un point central, puisque le périmètre de mon "générateur live" (jusqu'à quel point un modèle reste-t-il "basique" ?) est directement lié aux limites des behaviors.

Je fouille dans les entrailles de Symfony, j'arrive à comprendre les behaviors "sluggable" ou "timestampable" qui ne gèrent que des colonnes en plus, mais les behaviors "versionable" et "i18n" qui effectivement gèrent des création de tables sont beaucoup plus subtils, avec des instanciations de plugin, extendant eux même des Doctrine_Record .... et là c'est (encore !) le drame !

Je vais poursuivre ma session lego-killer avec Doctrine, affaire à suivre !

[Michel Rotta]

Regarde du côté des plugins, qui seront peut-être plus adaptés. De plus, il est possible de construire un plugin qui génère le code des modules auto-généré, permettant d'aller très loin dans la personnalisation.

Le travail avec les behavior ce passe essentiellement par des listner au niveau de doctrine. A priori ils ressemblent à ceux de symfony, mais je n'en ai jamais démonté un.