J'en profite pour faire la même chose. J'ai ajouté un behavior afin que les plugins puisse ajouter des colonnes dans les listes admin. Je l'ai nommé adminGenericListConstruct. Si jamais ça ne vous plait pas/voyez mieux, n'hésitez pas ;)

Si on faisait comme tu le préconises, cela veux dire que lorsque quelqu'un crée une nouvelle liste, il devra y placer son constructeur ainsi que ne pas oublier de créer son behavior. D'une, ça fait plus de code pour le dev (bon c'est une ligne je sais :P) et de deux, il peux très bien oublier de le faire et ainsi priver d'autres plugins de rajouter leurs propres colonnes. Tu vois l'idée?

Le 30 juin 2011 09:47, Dsls <dsls(a)morefnu.org&gt; a écrit : > Si on faisait comme tu le préconises, cela veux dire que lorsque > quelqu'un > > crée une nouvelle liste, il devra y placer son constructeur ainsi que ne > pas > > oublier de créer son behavior. D'une, ça fait plus de code pour le dev > (bon > > c'est une ligne je sais :P) et de deux, il peux très bien oublier de le > > faire et ainsi priver d'autres plugins de rajouter leurs propres > colonnes. > > > > Tu vois l'idée? > > Oui, mais ça ne me plaît pas... une classe générique doit rester > générique. Si elle contient des spécificités de chacun de ses > héritiers, ça casse le modèle. > > On peut faire différemment : dans ton constructeur admingeneric list, tu > fais : > > public function __construct($core,$rs,$rs_count) > { > $this->core =& $core; > $this->rs =& $rs; > $this->rs_count = $rs_count; > $this->context = get_class($this); > $this->columns = array(); > $this->form_prefix = 'col_%s'; > $this->form_trigger = 'add_filter'; > > $this->html_prev = __('&#171;prev.'); > $this->html_next = __('next&#187;'); > > $this->setColumns(); > > $core->callBehavior('adminGenericListConstruct',$this); > > $this->setColumnsVisibility(); > } > abstract protected function setColumns() {} > > et chaque classe fille surcharge alors setColumns en ajoutant ses > propres colonnes. On garde alors le behavior générique (on peut même > l'appeler plus simplement adminListConstruct), et tout baigne... > Certes, tu as raison. Je vais faire la modif :)

> Yo Bruno! > Voilà, je me rappelle pourquoi j'avais fait comme ça est c'est une super > bonne raison: la rétro compatibilité! :D > Vu que je viens de déclarer la classe adminGenericList en abstrait, tous les > plugins qui l'utilisent (comme daInstaller) doivent obligatoirement modifier > leurs codes pour ajouter la fonction abstraite setColumns() avant le > déploiement de la 2.4 sinon: BOOOOOM! > Tu vois le truc? ;) Bah. Il suffit de ne plus définir la fonction setColumns comme abstraite, et la mettre vide par défaut. Non ?

> Ouais ouais bien sur mais pour le coup, je trouve ça plus très... propre :P > Mais bon, t'inquiète, je vais faire le nécessaire ;) C'est uniquement pour la rétrocompatibilité. Le jour où on veut forcer les gens à changer, on déclare la méthode abstraite, et ce qui aura été fait dans le core marchera sans autres changements. Pour être complètement propre, il aurait fallu déclarer une classe complètement disjointe, et laisser la classe actuelle uniquement pour les plugins, en la marquant deprecated.