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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.