[Spip] italiques,

Salut,

comment avez-vous résolu la question des italiques dans les champs texte ?
Il faut taper soi-même les codes <i> </i> ? Utiliser un post-processeur qui
le fait pour vous, c'est pas mal, à condition de pouvoir retoucher ensuite,
ce qui laisse la question entière.

Peut-être une macro dans l'infame WORD qui transformerait un texte avec
itals en texte avec <i> </i> et, dans la foulée, ferait une transformation
intelligente des « » pour les préserver lors du copier/coller sur le
formulaire web ?

Le post-processeur qui a l'air d'avoir la cote :
http://www.kanga.nu:80/wiki/index.php?TextFormattingRules

il faut dire que Wiki a l'air d'être un système très rigolo.

Paragraphs
* Don't Indent paragraphs
* Words wrap and fill as needed
* Use blank lines as separators
* Four or more minus signs make a horizontal rule

Lists
* tab-* for first level
* tab-tab-* for second level, etc.
* Use * for bullet lists, 1. for numbered lists (mix at will)
* tab-Term:-tab Definition for definition lists
* One line for each item
* Other leading whitespace signals preformatted text, changes font.

Fonts
* Indent with one or more spaces to use a monospace font:

This is in monospace
This is not

Indented Paragraphs (Quotes)
* tab-space-:-tab -- often used (with emphasis) for quotations. (See
SimulatingQuoteBlocks?)

Emphasis
* Use doubled single-quotes ('') for emphasis (usually italics)
* Use tripled single-quotes (''') for strong emphasis (usually bold)
* Use five single-quotes ('), or triples within doubles, for some other
kind of emphasis (BoldItalicInWiki?), but be careful about the bugs in the
Wiki emphasis logic...
* Emphasis can be used multiple times within a line, but cannot cross line
boundaries

References
* JoinCapitalizedWords? to make local references [ INUTILE POUR SPIP ]
* [1], [2], [3], [4] refer to remote references. Click EditLinks? on the
edit form to enter URLs
* Or precede URLs with "http:", "ftp:" or "mailto:" to create links
automatically as in: http://c2.com/
* URLs ending with .gif are inlined if inserted as a remote reference

Mark-Up Language

* Don't bother
* < and > are themselves
* The & characters will not work
* If you really must use HTML, start each line with a bar (|). Note that
this featured must be enabled by the system administrator.

* Fil (fil@bok.net) écrivait :

Le post-processeur qui a l'air d'avoir la cote :
http://www.kanga.nu:80/wiki/index.php?TextFormattingRules

il faut dire que Wiki a l'air d'être un système très rigolo.

Et il y a un clone en PHP
http://www.c2.com/cgi/wiki?PhpWiki

> il faut dire que Wiki a l'air d'être un système très rigolo.
http://www.c2.com/cgi/wiki?PhpWiki

Si vous voulez jouer ...

http://atlas.bok.net:80/~fil/wiki/index.php3

De mon côté, pour Vuibert, je fais aussi des raccourcis (puisque les éditeurs font eux-mêmes la mise-à-jour du site, il leur faut quelques options de mise en page, sans HTML).

Je fais un truc particulièrement simple. La liste fournie par Fil est intéressante, mais trop compliquée à mon goût (même si y'a des idées à reprendre). En particulier, il ne faut pas perdre de vue que dans les habitudes, il y a le copier-coller direct depuis Word ou d'anciennes pages Web. Surtout, question rigueur, c'est pas vraiment ça (par exemple, le coup de laisser un blanc pour passer en mode "courrier", c'est trop rigoureux pour mes éditeurs...).

Voici pour l'instant ce que j'ai implémenté:

-> Pour changer de paragraphe, laisser une ligne blanche (le système est assez souple là-dessus: on peut laisser plusieurs lignes blanches, et même laisser des blancs parasites dans la ligne "vide").

-> Pour faire des énumérations, il suffit de commencer la ligne par un tiret.

-> L'italique s'obtient en mettant entre accolades: {italique}.

-> Le gras en mettant entre deux accolades: {{gras}}.
C'est ce que j'ai trouvé de plus simple à mémoriser. Sachant que je n'ai pas besoin, comme SPIP, d'intertitres centrés. Remarquez, pour conserver la logique (plus il y a d'accolades, plus ça signifie que l'enrichissement est important), je peux marquer les intertitres avec trois accolades: {{{intertitre}}}

-> Les blancs insécables sont indiqués par un "tilde": par exemple 60~000.

-> Inutile de respecter les règles typographiques pour les deux points, points virgule, point d'interrogation, etc. Le système corrige tout seul.

-> Pour faire un lien hypertexte: [texte->http://url]. Par exemple: [Scarabée->http://www.scarabee.fr]

Je pense ajouter un raccourci pour faire des tableaux simples. Je pensais utiliser les tabulations:

(tab) Nom (tab) Prénom (tab) Date de naissance
(tab)Martin (tab) Arnaud (tab) 05/05/1970

Mais j'ai un problème d'interface, ensuite, car Microsoft Explorer refuse les tabulations dans les champs texte (ça passe directement au champ suivant...)

Salut tout le monde,

Ca a l'air excellent, Arno, ton système de raccourcis... Et bravo pour
le correcteur typo! L'idéal, ce serait d'intégrer tout ça dans une
interface spipesque, en essayant de supporter un maximum de choses : tes
raccourcis, mais aussi les tags HTML. On commence à avoir vraiment
toutes les briques pour faire quelque chose de solide.

Je reviens sur ce que tu disais dans ton premier mail sur Vuibert : le
fait de faire l'effort de tout rentrer dans une même base permet ensuite
de générer facilement toutes sortes de documents papiers ou pages Web.
J'avais fait la même chose quand je bossais chez Lucent : on entrait
toutes les fiches de tests en Intranet, et à partir de ça je pouvais
générer des fiches de suivi sur le Web, mais aussi générer
automatiquement de superbes documents FrameMaker.

Il faudrait qu'on fasse la même chose avec notre Spip/Rezo. Mes derniers
"blocages" techniques, ces derniers temps, ça a été quand on m'a demandé
s'il n'était pas possible de générer un joli document PDF 3 colonnes
avec tous les articles de notre salve anti-friconautes (sur le modèle de
ce que j'avais pu faire en PDF avant). Et là, bien embêté le Laz : avec
des papiers issus de tas de webzines différents, il fallait que j'en
fasse les 3/4 à la main. Premier embêtement.

Deuxième embêtement : on me demande d'ajouter, dans la Semaine des
Copains, des chapôs pour chaque article, parce qu'un titre seul n'est
pas très explicite. C'est une excellente suggestion. Problème : je vais
pas me taper la rédaction de chapôs pour tous les articles. Il faut donc
que les chapôs soient stockés dans ma base d'articles. Mais en même
temps, c'est dur de demander à chaque webmestre de venir catégoriser son
article et entrer un chapô dans notre base.

D'où l'idée suivante, de mettre tout dans un chapeau et de mélanger. Ce
qui donne : et si on proposait pour tous les copains un outil
d'HTMLisation en ligne sur rezo ? Mélange du Spip initial et du Spip
d'Arno : tu lui balances ton texte, en remplissant consciencieusement
titre, chapô, auteur, mais aussi en choisissant un thème et/ou un
dossier de rattachement, et il te le recrache en joli HTML bien propre
(soit une page complète dans un template, soit un bloc .shtml comme ceux
qu'Arno et moi utilisons) que tu peux mettre directement sur ton site.
Mais surtout, non seulement l'outil t'a donné une jolie page HTML, mais
il a aussi intégré le papier dans sa base d'articles : il est référencé
thématisé chapôtisé dans le portail, et il est sous une forme standard
qui permettra très facilement de l'intégrer dans d'éventuels recueils
papiers : la fabrication d'un document Tex (puis PDF) regroupant tous
les articles d'un thème ou d'un dossier devient théoriquement facilement
automatisable.

Y a aussi une variante possible pour le Spiper d'articles, vu que
beaucoup de monde utilise Word, c'est d'avoir un modèle de fichiers Word
(un peu comme ceux qu'utilise Fil pour le Diplo), où tu mets
<TIT>Gnagnagna, <TXT>Blablabla. Avec quelques tags de ce type, on peut
très bien imaginer que le fichier .doc soit carrément uploadé sur le
serveur et transformé illico en document HTML.

Laz

Salut tout le monde,

Ca a l'air excellent, Arno, ton système de raccourcis... Et bravo pour
le correcteur typo! L'idéal, ce serait d'intégrer tout ça dans une
interface spipesque, en essayant de supporter un maximum de choses : tes
raccourcis, mais aussi les tags HTML. On commence à avoir vraiment
toutes les briques pour faire quelque chose de solide.

J'ai pas bien essayé, mais je crois que mon truc accepte les tags HTML. Cela dit, on peut faire deux variantes: une qui accepte, l'autre qui les fait sauter.

Par exemple, dans mon forum de discussion, je choisirais l'option "faire sauter le HTML", histoire d'être certain qu'un malin ne fasse pas sauter ma mise en page (c'est vite fait: tu balances un "<TR>" isolé à dedans, et la mise en page globale explose complètement).

Autre intérêt de ne pas utiliser du tout le HTML: on peut ajouter un bouton "envoyer cet article à un ami par courrier électronique". Je ferais bien ça pour les éditos du Scarabée, mais avec mes anciens articles, y'a plein de HTML, et j'ai peur du résultat une fois mouliné dans un email.

Il faudrait qu'on fasse la même chose avec notre Spip/Rezo. Mes derniers
"blocages" techniques, ces derniers temps, ça a été quand on m'a demandé
s'il n'était pas possible de générer un joli document PDF 3 colonnes
avec tous les articles de notre salve anti-friconautes (sur le modèle de
ce que j'avais pu faire en PDF avant). Et là, bien embêté le Laz : avec
des papiers issus de tas de webzines différents, il fallait que j'en
fasse les 3/4 à la main. Premier embêtement.

Hé hé, y'a toujour des futés pour demander des trucs insurmontables ET inutiles: à quoi ça sert, franchement, d'avoir 3 colonnes dans une page A4? :-))

Deuxième embêtement : on me demande d'ajouter, dans la Semaine des
Copains, des chapôs pour chaque article, parce qu'un titre seul n'est
pas très explicite. C'est une excellente suggestion. Problème : je vais
pas me taper la rédaction de chapôs pour tous les articles. Il faut donc
que les chapôs soient stockés dans ma base d'articles. Mais en même
temps, c'est dur de demander à chaque webmestre de venir catégoriser son
article et entrer un chapô dans notre base.

Ta solution: "c'est le portail SPIP qui génère les articles", hum, ça me semble plus compliqué qu'autre chose. Encore plus lourd, à mon avis, que de demander aux webmestres de venir se catégoriser eux-mêmes. En tout cas, vu que toi, Erwan et moi faisons déjà nos articles avec nos propres systèmes dédiés, on serait les premiers à ne pas l'utiliser! Surtout que si on finit, un beau jour, par livrer une version de SPIP, bonjour le foutoir ("alors, les articles, je les génère avec SPIP ou avec le système sur rezo.net?").

Deux idées tout de même:

-> si on monte un Rézo thématique et avec plus d'options, il est bien prévu, justement, d'inviter les webmestres à y participer eux-mêmes, non? Et après tout, vu que le site amène de l'audience, cela dans un win-win co-brandé hyper-catégoriel, les webmestres qui viennent compléter le référencement de leurs articles ont tout à y gagner.

-> Proposons des "tags" pseudo-HTML pour rezo.net. Par exemple: si j'ai envie que mes articles soient mieux référencés, mais que je n'ai pas envie de me cogner le référencement directement dans le rezo.net, j'ajoute dans mes propres pages quelques tags. Par exemple, j'entoure mes chapos de méta-tags:

<rezo_chapo>
Blah blah blah blah
</rezo_chapo)

Comme ça, quand le moteur de rezo.net vient voir ma page pour la référencer, il peut directement récupérer les informations nécessaires.

ARNO*

Hello,

ARNO* a écrit:

Autre intérêt de ne pas utiliser du tout le HTML: on peut ajouter un
bouton "envoyer cet article à un ami par courrier électronique". Je
ferais bien ça pour les éditos du Scarabée, mais avec mes anciens
articles, y'a plein de HTML, et j'ai peur du résultat une fois
mouliné dans un email.

Si tu veux générer des courriers électroniques nickels, sans t'inquiéter
des tags HTML, y a beaucoup mieux :
lynx -dump http://scarabee.com/EDITO2/140200.shtml

C'est ce que je fais pour envoyer mes chroniques sur la liste : le lynx
-dump est appelé par un system() en PHP à l'intérieur d'un formulaire
d'édition de texte. Résultat, j'obtiens instantanément la version texte
pur de mon édito et je peux faire quelques modifs avant de l'envoyer.

Hé hé, y'a toujour des futés pour demander des trucs insurmontables
ET inutiles: à quoi ça sert, franchement, d'avoir 3 colonnes dans une
page A4? :-))

Enfin bon, le nombre de colonnes c'est un détail, mais sur le fond,
avoir un recueil en PDF c'est quand même vachement utile. Ca évite
notamment d'imprimer 10 pages pour tes éditos!

Ta solution: "c'est le portail SPIP qui génère les articles", hum, ça
me semble plus compliqué qu'autre chose. Encore plus lourd, à mon
avis, que de demander aux webmestres de venir se catégoriser
eux-mêmes. En tout cas, vu que toi, Erwan et moi faisons déjà nos
articles avec nos propres systèmes dédiés, on serait les premiers à
ne pas l'utiliser!

Euh, vous peut-être, mais moi mon système dédié je ne le trouve pas si
génial que ça... Si on sort un système d'édition plus complet, je ne
demande qu'à faire les modifs nécessaires sur menteur pour l'utiliser.
Ca évitera de maintenir N systèmes différents (genre si je veux la
correction typo, et si Erwan la veut, il faut qu'on aille bidouiller nos
systèmes respectifs pour l'intégrer... et si tu veux mes lettrines,
idem)

Surtout que si on finit, un beau jour, par livrer
une version de SPIP, bonjour le foutoir ("alors, les articles, je les
génère avec SPIP ou avec le système sur rezo.net?").

Mon idée, c'était que les deux systèmes puissent collaborer. J'y reviens
à la fin de ce mail.

-> si on monte un Rézo thématique et avec plus d'options, il est bien
prévu, justement, d'inviter les webmestres à y participer eux-mêmes,
non? Et après tout, vu que le site amène de l'audience, cela dans un
win-win co-brandé hyper-catégoriel, les webmestres qui viennent
compléter le référencement de leurs articles ont tout à y gagner.

Yep, c'est le principe de base. Du reste, l'expérience du rezo actuel a
montré que tous les webmestres étaient prêts à maintenir une page de
sommaire spéciale quand il le fallait, pour gagner de l'audience.

Comme ça, quand le moteur de rezo.net vient voir ma page pour la
référencer, il peut directement récupérer les informations
nécessaires.

Là, pas d'accord : c'est hyper dur à faire. N'oublie pas que le moteur
rezo.net ne vient pas voir les pages qu'il référence, il ne vient voir
que ta page de sommaire. Et il la visite avec des lynx -dump, justement,
qui sont facilement interprétables. Tes tags <rezo> ne pourraient être
lus qu'en faisant un moteur qui visiterait toutes les pages en mode
source, et c'est vraiment trop lourd.

Donc je reviens à ce que je disais que je disais à la fin du mail, sur
l'idée d'intégrer Spip au Portail et vice-versa. En intégrant les
judicieuses remarques d'Arno, je verrais bien cette solution-là :

1) Le portail est capable d'intégrer automatiquement (par mes mécanismes
de fetch) les nouveaux articles. Mais si le webmestre veut une meilleure
visibilité (apparaître dans la navigation thématique et par dossiers, et
dans la Semaine, il doit venir catégoriser via l'interface spécifique de
rezo ses articles et fournir un chapô).

2) Toutefois, les webmestres utilisant un système compatible Spip sur
leurs sites seront avantagés : le portail sera capable de venir y
piocher tout seul les chapôs et les catégories.

C'est pas mal, ça, non ? Quand je dis "un système compatible Spip",
c'est juste qu'on aura défini un format de "what's new" qui puisse être
compris par le portail. Si ton système d'édition est capable de
maintenir une page où figure une liste de paragraphes de ce type:
URL=http://
Date=Demain
Titre=Blabla
Chapo=Gnagna
Catégorie=Beurk
...alors tu n'auras pas besoin de venir référencer quoi que ce soit sur
rezo, le portail comprendra tout seul.

Laz

Salut tout le monde,

Vu que j'en ai besoin pour Vuibert, voici une fonction PHP qui écrit les nombres (jusqu'aux centaines de milliards, après ça ne gère plus) en toutes lettres. Pour moi, c'est utile pour générer les contrats divers et variés (dans les contrats, habituellement, on écrit à la fois la somme en chiffres, suivie entre parenthèses de la même somme en toutes lettres). Par exemple: "Veuillez payer 856 francs (huit cent cinquante-six francs)..."

La fonction est:
function enlettres($lenombre,$unite,$unites,$entre,$apres,$apress){

$lenombre, c'est le nombre à écrire en toutes lettres;
$unite c'est le "nom", "texte" de l'unité au singulier (par exemple "franc");
$unites c'est le même, mais au plusieur ("francs") (au début, je me contentais d'ajouter un "s" à $unite quand y'en avait plusieurs, m'enfin si on se met à compter des choux, ça merde...);
$entre, c'est le texte qui va entre les unités et les dizièmes (par exemple "et", ou "virgule");
$apres, c'est le texte qui va après les chiffres après la virgule (par exemple "centime");
$apress, c'est le même, au pluriel ($centimes).

Bon, c'est pas encore parfait. Par exemple si je fais:
echo enlettres("0,12","","","virgule","","");
Ca renvoit "douze", et non "zéro virgule douze".
Je ne peux pas non plus l'obliger à me renvoyer: "treize virgule douze mètres", mais uniquement "treize mètres et douze centimètres", ce qui n'est pas toujours pratique. Donc il faut que je trouve un appel de fonction plus adéquat.

ARNO*

Maintenant, un exercice plus difficile : tu écris la fonction qui fait
l'inverse :-))))

Laz

ARNO* a écrit:

C'est ça... et un code PHP qui "écoute" un fichier MPEG et t'en sort les paroles et une partition. :-)))

A part ça, j'ai bien avancé sur mon générateur de documents à partir de la base de données et de fichiers HTML. J'ai ajouté la gestion des fonctions.

Comme je vous ai déjà raconté, le principe est la suivant: dans le fichier HTML, j'indique:

[Prix de vente: (#PRIX) FF.<BR>]

Et, si ce prix existe dans la base de données, ça remplace par la phrase et le prix. Mais si cette valeur n'existe pas dans la base, alors toute la phrase est supprimée.

J'ai ajouté des "variables libres", pour des données qui, c'est certain, n'existent pas dans la base. Là, j'écris:
(#VAR1)
lors du premier "chargement" du fichier, ça remplace (#VAR1) par un champ texte que l'on remplit; une fois que c'est fait, on valide et on réaffiche la page, mais cette fois-ci on affiche bien la valeur spécifiée.

En fait, c'est un peu plus subtile, car la valeur peut être utilisée plusieurs fois dans la page (et il serait inutile d'avoir plusieurs champs de formulaire texte pour la même valeur). Du coup, on fait comme ça:

(#VAR1) blah blah blah
(#VAR1-Tirage) blah blah blah
(#VAR1) blah blahblah

C'est (#VAR1-Tirage) qui est utilisée: ça remplace par un champ de texte de formulaire, avec comme valeur "par défaut" le mot "Tirage". Avantage: ça explicite un peu la signification de l'élément qui manque. Les autres (#VAR1) sont remplacés simplement par des "XXXXX".

S'il est encore temps de suggérer...

* Arno* (arno@scarabee.com) écrivait :

ça (par exemple, le coup de laisser un blanc pour passer en mode
"courrier", c'est trop rigoureux pour mes éditeurs...).

absolument

-> Le gras en mettant entre deux accolades: {{gras}}.
C'est ce que j'ai trouvé de plus simple à mémoriser. Sachant que je
n'ai pas besoin, comme SPIP, d'intertitres centrés. Remarquez, pour
conserver la logique (plus il y a d'accolades, plus ça signifie que
l'enrichissement est important), je peux marquer les intertitres avec
trois accolades: {{{intertitre}}}

oui ! Et {{{{ }}}} pour encore autre chose !

-> Inutile de respecter les règles typographiques pour les deux
points, points virgule, point d'interrogation, etc. Le système
corrige tout seul.

sauf quand il ne faut pas (ex : dans les URL://) ?

-> Pour faire un lien hypertexte: [texte->http://url]. Par exemple:
[Scarabée->http://www.scarabee.fr]

Pourquoi passer des {} aux ? Tu vas perdre tes utilisateurs, et tu perds
un caractère quand même pratique...

(tab) Nom (tab) Prénom (tab) Date de naissance
(tab)Martin (tab) Arnaud (tab) 05/05/1970

remplace par {}Nom {}Prénom {}Etc

[Ceci est le (#PRIX) en {francs français}.<P>]

hi hi: Ceci est le 17 en francs français ?

De plus, comme je génère des documents "de travail" (à imprimer ou à
sauvegarder), il se peut que j'ai besoin de demander des valeurs que
la base ne contient pas. Par exemple, un contrat d'auteur, sachant
qu'on connait toutes les infos sur le livre et l'auteur, mais pas le
montant des droits d'auteurs. Dans ce cas, dans le format HTML,
j'indique: (#VAR1) (on peut en mettre plusieurs: (#VAR2), (#VAR3)...)
qui, lors du premier affichage, indique un champ de formulaire et un
bouton de validation; l'utilisateur entre ainsi les valeurs
nécessaires, valide, et là c'est la bonne page qui est affichée.

Génial

Je vais aussi ajouter des "fonctions" pour les valeurs: par exemple
(#PRIX_EN_EUROS) affiche la valeur de #PRIX calculée en euros.

Il manque une chose dans tout ça : comment entrer une fiche de données
(correspondant à un "article") en "un coup", sans remplir les champs d'un
formulaire web (toujours très peu pratique). J'ai une solution dans mon
édition anglaise : tu prépares ton fichier html en encadrant les valeurs par
les clés d'accès :
     <TIT=le titre>
     <CHAPO=le chapo>
     <TEX=ml fj slkfjslkdjf lsd fslk flsk et tout ça dans l'éditeur html,
        qui prend donc en compte les itals, les para etc. >

Seul problème : l'upload. Si ce fichier arrive sur le site et se fait
"aspirer" dans la base de données, faut il l'effacer ? Comment gérer alors
les corrections, etc ? Pour l'instant, c'est l'ensemble de ces fichiers
html qui fait foi, et dès que ça change un cron se charge de reconstruire la
base de données. Mais c'est pas très satisfaisant. Si vous avez des
suggestions;

* Pierre Lazuly (lazuly@rezo.net) écrivait :

C'est pas mal, ça, non ? Quand je dis "un système compatible Spip",
c'est juste qu'on aura défini un format de "what's new" qui puisse être
compris par le portail. Si ton système d'édition est capable de
maintenir une page où figure une liste de paragraphes de ce type:
URL=http://
Date=Demain
Titre=Blabla
Chapo=Gnagna
Catégorie=Beurk
...alors tu n'auras pas besoin de venir référencer quoi que ce soit sur
rezo, le portail comprendra tout seul.

Je rappelle à toutes fins utiles que le standard pour ce genre de choses
c'est le format RDF. Ca ressemble à du XML (c'est est sans doute).

* Arno* (arno@scarabee.com) écrivait :

Vu que j'en ai besoin pour Vuibert, voici une fonction PHP qui écrit

Et si, puisqu'on a tous des besoins quand même différents, on se mettait à
faire une vraie *bibliothèque partagée de fonctions*. Ainsi, l'appel
principal dans un fichier php quelconque serait

    require ("/chemin/vers/spiplib.inc");

et on évoluerait en parallèle sur ces fonctions.

Il manque une chose dans tout ça : comment entrer une fiche de données
(correspondant à un "article") en "un coup", sans remplir les champs d'un
formulaire web (toujours très peu pratique). J'ai une solution dans mon
édition anglaise : tu prépares ton fichier html en encadrant les valeurs par
les clés d'accès : <TIT=le titre>
     <CHAPO=le chapo>
     <TEX=ml fj slkfjslkdjf lsd fslk flsk et tout ça dans l'éditeur html,
        qui prend donc en compte les itals, les para etc. >

Seul problème : l'upload. Si ce fichier arrive sur le site et se fait
"aspirer" dans la base de données, faut il l'effacer ? Comment gérer alors
les corrections, etc ? Pour l'instant, c'est l'ensemble de ces fichiers
html qui fait foi, et dès que ça change un cron se charge de reconstruire la
base de données. Mais c'est pas très satisfaisant. Si vous avez des
suggestions;

Oui, c'est aussi un truc que des éditeurs m'ont demandé. Mais pour eux, le pseudo-HTML c'est pas vraiment une facilité.

Du coup, peut-être leur proposer un fichier Excel à télécharger, avec dans la colonne de gauche le titre des champs, et à droite la colonne à remplir. Ensuite, ils sélectionnent tout, le copie dans un formulaire unique, et une petite moulinette fait tout entrer dans les cases qui vont bien...

ARNO*

Hum,

On pourrait commencer par déposer SPIP.org, vu que c'est libre (et que par Gandi, ça coûte rien...).

Fil, tu peux nous héberger ça?

ARNO*

Bah, je suis pas sûr que ce soit le plus urgent...

Pour moi la priorité c'est surtout qu'on arrive à se mettre d'accord sur
un modèle de base de données. Il en faut même deux, un pour le portail
et un pour les bases d'articles type Spip.

Une fois qu'on aura créé sur notre phpMyAdmin les bases en question, on
pourra commencer à intégrer toutes les briques existantes autour d'un
même système. Sinon, si on dépose tous des fonctions qui travaillent
toutes sur des modèles de données différents, on va avoir du mal à les
réutiliser...

Laz

ARNO* a écrit:

* Pierre Lazuly (lazuly@rezo.net) écrivait :

Bah, je suis pas sûr que ce soit le plus urgent...

Tu veux réunir un comité décisionnaire sur les priorités ? Ah ah !
Laisse faire Arno s'il a envie !

même système. Sinon, si on dépose tous des fonctions qui travaillent
toutes sur des modèles de données différents, on va avoir du mal à les
réutiliser...

Ah voilà ! On ne s'est pas compris : il faut pouvoir s'échanger les
fonctions de conversion standard. Pas grand chose à voir avec la BDD.

A +

> -> Inutile de respecter les règles typographiques pour les deux

points, points virgule, point d'interrogation, etc. Le système
corrige tout seul.

sauf quand il ne faut pas (ex : dans les URL://) ?

Pour les URL, pas de problème. Mais j'ai pas tenté le coup avec mailto: et ftp:
Mais ce sera facile à corriger.

> -> Pour faire un lien hypertexte: [texte->http://url]. Par exemple:

[Scarabée->http://www.scarabee.fr]

Pourquoi passer des {} aux ? Tu vas perdre tes utilisateurs, et tu perds
un caractère quand même pratique...

Non non, je ne perds pas les accolades , puisque le "texte" remplacé par un lien hypertexte est de la forme:
[ xxxx -> xxxx]
(il faut la "flèche" au milieu).

Et je préfère réserver les {} aux enrichissements typographiques stricto sensu.

> (tab) Nom (tab) Prénom (tab) Date de naissance

(tab)Martin (tab) Arnaud (tab) 05/05/1970

remplace par {}Nom {}Prénom {}Etc

Il y a encore plus simple (toujours dans l'idée de garder les {} pour les enrichissements typographiques), utiliser la barre verticale:

Nom | Prénom | Date de naissance

ARNO*

* Arno* (arno@scarabee.com) écrivait :

Non non, je ne perds pas les accolades , puisque le "texte"
remplacé par un lien hypertexte est de la forme:
[ xxxx -> xxxx]
(il faut la "flèche" au milieu).
Et je préfère réserver les {} aux enrichissements typographiques stricto sensu.
Il y a encore plus simple (toujours dans l'idée de garder les {} pour
les enrichissements typographiques), utiliser la barre verticale:
> Nom | Prénom | Date de naissance

Ajoute un dernier | et je prends !