Re: Sur les "illustrations" et le "portfolio"
Cédric Morin <[email protected]>
| Newsgroups | gmane.comp.web.spip.devel |
|---|---|
| Message-ID | <[email protected]> |
Pour complèter la discussion en essayant de pas la noyer :
- le portfolio a un défaut technique historique, il porte sur le
document et pas sur le lien — c'est du à l'époque où on ne pouvait pas
associer un même document à plusieurs articles.
Du coup si on passe un document en portfolio sur un article, il y est
aussi pour tous les autres articles auxquels il est attaché. C'est un
bug historique à corriger
- le "portfolio" n'est ambigu que pour les images : tous les documents
non visuels sont de facto dans le portfolio. Ce sont les documents
joints à l'article.
- le portfolio actuel du core, dans son usage tant que dans son esprit
s'apparente à un album de documents du plugin albums
Pour le futur :
A ce titre je pense que ça devrait disparaitre du core et que cette
fonctionnalité devrait être émulée/proposée par le plugin albums pour
les afficionados de cette feature
"Déposer dans le portfolio" créerait automatiquement un album
"Portfolio" associé à l'article
De même l'association d'un pdf a un article créerait automatiquement un
album portfolio
- le champ 'mode' serait supprimé de la table des documents
- le compilateur introduirait une compilation dérogatoire pour traduire
'mode=document' en 'document qui est dans un album de type portfolio'
(ou alors on déplace le champ mode sur la table spip_documents_liens, et
on laisse le plugin album gérer ce champ de façon à ce qu'on retrouve
nos petits dans les boucles)
--
Cédric
JLuc a écrit :
> Le 10/01/2017 à 22:11, Maïeul a écrit :
>> Moi non plus, j'ai jamais compris cette histoire de portfolio… du coup
>> je m'en sert pas, et j'utilise uniquement {vu}.
>> Et je surcharge les modèles par défaut pour qu'il oublie cette
>> histoire de mode document/images.
>
> J'espérais que relater mon parcours de découverte aiderait aussi à
> comprendre.
> As tu lu en détail ?
>
> Avec le recul de la nuit je m'aperçois que l'analogie de "portfolio"
> avec "selection éditoriale" ou "grape" est en fait inadéquat
> car il n'y a qu'un seul et unique "portfolio" pour tout le site.
> C'est plus comme une banale case à cocher sur les documents.
>
> La notion de Portfolio, ça part d'une bonne intention (calquer l'UI sur
> une notion de la vie courante),
> mais l'implémentation et la documentation sont trompeuses.
> Pour mettre à plat le truc, voici des explications qui semblent complètes
> et plus clairement structurées :
>
> ====
> Le portfolio c'est 2 trucs différents qu'il ne faut pas confondre :
>
> ## 1) "Être dans le portfolio" c'est une propriété booléenne des documents.
> Au lieu de cocher une checkbox comme on fait normalement pour un champ
> booléen,
> l'interface propose de "Déposer dans le portfolio" ou de les en "Retirer"
>
> Dans l'absolu du code SPIP hors squelettes-dist, "Etre dans le
> portfolio" a 3 conséquences :
>
> - Dans une boucle d'un squelette, on peut sélectionner ces documents
> avec le critère {mode=document}
> et on peut sélectionner ceux qui ne sont pas dans le portfolio avec
> {mode=image}
>
> - Dans la page d'édition d'un objet éditorial, ces document apparaissent
> dans une liste séparée,
> les documents "pas dans le portfolio" apparaissant, eux, dans une liste
> titrée "Illustration"
>
> - Lors de l'édition d'un article ou d'un objet éditorial, seuls certains
> raccourcis sont proposés
> dans la colonne de gauche de la page d'édition, selon que le document
> soit ou non dans le portfolio.
> * Dans le portfolio -> emb, doc (et img ?)
> * Pas dans le portfolio -> img
> Cependant, même si pas proposés, tous ces raccourcis sont toujours
> utilisables.
>
> ## 2) "Le Portfolio", c'est aussi un diaporama présenté, sur les pages
> publiques d'un objet éditorial,
> sous le contenu principal de cet objet, par l'inclusion "documents" de
> squelettes-dist
> C'est donc relatif uniquement à squelettes-dist et aux squelettes qui
> reproduisent ce comportement
>
> Les documents présentés dans ce diaporama sont ceux qui vérifient
> {mode=document} ET {vu=non}
> Là où c'est trompeur, c'est que ce ne sont donc que certains documents
> du portfolio au sens 1)
> qui apparaissent : ceux qui ne sont pas déjà insérés dans l'objet
> éditorial.
>
> ====
>
> Suivent quelques réflexion sur des améliorations possibles :
>
> - Doc :
>
> Si la notion de portfolio perdure, rassembler dans un même doc
> et expliciter cette notion de portfolio (au moins comme ci dessus)
> Surtout : arrêter de confondre l'absolu de spip et le relatif de
> squelettes-dist
> (bien le préciser quand on parle du portfolio de squelettes-dist)
> Ne pas trop faire de supposition sur les cas d'usages et ce que les gens
> veulent faire
> ou en tout cas ne pas se reposer là dessus dans la doc pour exposer un
> concept
> (mais seulement en exemple)
>
> - Nomenklatura :
>
> Pour la cohérence entre code squelette et interface, et facilité de
> documenter,
> il serait préférable que les critères soient {mode=portfolio} et
> {mode=illustration}
> au lieu de {mode=document} et {mode=image}
>
> Ou bien abandonner dans l'interface privée ces termes ambigus de
> "portfolio" et "illustration"
> et avoir des titres simplement "mode: document" et "mode: image"
>
> - Inclusion dans le portfolio (UI) :
>
> Si le portfolio c'est une propriété booléenne, peut être une checkbox
> serait plus claire ?
>
> Ou si au contraire c'est une sélection éditoriale comme l'interface
> actuelle le laisse penser,
> alors une évolution serait de permettre à l'utilisateur d'en définir
> d'autres :
> "Schémas" et "Photos" par exemple, dont les documents seraient
> sélectionnables par
> {mode=schémas} ou {mode=photos}
>
> - Insertion dans un contenu
>
> Je me demande s'il est utile de distinguer les modèles proposés,
> alors qu'ils sont tous utilisables (selon l'extension tout de même).
> Dans la mesure où c'est l'utilisateur qui définit si un document est
> "document" ou non,
> il peut aussi bien définir s'il utilise "emb" ou "doc" ou "img".
>
> JL
>
>
>
>
> _______________________________________________
> liste: http://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip