Bon, je ne comprends rien au code ni au débat. Voilà ce que je crois
comprendre
Coucou,
Fil wrote:
Bon, je ne comprends rien au code ni au débat
Beuh :)))
1) Je suis convaincu qu'{inclus} était un bon champ dans spip_documents, et
que le fait que le doc apparaisse dans le texte doit être utilisable de
manière à n pas répéter le doc dans la liste des docs attachés sous
l'article.
- pourquoi, dans une mise en page spécifique, vouloir à la fois des docs
dans l'article et des docs en-dessous ? pourquoi, de plus, ne pas
se satisfaire de la sélection selon la présence d'une vignette ou non ?
- pourquoi détester cette redondance ? au contraire c'est bien pratique
d'avoir un récapitulatif en-dessous de l'article.
- pourquoi ce type de choix de mise en page devrait-il apparaître dans
l'espace privé ? (avec un formulaire qui n'indique que les documents
pas déjà inclus dans le texte, ce qui est incompréhensible pour quelqu'un
qui ne suit pas la même logique que toi)
2) Antoine a un bon argument pour dire qu'il n faut pas modifier inclus à
chaque lecture de l'article dans articles.php3
Bon, j'ai trouvé une solution, si ça ne vous déplaît pas : il n'y a pas
de champ dans la base et on utilise {doublons} à la place. C'est toujours
aussi inutile à mon avis, mais au moins c'est indolore techniquement 
3) pourquoi reste-t-il des requetes portant sur ce champ alors que inc_base
supprime le champ en question ?
Parce que, tout le monde n'étant pas d'accord, j'ai préféré ne pas tout
virer
a+
Antoine.
@ Antoine Pitrou <antoine@rezo.net> :
- pourquoi, dans une mise en page spécifique, vouloir à la fois des docs
dans l'article et des docs en-dessous ? pourquoi, de plus, ne pas
se satisfaire de la sélection selon la présence d'une vignette ou non ?
"à la fois" ou bien "soit...soit" ou enore "ou...et/ou" ne signifient pas la
même chose.
- pourquoi détester cette redondance ? au contraire c'est bien pratique
d'avoir un récapitulatif en-dessous de l'article.
Je n'ai rien là-contre. Mais rien ne t'oblige à avoir {inclus=non} dans ton
squelette !
- pourquoi ce type de choix de mise en page devrait-il apparaître dans
l'espace privé ? (avec un formulaire qui n'indique que les documents
pas déjà inclus dans le texte, ce qui est incompréhensible pour quelqu'un
qui ne suit pas la même logique que toi)
Là, je suis d'accord, l'espace privé doit permettre d'intervenir de manière
égale sur les documents et les images, inclus ou non.
>2) Antoine a un bon argument pour dire qu'il n faut pas modifier inclus à
>chaque lecture de l'article dans articles.php3Bon, j'ai trouvé une solution, si ça ne vous déplaît pas : il n'y a pas
de champ dans la base et on utilise {doublons} à la place. C'est toujours
aussi inutile à mon avis, mais au moins c'est indolore techniquement
Ce qu'Arno est en train de commiter, j'ai bien l'impression..
>3) pourquoi reste-t-il des requetes portant sur ce champ alors que inc_base
>supprime le champ en question ?Parce que, tout le monde n'étant pas d'accord, j'ai préféré ne pas tout
virer
SVP : quand vous passez le CVS en mode "ça marche plus", essayez de le crier
très fort et de corriger vite (ou de dire "à corriger fissa"). Là je me suis
fait assez mal, sur ce coup-là, perdu 2 heures à un moment où j'aurais pas
dû. Le soir, je peux bosser de chez moi et perdre du temps, là tout de suite
ça fait désordre
-- Fil
Fil wrote:
Bon, j'ai trouvé une solution, si ça ne vous déplaît pas : il n'y a pas
de champ dans la base et on utilise {doublons} à la place. C'est toujours
aussi inutile à mon avis, mais au moins c'est indolore techniquementCe qu'Arno est en train de commiter, j'ai bien l'impression..
Ok, voilà un point de réglé 
SVP : quand vous passez le CVS en mode "ça marche plus", essayez de le crier
très fort et de corriger vite (ou de dire "à corriger fissa"). Là je me suis
fait assez mal, sur ce coup-là, perdu 2 heures à un moment où j'aurais pas
dû. Le soir, je peux bosser de chez moi et perdre du temps, là tout de suite
ça fait désordre
Désolé Mais n'oublie pas qu'une version CVS n'est vraiment pas censée marcher
au poil....
Coucou,
Fil wrote:
Bon, je ne comprends rien au code ni au débat
Beuh :)))
1) Je suis convaincu qu'{inclus} était un bon champ dans spip_documents, et
que le fait que le doc apparaisse dans le texte doit être utilisable de
manière à n pas répéter le doc dans la liste des docs attachés sous
l'article.- pourquoi, dans une mise en page spécifique, vouloir à la fois des docs
dans l'article et des docs en-dessous ? pourquoi, de plus, ne pas
se satisfaire de la sélection selon la présence d'une vignette ou non ?
- Parce que c'est extrêmement fréquent. Ca se fait sur de nombreux sites, c'est très pratique.
- Surtout, tu ne peux absolument pas prévoir le comportement des rédacteurs. Certains vont installer des documents sans vignettes, des documents avec vignettes, des images, certains vont installer certaines images dans le texte, d'autres non... Il faut donc se donner de la souplesse pour réussir à obtenir une interface cohérente.
Sans le {inclus}, une chose est certaine: les documents installés dans le corps de l'article apparaîtront en dessous. Si on commence à jouer avec la présence des vignettes ou non, là ça devient totalement incompréhensible, et surtout pas du tout souple: je peux très bien vouloir, dans un article, intégrer le lien d'un document PDF sans vignette personnalisée dans le corps de l'article (à l'endroit où il est mentionné); à l'inverse je peux vouloir attribuer une vignette personnalisée à certains documents qui apparaissent en bas de l'article.
- pourquoi détester cette redondance ? au contraire c'est bien pratique
d'avoir un récapitulatif en-dessous de l'article.
C'est une question de choix alors, les goûts et les couleurs. Et là, justement, le {inclus} n'interdit pas à ceux qui le désirent de jouer de cette redondance, et cela d'une manière extrêmement fine. Sans {inclus}, c'est la redondance obligatoire. Avec {inclus}, c'est au choix du webmestre.
Cela dit, vues les tripotées de possibilités d'utilisation des documents-vignettes, le choix de la non redondance est le plus sûre. Par exemple, j'installe dans l'article une belle et grosse vignette cliquable qui mène à un document; avec la redondance, j'aurais une énorme vignette de prévisualisation (déjà présente dans le texte), en bas de l'article, à côté d'une petite vignette "PDF" par défaut.
- pourquoi ce type de choix de mise en page devrait-il apparaître dans
l'espace privé ? (avec un formulaire qui n'indique que les documents
pas déjà inclus dans le texte, ce qui est incompréhensible pour quelqu'un
qui ne suit pas la même logique que toi)
Parce que de cette façon, la page de l'espace privé ressemble à une page classique, pas à un récapitulatif général: elle affiche d'un côté les documents insérés dans le texte, et ensuite les documents qui apparaîtront sous le forme "Documents joints". Si on affiche tous les documents sur cette page, effectivement on aura du mal à contrôler ce qu'on publie ou non.
Bon, j'ai trouvé une solution, si ça ne vous déplaît pas : il n'y a pas
de champ dans la base et on utilise {doublons} à la place. C'est toujours
aussi inutile à mon avis, mais au moins c'est indolore techniquement
C'est ce que j'étais en train de faire.
Franchement, "techniquement", ça n'a rigoureusement rien d'élégant (ne serait-ce que parce qu'on balance pour la première fois un "doublons" sur lequel le webmestre n'a aucun contrôle). Surtout c'est nettement moins souple. On s'interdit par exemple de présenter les documents joints et le portfolio sur une page séparée, de faire un comptage des documents joints (affichés sur la page d'une rubrique) puisqu'il faut obligatoire afficher le texte, avant les documents.
Pour moi, c'est un contournement en attendant que tu nous proposes une solution élégante qui redonne la souplesse du champs {inclus}. Vraiment, le principe des documents joints de SPIP est très intéressant, c'est très dommage de se priver de toute la souplesse possible dans la création des squelettes.
ARNO*
Bonjour,
Je profite du petit débat en cours sur les {inclus} et autre pour ramener
ma fraise sur un sujet connexe que je voulais ammené depuis longtemps.
Ce qui m'a le plus surpris au début de mon utilisation de spip a été la
réinvention d'un langage propre pour marquer les éléments du texte (les {,
les liens avec '[ -->]', etc). Je pense que c'est une mauvaise idée, et
j'aimerais dire pourquoi il me semble qu'un marquage à la sgml (html) me
semble meilleurs.
Les raisons:
1/ Ergonomiques pour l'utilisateur
Les rédacteurs ont souvent été ammenés à connaitre (au moins un peu) le
HTML, pourquoi le refaire un autre langage à apprendre, avec une logique
différente ? Plutot que [ -> ], <a =""></a> (ou approprie) ne serait il
pas préférable ?
Mieux, les rédacteurs ne connaissent peut etre rien au html quand ils
arrivent, mais peuvent etre ammené à s'y interesser (logique). SPIP avec
son langage actuel ne les y prépapre pas vraiment...
Je ne sais pas si ces marqueurs ont étés choisi en pensant que ca serait
plus 'simple', mais si c'est le cas, je pense que cd'etsfaire fausse
route.
2/ Pratiques pour le développeur
PHP comporte un parseur xml intégré, il existe de nombreux autres outils
pour gerer ce genre de tag. C'ets peut etre mieux que de réinventer une
autre roue (probablement beaucoup moins bien).
3/ Théoriques pour le futur de spip
Le sgml a émergé à la suite de plus de 30 ans de réflexion dans le domaine
du formatage des documents. La solution sgml finalement retenue est
l'aboutissement de cette réflexion et donc très bien pensée.
En particulier:
- Il est naturelemnt extensible facilement et logiquement
- Il se parse aisément sans ambiguité
- Il est lisible et composable à la main
etc etc...
Hum, vous en pensez quoi: OUI / NON / NSP
Yannick
[bla bla bla]
Et j'ai oublié de'ajouter:
Une interface 'graphique' sur la composition de texte *oui*, mais que si
on peut aussi utiliser une méthode texte brute lisible...
Et au dela d'une certaine complexité le sgml/xml risque bien d'apparaitre
comme le seul mmarquage permetant de réaliser les deux.
Yannick
Hello,
OUI
Salut,
Les rédacteurs ont souvent été ammenés à connaitre (au moins un peu) le
HTML, pourquoi le refaire un autre langage à apprendre, avec une logique
différente ? Plutot que [ -> ], <a =""></a> (ou approprie) ne serait il
pas préférable ?
Ben, je connais le HTML, et je trouve les raccourcis SPIP beaucoup plus
agréables (simples, rapides) quand il s'agit d'écrire un texte. Et je
pense que la différence est encore plus flagrante pour quelqu'un qui ne
connaît pas le HTML.
PHP comporte un parseur xml intégré, il existe de nombreux autres outils
pour gerer ce genre de tag. C'ets peut etre mieux que de réinventer une
autre roue (probablement beaucoup moins bien).
Hmmm, le parseur XML n'est pas intégré, c'est une extension (regarde ce
que j'ai dû coder pour la restauration de bases de données). D'autre part
le HTML tel que codé couramment est rarement "XML well-formed". Enfin le
parseur XML (expat) est évènementiel, ce qui implique de toute façon de
construire toute une structure autour pour faire du parsing haut niveau.
Le sgml a émergé à la suite de plus de 30 ans de réflexion dans le domaine
du formatage des documents.
Oui mais ce n'est pas du tout le même public. SPIP n'est pas fait pour
consigner la doc technique Airbus....
a+
Antoine.
Bonsoir,
1/ Ergonomiques pour l'utilisateur
Plutot que [ -> ], <a =""></a>
Je vois pas du tout le bonus ergonomique.
2/ Pratiques pour le développeur
PHP comporte un parseur xml intégré
Faux.
3/ Théoriques pour le futur de spip
Le sgml a émergé à la suite de plus de 30 ans de réflexion dans le
domaine du formatage des documents.
Créé par IBM dans les années 60, le sgml reste d'utilisation TRES
difficile et anecdotique.
- Il est naturelemnt extensible facilement et logiquement
Bof.
- Il se parse aisément sans ambiguité
Non.
- Il est lisible et composable à la main
Non plus.
Par contre, ces trois point peuvent être vrais pour le XML, mais sa
syntaxe est tout de même bien plus complexe que celle de SPIP.
De toute façon, si on veut faire du XML, on prend un outil adéquat,
genre Cocoon, et sinon on regarde ce que donne SPIP ...
-Nicolas
Ce qui m'a le plus surpris au début de mon utilisation de spip a été la
réinvention d'un langage propre pour marquer les éléments du texte (les {,
les liens avec '[ -->]', etc). Je pense que c'est une mauvaise idée, et
j'aimerais dire pourquoi il me semble qu'un marquage à la sgml (html) me
semble meilleurs.
Parce que tu penses que Spip est pour les "Les rédacteurs ont souvent été ammenés à connaitre (au moins un peu) le
HTML".
Ce qui est assez élitiste.
Pour moi, Spip, à l'utilisation (pas à la fabrication d'interface personnalisée, etc) est JUSTEMENT fait pour tous ceux qui ne veulent, ne peuvent pas ou plus se faire chier avec du cambouis.
Mieux, les rédacteurs ne connaissent peut etre rien au html quand ils
arrivent, mais peuvent etre ammené à s'y interesser (logique). SPIP avec
son langage actuel ne les y prépapre pas vraiment...
Le but de Spip ne me semble pas préparer au html. Bien au contraire.
C'est de proposer à tous, (TOUS) un moyen de s'exprimer sans jamais se faire chier avec la technique.
Je ne sais pas si ces marqueurs ont étés choisi en pensant que ca serait
plus 'simple', mais si c'est le cas, je pense que cd'etsfaire fausse
route.
Au contraire, la route est parfaite. Et mon expérience avec les gens à qui on propose des sites sous SPip sont plus qu'enchantés.
Même ceux qui font du html !
Et moi la première !
Pouvoir s'énerver à 23h10 et le mettre en ligne sans tralala, mais avec une mise en page nickel à 23h28 (parce que ça m'a pris 17 mn à rédiger) c'est autre chose....
Hum, vous en pensez quoi: OUI / NON / NSP
Pas sur ce sujet.
Hello !
1/ Ergonomiques pour l'utilisateur
Les rédacteurs ont souvent été ammenés à connaitre (au moins un peu) le
HTML, pourquoi le refaire un autre langage à apprendre, avec une logique
différente ? Plutot que [ -> ], <a =""></a> (ou approprie) ne serait il
pas préférable ?
Là je vois pas l'avantage...
Jusqu'à présent, je suis le seul rédacteur de mon site, car écrit en dur en HTML, cela se comprend.
Le but de passer à SPIP est, à part faciliter mon boulot de maintenance,
aussi d'encourager les copains du club a écrire des news; ce ne sont pas
des informaticiens, mais issus de toutes professions, simplement des
passionnés du sujet du site en question, qui n'ont pas forcément l'intention de connaître l'existance de l'HTML, encore moins de l'apprendre.
Donc pas question pour moi de leur expliquer pourquoi on ouvre une balise
avec une lettre entre <> et que l'on doit la refermer en ajoutant un /
devant cette lettre, et quand on voit la tête du <a href="...">...</a> (que
veut dire "a" pour eux?), car pour reprendre l'argument didactique, autant
utiliser la syntaxe officielle, que d'apprendre une syntaxe intermédiaire
mais trop proche de l'officielle, qui sera source de confusion.
Et puis que je sache, on peut toujours saisir des balises html dans le
texte avec SPIP, non ? Il suffit de mettre <HTML>...</HTML> autour de tout le texte.
Donc on a les deux, ou je me trompe (je suis nouveau dans SPIP) ?
Cordialement,....
..............Thierry,
mail to: thierry66ch@gmx.net
Le 18 Apr 2002 à 00:51,
Yannick Patois (patois@calvix.org) a ecrit :
---------------------- Debut du message original ----------------------
Bonjour,
Je profite du petit débat en cours sur les {inclus} et autre pour ramener
ma fraise sur un sujet connexe que je voulais ammené depuis longtemps.Ce qui m'a le plus surpris au début de mon utilisation de spip a été la
réinvention d'un langage propre pour marquer les éléments du texte (les {,
les liens avec '[ -->]', etc). Je pense que c'est une mauvaise idée, et
j'aimerais dire pourquoi il me semble qu'un marquage à la sgml (html) me
semble meilleurs.Les raisons:
1/ Ergonomiques pour l'utilisateur
Les rédacteurs ont souvent été ammenés à connaitre (au moins un peu) le
HTML, pourquoi le refaire un autre langage à apprendre, avec une logique
différente ? Plutot que [ -> ], <a =""></a> (ou approprie) ne serait il
pas préférable ?Mieux, les rédacteurs ne connaissent peut etre rien au html quand ils
arrivent, mais peuvent etre ammené à s'y interesser (logique). SPIP avec
son langage actuel ne les y prépapre pas vraiment...Je ne sais pas si ces marqueurs ont étés choisi en pensant que ca serait
plus 'simple', mais si c'est le cas, je pense que cd'etsfaire fausse
route.2/ Pratiques pour le développeur
PHP comporte un parseur xml intégré, il existe de nombreux autres outils
pour gerer ce genre de tag. C'ets peut etre mieux que de réinventer une
autre roue (probablement beaucoup moins bien).3/ Théoriques pour le futur de spip
Le sgml a émergé à la suite de plus de 30 ans de réflexion dans le domaine
du formatage des documents. La solution sgml finalement retenue est
l'aboutissement de cette réflexion et donc très bien pensée.
En particulier:
- Il est naturelemnt extensible facilement et logiquement
- Il se parse aisément sans ambiguité
- Il est lisible et composable à la mainetc etc...
Hum, vous en pensez quoi: OUI / NON / NSP
Yannick
_______________________________________________
spip-dev@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-dev
---------------------- Fin du message original ----------------------
NSP (trop technique pour moi, pas tout compris mais intéressé par le sujet).
Donatien
-----Message d'origine-----
1/ Ergonomiques pour l'utilisateur
Les rédacteurs ont souvent été ammenés à connaitre (au moins un peu) le
HTML, pourquoi le refaire un autre langage à apprendre, avec une logique
différente ? Plutot que [ -> ], <a =""></a> (ou approprie) ne serait il
pas préférable ?
Non, la question n'est pas d'être plus "ergonomique" que le HTML, mais "plus lisible". Il me semble que:
Lire ce [texte->33]
est plus lisible que
Lire ce <a href="article.php3?id_article=33">texte</a>
3/ Théoriques pour le futur de spip
Le sgml a émergé à la suite de plus de 30 ans de réflexion dans le domaine
du formatage des documents.
Oui, mais pourquoi pas le format TeX, à peu près la même époque que le SGML, beaucoup plus utilisé? Pour mettre en gras, on ferait simplement:
Ce texte est {\bf en gras}.
Pour les notes de bas de page:
\footnote{Une note en bas de page}
Pour les intertitres:
\intertitre{Mon titre}
et il suffirait de définir en début de document:
\def\intertitre#1{\bigbreak
\centerline{\bf#1}
\medskip}
Pour le traitement automatique de la mise en page, TeX a fait ses preuves, en plus on pourra facilement le convertir en MathML par la suite. Dans un second temps, on pourra intégrer les macros LaTeX, moi j'aime pas, m'enfin c'est très répandu...
Non, sérieusement, SGML... Certes, je m'étais bien amusé à jouer avec "FrameMaker+SGML", m'enfin de là à l'utiliser pour créer un site Web...