🚀 go-pugleaf

Eric Jacoboni a �crit dans <87n1i1eygo.fsf@titine.fr.eu.org>
> >>>>> "(TOM)" == (TOM)  writes:
> (TOM)> Tu n'as pas � t'occuper du processeur XSLT qu'auront les "lecteurs"
> (TOM)> eventuels de tes documents (si tu les distribuent ensemble).
>
> Oui, vu sous cet angle... Moi je partais du principe que :
>
> 1) tout syst�me s�rieux � Perl
> 2) j'envoyais le doc XML + la DTD + les scripts de transformation
> 3) il suffit au lecteur d'installer XML::Parser en trois coups de
>    cuill�re a pot (un appel � make), il a le html, le tex, le docbook.

Ah, tout syst�me s�rieux doit donc aussi avoir make ;o) (enfin en g�n�ral
les modules Perl ils s'installent avec un 'perl Makefile' ou quelque chose
du style non ?)

Bon, pour trancher, on va dire (encore une fois) qu'il bien entendu voir au
cas par cas (tu sais que les destinataires ont Perl donc...)

> (TOM)> XSLT est plus puissant qu'un processeur SAX comme Expat
>
> Peut-�tre, je ne connais pas suffisamment pour juger, je parlais du
> point de vue qui est le mien : je ma�trise suffisamment bien la
> programmation pour que la confection de scripts ne me pose pas de
> probl�me. D'o� la question sur l'int�r�t d'apprendre un autre
> langage. Je pense que le r�el atout de xls est, comme le dit Doeni,
> est sa facult� de g�n�ration � � la vol�e �.

Bah en Perl (ou autre) aussi, c�t� serveur (tu parles de g�n�ration), avec
un b�te script/programme appel� via CGI. C�t� client, on en revient � ma
premi�re remarque : tu en es ind�pendant.

> (TOM)> Avec expat (utilis� avec PHP pour ma part ;o) , pas facile et
> (TOM)> surtout peu lisible, avec XSLT c'est un jeu d'enfant.
>
> Mouais, il suffisait de d�clarer une variable pour m�moriser le titre
> de la section en cours, non ?

Oui bien s�r (en plus, et surtout, de compter pour le "une fois sur 2" et
2-3 autres bricoles), vraiment rien de compliqu�, mais bien moins trivial
qu'avec XSLT (j'ai m�me fait pire : comme j'avais que 5 docs minuscules,
j'ai pris mes mimines, mon copier/coller et mes search/replace). Pour info,
la feuille XSLT ressemblerait (en tr�s et en coupant le "non-d�terminant") �
:
<!--
  pour ceux qui maitrisent XSLT, notez que ce sont quasiment mes premi�res
  feuilles XSLT (j'en suis m�me niveau de test que toi Eric ;o) , alors un
  peu d'indulgence et surtout corrections et am�liorations sont les bien
  venues !
-->
<xsl:template match="section">
  <xsl:variable name="impair" select="boolean(position() % 2)"/>
  <table summary="{titre}"><tr>
  <xsl:choose>
    <xsl:when test="$impair">
      <th><xsl:value-of select="titre"/></th>
      <td><xsl:value-of select="texte"/></td>
    </xsl:when>
    <xsl:otherwise>
      <td><xsl:value-of select="texte"/></td>
      <th><xsl:value-of select="titre"/></th>
    </xsl:otherwise>
  </xsl:choose>
</tr></table>
</xsl:template>

De mon point de vue (et j'insiste l� dessus), c'est plus
lisible/compr�hensible.

> Dans le m�me ordre d'id�e, g�n�rer une
> table des mati�res dans la transformation HTML est facile avec Expat,
> je tremble � l'id�e de le faire avec XSLT...

Tu ne "match" que les �l�ments que tu veux :
<xsl:template match="/">
  ...
  <ol>
    <xsl:apply-templates select="chapitre"/>
  </ol>
  ...
</xsl:template>

<xsl:template match="chapitre|section|paragraphe">
  <li>
    <xsl:value-of select="@titre"/>
    <xsl:choose>
      <xsl:when test="descendant::section">
        <ol>
          <xsl:apply-templates select="section"/>
        </ol>
      </xsl:when>
      <xsl:when test="descendant::paragraphe">
        <ol>
          <xsl:apply-templates select="paragraphe"/>
        </ol>
      </xsl:when>
    </xsl:choose>
  </li>
</xsl:template>

Et encore, c'est pas franchement lisible parce que j'ai condens� (un
template au lieu de 3) , j'aurai pu aussi rajouter tr�s facilement des
liens, une num�rotation g�r�e par XSLT (pour par exemple avoir une
num�rotation � plusieurs niveaux : 1 (1.1, 1.2, 1.3), 2 (2.1, 2.2, 2.3) par
exemple) plutot que par HTML (ce qui permet de num�roter aussi avec d'autres
formats de sortie), etc.

Bien s�r, ca ne demande pas la m�me tournure d'esprit, et dans le cas d'une
table des mati�res, o� on respecte l'ordre des �l�ments, etc. on n'a pas
besoin d'avoir l'arbre complet en m�moire, une programmation �v�nementielle
(donc avec quelque chose comme expat) est je pense plus adapt�.

Encore une fois, il n'y a pas moyen de trancher et SURTOUT, il n'y a pas de
raison de trancher ! S'il existe les 2 approches (SAX et DOM), c'est
qu'elles sont compl�mentaires.
--
Voili voilou

(TOM)