[SPIP Zone] [Spip-zone-commit] r30287 - in /_squelettes_/cheznous: img/panorama.jpg inc-portfolio.html

cerdic · Juillet 28, 2009, 1:54

Je crois que l'absence de {mode=document} est volontaire et délibérée devant le problème récurrent des utilisateurs devant le fonctionnement dudit porftolio de l'espace privé

Cédric

Le 28 juil. 09 à 15:26, fil@rezo.net a écrit :

Author: fil@rezo.net
Date: Tue Jul 28 15:26:08 2009
New Revision: 30287

Log:
le portfolio qui donne le descriptif en longdesc (sympa avec facebox), et n'affiche pas les images 'hors portfolio'

Modified:
   _squelettes_/cheznous/img/panorama.jpg
   _squelettes_/cheznous/inc-portfolio.html

Modified: _squelettes_/cheznous/img/panorama.jpg

Binary files - no diff available.

Modified: _squelettes_/cheznous/inc-portfolio.html

--- _squelettes_/cheznous/inc-portfolio.html (original)
+++ _squelettes_/cheznous/inc-portfolio.html Tue Jul 28 15:26:08 2009
@@ -21,19 +21,43 @@
  {extension IN jpg,gif,png}
  {largeur>300}{hauteur>200}
  {doublons tof}
+ {mode=document}
  {!par date}
  >

- <BOUCLE_tof_titre(ARTICLES)
+ [(#SET{desc,[(#TITRE*|sinon{#DESCRIPTIF*}|?{' '})]})]
+ <BOUCLE_lien_article(ARTICLES)
  {id_document}
+ {exclus}
  {0,1}
- >#SET{tof_titre,#TITRE}</BOUCLE_tof_titre>
+ >#SET{tof_titre,#TITRE}</BOUCLE_lien_article>
  [(#COMPTEUR_BOUCLE|moins{#GET{pas}}|<={#ENV{debut_photos,0}}|?{#COMPTEUR_BOUCLE}|>{#ENV{debut_photos,0}}|?{
    [(#SET{vignette,[(#FICHIER|copie_locale|image_passe_partout{#GET{taille},#GET{taille}}|image_recadre{#GET{taille},#GET{taille},center}|image_aplatir{jpg,ffffff}|inserer_attribut{class,spip_logos[ modulo(#COMPTEUR_BOUCLE|alterner{1,2,3,4,5})]})]})]
  ,
    [(#SET{vignette,''})]
  })]
- <a href="[(#FICHIER|copie_locale|image_reduire{800}|extraire_attribut{src})]" type="#MIME_TYPE"[ title="(#TITRE|sinon{#GET{tof_titre}}|texte_backend)"]>#GET{vignette}</a>
+
+ [(#REM)
+ Inserer le longdesc dans la vignette (la creer le cas echeant)
+ ]
+ [(#GET{desc}|?{[(#SET{vignette,[(#GET{vignette}
+ |sinon{<img style="display:none;" />}
+ |inserer_attribut{longdesc,[(#VAL{#desc}|concat{#ID_DOCUMENT})]})]})]})]
+ <a href="[(#FICHIER|copie_locale|image_reduire{800}|extraire_attribut{src})]"
+ type="#MIME_TYPE"[
+ title="(#TITRE|sinon{#GET{tof_titre}|supprimer_tags}|texte_backend)"]>#GET{vignette}</a>
+
+ [(#GET{desc})
+ [(#VAL{"<script"}|unique{scriptlongdesc}) type="text/javascript">
+ $("<style>div.longdesc {position: absolute; left: -9999px;}<\/style>")
+ .attr('type', 'text/css')
+ .appendTo('head');
+ </script>
+ ]
+ <div id="desc#ID_DOCUMENT" class="longdesc">
+ [<h4 class="#EDIT{titre}">(#TITRE)</h4>]
+ [<div class="#EDIT{descriptif}">(#DESCRIPTIF)</div>]
+ </div>]
  </BOUCLE_tof>

  <BOUCLE_photos(DOCUMENTS)

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

fil · Juillet 28, 2009, 3:27

2009/7/28 cedric.morin@yterium.com <cedric.morin@yterium.com>:

Je crois que l'absence de {mode=document} est volontaire et délibérée devant
le problème récurrent des utilisateurs devant le fonctionnement dudit
porftolio de l'espace privé

cf. discussion sur irc.

A mon sens on ne "corrige" pas un problème en en créant un nouveau
ailleurs. Mais si c'est ton approche je te laisse faire le revert.

-- Fil

romy · Juillet 28, 2009, 3:37

Le 28 juil. 2009 à 17:27, Fil a écrit :

2009/7/28 cedric.morin@yterium.com <cedric.morin@yterium.com>:

Je crois que l'absence de {mode=document} est volontaire et délibérée devant
le problème récurrent des utilisateurs devant le fonctionnement dudit
porftolio de l'espace privé

cf. discussion sur irc.

A mon sens on ne "corrige" pas un problème en en créant un nouveau
ailleurs. Mais si c'est ton approche je te laisse faire le revert.

+ 1 pour le revert

Je regarderais si je sais faire, mais je suis pour la disparition du portfolio de l'espace privé et des différents modes (ou la confection d'un plugin dédié), si c'est si gênant. Quelqu'un a déjà fait ça ?

--
Romy

Simon_Camerlo · Juillet 29, 2009, 2:27

romy@rezo.net a écrit :

Le 28 juil. 2009 à 17:27, Fil a écrit :

2009/7/28 cedric.morin@yterium.com <cedric.morin@yterium.com>:

Je crois que l'absence de {mode=document} est volontaire et délibérée devant
le problème récurrent des utilisateurs devant le fonctionnement dudit
porftolio de l'espace privé

cf. discussion sur irc.

A mon sens on ne "corrige" pas un problème en en créant un nouveau
ailleurs. Mais si c'est ton approche je te laisse faire le revert.

+ 1 pour le revert

Je regarderais si je sais faire, mais je suis pour la disparition du portfolio de l'espace privé et des différents modes (ou la confection d'un plugin dédié), si c'est si gênant. Quelqu'un a déjà fait ça ?

Vous feriez une centaine d'utilisateurs qui ne comprennent rien au portfolio heureux
(ils ont déjà poussé un gros "ouf" de soulagement avec la fusion des fenêtres "ajouter un document" et "ajouter une image" dans spip 2, à mon avis tout ça va dans le bon sens)

Donc +1 pour la disparition, et +1 aussi pour la disparition du {mode=xx} partout où c'est possible (je l'ai fait dans tous mes squelettes et modèles, je travaille plutôt en filtrant les extensions).

Simon

fil · Juillet 29, 2009, 7:07

Donc +1 pour la disparition, et +1 aussi pour la disparition du {mode=xx}
partout où c'est possible (je l'ai fait dans tous mes squelettes et modèles,
je travaille plutôt en filtrant les extensions).

Je veux bien, mais comment fais-tu pour distinguer une image
(généralement petite) mise dans un flux de texte pour illustrer un
article, d'une photo destinée à être traitée comme un document à part
entière ? Tant qu'on ne répond pas à cette question, on n'avance pas.

-- Fil

Simon_Camerlo · Juillet 29, 2009, 7:47

Fil a écrit :

Donc +1 pour la disparition, et +1 aussi pour la disparition du {mode=xx}
partout où c'est possible (je l'ai fait dans tous mes squelettes et modèles,
je travaille plutôt en filtrant les extensions).


Je veux bien, mais comment fais-tu pour distinguer une image
(généralement petite) mise dans un flux de texte pour illustrer un
article, d'une photo destinée à être traitée comme un document à part
entière ? Tant qu'on ne répond pas à cette question, on n'avance pas.

-- Fil

Pour ma part, les particularités du site que j’administre font que je n’ai pas besoin de tous les cas.
Voici ceux que je gère, ça peut aider à la réflexion.
Tout passe par le modèle doc.html, tous les autres modèles (emb et img) sont en fait des inclusions particulières ou pas de l’un de ces cas :

toutes les images sont cliquables pour s’afficher en grand dans la thickbox (qu’elles soient incluses dans le texte ou dans une gallerie / « portfolio »)
tous les documents affichent systématiquement leur légende si elle est définie (titre suivi de descriptif), je ne vois pas dans quel cas ce comportement n’est pas souhaitable (si on ne veut pas de légende, on laisse les champs vides)
traitement spécifique par extension de fichier (player pour flv ou mp3, etc.)
deux paramètres ajoutés au modèle doc : L et H provoquant un image_reduire sur le fichier (image jpg/gif/png) ou la vignette (autres docs ou image jpg/gif/png avec vignette custom) avec des min/max de sécurité
=> on peut enfin régler la taille d’un image sans avoir à passer par un programme de retouche photo + ré-upload de l’image, etc.

C’est tout.

Dans le cadre d’une utilisation plus généraliste, on pourrait imaginer l’ajout d’un paramètre du genre « noclic » pour désactiver l’affichage en grand des images sur clic, et on aurait là la même différenciation que celle qui existe (à moins que je n’aie raté des épisodes).

On pourrait aussi imaginer d’intégrer des modèles « raccourcis » plus explicites par défaut (pour les images, parce que le problème ne concerne pas les autres types de documents) :

img pour les images dans le flux de texte
imgclic pour les images cliquables affichées directement avec la taille de miniature définie dans les options du site (remplacerait le raccourci dans le cadre d’insertion de document quand le doc courant a une extension d’image)
tout ça pouvant bien sûr se baser soit sur un modèle standard unique (comme chez moi) avec des jeux de paramètres différents (donc possibilité de faire des appels plus personnalisés pour les contributeurs bien informés), soit un modèle par extension de fichier inclus contextuellement, soit un mélange des deux, tout dépend des besoins

Je pense que ça serait beaucoup plus intuitif pour les utilisateurs que l’utilisation actuelle de pour les images qui les déroute (différence de comportement selon la présence ou non de l’image dans le portfolio qu’ils ne comprennent pas de toute façon).

Plus généralement je ne perçois pas la nécessité de différencier dans la base de données les images qu’on souhaite insérer au texte et celle qu’on souhaite avoir comme miniature (particulièrement quand on sait que ces images attachés « en tant qu’image » ne sont potentiellement pas insérées dans le texte !).
Si on veut faire cette distinction, il serait plus judicieux, à mon avis, de scanner le texte de l’objet à l’affichage dans l’espace privé pour séparer les images (et documents ?) qui sont effectivement insérées dans un flux de texte de cet objet.

Simon

RastaPopoulos1 · Juillet 29, 2009, 7:53

Le 29/07/2009 09:07, Fil a écrit :

Je veux bien, mais comment fais-tu pour distinguer une image
(généralement petite) mise dans un flux de texte pour illustrer un
article, d'une photo destinée à être traitée comme un document à part
entière ? Tant qu'on ne répond pas à cette question, on n'avance pas.

Avec {doublons}, on peut bien récupérer uniquement les documents qui ne sont pas déjà inclus dans le texte, non ?

Surtout que dans un SPIP de base (et encore plus avec la Médiathèque !), un MÊME document peut être inclus dans plusieurs articles différents.

Ainsi dans tel article, on pourrait vouloir le document à l'intérieur du texte, et dans tel autre article ou dans une rubrique on pourrait le vouloir en galerie en dehors.

Un document ne peut donc pas avoir un mode propre à lui-même. Sa situation dépend du contexte.

--
RastaPopoulos

Simon_Camerlo · Juillet 29, 2009, 7:57

RastaPopoulos a écrit :

Avec {doublons}, on peut bien récupérer uniquement les documents qui ne sont pas déjà inclus dans le texte, non ?

Oui, j'ai oublié de préciser que je l'utilise dans mes squelettes également.

Simon

romy · Juillet 29, 2009, 8:53

Le 29 juil. 2009 à 09:53, RastaPopoulos a écrit :

Le 29/07/2009 09:07, Fil a écrit :

Je veux bien, mais comment fais-tu pour distinguer une image
(généralement petite) mise dans un flux de texte pour illustrer un
article, d'une photo destinée à être traitée comme un document à part
entière ? Tant qu'on ne répond pas à cette question, on n'avance pas.

Avec {doublons}, on peut bien récupérer uniquement les documents qui ne sont pas déjà inclus dans le texte, non ?

Surtout que dans un SPIP de base (et encore plus avec la Médiathèque !), un MÊME document peut être inclus dans plusieurs articles différents.

Ainsi dans tel article, on pourrait vouloir le document à l'intérieur du texte, et dans tel autre article ou dans une rubrique on pourrait le vouloir en galerie en dehors.

Vi vi vi !

Je peux aussi vouloir telle image insérée en petite illustration dans l'article ET proposée en dessous du même article dans la galerie de photos agrandissables, et aussi mentionnée dans un autre article comme un doc téléchargeable...

Pour répondre à Fil, c'est l'usage (via le modèle utilisé), qui fait que l'image est une « illustration » ou un « document à part » et ceci ne peut pas être une donnée associée à l'image, stockée en bdd comme actuellement, sauf si l'on veut restreindre les possibilités.

Illustration ou document, c'est de la mise en page, pas de la metadonnée.

Voir aussi cette proposition de fonctionnement, à partir de la diapo 21 :
http://docs.google.com/present/view?skipauth=true&id=dccr995j_512m2pj7fq

--
Romy

Simon_Camerlo · Juillet 29, 2009, 9:27

romy@rezo.net a écrit :

Voir aussi cette proposition de fonctionnement, à partir de la diapo 21 :
http://docs.google.com/present/view?skipauth=true&id=dccr995j_512m2pj7fq

Excellente proposition en effet.

Deux remarques (slide 23 et suivants) :

- contextualiser le pavé d'insertion en fonction de l'extension de fichier, pour ne pas afficher "player" pour un fichier image et sélectionner "vignette" par défaut par exemple...

- donner la possibilité de changer la taille de l'image à l'insertion dans le texte est vitale à mon avis (le plus gros argument de mes utilisateurs FCKeditoristes)
    => intégrer deux champs L et H dans le pavé d'insertion d'image avec le comportement suivant :
          - à la sélection du radiobouton "vignette" L et H = taille de vignette par défaut définie dans les options
                (mais modifiable => vignette recalculée depuis le fichier si aucune vignette personnalisée n'est définie)
          - à la sélection du radiobouton "image" L et H = taille de l'image
          - à la sélection du radiobouton "icone" les champs disparaissent (taille standard d'icône)
          - évidemment le modèle doit utiliser image_reduire, pas juste un attribut width / height
          - un bouton "aperçu" à côté des sélecteurs de taille qui fait apparaître au survol un tooltip ajax contenant l'image à la taille choisie

Qu'en dites-vous ?

Simon

romy · Juillet 29, 2009, 10:00

Le 29 juil. 2009 à 11:27, Simon Camerlo a écrit :

romy@rezo.net a écrit :

Voir aussi cette proposition de fonctionnement, à partir de la diapo 21 :
http://docs.google.com/present/view?skipauth=true&id=dccr995j_512m2pj7fq

Excellente proposition en effet.

Deux remarques (slide 23 et suivants) :

- contextualiser le pavé d'insertion en fonction de l'extension de fichier, pour ne pas afficher "player" pour un fichier image et sélectionner "vignette" par défaut par exemple...

- donner la possibilité de changer la taille de l'image à l'insertion dans le texte est vitale à mon avis (le plus gros argument de mes utilisateurs FCKeditoristes)
   => intégrer deux champs L et H dans le pavé d'insertion d'image avec le comportement suivant :
         - à la sélection du radiobouton "vignette" L et H = taille de vignette par défaut définie dans les options
               (mais modifiable => vignette recalculée depuis le fichier si aucune vignette personnalisée n'est définie)
         - à la sélection du radiobouton "image" L et H = taille de l'image
         - à la sélection du radiobouton "icone" les champs disparaissent (taille standard d'icône)
         - évidemment le modèle doit utiliser image_reduire, pas juste un attribut width / height
         - un bouton "aperçu" à côté des sélecteurs de taille qui fait apparaître au survol un tooltip ajax contenant l'image à la taille choisie

Qu'en dites-vous ?

Oui, évidemment.
Mais tout reste à coder

--
Romy

fil · Juillet 29, 2009, 10:49

Pour répondre à Fil, c'est l'usage (via le modèle utilisé), qui fait que
l'image est une « illustration » ou un « document à part » et ceci ne peut
pas être une donnée associée à l'image, stockée en bdd comme actuellement,
sauf si l'on veut restreindre les possibilités.

Illustration ou document, c'est de la mise en page, pas de la metadonnée.

Pas d'accord avec ça justement. Avec ton concept il est impossible de
faire automatiquement la liste des "illustrations", ou d'avoir une
page page_photos qui ne liste QUE les images "documents". Tu es
obligée d'introduire un critère arbitraire (dans le cas de "cheznous",
tu as choisi la taille) pour faire le tri. Je propose pour ma part
d'utiliser un critère arbitraire lui aussi, qui est le "mode". Il a
l'avantage, par rapport à la taille. d'être modifiable à la main image
par image.

Cela dit la discussion montre qu'on va finir par avoir un "critère
portfolio par défaut", et ça suffira à mon bonheur si c'est le même
qu'on applique dans le privé et dans le public. Toi tu mettras la
taille, et moi le mode.

-- Fil

romy · Juillet 29, 2009, 11:05

Le 29 juil. 2009 à 12:49, Fil a écrit :

Pour répondre à Fil, c'est l'usage (via le modèle utilisé), qui fait que
l'image est une « illustration » ou un « document à part » et ceci ne peut
pas être une donnée associée à l'image, stockée en bdd comme actuellement,
sauf si l'on veut restreindre les possibilités.

Illustration ou document, c'est de la mise en page, pas de la metadonnée.

Pas d'accord avec ça justement. Avec ton concept il est impossible de
faire automatiquement la liste des "illustrations", ou d'avoir une
page page_photos qui ne liste QUE les images "documents". Tu es
obligée d'introduire un critère arbitraire (dans le cas de "cheznous",
tu as choisi la taille) pour faire le tri. Je propose pour ma part
d'utiliser un critère arbitraire lui aussi, qui est le "mode". Il a
l'avantage, par rapport à la taille. d'être modifiable à la main image
par image.

Comment insérer une image en illustration pleine largeur sans légende dans un article (mode image insérée en modèle embed) ET en vignette légendée cliquable dans un autre article (mode document inséré en modèle doc) ?
Et, surtout, comment expliquer ça simplement à un rédacteur ?

Si, il est possible de faire la liste des « illustrations » du site : une boucle DOCUMENTS avec les critères {extension IN jpg,gif,png} et surtout {vu=oui} retournera tous les fichiers images utilisés dans un

--
Romy

Pascal23 · Juillet 29, 2009, 11:36

Bonjour à Romy et aux autres,

A quand ce beau fonctionnement (la fin de ton diaporama) ??
Parce que je supplois sur le fait que la gestion et l'insertion des images
sous Spip 2 est encore loin d'être simple pour le "simple rédacteur de base"

Bon courage à ceux qui auront le temps et les capacités à mettre cela en
lignes de code

Portez-vous bien et bonnes vacances à tous

Pascal-JPM

-----Message d'origine-----
De : romy@rezo.net [mailto:romy@rezo.net]
Envoyé : mercredi 29 juillet 2009 10:53
À : SPIP liste Zone
Objet : Re: [SPIP Zone] [Spip-zone-commit] r30287 -
in/_squelettes_/cheznous: img/panorama.jpg inc-portfolio.html

Le 29 juil. 2009 à 09:53, RastaPopoulos a écrit :

Le 29/07/2009 09:07, Fil a écrit :

Je veux bien, mais comment fais-tu pour distinguer une image
(généralement petite) mise dans un flux de texte pour illustrer un
article, d'une photo destinée à être traitée comme un document à part
entière ? Tant qu'on ne répond pas à cette question, on n'avance pas.

Avec {doublons}, on peut bien récupérer uniquement les documents
qui ne sont pas déjà inclus dans le texte, non ?

Surtout que dans un SPIP de base (et encore plus avec la
Médiathèque !), un MÊME document peut être inclus dans plusieurs
articles différents.

Ainsi dans tel article, on pourrait vouloir le document à
l'intérieur du texte, et dans tel autre article ou dans une
rubrique on pourrait le vouloir en galerie en dehors.

Vi vi vi !

Je peux aussi vouloir telle image insérée en petite illustration dans
l'article ET proposée en dessous du même article dans la galerie de
photos agrandissables, et aussi mentionnée dans un autre article
comme un doc téléchargeable...

Pour répondre à Fil, c'est l'usage (via le modèle utilisé), qui fait
que l'image est une « illustration » ou un « document à part » et
ceci ne peut pas être une donnée associée à l'image, stockée en bdd
comme actuellement, sauf si l'on veut restreindre les possibilités.

Illustration ou document, c'est de la mise en page, pas de la
metadonnée.

Voir aussi cette proposition de fonctionnement, à partir de la diapo
21 :
http://docs.google.com/present/view?skipauth=true&id=dccr995j_512m2pj7fq

--
Romy

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

__________ Information provenant d'ESET NOD32 Antivirus, version de la base
des signatures de virus 4287 (20090729) __________

Le message a été vérifié par ESET NOD32 Antivirus.

http://www.eset.com

__________ Information provenant d'ESET NOD32 Antivirus, version de la base
des signatures de virus 4287 (20090729) __________

Le message a été vérifié par ESET NOD32 Antivirus.

http://www.eset.com

JLuc · Juillet 29, 2009, 12:52

Fil a écrit :

Illustration ou document, c'est de la mise en page, pas de la metadonnée.

Pas d'accord avec ça justement. Avec ton concept il est impossible de
faire automatiquement la liste des "illustrations", ou d'avoir une
page page_photos qui ne liste QUE les images "documents".

Il me semble que dans ce cas, tu interroges les pages,
pas les documents eux-même.

Ne devrait-ce pas être en interrogeant le-s contenant-s
que tu pourrais obtenir ces renseignements ?

Il faudrait pour cela un filtre complexe appliqué à un article
ou à une rubrique,
ou des critères supplémentaires pour les boucles DOCUMENTS
(lesquels critères devraient faire référence au contenant).

JLuc

fil · Juillet 29, 2009, 2:59

Si, il est possible de faire la liste des « illustrations » du site : une
boucle DOCUMENTS avec les critères {extension IN jpg,gif,png} et surtout
{vu=oui} retournera tous les fichiers images utilisés dans un

Le critère {vu} s'en rapproche mais ne correspond pas précisément à la
notion d'illustration.

-- Fil

Simon_Camerlo · Juillet 30, 2009, 3:08

Fil a écrit :

Pas d'accord avec ça justement. Avec ton concept il est impossible de
faire automatiquement la liste des "illustrations", ou d'avoir une
page page_photos qui ne liste QUE les images "documents". Tu es
obligée d'introduire un critère arbitraire (dans le cas de "cheznous",
tu as choisi la taille) pour faire le tri. Je propose pour ma part
d'utiliser un critère arbitraire lui aussi, qui est le "mode". Il a
l'avantage, par rapport à la taille. d'être modifiable à la main image
par image.

Il y a quelque-chose que je ne comprends pas dans tout ça :

- soit on a un tri manuel où l'utilisateur détermine si l'image est une illustration ou pas au moment de la mise en ligne ou plus tard, auquel cas les mots clés me semblent tout indiqués car ça me semble juste être un cas particulier de tri des documents parmi d'autres

- soit on a un tri automatique sans intervention humaine d'un bout à l'autre de la chaine : il doit alors se faire sur l'insertion ou pas des images dans les flux textuels du site (illustration mais pas seulement puisqu'on peut filtrer aussi par extension), ce qui n'est pas le cas avec le fonctionnement actuel (une image peut être attachée en tant qu'image mais non insérée dans le corps d'un article, libre au squelette de gérer ce cas où pas, mais ça génère beaucoup de confusion au niveau utilisateur comme ça a été dit).

D'ailleurs à quoi correspond la propriété "vu" dans la table documents_liens et le critère associé ? Je ne trouve pas la doc...

Simon

Pierre_FICHES · Juillet 30, 2009, 6:23

Le 30 juil. 09 à 05:08, Simon Camerlo a écrit :

D'ailleurs à quoi correspond la propriété "vu" dans la table documents_liens et le critère associé ? Je ne trouve pas la doc...

Sauf erreur ça signifie le document est-il vu dans un objet ? (son raccourci est-il inséré dans un article par exemple)
si non vu=non
si oui vu=oui

pierre

Simon_Camerlo · Juillet 30, 2009, 7:48

Pierre Fiches a écrit :

Le 30 juil. 09 à 05:08, Simon Camerlo a écrit :

D'ailleurs à quoi correspond la propriété "vu" dans la table documents_liens et le critère associé ? Je ne trouve pas la doc...

Sauf erreur ça signifie le document est-il vu dans un objet ? (son raccourci est-il inséré dans un article par exemple)
si non vu=non
si oui vu=oui

pierre

Ah, ben c'est exactement ce que je décrivais comme comportement alors, je ne vois donc plus rien qui rende la propriété mode des documents obligatoire...

Simon