Mes remarques concerneront un reader apparemment peu document� dans Cocoon <http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/reading/ImageReader.html> qui permet de redimensionner des images JPG � la vol�e.
Il est vrai qu'il repose sur des classes sp�cifiques � SUN, mangeuses de performances.
J'ai l'impression que l'auteur original est Stefano Mazzocchi, pourtant, je note qu'il ne l'utilise pas pour son album <http://gallery.betaversion.org/view_album.php?set_albumName=stefano> ( Powered by Gallery v1.4.3-pl2) alors que son blog est sous cocoon <http://www.betaversion.org/~stefano/linotype/>.
Est-ce qu'il y aurait des contre-indications � son usage ?
Je vois un premier inconv�nient, la cache. Les images g�n�r�es ont l'air d'�tre stock�es dans les "store" de cocoon, mais �videmment dans la limite du nombre d'objets (1000 par d�faut). Pour plus d'images, demand�es en de nombreux formats diff�rents, on peut vite d�passer la limite, surtout qu'elles ne sont pas servies toutes seules.
Sur le mod�le de l'action copy-source de Sylvain Wallez, j'ai impl�ment� un m�canisme tr�s simple de stockage contr�l� en syst�me de fichier, qui s'informe au passage si l'image source a �t� modifi�e. Je soumet cette syntaxe � des gurus de sitemap
<!--
le tuyau qui g�n�re les vignettes, � placer avant celui qui
suit, pour �viter les boucles infinies
-->
<map:match pattern="generate/**_*.*">
<!-- s�lecteur selon le fichier source -->
<map:select type="exists">
<map:when test="{global:collection}{1}.jpg">
<map:read type="image" mime-type="image/jpg" src="{global:collection}{1}.jpg">
<map:parameter name="expires" value="0"/>
<map:parameter name="width" value="{2}"/>
<map:parameter name="height" value="{2}"/>
</map:read>
</map:when>
</map:select>
</map:match>
<!--
le tuyau qui r�ponds au public
succ�s de l'action s'il y a un fichier "depend" contre lequel
valider la cache en "dest" (obtenu par appel de "src")
-->
<map:match pattern="**_*.*">
<map:act type="file-store" src="cocoon:/generate/{0}">
<map:parameter name="dest" value="{global:cache}/{0}"/>
<map:parameter name="depend" value="{global:collection}/{1}.jpg"/>
<!-- on r�ponds sur la cache -->
<map:read src="{global:cache}/{../0}"/>
</map:act>
<!-- juste pour test, un beau sitemap si la source a disparu (depend) -->
<map:read src="sitemap.xmap"/>
</map:match>
Le code se r�sume � quelques lignes que les commiters sauraient bien mieux faire que moi.
A cette occasion, j'ai consid�r� les abstractions excalibur (Source). Pour le cas particulier de ce reader, getLastModified() ou getValidity() ne r�pondaient pas grand chose, d'o� le besoin d'un bon vieux fichier dont on est � peu pr�s s�r qu'il r�pondra une date. C'est la raison du param�tre "depend", pour comparer au fichier cach�, dans l'esprit de la t�che ant "depend" <http://ant.apache.org/manual/OptionalTasks/depend.html>.
Ceci dit, j'ai pu voir que des tuyaux XML r�pondait bien un objet validit�. Je suppose que pour le bien, il faudrait le d�plier et chercher des dates quand on peut en obtenir, ou alors, garder en m�moire des SourceValidity. Mais ce serait refaire une cache, avec une limite � configurer en nombre d'objets ?
J'ai l'impression qu'une b�te comparaison de fichiers, m�me si cela demande un acc�s disque sera globalement plus efficace pour mon probl�me initial, g�n�rer des vignettes sur des images. En plus, cela me permet de monter un dossier assez propre pour des exports statiques, ou pour un mod_cache.
Je ne demande qu'� �tre corrig� si je faisais erreur.
--
Fr�d�ric Glorieux ("AJLSM", <http://ajlsm.com>)--------------------------------------------------------------------- Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
