developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Opened 10 years ago

Last modified 8 years ago

#1075 assigned new feature

Support de Doctrine

Reported by: foxmask Owned by: foxmask
Priority: normal Milestone: Jelix 2.0.0
Component: jelix Version:
Severity: normal Keywords:
Cc: Blocked By:
Blocking: Documentation needed: no
Hosting Provider: Php version:

Description

Une possibilité d'utiliser doctrine pour jelix serait intéressante.

Par contre je ne pense pas qu'inclure doctrine dans le build soit opportun.

Mais qu'une page de doc indiquant où ajouter doctrine serait plus souple.

A cet effet j'ai un patch à proposer, tester avec jelix 1.1 et 1.2. J'ai pu généré les models dans un dossier models dédié puis l'exploiter via un

 $data = jDoctrine::get('module~Model')->findAll();

A noter que pour utiliser le patch à venir, plutot que de modifier le init.php, j'ai trouve plus simple de modifier le application.ini.php avec les infos suivantes à la fin du fichier :

spl_autoload_register(array('Doctrine', 'autoload'));
$manager = Doctrine_Manager::getInstance();
spl_autoload_register(array('Doctrine_Core', 'modelsAutoload'));
$manager->setAttribute(Doctrine_Core::ATTR_MODEL_LOADING, Doctrine_Core::MODEL_LOADING_CONSERVATIVE);

Ainsi on disposera de toute l'artillerie de Doctrine à portée de main.

Attachments (2)

ticket_1075_doctrine_support.2.diff (7.2 KB) - added by foxmask 10 years ago.
Support Doctrine ; avec un plugin coord en plus pour eviter de toucher a application.ini.php (typos fix)
ticket_1075_doctrine_support.diff (8.1 KB) - added by foxmask 10 years ago.
Support Doctrine

Download all attachments as: .zip

Change History (24)

comment:1 Changed 10 years ago by foxmask

  • review set to review?

je passe en review? histoire d'avoir au moins un feedback sur un test de ce bout de code ;)

Changed 10 years ago by foxmask

Support Doctrine ; avec un plugin coord en plus pour eviter de toucher a application.ini.php (typos fix)

comment:2 Changed 10 years ago by foxmask

le 2nd patch serait plus souple et eviterait de toucher à application.ini.php.

comment:3 Changed 10 years ago by geekbay

Plutot que de modifier init.php, on ne peut pas faire les require de jDoctrine et jSelectorDoctrine dans doctrine.coord.php ? parce que c'est vrai que ce n'est pas grand chose mais si on n'utilise pas doctrine, je ne vois pas pourquoi ils seraient requis dans init ?

comment:4 Changed 10 years ago by foxmask

Oui c'est bien le propos du dernier patch on ne touche pas aux coeur de jelix on lui rajoute un point d'entrée vers doctrine via un coord + selector + 1 class et c'est tout. Cf le dernier patch ;)

comment:5 Changed 10 years ago by laurentj

  • Component changed from jelix:core to jelix
  • Milestone Jelix 1.2 deleted
  • Owner laurentj deleted
  • review changed from review? to review-
  • pas de fichier spécifique à doctrine dans le core. dans jelix/core, uniquement les fichiers qui sont indispensables au fonctionnement du framework. Je les verrais plutôt directement dans le repertoire du plugin, tout simplement, et qui serait chargés par le plugin si activé.
  • la façon dont on utilise les informations de jDbProfils me gène. Et tu n'utilises pas le paramètre $profile. Je pense qu'il faudrait plutôt appeler jDb::getProfile() pour avoir les informations d'un profile de connection, en lui donnant le paramètre $profile.
  • essaye de remplir le fichier plugin.xml correctement (comme pour un module.xml en fait), même si pour le moment, ce n'est pas pris en charge par le système d'installation.

comment:6 follow-up: Changed 10 years ago by laurentj

Doit-on vraiment nommé le repertoire "models" ? Peut-être plutôt faire un models/doctrine ? Ou doctrine_models ?

Parce que si un jour on veut apporter le support d'un autre ORM, comme Propel ou le vaporware jOrm, ce repertoire "models" peut préter à confusion.

comment:7 Changed 10 years ago by laurentj

ou doctrineModels...

comment:8 in reply to: ↑ 6 Changed 10 years ago by foxmask

Replying to laurentj:

  • pas de fichier spécifique à doctrine dans le core. dans jelix/core, uniquement les fichiers qui sont indispensables au fonctionnement du framework. Je les verrais plutôt directement dans le repertoire du plugin, tout simplement, et qui serait chargés par le plugin si activé.

Comment ferait-on un jDoctrine::get() si tout est dans le plugin ?

  • la façon dont on utilise les informations de jDbProfils me gène. Et tu n'utilises pas le paramètre $profile. Je pense qu'il faudrait plutôt appeler jDb::getProfile() pour avoir les informations d'un profile de connection, en lui donnant le paramètre $profile.

j'évitais cette operation pour ne pas déjà provoquer une connexion à la base avec jDb mais si getProfile() n'en fait pas alors ok

  • essaye de remplir le fichier plugin.xml correctement (comme pour un module.xml en fait), même si pour le moment, ce n'est pas pris en charge par le système d'installation.

oui pas de soucis

Replying to laurentj:

Doit-on vraiment nommé le repertoire "models" ?

non rien n'est imposé du tout, Doctrine_Core::loadModels() prend en argument un path (relatif ou absolu), celui où sont localisés des models. Je dis "des" parce qu'on peut avoir des models dans differents répertoires. Cela dit je pense qu'un éclaircissement de Bastnic serait bienvenu sur le "best practice" pour cela.

comment:9 follow-up: Changed 10 years ago by laurentj

Comment ferait-on un jDoctrine::get() si tout est dans le plugin ?

Comme je l'ai dis, le plugin doit charger les classes si doctrine.activate.

j'évitais cette operation pour ne pas déjà provoquer une connexion à la base avec jDb mais si getProfile() n'en fait pas alors ok

getProfile ne fait pas de connexion.

Cela dit je pense qu'un éclaircissement de Bastnic serait bienvenu sur le "best practice" pour cela.

Si tu veux, et je sais bien qu'on peut indiquer ce qu'on veut à Doctrine. Mais je parlais d'un point de vue "design" de l'arbo dans jelix. C'est à nous de choisir où l'on veut mettre les modèles. Et il faut trouver un endroit qui ne risque pas, plus tard, de nous poser problème. Si par exemple on ajoute le support pour un jOrm, où mettra t-on les modèles de jOrm ? si on a choisi models/ pour doctrine, on va pas pouvoir utiliser un répertoire models/ pour jOrm.

Aussi peut être est-ce judicieux de faire un répertoire models/doctrine, et puis plus tard on pourra faire models/propel, models/jorm, et pourquoi pas aussi models/dao si pour la 2.0 on décide de bouger les daos.

Histoire d'avoir plus de cohérence pour tout ce qui est modèle de données quoi..

Le seul truc qui me chiffonne, c'est d'ajouter un niveau supplémentaire dans l'arborescence. À moins que cela ne gène personne finalement...

comment:10 in reply to: ↑ 9 Changed 10 years ago by foxmask

Replying to laurentj:

Comment ferait-on un jDoctrine::get() si tout est dans le plugin ?

Comme je l'ai dis, le plugin doit charger les classes si doctrine.activate.

Ok donc lib/core/jelix/jDoctrine.class.php et lib/core/jelix/selector/jSelectorDoctrine.class.php passent à lib/jelix/plugins/coord/doctrine/ et c'est dans le coord que seront fait les require_once respectifs

j'évitais cette operation pour ne pas déjà provoquer une connexion à la base avec jDb mais si getProfile() n'en fait pas alors ok

getProfile ne fait pas de connexion.

ok alors je prends ça :)

Cela dit je pense qu'un éclaircissement de Bastnic serait bienvenu sur le "best practice" pour cela.

Si tu veux, et je sais bien qu'on peut indiquer ce qu'on veut à Doctrine. Mais je parlais d'un point de vue "design" de l'arbo dans jelix. C'est à nous de choisir où l'on veut mettre les modèles. Et il faut trouver un endroit qui ne risque pas, plus tard, de nous poser problème. Si par exemple on ajoute le support pour un jOrm, où mettra t-on les modèles de jOrm ? si on a choisi models/ pour doctrine, on va pas pouvoir utiliser un répertoire models/ pour jOrm.

Aussi peut être est-ce judicieux de faire un répertoire models/doctrine, et puis plus tard on pourra faire models/propel, models/jorm, et pourquoi pas aussi models/dao si pour la 2.0 on décide de bouger les daos.

Histoire d'avoir plus de cohérence pour tout ce qui est modèle de données quoi..

tout cela me va très bien

comment:11 Changed 10 years ago by laurentj

donc lib/core/jelix/jDoctrine.class.php et lib/core/jelix/selector/jSelectorDoctrine.class.php passent à lib/jelix/plugins/coord/doctrine/ et c'est dans le coord que seront fait les require_once respectifs

oui

et ok, prenons models/doctrine/ comme répertoire.

comment:12 Changed 10 years ago by laurentj

  • Milestone set to Jelix 1.2 beta

un nouveau patch ? Ce serait bien de pouvoir mettre ça dans la beta

comment:13 Changed 10 years ago by foxmask

Je l ai prépare mais :

sous Windows j'ai un pb avec doctrine 'seul' http://www.foxmask.info/post/2010/04/01/doctrine-sur-windows-font-ils-bon-menage/

au début j'ai cru que c'était un pb d'intégration avec jelix mais en isolant doctrine et son bootstrap ça marche pas.

donc je n'ai pour l'heure aucun moyen de le valider.

Je vais essayer sur un Linux sur une virtualbox, mais je ne sais pas comment la mettre sur le même l'an que 192.168.

Enfin bref, des trucs qui menquiquinent pour rien mais sont handicapant pour aller au bout :)

comment:14 Changed 10 years ago by foxmask

  • review changed from review- to review?

et voilà https://bitbucket.org/foxmask/jelix-trunk/changeset/5aeac16bd48e/ :-)

si ca convient ; suffit de faire un hg pull depuis le depot jelix-trunk si j'ai bien compris, non ?

comment:15 follow-up: Changed 10 years ago by laurentj

  • review changed from review? to review-

le paramètre $profile n'est toujours pas pris en compte. Que ce soit dans jSelectorDoctrine que dans jDoctrine::get. regarde jSelectorDao.

De plus, tu stockes une connection doctrine dans $_doctrineSingleton[$DoctrineId?], mais si elle existe, tu ne la réutilise pas et fait un simple Doctrine_Manager::connection();. Je ne comprend pas. à quoi sert le $_doctrineSingleton ? que renvoit Doctrine_Manager::connection() exactement ? peux-t-on vraiment avoir plusieurs connections doctrine en même temps ? on ne donne pas une connection doctrine à Doctrine_Core::loadModels etc ?

comment:16 in reply to: ↑ 15 Changed 10 years ago by foxmask

Replying to laurentj:

le paramètre $profile n'est toujours pas pris en compte. Que ce soit dans jSelectorDoctrine que dans jDoctrine::get. regarde jSelectorDao.

De plus, tu stockes une connection doctrine dans $_doctrineSingleton[$DoctrineId?], mais si elle existe, tu ne la réutilise pas et fait un simple Doctrine_Manager::connection();. Je ne comprend pas. à quoi sert le $_doctrineSingleton? que renvoit Doctrine_Manager::connection() exactement ?

Ça renvoi la session courante de la base de données

peux-t-on vraiment avoir plusieurs connections doctrine en même temps ?

oui

on ne donne pas une connection doctrine à Doctrine_Core::loadModels etc ?

Non cette méthode se contente de prendre en argument le chemin vers les models dont on va de servir donc pas de liens avec ::connection()

comment:17 Changed 10 years ago by laurentj

  • Milestone changed from Jelix 1.2 beta to Jelix 1.2

Changed 10 years ago by foxmask

Support Doctrine

comment:18 Changed 10 years ago by foxmask

  • review changed from review- to review?

Alors j'ai fait quelques modif selon tes attentes tout en sachant que :

J'ai ajouté un nouveau parm au doctrine.coord.ini.php permettant à l'utilisateur de donner le nom de la connexion. Nom utilisé lors de la génération des modèles et qui se retrouve "en dur" dans les classes générées par doctrine.

Qu'en penses tu ?

comment:19 Changed 10 years ago by laurentj

  • Milestone changed from Jelix 1.2 to Jelix 1.3

Bon finalement, on va pas inclure ça dans la 1.2. Faudrait plus de temps pour bien intégrer et tester tout ça. Pas envie d'inclure un si gros morceau au dernier moment.

comment:20 Changed 9 years ago by laurentj

  • Milestone Jelix 1.3 deleted

comment:21 Changed 8 years ago by laurentj

  • Owner set to foxmask
  • review review? deleted
  • Status changed from new to reviewing

comment:22 Changed 8 years ago by laurentj

  • Milestone set to Jelix 2.0
  • Status changed from reviewing to assigned

Je propose que ce qui a été fait jusqu'à maintenant soit un projet "externe" et proposé sur booster.

Je propose que l'on étudie la possibilité d'apporter un support de doctrine "natif" plus tard, pour jelix 2

Note: See TracTickets for help on using tickets.