[spip-dev] Fonction INCLURE

Salut,

J'utilisais la fonction INCLURE que je ne sais plus qui avait développée et
qu'il fallait mettre dans le fichier inc-calcul-squel.php3.
Malheureusement cette fonction n'a pas été incorporée dans les nouvelles
versions de spip.
De plus quand je la copie désormais dans le nouveau fichier
inc-calcul-squel.php3, cela ne marche plus...
Serait-il possible d'inclure cette fonction dans les prochaines versions,
elle est très pratique puisqu'elle permet d'inclure un squelette dans un
autre.

Heu, tu sais, on ne peut pas assurer la compatibilité avec des choses
extérieures à SPIP... Il est possible qu'un jour on fasse une fonction
d'inclusion, mais il n'y a aucune raison qu'elle fonctionne de la même
façon que celle que tu utilisais.

Je suis vraiment désolé, mais on ne peut pas te donner d'assurance que
ton problème sera résolu ;))

Amicalement

Antoine.

Salut,

La nouvelle interface des documents pose plusieurs problèmes.

1) Elle est extrêmement lourde. En effet la page article, qui
était déjà chargée (voir tous les efforts faits depuis des mois
pour essayer de l'alléger), l'est encore plus maintenant qu'elle
affiche l'intégralité des documents et formulaires associés.
C'est encore aggravé par le fait que les images (vignettes et/ou
réductions) ne sont pas masquées par l'interface dépliable.
Du coup, l'utilisateur d'accès RTC ou de machine lente va
s'arracher les cheveux ; déjà je me souviens de la lenteur
d'affichage de l'interface de SPIP 1.3 sur les machines de la
No-Zelig, quand on y a fait une petite formation avec Arno....

J'insiste sur cet aspect : à chaque fois qu'on a droit à des
commentaires sur l'interface, ce n'est pas pour dire qu'elle
est inélégante mais bien qu'elle est lourde techniquement
(machines peu puissantes, connexions lentes, comme souvent dans
les associations) ou visuellement (reproche récurrent sur uzine,
avec de longs forums de validation). Si on insère toute une
artillerie de gestion des documents (avec quatre documents,
ça prend déjà plus d'une page en hauteur), ça empire. De même,
si on doit recharger toute la page articles à chaque fois qu'on
change un paramètre d'un document, c'est *très* inconfortable.
On ne peut pas avoir un SPIP qui n'est utilisable que sur les
grosses configs.

2) Elle est compliquée. Sur la page articles.php3, on peut télécharger
des documents. Les images seront traitées comme des documents à
part entière avec création automatique d'une vignette dont les
caractéristiques sont configurées de façon globale pour tout le
site. On ne peut pas y télécharger d'images utilisables dans l'article.

Sur la page articles_edit.php3, si l'on télécharge des images elles
seront au contraire automatiquement considérées comme vignettes
(images affichables). Cependant elles apparaissent automatiquement
dans articles.php3 si jamais elles ne sont pas inclues dans l'article
(fonctionnement du flag inclus, que je viens de supprimer au niveau
de la base). La logique est difficile à saisir et à maîtriser.

(Il y a d'autres détails : par exemple, on ne plus uploader de vignette
à partir du dossier upload....)

Pour résoudre ces deux points, il me semble qu'un retour à une
fenêtre séparée, comme c'était le cas auparavant, est la meilleure
solution. Cela permet d'avoir un espace dédié pour l'affichage des
documents, avec une interface unique et générale, et de gérer les
documents de façon beaucoup plus fluide (affichage beaucoup plus
léger). Accessoirement ça rend la chose beaucoup plus adaptable
pour l'ajout de documents à d'autres types d'objets (messages
internes...). L'idée est aussi d'utiliser une largeur d'interface
permettant plus tard d'avoir une interface centralisée de gestion
des documents pour l'utilisateur (colonne principale).

Il faudrait donc rétablir l'ancienne interface, y ajouter les
nouvelles fonctionnalités (création de vignette semi-auto), la
rendre plus parlante (messages d'explication ajoutés par Arno) et
éventuellement l'enjoliver graphiquement.

a+

Antoine.

Il faudrait donc rétablir l'ancienne interface, y ajouter les
nouvelles fonctionnalités (création de vignette semi-auto), la
rendre plus parlante (messages d'explication ajoutés par Arno) et
éventuellement l'enjoliver graphiquement.

+1

-Nicolas

Ca c'est bien vrai, c'est **très** inconfortable, même que j'ai une liaison rapide !
Par contre, je trouve le système de téléchargement extra, le "lot à télécharger" égalemement (à condition qu'on ait des dossiers de lot pour télécharger selon les articles et/ou rubriques).

Côté apparence, les trois ou quatre lignes de choix (icônes ou pas) en haut me bouffent les trois quarts de l'écran, la sroll systématique pour arriver à faire ce qu'on veut est vraiment handicapant.

Mais on pourrait aussi élargir le cadre consacré à l'article, réduire les polices, les blancs des données entre les colonnes, ceux du haut (titre, descriptif, etc.), ceux entre les cadres, le modifier cet article du bas collé à côté de quelque chose pour gagner une épaisseur.

Les photos et vignettes étaient bien à gauche (moins occupé que dessous l'article, à droite)
Je crois qu'il faut vraiment chercher par là aussi.
Les icônes seraient plus sobres, elles pourraient être plus petites.

Pour l'aspect, j'aime beaucoup (c'est très reposant) le gris de fond d'en bas.

Mais le rayé d'en haut est pour les lapins (bis).

PS : on peut mettre des images dans le descriptif ???
[ttp://rezo.net/~arno/article.php3?id_article=8]

Salut,

Je viens de supprimer le flag "inclus" dans la table spip_documents.
En effet c'était :

- inutile : il suffit de n'afficher en-dessous de l'article que les
docs qui n'ont pas de vignette
- horriblement contre-intuitif : si on téléchargeait un document
et qu'ensuite on ne l'incluait pas dans l'article (changement de
décision, test...), il se retrouvait automatiquement sous l'article !
- techniquement pas joli du tout : ça introduisait une modif regulière
de la base de données dans une fonction d'affichage

On peut très bien se débrouiller en n'affichant séparément que les
documents qui n'ont pas de vignette. De plus, pour un portfolio,
il est évident qu'on fera un squelette spécifique à la rubrique,
qui affichera toutes les images en-dessous de l'article.

Je pense tout le contraire. C'est une fonction très pratique, et de toute façon optionnelle (si tu ne mets pas {inclus=''} dans tes boucles, tu obtiens bien ton fonctionnement. Elle ajoute une souplesse d'utilisation réellement utile pour le webmestre qui veut contrôler finement son interface graphique. Il est absolument _indispensable_ de pouvoir ne pas afficher en double des liens qui sont déjà présents dans l'article. L'exemple du portfolio est tout de même évident: sans "inclus", ça n'est plus réalisable simplement: afficher les documents sans vignette ne convient pas du tout pour un portfolio, et devoir réaliser un squelette spécifique pour une chose aussi simple ne convient pas plus. La solution du "inclus" a au moins le mérite de fonctionner correctement et simplement.

- inutile; pas d'accord, bien au contraire, je pense que c'est indispensable pour bien maîtriser son interface;
- contre-intuitif (si on laisse un document, il apparaît en ligne); ben oui, de la même façon que si on laisse du texte dans son document et qu'on le publie alors qu'en fait, on l'avait mis là pendant la rédaction, hé ben il est publié... Si on ajoute une information à un article, hé ben elle est publiée, ça n'a rien de "contre-intruitif";
- techniquement pas joli. Peut-être, je veux bien le croire. Alors il faut trouver une solution technique élégante, pas supprimer une fonction extrêmement pratique.

Salut,

La nouvelle interface des documents pose plusieurs problèmes.

Evidemment qu'elle n'est pas parfaite. Mais pour l'instant, c'est le plus efficace. La fenêtre séparée est bien pire, et totalement incompréhensible. Evidemment qu'il faut améliorer l'interface, mais la fenêtre est réellement la pire des solutions. L'information nécessaire doit être présente à l'endroit où on en a besoin, et une autre fenêtre est l'endroit le plus éloigné qu'on puisse imaginer.

1) Elle est extrêmement lourde.

Ca se travaille. Elle prend de la place, mais elle n'est pas extrêmement lourde: une image déjà chargée ne se charge pas à nouveau. Le cas chiant, c'est un article déjà très très long qu'il faut recharger; et là, le problème c'est le texte, et non les vignettes (qui sont déjà en cache), problème qu'on a déjà de toute façon pour gérer le logo, changer la date, ajouter un auteur, gérer les mots-clés, participer aux forums... sous un très gros article. Donc ça n'est pas spécifique à l'interface des images, c'est propre aux textes longs; et on ne va pas créer des nouvelles fenêtres pour tous ce qui se rattache à un article, tout de même...

2) Elle est compliquée.

Hé ben ça se travaille. Mais la page séparée est encore plus incompréhensible.

Pour résoudre ces deux points, il me semble qu'un retour à une
fenêtre séparée, comme c'était le cas auparavant, est la meilleure
solution.

Autant, améliorer l'interface actuelle, oui, sans problème, évidemment, l'alléger, la rendre plus claire... Mais la fenêtre séparée, vraiment, c'est la pire des solutions. Ca déplace le problème sans le résoudre (la différence entre images, vignettes, documents n'est pas simple), ça éloigne l'information utile de l'endroit où elle doit être utilisée, ça introduit une nouvelle méthode d'interface (le popup), ça ajoute encore une fenêtre (je travaille déjà en permanence avec minimum 3 ou 4 fenêtres affichées dans mon butineur, j'attends vraiment pas de SPIP qu'il m'en ouvre d'autres).

ARNO*

ARNO* a écrit :

>Salut,
>
>La nouvelle interface des documents pose plusieurs problèmes.

>2) Elle est compliquée.

Hé ben ça se travaille. Mais la page séparée est encore plus incompréhensible.

>Pour résoudre ces deux points, il me semble qu'un retour à une
>fenêtre séparée, comme c'était le cas auparavant, est la meilleure
>solution.

Autant, améliorer l'interface actuelle, oui, sans problème,
évidemment, l'alléger, la rendre plus claire... Mais la fenêtre
séparée, vraiment, c'est la pire des solutions.

totalement d'accord…

Ca déplace le problème sans le résoudre (la différence entre images, vignettes,

documents n'est pas simple), ça éloigne l'information utile de
l'endroit où elle doit être utilisée,

oui…

ça introduit une nouvelle méthode d'interface (le popup),

qui complique la manip. en effet…

ça ajoute encore une fenêtre (je
travaille déjà en permanence avec minimum 3 ou 4 fenêtres affichées
dans mon butineur, j'attends vraiment pas de SPIP qu'il m'en ouvre
d'autres).

d'accord avec ARNO*.

Attentivement.

simo

C'est une bonne idée, en fait... d'inclure une directive d'inclusion de
code (html ou php) mais qui puisse être cahé.

Un bête <? include"toto.php3" ?> n'est pas caché.
Imaginons qu'un #INCLURE "fichier.html" peremtte de factoriser des bouts
de code, et que cela puisse être mis dans le cache (pour ne pas le
recalculer à chaque fois)

Non ? Je dis une connecrie ?

Salut,

> L'exemple du portfolio est tout de même évident: sans

"inclus", ça n'est plus réalisable simplement: afficher les documents sans vignette ne convient pas du tout pour un portfolio, et devoir réaliser un squelette spécifique pour une chose aussi simple ne convient pas plus.

Ben, si. Tu ne fais pas le même squelette si tu veux :

- afficher un article contenant des documents référencés via des vignettes
(auquel cas tu indiques l'endroit où afficher ces vignettes dans l'article),
et d'autres accessibles séparément (auquel cas il est logique de ne pas
ajouter de vignette).

- ou afficher un "portfolio", c'est-à-dire une série d'images liées à
un article qui n'est qu'une coquille vide ; et pour lesquelles tu as
envie d'une présentation spécifique qui n'a aucune raison de convenir
au cas général.

C'est la même différence entre une rubrique qui sert à présenter des
articles, et une rubrique qui sert à présenter des sites référencés.
Tu ne fais pas le même squelette pour présenter trois liens en vrac,
ou pour réaliser un annuaire structuré.

On sait très bien que les squelettes par défaut ne répondent à aucun
besoin spécifique, je ne vois pas trop pourquoi le portfolio constituerait
une exception. Ceux qui veulent faire une galerie doivent faire une
mise en page à cet effet, c'est normal.

- contre-intuitif (si on laisse un document, il apparaît en ligne); ben oui, de la même façon que si on laisse du texte dans son document et qu'on le publie alors qu'en fait, on l'avait mis là pendant la rédaction, hé ben il est publié... Si on ajoute une information à un article, hé ben elle est publiée, ça n'a rien de "contre-intruitif";

Non, désolé. Si j'enlève le <img1|left> de mon article, l'image s'affichera
en-dessous de l'article avec ton système, alors qu'il est évident que par
ce geste je voulais ne plus l'afficher du tout (et je n'ai pas envie, et
n'ai pas le réflexe, de supprimer totalement le document parce que je peux
avoir envie de le remettre par la suite).

C'est la même chose dans l'espace privé : si on inclut un document dans
l'article, alors son formulaire n'est plus accessible dans la page
articles.php3 mais uniquement articles_edit.php3 !

Evidemment qu'elle n'est pas parfaite. Mais pour l'instant, c'est le plus efficace. La fenêtre séparée est bien pire, et totalement incompréhensible. Evidemment qu'il faut améliorer l'interface, mais la fenêtre est réellement la pire des solutions. L'information nécessaire doit être présente à l'endroit où on en a besoin, et une autre fenêtre est l'endroit le plus éloigné qu'on puisse imaginer.

Le problème est de réaliser un compromis entre cette exigence et l'exigence
de légèreté. Là on a une interface de documents qui devient vite énorme
dès qu'il y en a trois ou quatre, et qui pénalise à la fois la modification
des documents et celle de l'article.

En plus l'affichage est de plus en plus exigu et ratatiné au fur et à mesure
qu'on essaie d'y ajouter des fonctionnalités, ce qui rend la chose peu commode.
(polices de caractères minuscules presque illisibles, formulaires rikiki,
et colonne super étroite dans la page articles_edit.php3).

Donc ça n'est pas spécifique à l'interface des images, c'est propre aux textes longs; et on ne va pas créer des nouvelles fenêtres pour tous ce qui se rattache à un article, tout de même...

En l'occurence on a une fonctionnalité riche et complexe, qui justifie
largement une page séparée. Il ne s'agit pas simplement de taper le
nom d'un auteur pour l'ajouter à une liste sous forme de petit tableau
HTML.

Ca déplace le problème sans le résoudre (la différence entre images, vignettes, documents n'est pas simple), ça éloigne l'information utile de l'endroit où elle doit être utilisée, ça introduit une nouvelle méthode d'interface (le popup), ça ajoute encore une fenêtre (je travaille déjà en permanence avec minimum 3 ou 4 fenêtres affichées dans mon butineur, j'attends vraiment pas de SPIP qu'il m'en ouvre d'autres).

De même l'utilisateur de machine ou de connexion lente peut dire :
"ma machine prend déjà cinq secondes à afficher la page d'un article,
je ne veux pas que ça double encore quand je veux gérer mes documents".
Je veux bien qu'on laisse ça sur la même page, mais je ne vois vraiment
pas comment s'en sortir pour avoir quelque chose d'utilisable. Même
sur une configuration moderne, c'est pénible à utiliser. Je suis bien
d'accord que les pop-ups ne sont pas la panacée, et en temps normal
je n'aime pas trop ça non plus, mais là c'est encore ce qu'il y a de
moins incommode.

a+

Antoine.

Si j'enlève le <img1|left> de mon article, l'image s'affichera
en-dessous de l'article avec ton système, alors qu'il est évident
que par ce geste je voulais ne plus l'afficher du tout (et je n'ai
pas envie, et n'ai pas le réflexe, de supprimer totalement le
document parce que je peux avoir envie de le remettre par la suite).

Un exemple encore plus frappant est celui de ceux qui bossent en
rédigeant sur Word et passent ensuite par la macro gentillement
proposée pour passer en format SPIP. Ils attachent le doc de référence
à l'article pour le partager avec d'autres rédacteurs, mais ne veulent
pas le mettre sur le site public.

-Nicolas

L'intérêt de mettre en cache un bout de code qui est déjà lui-même en cache ne m'apparaît pas des masses. Au contraire. Si "toto.php3" est une page avec des boucles SPIP, il dispose de son propre cycle de cache. Et l'inclusion PHP, ça ne doit pas bouffer des masses, non? Avantage de laisser toto.php3 avec son propre cycle de cache: par exemple tu veux afficher en permanence sur ton site la liste des dernières brèves publiées, en imaginant un taux de rafraîchissement des brèves très rapide (genre une brève toutes les heures) dans un très gros site, avec une tripotée d'articles qui n'évoluent pas; hé ben avec le "include", tes pages d'articles peuvent avoir une périodicité longue (genre une semaine en cache), mais affichent toujours la liste des toutes dernières brèves publiées (puisque le fichier inclus a, lui, une périodicité courte - genre 2 heures).

Je signale qu'un moyen de contourner la limitation du include("toto.php3"), c'est de passer par le serveur Apache plutôt que d'aller chercher directement le fichier.
<?
include("http://www.monsite.com/toto.php3");
?>

On peut évidemment utiliser les variables des boucles:
<?
include("http://www.monsite.com/haut-rubrique.php3?id_rubrique=#ID_RUBRIQUE");
?>

Evidemment, ça ne doit pas fonctionner en safe mode.

ARNO*

Euh... ce n'est pas ce que je disais, mais ta proposition me paraît
sexy.

Je voulais inclure un fichier type
--- toto.php3
<? $toto=5; echo $toto ?>