Mailing-List: contact users-fr-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users-fr@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <4350BD70.1030101@citycita.net>
Date: Sat, 15 Oct 2005 16:27:28 +0800
From: Philippe Guillard <pguillard@citycita.net>
User-Agent: Mozilla Thunderbird 0.8 (X11/20041020)
MIME-Version: 1.0
To: users-fr@cocoon.apache.org
Subject: [Again]ImageReader et .gif
References: <431AB861.3090800@citycita.net> <431B47BB.3000808@ajlsm.com>
 <431C019E.1010600@citycita.net> <431C0E2D.8080508@ajlsm.com>
 <431C1160.6090800@citycita.net>
In-Reply-To: <431C1160.6090800@citycita.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Bonjour,

J'ai choisi une strategie simple pour sortir les images de mes 
utilisateurs depuis database: ImageReader pour le jpg, et resource 
reader pour le gif.
Seulement je ne vois toujours pas comment proceder. Quelqu'un peut-il me 
dire ce qu'il en pense?

1. L'ideal serait de faire un match dans la sitemap selon l'extension 
.gif->resource reader, .jpg-> ImageReader. Mais ces images viennent de 
ma DB, et je ne connais pas encore l'extension (example ci dessous)
(Je ne vois pas comment inserer un check entre 2 pipelines comme ceux la)
2. L'autre solution serait d'etendre ImageReader pour detecter le gif et 
dans ce cas le sortir tel quel. Hum pas si simple.

    <map:match pattern="photo/*">   <!-- example photo/100 (100 est la 
clef primaire dans la database)
        <map:read type="image" src="cocoon:/photoDB/{1}" 
mime-type="image/jpeg">
            <map:parameter name="width" value="102"/> 
            <map:parameter name="height" value="76"/>             
        </map:read>
    </map:match>
   
    <map:match pattern="photoDB/*">  
        <map:read type="databasereader" src="{1}">
            <map:parameter name="table" value="IMAGE"/>
            <map:parameter name="image" value="image"/>
            <map:parameter name="key" value="idimage"/>
        </map:read>
      </map:match>

3. L'autre solution serait de sortir le nom plus l'extension de mes 
images dans mes pages, mais j'utilise hibernate avec des class lazy, 
aller chercher l'id de l'image ne me coute rien, aller chercher son 
extension me fait charger le bean en entier avec l'image pour pas grand 
chose, puisque le browser va charger l'imagine dans un autre request...

Phil


Philippe Guillard wrote:

> Merci
> Phil
>
> Fr�d�ric Glorieux wrote:
>
>>
>>> Oups je n'avais pas vu ces mails en effet. Merci Frederic.
>>> Je serais pas contre de voir le code de l'action en effet, mais 
>>> avant je crois je dois verifier mon besoin:
>>> Je voudrais surtout en savoir plus sur le probleme de perf 
>>> d'ImageReader : je ne gere max qu'une photo personnelle sur la page 
>>> perso de chaque user, et pas un album, donc j'espere  beaucoup 
>>> d'images, mais jamais 2 par page. Crois tu qu'ImageReader pourrait 
>>> etre acceptable pour cela?
>>
>>
>>
>> Une image par page, peu de risques de probl�mes, sauf si 20 personnes 
>> en m�me temps se connectent dans la m�me seconde, et que la JVM est 
>> limit�e � 64Mo. Apr�s la premi�re demande, l'image est bien mise en 
>> cache par cocoon, ce n'est plus le probl�me de l'ImageReader.
>>
>> Un probl�me qui reste, l'ImageReader ne supporte pas nativement le gif.
>>
>> Notre choix d'ImagMagick nous a permis de r�soudre facilement ce 
>> probl�me.
>>
>> Pour des autres librairies JAVA, le fil cit� parle un peu de JAI, il 
>> faut avoir envie, sinon j'ai d�j� pu tester
>> <http://schmidt.devlib.org/jiu/documentation.html>.
>>
>> En exploitation, j'ai tir� du bon code pour trouver les octets 
>> magiques qui d�terminent le format d'une image 
>> <http://schmidt.devlib.org/image-info/index.html> (sur le flux 
>> d'octets, sans charger un pixel).
>>
>>> (par contre je crois etre tombe sur cette situation similaire a ce 
>>> que tu decris dans ces mails avec une image vide qui semble rester 
>>> cachee quelquepart et peut etre comme j'ai lu par firefox...)
>>
>>
>>
>> C'est vrai qu'un probl�me serveur peut se r�soudre, mais on n'a pas 
>> la main sur la cache du client. Je n'ai pas trouv� de m�thode pour 
>> �viter l'effet d'une r�ponse 200 de Cocoon/Tomcat, quand il y a un 
>> out of memory.
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
>
>
>


---------------------------------------------------------------------
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