Bonjour,
Je n'ai pas réussi à comprendre avec la doc de « Champs Extra 2 » si on peut l'utiliser sur d'autres tables que celles des objets éditoriaux de base de SPIP.
« Auteurs complets » s'appuie par exemple sur les auteurs qui existent déjà.
-Nicolas
--
Nicolas HOIZEY
Blog : http://www.gasteroprod.com/
Photos : http://flic.kr/nicolas-hoizey/
Le 21/08/2009 12:26, Nicolas Hoizey a écrit :
Bonjour,
Je n'ai pas réussi à comprendre avec la doc de « Champs Extra 2 » si on
peut l'utiliser sur d'autres tables que celles des objets éditoriaux de
base de SPIP.
Il fonctionne avec Tickets et Agenda aussi (il faut déclarer l'utilisation possible via le pipeline «objets_extensibles» de champs extras). Cependant il y a des contraintes fortes :
- formulaire l'édition en CVT (formulaires/editer_XX) avec un commentaire <--extra--> dans le HTML
- utilisation des fonctions génériques des objets du core (qui font passer le code dans les bons pipelines) tel que formulaires_editer_objet_charger(), formulaires_editer_objet_verifier() et formulaires_editer_objet_traiter().
--
MM.
Le 21/08/2009 14:50, Matthieu Marcillaud a écrit :
- formulaire l'édition en CVT (formulaires/editer_XX) avec un
commentaire <--extra--> dans le HTML
Le premier point, je comprends car sinon tu ne sais pas où coller tes nouveaux champs.
- utilisation des fonctions génériques des objets du core (qui font
passer le code dans les bons pipelines) tel que
formulaires_editer_objet_charger(), formulaires_editer_objet_verifier()
et formulaires_editer_objet_traiter().
Mais le deuxième, je ne comprends pas : ça ne peut pas être fait directement avec les pipelines de CVT (il y en a un pour chaque fonction) ?
--
RastaPopoulos
Le 21 août 09 à 14:50, Matthieu Marcillaud a écrit :
Le 21/08/2009 12:26, Nicolas Hoizey a écrit :
Bonjour,
Je n'ai pas réussi à comprendre avec la doc de « Champs Extra 2 » si on
peut l'utiliser sur d'autres tables que celles des objets éditoriaux de
base de SPIP.Il fonctionne avec Tickets et Agenda aussi
Ah super, je vais pouvoir regarder.
(il faut déclarer l'utilisation possible via le pipeline «objets_extensibles» de champs extras).
OK.
Cependant il y a des contraintes fortes :
- formulaire l'édition en CVT (formulaires/editer_XX) avec un commentaire <--extra--> dans le HTML
Ca c'est bon.
- utilisation des fonctions génériques des objets du core (qui font passer le code dans les bons pipelines) tel que formulaires_editer_objet_charger(), formulaires_editer_objet_verifier() et formulaires_editer_objet_traiter().
Je vais regarder, je ne me souviens pas avoir utilisé ces fonctions lors de la migration en pur SPIP 2 de CleverMail...
-Nicolas
--
Nicolas HOIZEY
Blog : http://www.gasteroprod.com/
Photos : http://flic.kr/nicolas-hoizey/
Le 21/08/2009 14:56, RastaPopoulos a écrit :
Le 21/08/2009 14:50, Matthieu Marcillaud a écrit :
- utilisation des fonctions génériques des objets du core (qui font
passer le code dans les bons pipelines) tel que
formulaires_editer_objet_charger(), formulaires_editer_objet_verifier()
et formulaires_editer_objet_traiter().Mais le deuxième, je ne comprends pas : ça ne peut pas être fait
directement avec les pipelines de CVT (il y en a un pour chaque fonction) ?
La raison principale est que par souci d'économie je n'aime pas multiplier les requêtes : Exemple avec : formulaires_editer_objet_traiter(). Il va passer dans les fonctions de SPIP qui vont bien et sont faites pour ça (_insert, _revision, _modifier) qui appellent les bons pipelines dans l'ordre qui va bien (pre|post_insertion (en 2.1), pre|post_edition).
Il y a alors une seule requete d'update d'effectuée, une seule révision, les traitements md5 sont pris en compte par SPIP => c'est générique, ça ne demande pas d'entretien, c'est SPIP qui gère.
Si on passe par les pipelines CVT pour les traitements, tu te contrains à dupliquer du code, des requêtes et multiplier les révisions par 2 aussi pour chaque modification.
--
MM.