problème de génération java via XSP

[Bertrand MARCHAL <BM...@ALTAPROFITS.FR>]

Bonjour, chez Altaprofits, nous avons un site web base sur le framework cocoon.
Nous avons la version 2.1.9
L'application est basée principalement sur la technologie XSP.
Nous avons une particularité, c'est que nous générons dynamiquement le document XSP par un traiment XSL préalable.
Je constate que le nom du java généré est composé est prefixé du nom du document (dans l'uri) suivi de "_pipelinehash__suivi d'un numéro généré sans doute a partir de la query string.
exemple :MenuInternaute_xml_pipelinehash__5264880831221650291.java
Nous avons 2 soucis :
1.nous voulons éviter que cocoon genere autant de classes java que de que de query string possible.
exemple MenuInternaute.xml?toto=1 et MenuInternaute.xml?titi=1 doivent donner naissance à un même source
2.et si possible que cocoon ne regenère pas le point java.

Merci d'avance.
Bertrand Marchal
Altaprofits

Re: problème de génération java via XSP

[Sylvain Wallez <sy...@apache.org>]

Bertrand MARCHAL wrote:
> Bonjour, chez Altaprofits, nous avons un site web base sur le framework cocoon.
> Nous avons la version 2.1.9
> L'application est basée principalement sur la technologie XSP.
> Nous avons une particularité, c'est que nous générons dynamiquement le document XSP par un traiment XSL préalable.
>   

C'est une TRES MAUVAISE idée (j'écris en gros parce que c'est vraiment
une mauvaise idée).

> Je constate que le nom du java généré est composé est prefixé du nom du document (dans l'uri) suivi de "_pipelinehash__suivi d'un numéro généré sans doute a partir de la query string.
> exemple :MenuInternaute_xml_pipelinehash__5264880831221650291.java
> Nous avons 2 soucis :
> 1.nous voulons éviter que cocoon genere autant de classes java que de que de query string possible.
> exemple MenuInternaute.xml?toto=1 et MenuInternaute.xml?titi=1 doivent donner naissance à un même source
> 2.et si possible que cocoon ne regenère pas le point java.
>   

Et 3ème énorme souci: à chaque requête, Cocoon appèle le pipeline qui
construit la XSP (donc générateur + XSL) et passe ensuite toute une
série de XSLs (les logicsheet) pour aboutir à un fichier source Java,
qui est ensuite compilé avant d'être finalement exécuté.

Je suppose que les temps de réponse de l'application doivent être assez
catastrophiques...

Très franchement, il faut revoir l'architecture et ne pas utiliser cette
approche. Les XSPs doivent être des fichiers statiques, même si Cocoon
offre la possibilité de les générer avec un pipeline.

Pourquoi Cocoon l'autorise-t-il alors? Parce que même statique, le
source de la XSP peut venir de différents endroits (contexte de l'appli
web, classpath, fichier zip, etc) et que pour cela l'attribut src="..."
accepte une URL. Mais dans les URLs, il y a des protocoles très
efficaces et d'autres plus coûteux. Dans la catégorie des protocoles
coûteux, il y a "cocoon:" et aussi "http:".

Sylvain

-- 
Sylvain Wallez - http://bluxte.net


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