propel behaviors
Tristan Rivoallan
petit mail informatif :
en jetant un oeil à
http://www.symfony-project.com/trac/wiki/SymfonyPlugins, j'ai repéré
ceci
http://www.symfony-project.com/trac/wiki/sfPropelParanoidBehaviorPlugin.
c'est un plugin pour symfony qui permet d'ajouter un "comportement" à
Propel. En l'occurence. à l'appel de ->delete() sur une instance de
model, il mettra à jour la colonne "delete_at" de l'objet au lieu de
l'effacer. Un deuxième appel effacera effectivement l'objet.
on peut difficilement rêver plus simple pour implémenter une corbeille...
en outre le mécanisme d'ajout de comportement ouvre la porte à plein de
développements intéressants.
++
tristan
--
Tristan RIVOALLAN http://www.clever-age.com
Clever Age - conseil en architecture technique
GSM: +33 6 219 219 33 Tél: +33 1 53 34 66 10
Clever Age vous invite à ses petits-déjeuners
http://www.clever-age.com/actualites/petits-dejeuners/
Fabien POTENCIER
implémente le pattern optimistic lock pour Propel... A mon avis très
utile également.
Fabien
Tristan Rivoallan
> Et tu peux également regarder le sfPropelOptimisticLockPlugin qui
> implémente le pattern optimistic lock pour Propel... A mon avis très
> utile également.
>
je viens de voir ça. Vous êtes en train de développer un CMS ? ;)
à propos des behaviors : c'est une fonctionnalité propre à Symfony ou à
Propel ?
enfin : as-tu une idée (approximative) de la date de sortie de Propel
1.3. Je n'arrive pas à obtenir d'infos à ce sujet :S
Fabien POTENCIER
Les behaviors sont une fonctionnalité propre à symfony...
Pas d'info sur Propel 1.3 mais a priori on ne l'intégrera pas car elle
n'est pas BC (à cause de PDO). Je pense qu'on passera directement à
Doctrine... en gardant Propel en plugin bien sûr ;-)
Fabien
Tristan Rivoallan
> Salut Tristan,
>
> Les behaviors sont une fonctionnalité propre à symfony...
>
> Pas d'info sur Propel 1.3 mais a priori on ne l'intégrera pas car elle
> n'est pas BC (à cause de PDO). Je pense qu'on passera directement à
> Doctrine... en gardant Propel en plugin bien sûr ;-)
>
j'ai quelques questions à ce sujet (et un billet sur le blog de clever
age en préparation ;)
* est-ce que ce que tu dis signifie que Symfony arrête de supporter
officiellement Propel ?
j'ai quelques inquiétudes à propos de Doctrine :
* intégration à Symfony pas aussi complète que celle de Propel (admin
generator, i18n, behaviors, etc ;)
* le projet est développé par un *unique* étudiant. ce n'est pas
franchement un gage de pérennité. Ce sont les développeurs de Symfony
qui maintiendront la solution si le mainteneur se désiste avant qu'une
communauté n'existe ?
pour moi le seul problème de Propel ce sont les performances et la 1.3
basée sur pdo devrait le résoudre.
Fabien POTENCIER
Je dis simplement que symfony 1.0 sera basé sur la 1.2 pour est BC.
Qu'après, je souhaite que symfony soir au maximum indépendant de l'ORM
choisi et que Doctrine est une bonne alternative. Je suis en contact
régulier avec le dév principal de Doctrine.
Pour le moment, il est de toute façon clair que Doctrine et le plugin
Doctrine ne sont pas assez mature.
Propel 1.3 sera la première version qui sera installable par le système
de plugin dans symfony. Donc a priori pas d'intégration dans le core de
symfony.
Fabien
Tristan Rivoallan
> Non, symfony continue à supporter Propel. Pas de problème de ce côté là.
> Je dis simplement que symfony 1.0 sera basé sur la 1.2 pour est BC.
>
> Qu'après, je souhaite que symfony soir au maximum indépendant de l'ORM
> choisi et que Doctrine est une bonne alternative. Je suis en contact
> régulier avec le dév principal de Doctrine.
>
> Pour le moment, il est de toute façon clair que Doctrine et le plugin
> Doctrine ne sont pas assez mature.
>
> Propel 1.3 sera la première version qui sera installable par le système
> de plugin dans symfony. Donc a priori pas d'intégration dans le core de
> symfony.
>
merci pour tes réponses, me voilà rassuré.
je peux donc continuer à développer allègrement mes plugins avec Propel...
chtito
- l'intégration à symfony est *complète* à part quelques poins
signalé sur le wiki de sfDoctrine : les doubles listes et
l'importation de donnée (fixtures). Je ne sais pas pourquoi tout le
monde croit que l'admin generator ne marche pas alors que c'est le
premier truc qui a fonctionné.
- je ne suis pas étudiant, je ne suis pas non plus informaticien de
profession, je suis mathématicien
- si je suis le seul à travailler sur sfDoctrine c'est parce que cette
intégration n'était pas très difficile à réaliser
- sfDoctrine est évidemment open-source donc Fabien n'aura aucun mal
à poursuivre le développement si je m'arrête
- deux ou trois personnes m'ont aidé pour le développement (Pavel
Kunc, pookey, Bruce Edward).
Une opinion personnelle sur propel et doctrine : propel était la
meilleure solution quand symfony a démarré, mais propel est
désormais techniquement dépassé par doctrine.
La preuve en est que des additions comme i18n (ou bien même les
behaviours j'imagine) sont triviales à réaliser avec sfDoctrine.
D'autre part les fichiers générés ont environ une vingtaine de
lignes (contre des *milliers* avec propel). Support pour les relations
many2many, pour l'héritage etc. Je crois que c'est une très bonne
idée de se séparer de propel. À mon avis sfDoctrine est même VITAL
pour l'avenir de symfony. Ça c'est un gage de pérennité.
Enfin, même si sfDoctrine, je le répète, permet une intégration
complète de doctrine et symfony, sfDoctrine manque en effet de la
maturité nécessaire pour faire partie de symfony pour la version 1.0
en tout cas.
**Très important** : pour avoir des informations de premières main
sur sfDoctrine, le mieux est de me poser directement des questions sur
le forum de symfony ou bien par email.
Fabien POTENCIER
Fabien
Tristan Rivoallan
> Quelques précisions sur sfDoctrine:
>
> - l'intégration à symfony est *complète* à part quelques poins
> signalé sur le wiki de sfDoctrine : les doubles listes et
> l'importation de donnée (fixtures). Je ne sais pas pourquoi tout le
> monde croit que l'admin generator ne marche pas alors que c'est le
> premier truc qui a fonctionné.
>
ce n'est pas l'admin generator qui m'inquiète, mais l'i18n automatique,
les behaviors, etc
> - je ne suis pas étudiant, je ne suis pas non plus informaticien de
> profession, je suis mathématicien
> - si je suis le seul à travailler sur sfDoctrine c'est parce que cette
> intégration n'était pas très difficile à réaliser
>
je ne parlais pas du plugin sfDoctrine (là pas d'inquiétude), mais de la
maintenance de Doctrine : http://www.phpdoctrine.com/about.php
> - sfDoctrine est évidemment open-source donc Fabien n'aura aucun mal
> à poursuivre le développement si je m'arrête
>
ce n'est pas un bon argument à mes yeux. Un logiciel open source sans
communauté n'est pas beacoup plus intéressant un logiciel propriétaire
en ce qui me concerne.
> Une opinion personnelle sur propel et doctrine : propel était la
> meilleure solution quand symfony a démarré, mais propel est
> désormais techniquement dépassé par doctrine.
>
je suis d'accord. Mais Propel évolue et à une communauté (encore
limitée, mais c'est toujours mieux que rien).
Je ne compare pas les solutions en termes de performances / qualité
technique pure (là je ne doute pas que doctrine soit plus intéressant),
mais en termes de pérennité. Celle de Propel *commence* à être assurée,
celle de Doctrine ne l'est pas du tout.
> La preuve en est que des additions comme i18n (ou bien même les
> behaviours j'imagine) sont triviales à réaliser avec sfDoctrine.
> D'autre part les fichiers générés ont environ une vingtaine de
> lignes (contre des *milliers* avec propel). Support pour les relations
> many2many, pour l'héritage etc. Je crois que c'est une très bonne
> idée de se séparer de propel. À mon avis sfDoctrine est même VITAL
> pour l'avenir de symfony. Ça c'est un gage de pérennité.
>
pour moi ce qui est VITAL c'est l'extraction de l'ORM du coeur de
Symfony. Après pour ce qui est de la solution à utiliser j'attends de
voir. Mais je pense que ce serait une très mauvaise idée d'abandonner
Propel (ce qui ne va pas arriver d'après Fabien).
> Enfin, même si sfDoctrine, je le répète, permet une intégration
> complète de doctrine et symfony, sfDoctrine manque en effet de la
> maturité nécessaire pour faire partie de symfony pour la version 1.0
> en tout cas.
>
qu'on soit bien d'accord : je suis très impatient de pouvoir utiliser
Doctrine qui semble techniquement supérieur et je vois tous les jours le
travail que tu fournis pour l'intégration du plugin. Mais je ne
l'utiliserai pas pour le moment dans le cadre de développements
professionnels car je n'ai aucune garantie pour le futur de la solution
(doctrine, pas le plugin).
je me contenterai de l'utiliser sur des projets personnels en attendant ;)
chtito
php. Ces fichiers n'excédant pas la vingtaine de lignes, on peut aussi
les écrire à la main, comme le suggèrent les docs de doctrine.
> ce n'est pas l'admin generator qui m'inquiète, mais l'i18n automatique,
> les behaviors, etc
Aucune inquiétude à ce sujet. L'i18n fonctionne à 100%. Les
behaviours sont totalement triviaux à implémenter avec doctrine (ça
s'appelle Event Listener). Nul besoin de plugin externe. En général,
doctrine est plus facile à personnaliser.
As-tu d'autres sujets d'inquiétude, que je puisse te rassurer ? ;-)
> je suis d'accord. Mais Propel évolue et à une communauté (encore
> limitée, mais c'est toujours mieux que rien).
> Je ne compare pas les solutions en termes de performances / qualité
> technique pure (là je ne doute pas que doctrine soit plus intéressant),
> mais en termes de pérennité. Celle de Propel *commence* à être assurée,
> celle de Doctrine ne l'est pas du tout.
C'est une question d'opinion... Personnellement je ne crois pas du tout
que l'avenir de propel soit assuré. Je crois que les devs de propel
n'ont pas très bien compris ce qu'un ORM devrait être... :-P
> pour moi ce qui est VITAL c'est l'extraction de l'ORM du coeur de
> Symfony.
J'ai moi même réalisé cette extraction vitale. :-) Symfony ne
dépend plus de propel. C'est pour cette raison qu'on peut utiliser
doctrine avec symfony. L'ajout d'autres ORM ne devrait pas être
difficile non plus.
> > Enfin, même si sfDoctrine, je le répète, permet une intégration
> > complète de doctrine et symfony, sfDoctrine manque en effet de la
> > maturité nécessaire pour faire partie de symfony pour la version 1.0
> > en tout cas.
> qu'on soit bien d'accord : je suis très impatient de pouvoir utiliser
> Doctrine qui semble techniquement supérieur et je vois tous les jours le
> travail que tu fournis pour l'intégration du plugin. Mais je ne
> l'utiliserai pas pour le moment dans le cadre de développements
> professionnels car je n'ai aucune garantie pour le futur de la solution
> (doctrine, pas le plugin).
>
> je me contenterai de l'utiliser sur des projets personnels en attendant ;)
>
Ta prudence t'honore. Disons que sfDoctrine est encore en version
alpha : pas question en effet de l'utiliser dans des projets
professionnels pour l'instant.
Tristan Rivoallan
chtito a écrit :
> @Fabien: les fichiers générés sont des descriptions des classes en
> php. Ces fichiers n'excédant pas la vingtaine de lignes, on peut aussi
> les écrire à la main, comme le suggèrent les docs de doctrine.
>
>
>> ce n'est pas l'admin generator qui m'inquiète, mais l'i18n automatique,
>> les behaviors, etc
>>
>
> Aucune inquiétude à ce sujet. L'i18n fonctionne à 100%.
comment cela fonctionne-t-il ? (un lien vers un bout de doc / code peut
faire l'affaire :)
> Les
> behaviours sont totalement triviaux à implémenter avec doctrine (ça
> s'appelle Event Listener).
en effet c'est joliment fait :
http://www.phpdoctrine.com/documentation.php?index=2.8#2.8.3
> As-tu d'autres sujets d'inquiétude, que je puisse te rassurer ? ;-)
>
merci pour toutes ces réponses.
> C'est une question d'opinion... Personnellement je ne crois pas du tout
> que l'avenir de propel soit assuré. Je crois que les devs de propel
> n'ont pas très bien compris ce qu'un ORM devrait être... :-P
>
trop gros, passera pas :P
chtito
> > Aucune inquiétude à ce sujet. L'i18n fonctionne à 100%.
> comment cela fonctionne-t-il ? (un lien vers un bout de doc / code peut
> faire l'affaire :)
Ça fonctionne exactement comme dans symfony. Il y a un exemple sur le
wiki de sfDoctrine
(http://www.symfony-project.com/trac/wiki/sfDoctrine#Usageexamples).
Si tu veux générer les classes à la main avec doctrine il suffit
d'ajouter la déclaration:
$this->hasI18nTable('TableI18n', 'culture');
dans la fonction setUp, où "TableI18n" est la table qui contient les
traductions, et "culture" est le champ utilisé pour déterminer la
langue.
Si tu génères les tables automatiquement alors les champs nécessaire
(culture, id, etc.) sont déclarés automatiquement. J'ai un
utilisateur qui utilise sfDoctrine et i18n avec succès, semble-t-il.
> > C'est une question d'opinion... Personnellement je ne crois pas du tout
> > que l'avenir de propel soit assuré. Je crois que les devs de propel
> > n'ont pas très bien compris ce qu'un ORM devrait être... :-P
>trop gros, passera pas :P
Mon affirmation provocante manque surtout d'argument. Je les donnerai
en détail sur une page wiki de symfony qui explique pourquoi et
comment passer de propel à doctrine sans douleur.
Tristan Rivoallan
> Et tu peux également regarder le sfPropelOptimisticLockPlugin qui
> implémente le pattern optimistic lock pour Propel... A mon avis très
> utile également.
>
oui je viens de voir ça. Vous êtes en train de développer un CMS ? ;)
en ce qui concerne les behaviors : c'est une feature propre à symfony ou
à propel ?
et enfin : as-tu une idée (approximative) de la date de sortie de propel
1.3. Je n'arrive pas à obtenir d'infos à propos de l'avancement des devs :S