7:54 a.m.
Plop,
Je suis encore confronté à un défaut lié à l'ordre de chargement des
plugins et il s'avère qu'il serait intéressant d'avoir une boucle
supplémentaire, une fois celle qui appelle _prepend.php +
_admin.php/_public.php effectuée.
En effet certains traitements n'ont de sens qu'une fois tous les plugins
chargés. Par exemple les boutons qui s'invitent sur la barre d'outil d'un
éditeur ne doivent être initialisés qu'une fois que cet éditeur (lui aussi
un plugin depuis la 2.7) chargé et initialisé.
Utiliser la priorité (dans le _define.php) peut aider dans certains cas,
mais je suis en ce moment confronté à un cas où il faut, dans un plugin,
que je passe avant (définition d'une macro wiki) ET après (init d'un
bouton) un autre plugin (éditeur). Du coup ce n'est pas applicable.
Du coup une nouvelle boucle qui appellerait cette fois le _append.php (s'il
existe) de chaque plugin, construit de la même manière qu'un _prepend.php :
<?php
if (!defined('DC_RC_PATH')) { return; }
// public code
…
if (!defined('DC_CONTEXT_ADMIN')) { return false; }
// admin code
…
serait une solution.
Z'en dites les gens ?
--
Franck
8:03 a.m.
Salut Franck,
je ne comprends pas ton problème. Il faut dire à ma décharge qu'il est
encore un peu tôt !
La définition du bouton est juste un fichier javascript et la définition de
la macro c'est un bout de php. En quoi c'est lié ?
Je veux bien plus de détails.
a+
Nicolas
Le 16 janvier 2015 07:54, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
Plop,
Je suis encore confronté à un défaut lié à l'ordre de chargement des
plugins et il s'avère qu'il serait intéressant d'avoir une boucle
supplémentaire, une fois celle qui appelle _prepend.php +
_admin.php/_public.php effectuée.
En effet certains traitements n'ont de sens qu'une fois tous les plugins
chargés. Par exemple les boutons qui s'invitent sur la barre d'outil d'un
éditeur ne doivent être initialisés qu'une fois que cet éditeur (lui aussi
un plugin depuis la 2.7) chargé et initialisé.
Utiliser la priorité (dans le _define.php) peut aider dans certains cas,
mais je suis en ce moment confronté à un cas où il faut, dans un plugin,
que je passe avant (définition d'une macro wiki) ET après (init d'un
bouton) un autre plugin (éditeur). Du coup ce n'est pas applicable.
Du coup une nouvelle boucle qui appellerait cette fois le _append.php (s'il
existe) de chaque plugin, construit de la même manière qu'un _prepend.php :
<?php
if (!defined('DC_RC_PATH')) { return; }
// public code
…
if (!defined('DC_CONTEXT_ADMIN')) { return false; }
// admin code
…
serait une solution.
Z'en dites les gens ?
--
Franck
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
8:24 a.m.
Utiliser la priorité (dans le _define.php) peut aider dans certains cas,
mais je suis en ce moment confronté à un cas où il faut, dans un
plugin,
que je passe avant (définition d'une macro wiki) ET après (init d'un
bouton) un autre plugin (éditeur). Du coup ce n'est pas applicable.
Pas sûr de comprendre le problème. Il faut distinguer le moment où on
déclare l'ensemble des actions d'un behavior (via addBehavior), et le
moment ou ce behavior est appelé (via callBehavior). Il faut bien entendu
que les actions soient toutes définies avant le callbehavior().
Je pense que ton souci vient du fait que dcLegacyEditor appelle
coreInitWikiPost dans son _admin.php. Pour autant un plugin ne doit pas
être prioritaire face à dcLegacyEditorpour s'il agit sur coreInitWikiPost,
il "suffit" de faire le addBehavior dans son _prepend.php (qui et chargé
avant tout les _admin.php).
Du coup une nouvelle boucle qui appellerait cette fois le _append.php (s'il
existe) de chaque plugin, construit de la même manière qu'un
_prepend.php :
Je ne suis pas fan de l'ajout d'un fichier en plus de ce type, cela
ajouterait de la confusion pour les devs, et pas mal de cas particuliers à
gérer en plus. D'autant que je ne suis pas sûr que ça gère tous les cas.
S'il faut vraiment qu'on gère ce genre de choses, je serais plutôt partisan
de pouvoir ajouter des priorités (facultatives) au sein de addBehavior.
Voir ce ticket qui date de 7 ans et qu'olivier avait refusé :
http://dev.dotclear.org/2.0/ticket/523.
--
Bruno
8:31 a.m.
En fait après réflexion, comme dit Nicolas c'est tôt la matin, le pb que
j'ai est plutôt du côté des behaviours comme le précise Bruno.
Je vais reprendre tout ça à tête reposée tout à l'heure.
Le 16 janvier 2015 08:24, Bruno <dsls(a)morefnu.org> a écrit :
Utiliser la priorité (dans le _define.php) peut aider dans certains
cas,
> mais je suis en ce moment confronté à un cas où il faut, dans un plugin,
> que je passe avant (définition d'une macro wiki) ET après (init d'un
> bouton) un autre plugin (éditeur). Du coup ce n'est pas applicable.
>
Pas sûr de comprendre le problème. Il faut distinguer le moment où on
déclare l'ensemble des actions d'un behavior (via addBehavior), et le
moment ou ce behavior est appelé (via callBehavior). Il faut bien entendu
que les actions soient toutes définies avant le callbehavior().
Je pense que ton souci vient du fait que dcLegacyEditor appelle
coreInitWikiPost dans son _admin.php. Pour autant un plugin ne doit pas
être prioritaire face à dcLegacyEditorpour s'il agit sur coreInitWikiPost,
il "suffit" de faire le addBehavior dans son _prepend.php (qui et chargé
avant tout les _admin.php).
Du coup une nouvelle boucle qui appellerait cette fois le _append.php (s'il
> existe) de chaque plugin, construit de la même manière qu'un
_prepend.php :
>
Je ne suis pas fan de l'ajout d'un fichier en plus de ce type, cela
ajouterait de la confusion pour les devs, et pas mal de cas particuliers à
gérer en plus. D'autant que je ne suis pas sûr que ça gère tous les cas.
S'il faut vraiment qu'on gère ce genre de choses, je serais plutôt partisan
de pouvoir ajouter des priorités (facultatives) au sein de addBehavior.
Voir ce ticket qui date de 7 ans et qu'olivier avait refusé :
http://dev.dotclear.org/2.0/ticket/523.
--
Bruno
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
8:47 a.m.
Mon plugins (series, mais tags sera à la même enseigne) a une priorité à
1001 (si je mets moins que 1000 je n'ai pas de bouton vu qu'il sera chargé
avant dcLegacyEditor).
J'ai un
$core->addBehavior('coreInitWikiPost',array('seriesBehaviors','coreInitWikiPost'));
dans mon _prepend.php comme tu le suggères (ou alors j'ai pas bien
compris), mais ça reste inopérant, la macro n'est pas convertie à
l'enregistrement du billet.
Je m'arrache les cheveux avec ça !
Le 16 janvier 2015 08:31, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
En fait après réflexion, comme dit Nicolas c'est tôt la matin, le
pb que
j'ai est plutôt du côté des behaviours comme le précise Bruno.
Je vais reprendre tout ça à tête reposée tout à l'heure.
Le 16 janvier 2015 08:24, Bruno <dsls(a)morefnu.org> a écrit :
Utiliser la priorité (dans le _define.php) peut aider dans certains cas,
> > mais je suis en ce moment confronté à un cas où il faut, dans un plugin,
> > que je passe avant (définition d'une macro wiki) ET après (init d'un
> > bouton) un autre plugin (éditeur). Du coup ce n'est pas applicable.
> >
>
> Pas sûr de comprendre le problème. Il faut distinguer le moment où on
> déclare l'ensemble des actions d'un behavior (via addBehavior), et le
> moment ou ce behavior est appelé (via callBehavior). Il faut bien entendu
> que les actions soient toutes définies avant le callbehavior().
>
> Je pense que ton souci vient du fait que dcLegacyEditor appelle
> coreInitWikiPost dans son _admin.php. Pour autant un plugin ne doit pas
> être prioritaire face à dcLegacyEditorpour s'il agit sur coreInitWikiPost,
> il "suffit" de faire le addBehavior dans son _prepend.php (qui et chargé
> avant tout les _admin.php).
>
>
> Du coup une nouvelle boucle qui appellerait cette fois le _append.php
> (s'il
> > existe) de chaque plugin, construit de la même manière qu'un
> _prepend.php :
> >
> Je ne suis pas fan de l'ajout d'un fichier en plus de ce type, cela
> ajouterait de la confusion pour les devs, et pas mal de cas particuliers à
> gérer en plus. D'autant que je ne suis pas sûr que ça gère tous les cas.
> S'il faut vraiment qu'on gère ce genre de choses, je serais plutôt
> partisan
> de pouvoir ajouter des priorités (facultatives) au sein de addBehavior.
> Voir ce ticket qui date de 7 ans et qu'olivier avait refusé :
> http://dev.dotclear.org/2.0/ticket/523.
>
> --
> Bruno
> --
> Dev mailing list - Dev(a)list.dotclear.org -
> http://ml.dotclear.org/listinfo/dev
>
--
Franck
--
Franck
8:52 a.m.
J'ai un
$core->addBehavior('coreInitWikiPost',array('seriesBehaviors','coreInitWikiPost'));
dans mon _prepend.php comme tu le suggères (ou alors j'ai pas bien
compris), mais ça reste inopérant, la macro n'est pas convertie à
l'enregistrement du billet.
Ta classe seriesBehaviors est bien en autoload dans le prepend.php ? Il
faut que seriesBehaviors::coreInitWikiPost existe au moment du addBehavior.
--
Bruno
8:55 a.m.
Oui elle l'est, mon _prepend.php actuel :
$__autoload['seriesBehaviors'] =
dirname(__FILE__).'/inc/series.behaviors.php';
$core->addBehavior('coreInitWikiPost',array('seriesBehaviors','coreInitWikiPost'));
Le 16 janvier 2015 08:52, Bruno <dsls(a)morefnu.org> a écrit :
> J'ai un
>
>
$core->addBehavior('coreInitWikiPost',array('seriesBehaviors','coreInitWikiPost'));
> dans mon _prepend.php comme tu le suggères (ou alors j'ai pas bien
> compris), mais ça reste inopérant, la macro n'est pas convertie à
> l'enregistrement du billet.
>
Ta classe seriesBehaviors est bien en autoload dans le prepend.php ? Il
faut que seriesBehaviors::coreInitWikiPost existe au moment du addBehavior.
--
Bruno
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
9:12 a.m.
Le 16 janvier 2015 08:55, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
Oui elle l'est, mon _prepend.php actuel :
$__autoload['seriesBehaviors'] =
dirname(__FILE__).'/inc/series.behaviors.php';
$core->addBehavior('coreInitWikiPost',array('seriesBehaviors','coreInitWikiPost'));
Tu peux partager tes sources en l'état ? Je vais jeter un oeil dès que j'ai
un peu de temps.
--
Bruno
9:54 a.m.
Oui bien sûr, en pièce jointe la future version 0.5 de series.
En ce qui concerne _prepend.php + _admin.php/_public.php, ce ne sont pas
deux boucles indépendantes. Les deux appels ont lieu pour chacun des
plugins.
Le 16 janvier 2015 09:12, Bruno <dsls(a)morefnu.org> a écrit :
Le 16 janvier 2015 08:55, Franck Paul
<carnet.franck.paul(a)gmail.com> a
écrit :
> Oui elle l'est, mon _prepend.php actuel :
>
> $__autoload['seriesBehaviors'] =
> dirname(__FILE__).'/inc/series.behaviors.php';
>
>
>
$core->addBehavior('coreInitWikiPost',array('seriesBehaviors','coreInitWikiPost'));
>
Tu peux partager tes sources en l'état ? Je vais jeter un oeil dès que j'ai
un peu de temps.
--
Bruno
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
10:05 a.m.
Je te l'envoie en direct…
2015-01-16 10:03 GMT+01:00 Bruno <dsls(a)morefnu.org>:
Le 16 janvier 2015 09:54, Franck Paul
<carnet.franck.paul(a)gmail.com> a
écrit :
> Oui bien sûr, en pièce jointe la future version 0.5 de series.
>
Apparemment la pj ne passe pas sur la liste :)
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
12:16 p.m.
Je poursuis ma réflexion :
Je me demande s'il ne faudrait pas dissocier les deux appels _prepend.php
et _admin.php/_public.php, donc avoir 2 boucles au lieu d'une seule.
L'avantage serait que tous les _prepend.php auraient été chargés avant de
passer à la suite.
Par contre je mesure mal les conséquences de ce changement sur les plugins
existants — j'ai vérifié, cette boucle unique avec double appel existe
depuis le début de Dotclear 2.
Le 16 janvier 2015 10:05, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
Je te l'envoie en direct…
2015-01-16 10:03 GMT+01:00 Bruno <dsls(a)morefnu.org>:
> Le 16 janvier 2015 09:54, Franck Paul <carnet.franck.paul(a)gmail.com> a
> écrit :
>
> > Oui bien sûr, en pièce jointe la future version 0.5 de series.
> >
>
> Apparemment la pj ne passe pas sur la liste :)
> --
> Dev mailing list - Dev(a)list.dotclear.org -
> http://ml.dotclear.org/listinfo/dev
>
--
Franck
--
Franck
1:29 p.m.
Le 16 janvier 2015 12:16, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
Je poursuis ma réflexion :
Je me demande s'il ne faudrait pas dissocier les deux appels _prepend.php
et _admin.php/_public.php, donc avoir 2 boucles au lieu d'une seule.
L'avantage serait que tous les _prepend.php auraient été chargés avant de
passer à la suite.
Par contre je mesure mal les conséquences de ce changement sur les plugins
existants — j'ai vérifié, cette boucle unique avec double appel existe
depuis le début de Dotclear 2.
Je sais bien, je l'ai évoqué il y a 3 ans:
http://dev.dotclear.org/2.0/ticket/1296 :)
Je suis pour cette modification. Je propose qu'on la mette d'emblée sur la
2.8, et qu'on laisse maturer.
--
Bruno
1:36 p.m.
Vendu ! :-)
Le 16 janvier 2015 13:29, Bruno <dsls(a)morefnu.org> a écrit :
Le 16 janvier 2015 12:16, Franck Paul
<carnet.franck.paul(a)gmail.com> a
écrit :
> Je poursuis ma réflexion :
>
> Je me demande s'il ne faudrait pas dissocier les deux appels _prepend.php
> et _admin.php/_public.php, donc avoir 2 boucles au lieu d'une seule.
> L'avantage serait que tous les _prepend.php auraient été chargés avant de
> passer à la suite.
>
> Par contre je mesure mal les conséquences de ce changement sur les
plugins
> existants — j'ai vérifié, cette boucle unique avec double appel existe
> depuis le début de Dotclear 2.
>
Je sais bien, je l'ai évoqué il y a 3 ans:
http://dev.dotclear.org/2.0/ticket/1296 :)
Je suis pour cette modification. Je propose qu'on la mette d'emblée sur la
2.8, et qu'on laisse maturer.
--
Bruno
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
1:54 p.m.
Je viens quelques tests avec series et yash qui utilisent tous les deux des
macros, la double-boucle arrange bien les choses !
D'autre part je n'ai pas vu, pour l'instant, d'effet de bord gênant côté
Dotclear.
Le 16 janvier 2015 13:36, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
Vendu ! :-)
Le 16 janvier 2015 13:29, Bruno <dsls(a)morefnu.org> a écrit :
Le 16 janvier 2015 12:16, Franck Paul <carnet.franck.paul(a)gmail.com> a
> écrit :
>
> > Je poursuis ma réflexion :
> >
> > Je me demande s'il ne faudrait pas dissocier les deux appels
> _prepend.php
> > et _admin.php/_public.php, donc avoir 2 boucles au lieu d'une seule.
> > L'avantage serait que tous les _prepend.php auraient été chargés avant
> de
> > passer à la suite.
> >
> > Par contre je mesure mal les conséquences de ce changement sur les
> plugins
> > existants — j'ai vérifié, cette boucle unique avec double appel existe
> > depuis le début de Dotclear 2.
> >
>
>
> Je sais bien, je l'ai évoqué il y a 3 ans:
> http://dev.dotclear.org/2.0/ticket/1296 :)
>
> Je suis pour cette modification. Je propose qu'on la mette d'emblée sur la
> 2.8, et qu'on laisse maturer.
>
> --
> Bruno
> --
> Dev mailing list - Dev(a)list.dotclear.org -
> http://ml.dotclear.org/listinfo/dev
>
--
Franck
--
Franck
1:56 p.m.
Le 16 janvier 2015 13:54, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
Je viens quelques tests avec series et yash qui utilisent tous les
deux des
macros, la double-boucle arrange bien les choses !
D'autre part je n'ai pas vu, pour l'instant, d'effet de bord gênant côté
Dotclear.
Je pense que les effets de bord, s'il y en a, seront vraiment à la marge :)
--
Bruno
3:03 p.m.
Commité et mes deux plougs (series et yash) ont le poil lisse et soyeux \o/
M'occuperai de tags ASAP
Le 16 janvier 2015 13:56, Bruno <dsls(a)morefnu.org> a écrit :
Le 16 janvier 2015 13:54, Franck Paul
<carnet.franck.paul(a)gmail.com> a
écrit :
> Je viens quelques tests avec series et yash qui utilisent tous les deux
des
> macros, la double-boucle arrange bien les choses !
>
> D'autre part je n'ai pas vu, pour l'instant, d'effet de bord gênant
côté
> Dotclear.
>
Je pense que les effets de bord, s'il y en a, seront vraiment à la marge :)
--
Bruno
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
3:05 p.m.
Je n'ai pas fermé le ticket, tant qu'on aura pas testé un peu plus avec les
nightlies à venir, je pense que c'est préférable.
Le 16 janvier 2015 15:03, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
Commité et mes deux plougs (series et yash) ont le poil lisse et
soyeux \o/
M'occuperai de tags ASAP
Le 16 janvier 2015 13:56, Bruno <dsls(a)morefnu.org> a écrit :
Le 16 janvier 2015 13:54, Franck Paul <carnet.franck.paul(a)gmail.com> a
> écrit :
>
> > Je viens quelques tests avec series et yash qui utilisent tous les deux
> des
> > macros, la double-boucle arrange bien les choses !
> >
> > D'autre part je n'ai pas vu, pour l'instant, d'effet de bord
gênant côté
> > Dotclear.
> >
>
>
> Je pense que les effets de bord, s'il y en a, seront vraiment à la marge
> :)
>
> --
> Bruno
> --
> Dev mailing list - Dev(a)list.dotclear.org -
> http://ml.dotclear.org/listinfo/dev
>
--
Franck
--
Franck
3:08 p.m.
Le 16 janvier 2015 15:03, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
Commité et mes deux plougs (series et yash) ont le poil lisse et
soyeux \o/
\o/
Bon moi je vais aller voir d'autres tickets qui m'avaient été refusés à
l'époque par Olivier, on sait jamais :P
--
Bruno
3:11 p.m.
T'as pas déjà des zilliards de trucs en route ? Genre conversion de billet,
activation des modules / blog, … ?
Pfff t'en as jamais assez ! :-D
Le 16 janvier 2015 15:08, Bruno <dsls(a)morefnu.org> a écrit :
Le 16 janvier 2015 15:03, Franck Paul
<carnet.franck.paul(a)gmail.com> a
écrit :
> Commité et mes deux plougs (series et yash) ont le poil lisse et soyeux
\o/
>
>
\o/
Bon moi je vais aller voir d'autres tickets qui m'avaient été refusés à
l'époque par Olivier, on sait jamais :P
--
Bruno
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
3:16 p.m.
Je vais envoyer un mail à l'ancien chef. :-)
Le 16 janvier 2015 15:11, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
T'as pas déjà des zilliards de trucs en route ? Genre conversion
de billet,
activation des modules / blog, … ?
Pfff t'en as jamais assez ! :-D
Le 16 janvier 2015 15:08, Bruno <dsls(a)morefnu.org> a écrit :
> Le 16 janvier 2015 15:03, Franck Paul <carnet.franck.paul(a)gmail.com> a
> écrit :
>
> > Commité et mes deux plougs (series et yash) ont le poil lisse et soyeux
> \o/
> >
> >
> \o/
>
> Bon moi je vais aller voir d'autres tickets qui m'avaient été refusés à
> l'époque par Olivier, on sait jamais :P
>
> --
> Bruno
> --
> Dev mailing list - Dev(a)list.dotclear.org -
> http://ml.dotclear.org/listinfo/dev
>
--
Franck
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
4:49 p.m.
Le 16 janvier 2015 15:11, Franck Paul <carnet.franck.paul(a)gmail.com> a
écrit :
T'as pas déjà des zilliards de trucs en route ? Genre conversion
de billet,
activation des modules / blog, … ?
Pfff t'en as jamais assez ! :-D
Disons que je me retrouve (malheureusement trop) dans cette bd :
http://www.commitstrip.com/fr/2014/11/25/west-side-project-story/
...
5:14 p.m.
C'est bizarre, j'avais pensé à toi en découvrant cette BD :-D
Le 20 janvier 2015 16:49, Bruno <dsls(a)morefnu.org> a écrit :
Le 16 janvier 2015 15:11, Franck Paul
<carnet.franck.paul(a)gmail.com> a
écrit :
> T'as pas déjà des zilliards de trucs en route ? Genre conversion de
billet,
> activation des modules / blog, … ?
>
> Pfff t'en as jamais assez ! :-D
>
Disons que je me retrouve (malheureusement trop) dans cette bd :
http://www.commitstrip.com/fr/2014/11/25/west-side-project-story/
...
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
3394
days inactive
3398
days old
22 comments
3 participants
participants (3)
-
Bruno -
Franck Paul -
Nicolas