Discussion :

[Sylvain James]

Bonjour,

J'ai l'impression que le template xslc:ButtonPad n'est pas adapté pour des applis PHP (XMLC_UseXMLC_Action = 1).

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
<xsl:call-template name="xslc:ButtonPad">
<xsl:with-param name="Button_Submit_Click">ProcessPwd(); return false;</xsl:with-param>
<xsl:with-param name="DeleteAction">
<xsl:value-of select="/document/Aliases/DLL"/>DeleteUSER</xsl:with-param>
</xsl:call-template>

Dans le code ci dessous, le paramètre DeleteAction va générer le code javascript suivant (extrait) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
onclick="ConfirmDelete('MainForm','DeleteUSER',
'Etes vous sûr de vouloir supprimer cet élément ?');return false;"

La fonction javascript ConfirmDelete (xslc.js) va modifier l'attribut action du formulaire avant de le poster :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
function ConfirmDelete(FormName, DeleteAction, Prompt) {
	var F = document.forms[FormName];
	if (confirm(Prompt)) {
		F.action = DeleteAction;
		F.submit();
	}
}

Le problème est que quand XMLC_UseXMLC_Action=1, c'est le champ XMLC_Action qu'il faut modifier, et non pas l'attribut action du formulaire.

Remède ?
Ca suppose que le code javascript devrait être au courant qu'on soit en mode
XMLC_UseXMLC_Action=1 (variable js globale du type XMLC_PictosPath ?), et que le test devrait être effectué dans ConfirmDelete pour affecter l'action du formulaire au bon endroit.

[RDM]

Ca suppose que le code javascript devrait être au courant qu'on soit en mode
XMLC_UseXMLC_Action=1 (variable js globale du type XMLC_PictosPath ?), et que le test devrait être effectué dans ConfirmDelete pour affecter l'action du formulaire au bon endroit.

Exact.

[Sylvain James]

Proposition de correctif :

Dans xslc.xsl :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
 
<script language="javascript">
<xsl:if test="(/document/XMLC_Params/XMLC_TrapJavascriptError) and (/document/XMLC_Params/XMLC_TrapJavascriptError = '1')"><![CDATA[function trapError() { return true; }
window.onerror = trapError;
]]></xsl:if><![CDATA[var XMLC_BaseHRef = ']]><xsl:value-of select="$XMLC_BaseHRef"/><![CDATA[';
var XMLC_SkinPath = ']]><xsl:value-of select="$XMLC_SkinPath"/><![CDATA[';
var XMLC_Portal = ']]><xsl:value-of select="$XMLC_Portal"/><![CDATA[';
var XMLC_PictosPath = ']]><xsl:value-of select="$XMLC_PictosPath"/><![CDATA[';
var XMLC_UseXMLC_Action = ']]><xsl:value-of select="/document/XMLC_Params/XMLC_UseXMLC_Action"/><![CDATA[';
var XMLC_HandleScrollbars = ']]><xsl:value-of select="$HandleScrollbars"/><![CDATA[';]]><xsl:if test="$UpdateParentTitle = '1' and $Title != ''"><![CDATA[if (top != null)
  top.document.title = document.title;]]></xsl:if>

dans xslc.js :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
function ConfirmDelete(FormName, DeleteAction, Prompt) {
	var F = document.forms[FormName];
	if (confirm(Prompt)) {
		if (XMLC_UseXMLC_Action=='1') 
                   F.XMLC_Action.value = DeleteAction
                else
                   F.action = DeleteAction;
 
                F.submit();
	}
}

[Nicolas.Cogi]

Je me demandais, quid de mod_rewrite ?
Je pense que tous les dev XMLRAD php utilise Apache, et ont donc acces a mod_rewrite pour réécrire les urls.

Aucun probleme pour tout ce qui est GET, ca se fait plutot simplement. Mon probleme à ce sujet concerne les POST : comment rajouter avec mod_rewrite un nouveau champ dans les post params ? Est-ce possible ?

Ce qui me seduit avec mod_rewrite, c'est que rien ne bouge, quelque soit le type de projet XMLRAD. Les xsl sont générés tout pareils, que ce soit en ISAPI, module apache ou PHP. Ca permet donc simplement de passer d'un environnement à l'autre sans probleme à ce niveau là, la réécriture de l'URL invoquée se faisant coté serveur.

L'autre solution jouable aussi est d'encapsuler tous les liens hypertextes et les formulaires dans une template (xslc:Link et xslc:Form, prévues de toutes facons) ce qui permet de résoudre le probleme de portabilité, mais pas celui du Javascript...

Traiter le cas PHP dans toutes les fonctions formulaires de xslc.js ne me séduit pas trop. Et ca ne résout pas le problème d'écriture coté développeur.

Vous en pensez quoi ?

[Sylvain James]

Je me demandais, quid de mod_rewrite ?
Je pense que tous les dev XMLRAD php utilise Apache, et ont donc acces a mod_rewrite pour réécrire les urls.

Salut Nicolas,

Tu dois avoir raison, mais il me semble bien qu'on a écrit une appli au boulot qui tourne sous IIS + PHP...

Aucun probleme pour tout ce qui est GET, ca se fait plutot simplement. Mon probleme à ce sujet concerne les POST : comment rajouter avec mod_rewrite un nouveau champ dans les post params ? Est-ce possible ?

Je ne sais pas mais je pense que oui. J'imagine mal contraindre un développement à tout passer en GET...surtout aujourd'hui avec l'usinerie web 2.0.

Ce qui me seduit avec mod_rewrite, c'est que rien ne bouge, quelque soit le type de projet XMLRAD. Les xsl sont générés tout pareils, que ce soit en ISAPI, module apache ou PHP. Ca permet donc simplement de passer d'un environnement à l'autre sans probleme à ce niveau là, la réécriture de l'URL invoquée se faisant coté serveur.

L'autre solution jouable aussi est d'encapsuler tous les liens hypertextes et les formulaires dans une template (xslc:Link et xslc:Form, prévues de toutes facons) ce qui permet de résoudre le probleme de portabilité, mais pas celui du Javascript...

Traiter le cas PHP dans toutes les fonctions formulaires de xslc.js ne me séduit pas trop. Et ca ne résout pas le problème d'écriture coté développeur.

Vous en pensez quoi ?

Il est certain qu'imposer un passage par mod_rewrite semble une excellente solution pour éviter de spécialiser le framework selon telle ou telle plateforme, surtout que là, le binaire, les xsl et les javascripts sont impactés.
Malgré tout, on perd le côté multiplateforme, on se rend dépendant de mod_rewrite et surtout ça complexifie la configuration serveur.
Configurer mod_rewrite n'a pas l'air très fingers in the nose...

Actuellement, un projet XMLRAD / PHP ne peut pas fonctionner en XCopy sur une plateforme XMLRAD / Delphi par exemple. Tout simplement parce qu'il va y avoir quelques modifs à faire dans les XSL (XMLC_Action etc...). Donc la solution actuelle n'est pas non plus idéale.

Alors à condition d'inclure le paramétrage de mod_rewrite lors de la création d'un projet Apache / PHP, ça peut valoir le coup.

Maintenant de là à dire qu'on ne pourrait plus utiliser PHP sous IIS...? Il y a bien des filtres ISAPI qui existent pour la réécriture d'url. http://www.isapirewrite.com/ par exemple qui fournit une version Lite gratuite.

à suivre...

[Nicolas.Cogi]

Tu dois avoir raison, mais il me semble bien qu'on a écrit une appli au boulot qui tourne sous IIS + PHP...

Pas de bol pour mon argumentaire Néanmoins, comme tu l'indiques plus bas, il existe des équivalent mod_rewrite pour IIS.

Configurer mod_rewrite n'a pas l'air très fingers in the nose...

Clairement, mais les regles de base pour une appli XMLRAD sont simples et peuvent faire parti d'un fichier de conf .htaccess fourni de base.

J'ai posé la question sur le forum Apache, et à priori, POST n'est pas supporté par mod_rewrite pour faire ce qu'on veut (réecriture de l'url + rajout d'un champ dans les post params)... Damned !

Reste la solution de l'encapsulation dans des templates, qui résout pas mal de trucs, sauf le javascript du développeur.