[SPIP Zone] r96950 - in _plugins_/logos_roles/trunk

bystrano@gmx.ch a écrit le 02/05/2016 à 07:53 :

Author: bystrano@gmx.ch
Date: 2016-05-02 07:53:48 +0200 (Mon, 02 May 2016)
New Revision: 96950

Modified:
   _plugins_/logos_roles/trunk/README.md
   _plugins_/logos_roles/trunk/formulaires/inc-apercu-logo.html
Log:
ajoute un pipeline pour pouvoir ajouter des trucs en-dessous des aperçus de logos

Details: Connexion · GitLab

Bonjour,

Je viens de tester ce plugin.
Magnifique !

Je ne comprends pas pourquoi le readme dit :
« Il reste à trouver un moyen d'appeler les nouveaux type de logos dans les squelettes. »
Parce que je viens de tester avec SoyezCréateurs, et sans rrien changer au squelette, ça marche pour moi (précision : j'utilise toujours #LOGO_*_NORMAL ou SURVOL avec |extraire_attribut{src}, c'est peut-être pour ça que ça marche pour moi).

En plus c'est compatible avec le plugin Centre Image (J'ai commencé un nouveau plugin pour SPIP : *centre_image*).

Par contre, ça n'utilise pas le formulaire d'upload HTML5 (Formulaire d'upload en html5 - SPIP-Contrib), sans doute parce que celui-ci avait justement dû faire quelque chose de différent pour les logos.

La possibilité de modifier le logo normal sans avoir à supprimer le logo de survol avant est tout simplement ergonomique !

Et de pouvoir insérer un logo dans le texte (et voir que ça lui a rajouté le rôle automatiquement), c'est extra !

2 éléments un peu déstabilisant par contre :
- on peut passer un logo dans le portfolio, mais ça ne fait rien côté galerie en public parce qu'il faut *en plus* lui rajouter le rôle de document
- plus grave : en ayant mis un logo de survol et un logo normal, on peut affecter l'autre rôle à chacun (logo + logo de survol). Ne faudrait-il pas que lorsqu'il y en a déjà 1, on ne puisse pas mettre un 2 logo avec le même rôle ?

Merci, merci, merci !

--
RealET

Hello,

On 02/05/2016 10:04, RealET wrote:

bystrano@gmx.ch a écrit le 02/05/2016 à 07:53 :

Author: bystrano@gmx.ch
Date: 2016-05-02 07:53:48 +0200 (Mon, 02 May 2016)
New Revision: 96950

Modified:
   _plugins_/logos_roles/trunk/README.md
   _plugins_/logos_roles/trunk/formulaires/inc-apercu-logo.html
Log:
ajoute un pipeline pour pouvoir ajouter des trucs en-dessous des
aperçus de logos

Details: Connexion · GitLab

Bonjour,

Je viens de tester ce plugin.
Magnifique !

Je ne comprends pas pourquoi le readme dit :
« Il reste à trouver un moyen d'appeler les nouveaux type de logos
dans les squelettes. »
Parce que je viens de tester avec SoyezCréateurs, et sans rrien
changer au squelette, ça marche pour moi (précision : j'utilise
toujours #LOGO_*_NORMAL ou SURVOL avec |extraire_attribut{src}, c'est
peut-être pour ça que ça marche pour moi).

C'est parce que si on crée un nouveau type de logo, comme
"logo_slideshow_accueil", en ajoutant un rôle possible aux documents, le
formulaire le propose automatiquement et permet de l'enregistrer, mais
on n'a pas de méthode pour afficher le dit logo dans un squelette.
Il faudrait soit étendre la balise LOGO_* pour pouvoir faire un truc du
style #LOGO_ARTICLE_SLIDESHOW_ACCUEIL, soit créer une nouvelle balise,
comme #LOGO_ROLE{slideshow_accueil}.

Ceci dit les balises existantes fonctionnent, la compatibilité est assurée.

En plus c'est compatible avec le plugin Centre Image
(J'ai commencé un nouveau plugin pour SPIP : *centre_image*).

Par contre, ça n'utilise pas le formulaire d'upload HTML5
(Formulaire d'upload en html5 - SPIP-Contrib), sans doute
parce que celui-ci avait justement dû faire quelque chose de différent
pour les logos.

Non, c'est pour ça qu'il y a un TODO avant ce point dans le README. Pour
moi il faudrait fournir un mécanisme de surcharge qui permettrait
ensuite au plugin upload html5 de venir s'insérer dans le formulaire,
mais je n'ai pas encore bien étudié quelle serait la bonne façon de
faire ça…

La possibilité de modifier le logo normal sans avoir à supprimer le
logo de survol avant est tout simplement ergonomique !

Et de pouvoir insérer un logo dans le texte (et voir que ça lui a
rajouté le rôle automatiquement), c'est extra !

2 éléments un peu déstabilisant par contre :
- on peut passer un logo dans le portfolio, mais ça ne fait rien côté
galerie en public parce qu'il faut *en plus* lui rajouter le rôle de
document
- plus grave : en ayant mis un logo de survol et un logo normal, on
peut affecter l'autre rôle à chacun (logo + logo de survol). Ne
faudrait-il pas que lorsqu'il y en a déjà 1, on ne puisse pas mettre
un 2 logo avec le même rôle ?

Oui c'est effectivement un peu bof…
Je pensais m'en sortir à peu de frais en m'arrangeant pour que les logos
ne sortent pas dans les boucles DOCUMENTS par défaut. Du coup on ne les
verrai plus dans les listes de documents, et on ne pourrais plus leur
associer des rôles de logos.
Mais en y réfléchissant plus, je pense qu'il faudra arranger le select
d'attribution de rôles pour qu'il ne permette pas de faire n'importe
quoi avec les logos…

Hello,

Merci pour cette super contribution !
Mes quelques remarques :

- En testant sur SPIP 3.2 dev, j'obtiens un message d'erreur avec la fonction aide() qui ne semble pas être chargée dans editer_logo.php.
Résolu en faisant $aider = charger_fonction('aide', 'inc', true);
puis $aider('logoart');
etc.

> README.md : Ajoute un pipeline qui permet d'ajouter des liens d'actions en-dessous des aperçus de logo : `logo_desc_actions`
Est-ce qu'on ne pourrait pas tout simplement réutiliser le squelette modeles/document_case.html du plugin medias ? Il me semble qu'il y a déjà tout ce qu'il faut dedans.

> README.md : Les boucles `DOCUMENTS` posent un problème de compatibilité, puisqu'elle font soudainement apparaître les logos.
> Peut-être qu'il faudrait s'arranger pour que les boucles `DOCUMENTS` ne sortent les logos que si on ajoute un critère, genre `{afficher_logos}` ?
Je suis d'accord, les documents avec un rôle de logo ne devraient pas apparaître par défaut, à moins de le spécifier explicitement.
À mon avis, pas besoin d'un nouveau critère pour ça, {role = logo} devrait suffire.

> Par contre, ça n'utilise pas le formulaire d'upload HTML5
Je crois que c'est plutôt l'inverse : c'est le plugin upload_html5 qui n'utilise pas le formulaire d'ajout de documents, il s'ajoute "en plus". Ergonomiquement, il devrait se trouver dans l'onglet "depuis mon ordinateur" du formulaire d'ajout de document je trouve. Et du coup, les autres plugins qui utilisent ce formulaire ne bénéficient pas d'upload_html5.

> Mais en y réfléchissant plus, je pense qu'il faudra arranger le select d'attribution de rôles pour qu'il ne permette pas de faire n'importe quoi avec les logos…
Dans l'API des rôles, on ne peut pas dire qu'un rôle ne peut être utilisé qu'une seule fois par objet. Donc de ce côté là, on est coincés à moins de surcharger le formulaire d'attribution des rôles (ou la fonction qui liste les rôles aussi, je suppose).

Le 02/05/2016 11:16, Michel Bystranowski a écrit :

Hello,

On 02/05/2016 10:04, RealET wrote:

bystrano@gmx.ch a écrit le 02/05/2016 à 07:53 :

Author: bystrano@gmx.ch
Date: 2016-05-02 07:53:48 +0200 (Mon, 02 May 2016)
New Revision: 96950

Modified:
    _plugins_/logos_roles/trunk/README.md
    _plugins_/logos_roles/trunk/formulaires/inc-apercu-logo.html
Log:
ajoute un pipeline pour pouvoir ajouter des trucs en-dessous des
aperçus de logos

Details: Connexion · GitLab

Bonjour,

Je viens de tester ce plugin.
Magnifique !

Je ne comprends pas pourquoi le readme dit :
« Il reste à trouver un moyen d'appeler les nouveaux type de logos
dans les squelettes. »
Parce que je viens de tester avec SoyezCréateurs, et sans rrien
changer au squelette, ça marche pour moi (précision : j'utilise
toujours #LOGO_*_NORMAL ou SURVOL avec |extraire_attribut{src}, c'est
peut-être pour ça que ça marche pour moi).

C'est parce que si on crée un nouveau type de logo, comme
"logo_slideshow_accueil", en ajoutant un rôle possible aux documents, le
formulaire le propose automatiquement et permet de l'enregistrer, mais
on n'a pas de méthode pour afficher le dit logo dans un squelette.
Il faudrait soit étendre la balise LOGO_* pour pouvoir faire un truc du
style #LOGO_ARTICLE_SLIDESHOW_ACCUEIL, soit créer une nouvelle balise,
comme #LOGO_ROLE{slideshow_accueil}.

Ceci dit les balises existantes fonctionnent, la compatibilité est assurée.

En plus c'est compatible avec le plugin Centre Image
(J'ai commencé un nouveau plugin pour SPIP : *centre_image*).

Par contre, ça n'utilise pas le formulaire d'upload HTML5
(Formulaire d'upload en html5 - SPIP-Contrib), sans doute
parce que celui-ci avait justement dû faire quelque chose de différent
pour les logos.

Non, c'est pour ça qu'il y a un TODO avant ce point dans le README. Pour
moi il faudrait fournir un mécanisme de surcharge qui permettrait
ensuite au plugin upload html5 de venir s'insérer dans le formulaire,
mais je n'ai pas encore bien étudié quelle serait la bonne façon de
faire ça…

La possibilité de modifier le logo normal sans avoir à supprimer le
logo de survol avant est tout simplement ergonomique !

Et de pouvoir insérer un logo dans le texte (et voir que ça lui a
rajouté le rôle automatiquement), c'est extra !

2 éléments un peu déstabilisant par contre :
- on peut passer un logo dans le portfolio, mais ça ne fait rien côté
galerie en public parce qu'il faut *en plus* lui rajouter le rôle de
document
- plus grave : en ayant mis un logo de survol et un logo normal, on
peut affecter l'autre rôle à chacun (logo + logo de survol). Ne
faudrait-il pas que lorsqu'il y en a déjà 1, on ne puisse pas mettre
un 2 logo avec le même rôle ?

Oui c'est effectivement un peu bof…
Je pensais m'en sortir à peu de frais en m'arrangeant pour que les logos
ne sortent pas dans les boucles DOCUMENTS par défaut. Du coup on ne les
verrai plus dans les listes de documents, et on ne pourrais plus leur
associer des rôles de logos.
Mais en y réfléchissant plus, je pense qu'il faudra arranger le select
d'attribution de rôles pour qu'il ne permette pas de faire n'importe
quoi avec les logos…

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Le 02/05/2016 18:48, Charles Razack a écrit :

Dans l'API des rôles, on ne peut pas dire qu'un rôle ne peut être
utilisé qu'une seule fois par objet. Donc de ce côté là, on est coincés
à moins de surcharger le formulaire d'attribution des rôles (ou la
fonction qui liste les rôles aussi, je suppose).

On en avait parlé une fois, de dire que dans la déclaration, il devrait y avoir un système de description de comment s'utilise le rôle. Mais on avait juste évoqué l'idée, sans solution concrète.

Je pense toujours que ce serait la meilleure approche, plus générique, et non pas s'occuper spécifiquement des logos en particulier.

--
RastaPopoulos

Le 02/05/2016 18:48, Charles Razack a écrit :

> Peut-être qu'il faudrait s'arranger pour que les boucles `DOCUMENTS` ne sortent les logos que si on ajoute un
critère, genre `{afficher_logos}` ?
Je suis d'accord, les documents avec un rôle de logo ne devraient pas apparaître par défaut, à moins de le spécifier
explicitement.
À mon avis, pas besoin d'un nouveau critère pour ça, {role = logo} devrait suffire.

Idéalement il faudrait aussi simplement pouvoir dire "je veux les documents y compris les logos"...
C'est comme ça que j'avais compris {afficher_logos}

JL

Hello,

Je crois que c’est plutôt l’inverse : c’est le plugin upload_html5 qui n’utilise pas le formulaire d’ajout de documents, il s’ajoute « en plus ».

Le formulaire uploadhtml5 passe par le pipeline formulairefond, conditionné sur joindre_document : /uploadhtml5/trunk/uploadhtml5_pipelines.php#L51
Donc, sur le principe, je me branche sur le bon formulaire. (?)

Ergonomiquement, il devrait se trouver dans l’onglet « depuis mon ordinateur » du formulaire d’ajout de document je trouve.

Oui, c’était mon idée première. Malheureusement, la structure actuel du core ne le permet pas.
Pour le moment, on a un formulaire unique dont le contenu change en fonction du choix de l’utilisateur.

Pour moi, une bonne structure pour le core aurai été d’avoir 1 formulaire par fonction et non pas un formulaire pour 4 actions différentes.
Il serai alors trival de faire une intégration propre de la dropzone, car je pourrai directement cibler la bonne partie du formulaire.

Et du coup, les autres plugins qui utilisent ce formulaire ne bénéficient pas d’upload_html5.

Si si, si tu appel formulaire_joindre_document, tu bénéficies d’uploadhtml5.

Voilà voilà :slight_smile:

Le 2 mai 2016 21:17:21 GMT+02:00, Phenix <p@henix.be> a écrit :

Hello,

Je crois que c'est plutôt l'inverse : c'est le plugin upload_html5

qui

n'utilise pas le formulaire d'ajout de documents, il s'ajoute "en

plus".

Le formulaire uploadhtml5 passe par le pipeline formulaire/fond,
conditionné sur joindre_document :
Connexion · GitLab
Donc, sur le principe, je me branche sur le bon formulaire. (?)

Ergonomiquement, il devrait se trouver dans l'onglet "depuis mon
ordinateur" du formulaire d'ajout de document je trouve.

Oui, c’était mon idée première. Malheureusement, la structure actuel du
core ne le permet pas.
Pour le moment, on a un formulaire unique dont le contenu change en
fonction du choix de l’utilisateur.

Pour moi, une bonne structure pour le core aurai été d’avoir 1
formulaire par fonction et non pas un formulaire pour 4 actions
différentes.
Il serai alors trival de faire une intégration propre de la dropzone,
car je pourrai directement cibler la bonne partie du formulaire.

Une autre solution serait de construire le formulaire avec un tableau de saisies en PHP. D'autres plugins peuvent alors utiliser le pipeline formulaire_saisies pour modifier le formulaire.
À mon avis c'est même mieux, puisque ça permet à plusieurs plugins de modifier le formulaire en même temps, alors qu'avec une surcharge classique, il y a forcément un plugin qui prend le pas sur l'autre.

Le 02/05/16 18:48, Charles Razack a écrit :

Hello,

Merci pour cette super contribution !
Mes quelques remarques :

- En testant sur SPIP 3.2 dev, j'obtiens un message d'erreur avec la
fonction aide() qui ne semble pas être chargée dans editer_logo.php.
Résolu en faisant $aider = charger_fonction('aide', 'inc', true);
puis $aider('logoart');
etc.

> README.md : Ajoute un pipeline qui permet d'ajouter des liens
d'actions en-dessous des aperçus de logo : `logo_desc_actions`
Est-ce qu'on ne pourrait pas tout simplement réutiliser le squelette
modeles/document_case.html du plugin medias ? Il me semble qu'il y a
déjà tout ce qu'il faut dedans.

Je regarderai ça à l'occasion, j'ai pas de spip sous la main là maintenant... Mais à priori je suis bien dans l'idée de réutiliser le plus possible ce qui existe déjà.

> README.md : Les boucles `DOCUMENTS` posent un problème de
compatibilité, puisqu'elle font soudainement apparaître les logos.
> Peut-être qu'il faudrait s'arranger pour que les boucles

`DOCUMENTS`

ne sortent les logos que si on ajoute un critère, genre
`{afficher_logos}` ?
Je suis d'accord, les documents avec un rôle de logo ne devraient pas
apparaître par défaut, à moins de le spécifier explicitement.
À mon avis, pas besoin d'un nouveau critère pour ça, {role = logo}
devrait suffire.

À mon avis, {afficher_logo} aurait quand même sa place dans certains cas, quand on veut voir les logos sans forcément spécifier lesquels (par exemple dans la mediathèque).

<rastapopoulos@spip.org> a écrit :

Le 02/05/2016 18:48, Charles Razack a écrit :

Dans l'API des rôles, on ne peut pas dire qu'un rôle ne peut être
utilisé qu'une seule fois par objet. Donc de ce côté là, on est

coincés

à moins de surcharger le formulaire d'attribution des rôles (ou la
fonction qui liste les rôles aussi, je suppose).

On en avait parlé une fois, de dire que dans la déclaration, il devrait

y avoir un système de description de comment s'utilise le rôle. Mais on

avait juste évoqué l'idée, sans solution concrète.

Je pense toujours que ce serait la meilleure approche, plus générique,
et non pas s'occuper spécifiquement des logos en particulier.

Tout à fait d'accord avec toi, l'idéal serait de gérer ça au niveau du plugin rôles.

Ma première idée serait de pouvoir attribuer aux rôles des propriétés qui changeraient le comportement de l'interface.
Par exemple, on pourrait déjà gérer une bonne partie des cas avec une option "unique" pour dire qu'on ne doit pas proposer le rôle plus qu'une fois par objet, et une option "exclusif" qui forcerait l'unicité du rôle (on ne peut pas attribuer un autre rôle à un objet une fois qu'il a un rôle "exclusif").

Après il suffirait de déclarer les rôles de logos comme uniques et exclusifs...