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:[EMAIL PROTECTED]
Autres commandes : mailto:[EMAIL PROTECTED]
