cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric Glorieux <frederic.glori...@ajlsm.com>
Subject Vignettes et cache
Date Wed, 04 May 2005 15:36:21 GMT

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:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org


Mime
View raw message