[spip-dev] popup

fil · Novembre 26, 2003, 12:51

Coucou,

c'est en style télégraphique car il y a beaucoup de choses à noter, et pas
bcp de temps

- A propos de http://www.spip.net/ecrire/synchro.php3
  le lien d'abonnement serait mieux en popup et à la bonne dimension ; il faut
  que je fasse sur listes.rezo.net une page-relais pour ça, je pense... mais
  je ne vois pas comment m'en sortir avec juste une URL... peut-être qu'un
  texte libre serait plus adapté à des cas différents ?

- Je ne vois pas l'intérêt, par ailleurs, de mettre une suggestion de
configuration à cet endroit : en effet si jamais tu envoies les mails à une
adresse personnelle, ce truc va te gonfler.

- iCal : le calendrier est vraiment vide, et ne correspond pas à l'intitulé
  si le feed iCal ne permet pas de suivre les annonces de "trucs à faire" :
  articles, brèves etc. proposés/publiés, messages du forum à valider, etc.
  Idem pour RSS. En même temps on ne veut probablement pas tout imposer, ou
  pas forcément dans un seul feed. Donc il faut un truc très configurable,
  où je coche les familles de choses qui m'intéressent, et je récupère un
  URL de suivi... que je peux diffuser (calendrier des publications) ou pas
  (calendrier des messages à modérer) [c'est l'intérêt d'une clé différente
  selon ce qui est demandé]

- suivi rss : James (aka Kliké) et moi avons travaillé sur un projet de feed
  RSS ; mais je n'ai pas eu de nouvelles de James depuis un bail, je ne sais
  pas où ça en est. C'était surtout pour tester les idées exprimées
  ci-dessus.

- documents liés : la suppression des images et documents qui ne sont plus
  liés est une grosse connerie, tant qu'on ne sait pas vérifier s'ils ne
  sont pas appelés depuis d'autres articles. A mon sens la stratégie devrait
  être la suivante :
    * permettre de partager des docs/images d'un article à un autre (ce qui
      est actuellement permis, mais avec la menace d'incohérences en cas de
      suppression dans un article).
    * noter tous les liens entre article et images, docs (et mêmes liens
      internes et externes)
    * quand un document/image est supprimé d'un article, vérifier s'il n'a
      pas un autre lien ; si oui, changer son lien principal ; si non, le
      supprimer effectivement du disque

Personnellement je n'ai pas mis à jour les sites les plus importants
depuis qu'il y a cette fonction de suppression un peu brutale.

- recopie d'article pour la traduction (et l'élimination de mon patch d'hier
  soir) :
    * sur l'argument du risque d'incohérence sur les images : voir ci-dessus,
      car le problème n'est pas spécifique à la question des traductions
    * sur l'argument du bug : je veux bien regarder, mais quel était ce bug ?
        - tu évoques le problème d'accès, tu l'avais réglé
        - un problème de duplication d'article, a priori c'est quand on fait
          "back" pour corriger alors qu'on était dans la phase "new" de
          création d'un article (bug connu, et indépendant de l'histoire de
          la recopie d'article)

-- Fil

63438612493668b99328 · Novembre 26, 2003, 1:18

Coucou,

c'est en style télégraphique car il y a beaucoup de choses à noter, et pas
bcp de temps

- A propos de http://www.spip.net/ecrire/synchro.php3
  le lien d'abonnement serait mieux en popup et à la bonne dimension ; il faut
  que je fasse sur listes.rezo.net une page-relais pour ça, je pense... mais
  je ne vois pas comment m'en sortir avec juste une URL... peut-être qu'un
  texte libre serait plus adapté à des cas différents ?

Heu, non, pas de popup... C'est juste l'URL de la liste qui est mal
configurée sur spip.net, il vaut mieux renvoyer vers le listinfo.

- documents liés : la suppression des images et documents qui ne sont plus
  liés est une grosse connerie, tant qu'on ne sait pas vérifier s'ils ne
  sont pas appelés depuis d'autres articles. A mon sens la stratégie devrait
  être la suivante :
    * permettre de partager des docs/images d'un article à un autre (ce qui
      est actuellement permis, mais avec la menace d'incohérences en cas de
      suppression dans un article).

Bah. Cela veut dire que quand on change les caractéristiques d'un
document dans un article (légende, etc.) cela se répercute
silencieusement partout ailleurs (sans qu'on en soit informé).

A la rigueur on pourrait _dupliquer_ l'entrée correspondante dans la
table spip_documents, vers le même fichier (ce qui permet aussi de
partager des images avec des légendes différentes selon la langue...).

    * quand un document/image est supprimé d'un article, vérifier s'il n'a
      pas un autre lien ; si oui, changer son lien principal ; si non, le
      supprimer effectivement du disque

S'il y a une notion de "lien principal" et de "liens secondaires", ça va
devenir incompréhensible....

a+

Antoine.

fil · Novembre 26, 2003, 1:28

Heu, non, pas de popup... C'est juste l'URL de la liste qui est mal
configurée sur spip.net, il vaut mieux renvoyer vers le listinfo.

bof ; c'est pas multilingue, déjà

> - documents liés : la suppression des images et documents qui ne sont plus
> liés est une grosse connerie, tant qu'on ne sait pas vérifier s'ils ne
> sont pas appelés depuis d'autres articles. A mon sens la stratégie devrait
> être la suivante :
> * permettre de partager des docs/images d'un article à un autre (ce qui
> est actuellement permis, mais avec la menace d'incohérences en cas de
> suppression dans un article).

Bah. Cela veut dire que quand on change les caractéristiques d'un
document dans un article (légende, etc.) cela se répercute
silencieusement partout ailleurs (sans qu'on en soit informé).

C'est un peu le principe des mots-clés, des intitulés des rubriques, des
noms et bios des auteurs, etc. C'est des objets liés entre eux, le concept
est connu, simple et raisonnable.

A la rigueur on pourrait _dupliquer_ l'entrée correspondante dans la
table spip_documents, vers le même fichier (ce qui permet aussi de
partager des images avec des légendes différentes selon la langue...).

bonjour l'usine à gaz

> * quand un document/image est supprimé d'un article, vérifier s'il n'a
> pas un autre lien ; si oui, changer son lien principal ; si non, le
> supprimer effectivement du disque

S'il y a une notion de "lien principal" et de "liens secondaires", ça va
devenir incompréhensible....

Personne n'est obligé de comprendre ; c'est comme les liens fichiers sur
unix : ça marche, et tu n'es pas obligé de savoir pourquoi ni comment pour
l'utiliser. En gros on n'efface réellement les données que si le dernier
lien disparaît. Un document est affecté à l'endroit où il a été uploadé, et
ce sont les droits de cet article qui déterminent les droits d'édition du
document. Et dans le cas où un document multi-lié est effacé de cet article,
il "tombe" dans l'escarcelle d'un autre (au hasard...), ce qui est tout de
même MIEUX que de l'effacer carréement sans prévenir !

La poubellisation actuelle est tout à fait déraisonnable si on ne vérifie
pas que le document n'est pas appelé par ailleurs. A la limite je
préférerais une "galerie" comme il en avait été proposée une ici à une
époque, avec une vérification visuelle de ce qui est dans la "poubelle", et
validation manuelle des suppressions.

-- Fil

63438612493668b99328 · Novembre 26, 2003, 1:45

C'est un peu le principe des mots-clés, des intitulés des rubriques, des
noms et bios des auteurs, etc. C'est des objets liés entre eux, le concept
est connu, simple et raisonnable.

Pour l'instant les documents n'ont pas d'existence hors de l'objet
auquel ils sont liés (notamment, il n'y a pas de gestion globale des
documents, ni de leurs droits d'accès). Contrairement aux autres objets
que tu cites.

Donc, vouloir que les documents soient partagés alors qu'il n'y a aucun
endroit qui permette de gérer cette mise en commun, c'est un peu
incohérent sur le plan de l'interface.... D'ailleurs, je me demande
comment font pour s'y retrouver ceux qui partagent des documents entre
plusieurs articles ??

Personne n'est obligé de comprendre ; c'est comme les liens fichiers sur
unix : ça marche, et tu n'es pas obligé de savoir pourquoi ni comment pour
l'utiliser. En gros on n'efface réellement les données que si le dernier
lien disparaît. Un document est affecté à l'endroit où il a été uploadé, et
ce sont les droits de cet article qui déterminent les droits d'édition du
document.

C'est carrément délirant : pourquoi un article plutôt qu'un autre ?
Comment je sais quel est l'article "principal" ? Je dois changer
d'article principal pour changer les droits d'édition sur le document ?
Ca n'a rien à voir avec le concept "simple et raisonnable" dont tu
parlais plus haut, et rien à voir non plus avec la façon dont
fonctionnent les auteurs etc.

(et ce n'est pas comme ça que marchent les liens sous Unix : il n'y a
pas de répertoire "principal" quand tu crées plusieurs liens vers un
fichier ; chaque lien est à égalité avec les autres quand tu fais "ln" -
pas "ln -s")

Et dans le cas où un document multi-lié est effacé de cet article,
il "tombe" dans l'escarcelle d'un autre (au hasard...)

Oui c'est très logique et compréhensible les documents qui changent de
propriétaire et de droits d'édition au hasard

A la limite je
préférerais une "galerie" comme il en avait été proposée une ici à une
époque, avec une vérification visuelle de ce qui est dans la "poubelle", et
validation manuelle des suppressions.

C'est une solution, même si je trouverais mieux qu'on se mette d'accord
sur un système automatique et raisonnable.

a+

Antoine.

fil · Novembre 26, 2003, 1:50

(et ce n'est pas comme ça que marchent les liens sous Unix : il n'y a
pas de répertoire "principal" quand tu crées plusieurs liens vers un
fichier ; chaque lien est à égalité avec les autres quand tu fais "ln" -
pas "ln -s")

Je sais bien, mais c'était ce que je voyais de plus approchant, comme image.
Il n'y a pas non plus de gestion de droits séparés dans les liens unix,
hein...

C'est une solution, même si je trouverais mieux qu'on se mette d'accord
sur un système automatique et raisonnable.

J'ai un problème de méthode, avec ce que tu me dis là. Je vois que tu
*commites* des trucs déraisonnables (et même carrément délirants, puisque
j'ai dû réparer un gros site qui avait perdu toutes ses vignettes), et tu
me réponds "carrément délirant" quand je *parle* de pistes de solution.

Je ne vois pas d'autre solution raisonnable que 1) celle que je propose ou à
peu près, qui consiste à gérer les docs comme les auteurs, mots-clés etc,
avec une interface supplémentaire (galerie)... ou 2) celle qui existait au
tout-début (il était impossible d'appeler un document depuis un autre
endroit que l'article où il avait été uploadé). En attendant je propose de
supprimer la poubellisation automatique que tu as installée.

-- Fil

d09b37f86e750e3c8633 · Novembre 26, 2003, 1:56

mon expérience perso = c'est l'enfer pour se rappeler dans quel article il
ont été charge initialement lorsque l'on veut modifier une légende ... ceci
dit cette fonction de partage est réellement pratique des que l'on a une
base image un peu importante (genre 1000 doc/ima) cela permet d'illustrer
facilement un nouvel article, et sans alourdir l'hebergement. surtout que
les manutentions de chargement/commentaire des images dans Spip ne sont pas
tres rapides et que beaucoup de rédacteurs ne savent pas préparer celle ci
pour le web.

il est clair qu'un outil de travail en liste sur les documents et images
(galerie ?) serait tres pratique ... le besoin est récurent, aussi des
tentatives on déjà été proposée comme ici
http://support.cassiopea.org/spip/spip-tech.shtml#listimg
mais ce n'est pas encore ca

@+ et merci les devs
Nicolas RIQUOIS
http://www.pucroller.com

Paolo · Novembre 26, 2003, 2:03

Antoine et Fil écrivaient :

> A la rigueur on pourrait _dupliquer_ l'entrée correspondante dans la
> table spip_documents, vers le même fichier (ce qui permet aussi de
> partager des images avec des légendes différentes selon la langue...).

bonjour l'usine à gaz

En tout cas cela serait très utile : pouvoir traduire les légendes sans
devoir multiplier les copies d'images. Cela rendrait facile aussi de changer
une image dans toutes les langues, sans toucher aux légendes déjà traduites
en xx langues. (Par exemple une image qui porte la légende "Recontres de
jeunes" / "Youth Meeting" / "Jugendtreffen"... - je vais vouloir changer
l'image chaque quelques mois pour donner un aspect plus vivant au site, sans
changer les légendes que les traducteurs ont mises en place.)

> > * quand un document/image est supprimé d'un article, vérifier s'il

n'a

> > pas un autre lien ; si oui, changer son lien principal ; si non,

le

> > supprimer effectivement du disque
>
> S'il y a une notion de "lien principal" et de "liens secondaires", ça va
> devenir incompréhensible....

Personne n'est obligé de comprendre ; c'est comme les liens fichiers sur
unix : ça marche, et tu n'es pas obligé de savoir pourquoi ni comment pour
l'utiliser. En gros on n'efface réellement les données que si le dernier
lien disparaît. Un document est affecté à l'endroit où il a été uploadé,

et

ce sont les droits de cet article qui déterminent les droits d'édition du
document. Et dans le cas où un document multi-lié est effacé de cet

article,

il "tombe" dans l'escarcelle d'un autre (au hasard...), ce qui est tout de
même MIEUX que de l'effacer carréement sans prévenir !

La poubellisation actuelle est tout à fait déraisonnable si on ne vérifie
pas que le document n'est pas appelé par ailleurs. A la limite je
préférerais une "galerie" comme il en avait été proposée une ici à une
époque, avec une vérification visuelle de ce qui est dans la "poubelle",

et

validation manuelle des suppressions.

Cette dernière suggestion - si je la comprends bien - est de ne pas
supprimer les images non-reliées, mais d'avoir une fonction administrative
qui liste les images non-reliées. Cela permettrait à l'administrateur soit
de les supprimer, soit d'en garder certains pour un usage futur. A mon sens
ce contrôle manuel serait la meilleure option. (Par exemple, j'ai un certain
nombre de pages qui reviennent chaque année pour quelques semaines. Le texte
est différent, mais la page peut utiliser le même logo ou image que l'année
avant. Dans ce cas, je laisserai l'image sur le serveur d'une année à
l'autre.)

Paolo

63438612493668b99328 · Novembre 26, 2003, 2:09

J'ai un problème de méthode, avec ce que tu me dis là. Je vois que tu
*commites* des trucs déraisonnables (et même carrément délirants, puisque
j'ai dû réparer un gros site qui avait perdu toutes ses vignettes)

Mea culpa, mais c'était un bug dans le commit, qui a été corrigé.

Je ne vois pas d'autre solution raisonnable que 1) celle que je propose ou à
peu près, qui consiste à gérer les docs comme les auteurs, mots-clés etc,
avec une interface supplémentaire (galerie)...

Possible mais il faut le coder et trouver un moyen raisonnable de gérer
des milliers de documents et d'images éparpillés dans le site. Pas
évident, surtout avec une interface HTML...

Ca ne règle pas non plus la question des droits d'accès aux documents
(on ne peut pas appliquer les mêmes règles que pour les mots-clés, qui
sont trop strictes).

ou 2) celle qui existait au
tout-début (il était impossible d'appeler un document depuis un autre
endroit que l'article où il avait été uploadé).

J'en ai une autre :
3) afficher un warning dans la page de l'article quand celui-ci appelle
des <img> ou <doc> créés dans un autre article. Le warning (qui explique
gentiment pourquoi c'est une mauvaise idée de partager les <docXXX>) est
assorti d'un bouton permettant de "dupliquer les documents" (tous à la
fois, hein ;-)).

a+

Antoine.

df6b43a347612b8355d3 · Novembre 26, 2003, 2:55

Antoine wrote:
(...)

J'en ai une autre :
3) afficher un warning dans la page de l'article quand celui-ci appelle
des <img> ou <doc> créés dans un autre article. Le warning (qui explique
gentiment pourquoi c'est une mauvaise idée de partager les <docXXX>) est
assorti d'un bouton permettant de "dupliquer les documents" (tous à la
fois, hein ;-)).

suis pas certains que ce soit la bonne solution de dupliquer, on pourrait pas imaginer que tous les docs soient rattachés aux articles (ou rub) plutot que les intégrer à l'article ?
ce qui permettrait (peut-être) de rattacher un doc à plusieurs articles, avec une interface qui montre ou les doc sont rattachés, déplacer des docs d'un article à un autre, etc ...
les traducteurs dirons le tout multilingue, d'autre voudrons pouvoir ranger les doc dans des cathégories, que sais-je encore
je sais pas si ça peut être envisageable

sur un article on aurrait un truc :
- joindre un doc -> rajoute un nouveau doc et le rattache à l'article
- rattacher un doc existant -> popup pour choisir le doc

bon comme d'hab n'étant pas développeur je ne me rends pas bien compte de ce que ça enguage autour sur le plan technique

a+

JLuc · Novembre 26, 2003, 6:45

Nicolas RIQUOIS a écrit :

D'ailleurs, je me demande
comment font pour s'y retrouver ceux qui partagent des documents entre
plusieurs articles ??

Je linke si besoin à tout va
et avec confiance ...
inch allah !

Mais ce matin, je voulais des fonds de page différents selon les pages, et les logos étaient déjà occupés.
Alors, j'ai créé un article "FONDS DE PAGE" dans un secteur "AUXI" à part pour contenir en document lié spipement toutes les images fond de page. (cet article ne sera jamais affiché QUE dans la partie privée)
Et ceux ci sont référencés à la mano dans les vrais articles par le champ #PS pour tout vous dire.

JLuc

s_t_e_f · Novembre 26, 2003, 11:28

Possible mais il faut le coder et trouver un moyen raisonnable de gérer
des milliers de documents et d'images éparpillés dans le site. Pas
évident, surtout avec une interface HTML...

Il y a une idée un peu comme ça dans Delia, un CMS qu'on m'a présenté à l'interne de ma boîte un jour (c'est une boîte externe qui a fait ça mais j'ai perdu son nom, à l'occasion je vous le retrouve).

Ils ont un système de gestion de documents intéressant :
- liste de tous les docs centralisée
- appel d'un doc dans un article si besoin

Par contre je ne vois pas bien comment ils veulent pouvoir gérer des grosses quantités de documents de manière sensée (on y revient toujours).

Et de même je ne vois pas bien comment ils espèrent gérer les documents obsolètes vers lesquels plus aucun article ne pointe : comment les identifier facilement ?

Mais c'est vrai que les contributeurs des sites qu'on a sur notre intranet disent tous que du coup, dans de la com institutionnelle, on aimerait que chauqe article qui parle, par exemple, d'un organigramme, comporte simplement le même organigramme plutôt que de le dupliquer ou de bidouiller en allant chercher son id dans l'article auquel ile st associé.

Bon je vais me coucher, je sais pas coment vous faites... ou alors vous mâchouillez les grains de café sans les moudre ?
Bonne nuit les écureuils.