You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users-fr@cocoon.apache.org by Philippe Guillard <pg...@citycita.net> on 2005/05/28 15:45:14 UTC
XSP vs JXT !!
Bonjour,
Ce n'est pas une remise en question d'un debat deja passe, mais une
interrogation en suspend pour moi reactivee sur la liste aujourd'hui.
Sans remettre en question le fait que XSP a ete "deprecated" et est
moins propre que Flow+JXT, il reste une chose que je ne comprends pas:
Lorsque j'ai besoin simplement d'afficher des informations d'une DB et
cacher pour une meilleure performance , je ne vois toujours pas
d'equivalent a XSP avec cache tel que dans les
samples/blocks/xsp/java/cacheable.
Il est possible de cacher une page JXTemplate dans le cvs2.1,
accessoirement mettre une condition en flow pour ne pas aller chercher
la partie persistence en flow, mais de maniere globale le flow comme
l'action n'ont pa lieu d'etre caches. Donc personnellement je garde
actuellement mes XSP et reserve Flow essentiellement pour CForms ou ce
qui necessite du flow.
Ma vision est-elle fausse?
Phil
---------------------------------------------------------------------
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
Re: XSP vs JXT !!
Posted by Philippe Guillard <pg...@citycita.net>.
Ca se tient. J'enleve le moins propre, car ca depend en fait du besoin
au cas par cas. Je realise dailleurs que les pages XSP cachees dont je
parlais ont tellement de cas et acces lecture DB que ne pense pas etre
en mesure de les traduire en JX. De l'autre cote je trouve JX top pour
une reponse de CForm.
Pour le deprecated, c'est une constatation mais rien de plus : j'ai cru
comprendre que ca voulait dire "plus mis en avant" seulement.
Phil
Frédéric Glorieux wrote:
>
>>> Sans remettre en question le fait que XSP a ete "deprecated" et est
>>> moins propre que Flow+JXT
>>
>
> Je n'ai pas toujours bien compris ces débats. Il y a du PHP très
> propre, et des labyrinthes objet en JAVA illisible ? Qu'est-ce qui ne
> va pas dans XSP ?
>
> J'avais l'autre jour ce pb bête, une petite page d'admin qui affiche
> des contrôles pour les gens authentifiés.
>
> J'ai fait une page xsp du genre
>
> <xsp:page>
> <html xmlns="http://www.w3.org/1999/xhtml">
> <title>Administration</title>
> <body>
> <xsp:logic>
> String user=request.getParameter("user");
> if ("".equals(user)) session.removeAttribute("user");
> else if(user != null) session.setAttribute("user", user);
> else user=session.getAttribute("user");
> /* même chose pour pass */
>
> boolean allowed=MyAuth.validUser(user, pass);
>
> if (!allowed) {
> <form>
> <input name="user"/>
> <input name="pass"/>
> </form>
> } else {
>
> Object[] records=getRecords();
> for (int i=0; i< records.length; i++) {
> <form>
> <xsp:logic>records[i].toSax(this.contentHandler);</xsp:logic>
> <button name="add">Ajouter</button>
> <button name="del">Supprimer</button>
> </form>
> }
>
> </xsp:logic>
> </body>
> </xsp:page>
>
> Le html est très pauvre, il est traitée ensuite dans les tuyaux XSL
> sitemap, il n'y a pas de mélange contenu présentation.
>
> Il n'y pas vraiment de contenus, mais une logique de génération de
> contenus, et des contrôles.
>
> Je ne sais pas si c'est du mauvais design, mais il y a quelque chose
> de très pratique pour la maintenance de cette page,
>
> <input name="user"/>
> String user=request.getParameter("user");
>
> On sait ce que le client envoit, et on l'attrappe, dans des syntaxes
> qui ne demandent pas d'apprentissage, sans courir une caisse de
> fichiers dont il faut assurer le parallélisme. S'il faut plus de
> traitements, <xsp:include>org.domain.app.MyAuth</xsp:include>,
> <xsp:include>org.domain.app.MyDB</xsp:include>...
>
> Cette logique me semble moins captive (car un développement libre peut
> très bien entrer dans un logique propriétaire qui enferme), peut être
> portée dans d'autres environnements, car ma donnée compte plus que
> l'application pour la servir.
>
> Ceci dit, une chaîne de génération aussi proprement XML/JAva ne se
> laisse pas tomber comme ça.
>
>
---------------------------------------------------------------------
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
Re: XSP vs JXT !!
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
>> Sans remettre en question le fait que XSP a ete "deprecated" et est
>> moins propre que Flow+JXT
Je n'ai pas toujours bien compris ces débats. Il y a du PHP très propre,
et des labyrinthes objet en JAVA illisible ? Qu'est-ce qui ne va pas
dans XSP ?
J'avais l'autre jour ce pb bête, une petite page d'admin qui affiche des
contrôles pour les gens authentifiés.
J'ai fait une page xsp du genre
<xsp:page>
<html xmlns="http://www.w3.org/1999/xhtml">
<title>Administration</title>
<body>
<xsp:logic>
String user=request.getParameter("user");
if ("".equals(user)) session.removeAttribute("user");
else if(user != null) session.setAttribute("user", user);
else user=session.getAttribute("user");
/* même chose pour pass */
boolean allowed=MyAuth.validUser(user, pass);
if (!allowed) {
<form>
<input name="user"/>
<input name="pass"/>
</form>
} else {
Object[] records=getRecords();
for (int i=0; i< records.length; i++) {
<form>
<xsp:logic>records[i].toSax(this.contentHandler);</xsp:logic>
<button name="add">Ajouter</button>
<button name="del">Supprimer</button>
</form>
}
</xsp:logic>
</body>
</xsp:page>
Le html est très pauvre, il est traitée ensuite dans les tuyaux XSL
sitemap, il n'y a pas de mélange contenu présentation.
Il n'y pas vraiment de contenus, mais une logique de génération de
contenus, et des contrôles.
Je ne sais pas si c'est du mauvais design, mais il y a quelque chose de
très pratique pour la maintenance de cette page,
<input name="user"/>
String user=request.getParameter("user");
On sait ce que le client envoit, et on l'attrappe, dans des syntaxes qui
ne demandent pas d'apprentissage, sans courir une caisse de fichiers
dont il faut assurer le parallélisme. S'il faut plus de traitements,
<xsp:include>org.domain.app.MyAuth</xsp:include>,
<xsp:include>org.domain.app.MyDB</xsp:include>...
Cette logique me semble moins captive (car un développement libre peut
très bien entrer dans un logique propriétaire qui enferme), peut être
portée dans d'autres environnements, car ma donnée compte plus que
l'application pour la servir.
Ceci dit, une chaîne de génération aussi proprement XML/JAva ne se
laisse pas tomber comme ça.
--
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
Re: XSP vs JXT !!
Posted by Philippe Guillard <pg...@citycita.net>.
Rassurant, merci!
Phil
Sylvain Wallez wrote:
> Philippe Guillard wrote:
>
>> Bonjour,
>>
>> Ce n'est pas une remise en question d'un debat deja passe, mais une
>> interrogation en suspend pour moi reactivee sur la liste aujourd'hui.
>> Sans remettre en question le fait que XSP a ete "deprecated" et est
>> moins propre que Flow+JXT, il reste une chose que je ne comprends pas:
>> Lorsque j'ai besoin simplement d'afficher des informations d'une DB
>> et cacher pour une meilleure performance , je ne vois toujours pas
>> d'equivalent a XSP avec cache tel que dans les
>> samples/blocks/xsp/java/cacheable.
>
>
>
> Et c'est exactement pour ça que XSP et ESQL sont encore là ;-)
>
>> Il est possible de cacher une page JXTemplate dans le cvs2.1,
>
>
>
> Pas seulement dans le cvs (ou plutôt le svn), mais aussi dans les
> releases (depuis 2.1.5 si ma mémoire est bonne).
>
>> accessoirement mettre une condition en flow pour ne pas aller
>> chercher la partie persistence en flow, mais de maniere globale le
>> flow comme l'action n'ont pa lieu d'etre caches. Donc
>> personnellement je garde actuellement mes XSP et reserve Flow
>> essentiellement pour CForms ou ce qui necessite du flow.
>> Ma vision est-elle fausse?
>
>
>
> Non, c'est tout à fait opportun. Comme tu le soulignes, tout ce qui se
> situe dans le flowscript ne peut être mis en cache, parce qu'au niveau
> du contrôleur (seule la vue est cachée). Dans le cas de la
> *publication* du contenu d'une base, ESQL est dans Cocoon l'approche
> la plus simple. Par contre, les modifications du contenu de la base
> sont de la responsabilité du contrôleur et de la logique applicative,
> et ne doivent donc pas avoir lieu dans la XSP.
>
> Sylvain
>
---------------------------------------------------------------------
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
Re: XSP vs JXT !!
Posted by Sylvain Wallez <sy...@apache.org>.
Philippe Guillard wrote:
> Bonjour,
>
> Ce n'est pas une remise en question d'un debat deja passe, mais une
> interrogation en suspend pour moi reactivee sur la liste aujourd'hui.
> Sans remettre en question le fait que XSP a ete "deprecated" et est
> moins propre que Flow+JXT, il reste une chose que je ne comprends pas:
> Lorsque j'ai besoin simplement d'afficher des informations d'une DB et
> cacher pour une meilleure performance , je ne vois toujours pas
> d'equivalent a XSP avec cache tel que dans les
> samples/blocks/xsp/java/cacheable.
Et c'est exactement pour ça que XSP et ESQL sont encore là ;-)
> Il est possible de cacher une page JXTemplate dans le cvs2.1,
Pas seulement dans le cvs (ou plutôt le svn), mais aussi dans les
releases (depuis 2.1.5 si ma mémoire est bonne).
> accessoirement mettre une condition en flow pour ne pas aller chercher
> la partie persistence en flow, mais de maniere globale le flow comme
> l'action n'ont pa lieu d'etre caches. Donc personnellement je garde
> actuellement mes XSP et reserve Flow essentiellement pour CForms ou ce
> qui necessite du flow.
> Ma vision est-elle fausse?
Non, c'est tout à fait opportun. Comme tu le soulignes, tout ce qui se
situe dans le flowscript ne peut être mis en cache, parce qu'au niveau
du contrôleur (seule la vue est cachée). Dans le cas de la *publication*
du contenu d'une base, ESQL est dans Cocoon l'approche la plus simple.
Par contre, les modifications du contenu de la base sont de la
responsabilité du contrôleur et de la logique applicative, et ne doivent
donc pas avoir lieu dans la XSP.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
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