[sdx-developers] (logicsheet, ex-taglib) alléger sdx.xsl par cocoon2

[Frédéric Glorieux]

    Quelques trucs glanés dans la doc cocoon2 qui peuvent démoder certaines
habitudes dans SDX.
________________________________________________________
http://www.w3.org/TR/xinclude/
http://xml.apache.org/cocoon/userdocs/transformers/writedomsession-transform
er.html
<xi:include href="include.xml#xpointer(/p/strong)"/>

    Cocoon 2 a implanté le standard W3C xinclude, pouvant remplacer
<sdx:insertXMLFile/>. La norme apporte un gros avantage, attrapper un noeud
précis d'un document. Le seul problème (selon la doc), ce transformeur doit
être déclaré dans la chaîne de "pipes" d'un match (ce n'est pas une taglib,
ça opère après la génération, donc une déclaration cocoon.xconf ne semble
pas appropriée).
<map:match pattern="*.xsp">
    <map:generate type="serverpages" src="{1}.xsp"/>
    <map:transform type="xinclude"/>
    <map:transform src="xsl/{1}.xsl"/>
    <map:serialize/>
</map:match>

    Il suffit qu'un utilisateur construise son propre match et il perd le
xinclude. Si des couches venaient à s'additionner on pourrait penser à un
transformeur SDX par défaut (une classe chaînant des pipes).


__________________________________________________________________
http://xml.apache.org/cocoon/userdocs/transformers/xslt-transformer.html
a.. use-request-parameters: true|false - Setting this to true makes all
request parameters available in the XSLT stylesheet. Note that this might
have issues concerning cachability of the generated output of this
transformer, the caching algorithm not only checks the last modification
date but also all values of the request parameters. This property is false
by default. If set to true the values of a request parameter is available
using a variable in the xslt with the name of the parameter.

    Cette possibilité du sitemap démode fortement <sdx:parameters/> dans
<sdx:document/>. Il suffit de concevoir proprement sa xsl avec paramètres en
en-tête, et ces variables XSL sont nourries par les paramètres HTTP passés
par l'utilisateur (manquerait seulement les versions "urlencode")
    L'inconvénient pointé par Cocoon ("cachabilité" de la page) concerne
assez peu SDX, n'est-ce pas d'abord un instrument de recherche ? La
sitemap.xmap de SDX pourrait être configurée par défaut :
<map:transformers default="xslt">
    <map:transformer name="xslt"
src="org.apache.cocoon.transformation.TraxTransformer"
logger="sitemap.transformer.xslt" pool-max="32" pool-min="8" pool-grow="2">
        <!-- SDX added -->
        <use-request-parameters>true</use-request-parameters>
</map:transformer>

Cookie et session peuvent aussi être disponible.
En cas de page statique, en théorie l'utilisateur devrait pouvoir débrancher
.

<map:transform src="stylesheet.xsl">
    <map:parameter name="use-request-parameters" value="false"/>
</map:transform>

(mais après tests, cela ne semble pas fonctionner)

_________________________________________________


http://xml.apache.org/cocoon/userdocs/transformers/i18n-transformer.html
<map:transformer name="i18n" logger="sitemap.transformer.i18n"
src="org.apache.cocoon.transformation.I18nTransformer">
    <catalogue-name>messages</catalogue-name>
    <catalogue-location>translations</catalogue-location>
</map:transformer>
    Le filtre proposé pour la prise en charge multilingue ne semble pas
encore mûr. Il lui manque encore de s'adosser à une API solide. Il semble
qu'un usage judicieux d'attributs @xml:lang soit plus adapté.

________________________________________________

Les développeurs d'applications pourront apprécier la petite commodité
suivante pour voir la source générée par leur xsp :

<!-- Utility for viewing source xml or html -->
<map:match pattern="**.xsp2src">
    <map:generate type="serverpages" src="{1}.xsp"/>
    <map:transform src="WEB-INF/tools/simple-xml2html.xsl"/>
    <map:serialize/>
</map:match>