Geckozone

Bonjour,

je m'étonne d'une chose : les scripts ASP et JSP sont délimités par <% [...] %> ; or ce n'est pas une déclaration correcte de processing instruction, donc si j'ai bien compris on ne peut pas avoir de document valide XHTML contenant de l'ASP ou du JSP.
Vrai ou pas ???

Pour le PHP (que je connais assez bien, contrairement à ASP et JSP que je n'ai jamais utilisé), les scripts sont délimités par des balises <?php [...] ?> ; la forme "courte" <? [...] ?>, bien que très utilisée, est officiellement dépreciée (essentiellement parcequ'elle n'est pas conforme XML, justement).

Question : au lieu de <% [...] %>, est-il possible d'utiliser des balises du type <?asp [...] ?> et <?jsp [...] ?> pour ASP et JSP respectivement ?

J'ai besoin d'éclaircissements à ce sujet pour faire progresser mon extension NsmConText, afin d'implémenter le support ASP et JSP dans Nvu.

Merci d'avance !

La version 1.2 de la spécification JSP a introduit une syntaxe XML alternative (référence)
On pourra donc écrire

Code : Tout sélectionner

<jsp:scriptlet>...code...</jsp:scriptlet>

au lieu de

Code : Tout sélectionner

<%...code...%>

Mais j'ai l'impression que cette syntaxe est peu utilisée.

Merci pour cette info. Je suis allé visiter la référence que tu passes en lien mais ça m'a suscité d'autres questions :

* cette syntaxe suppose-t'elle qu'on déclare un namespace supplémentaire dans le document (x)HTML ?

* peut-on utiliser à la place une syntaxe du type

Code : Tout sélectionner

<script language="JSP"> [...] </script>

sans perturber le fonctionnement coté serveur ?

Ce n'est pas gênant que la syntaxe soit peu usitée, c'est uniquement pour rendre le document éditable par Nvu. Il est toujours possible de retransformer cette syntaxe en <% [...] %> lors de l'enregistrement de la page ASP/JSP.

Kaze a écrit :Bonjour,

je m'étonne d'une chose : les scripts ASP et JSP sont délimités par <% [...] %> ; or ce n'est pas une déclaration correcte de processing instruction, donc si j'ai bien compris on ne peut pas avoir de document valide XHTML contenant de l'ASP ou du JSP.
Vrai ou pas ???

Vrai. Mais tu ne peux pas non plus avoir une page valide xhtml avec du php dedans (<?php ?>)

Pour <jsp:scriptlet> effectivement, si tu définis le namespace (genre xmlns:jsp="http://java.sun.com/JSP/Page") c'est bon (tu peux mettre la définition de namespace dans la racine du document).

Cela dit... de toutes façons le navigateur ne saura pas l'interpréter, et le validateur html trouvera à tous les coups le contenu invalide (à moins que le tout ne soit dans une déclaration CDATA). Donc pour éditer, vu que c'est ce but uniquement, je serais plutôt du genre à dire de tester ce qui marche sur le serveur. Si <jsp:scriptlet> peut déclancher l'interprétation, pourquoi faire plus compliqué ?

Kaze a écrit : peut-on utiliser à la place une syntaxe du type
Code : Tout sélectionner
<script language="JSP"> [...] </script>
sans perturber le fonctionnement coté serveur ?

Non, cette notation sera interprétée comme du simple texte.

MERCI calimo pour ces infos.

calimo a écrit :
Kaze a écrit :je m'étonne d'une chose : les scripts ASP et JSP sont délimités par <% [...] %> ; or ce n'est pas une déclaration correcte de processing instruction, donc si j'ai bien compris on ne peut pas avoir de document valide XHTML contenant de l'ASP ou du JSP.
Vrai ou pas ???
Vrai. Mais tu ne peux pas non plus avoir une page valide xhtml avec du php dedans (<?php ?>)

Ah je ne savais pas ça

Le fait que htmlTidy "passe" sans problème mes templates PHP avec des balises du type <?php ?> m'a induit en erreur. Je pensais que c'était au moins valide XML...

calimo a écrit :Pour <jsp:scriptlet> effectivement, si tu définis le namespace (genre xmlns:jsp="http://java.sun.com/JSP/Page") c'est bon (tu peux mettre la définition de namespace dans la racine du document).

Cela dit... de toutes façons le navigateur ne saura pas l'interpréter, et le validateur html trouvera à tous les coups le contenu invalide (à moins que le tout ne soit dans une déclaration CDATA). Donc pour éditer, vu que c'est ce but uniquement, je serais plutôt du genre à dire de tester ce qui marche sur le serveur. Si <jsp:scriptlet> peut déclancher l'interprétation, pourquoi faire plus compliqué ?

Je ne cherche pas nécessairement à faire plus compliqué, mais :
* je cherche une méthode qui puisse être utilisée de la même façon pour ASP et JSP ; existe-t'il une balise du style <asp:scriptlet> ?
* si le code ASP/JSP est inclus dans une balise <jsp:scriptlet>, le contenu du script sera visible et modifiable dans la fenêtre d'édition de Nvu, ce que je trouve dangereux
* je comptais réutiliser le mécanisme qui permet à Nvu d'éditer des commentaires et des processing instructions... comme pour <?php ?>

En fait, je pensais qu'il y aurait une alternative du genre :

Code : Tout sélectionner

<script language="ASP"> [...] </script>

et

Code : Tout sélectionner

<script language="JSP"> [...] </script>

avec le contenu du script dans un CDATA, comme pour les styles.
Je n'en ai jamais vu, mais je crois avoir lu que ça serait correct au moins pour le cas du PHP.

Avantages : le code est masqué dans la fenêtre d'édition, et ça doit être valide xHTML
Inconvénients : je ne sais pas si ça déclanche l'interprétation serveur... et Nvu n'affiche pas de balise "script" dans la fenêtre d'édition (je dois pouvoir y remédier mais ça risque d'être compliqué).
Sais-tu quelque chose à ce sujet ?

Si ça ne déclenche pas l'interprétation serveur, alors il faudra de toutes façons remplacer <script language="JSP">...</script> par <%...%> lors de l'enregistrement du document ; auquel cas ça serait plus simple (coté développement de l'extension) d'utiliser une forme <?jsp...?>.

Merci encore pour ces précisions, je commence à y voir plus clair.

Gilles a écrit :
Kaze a écrit : peut-on utiliser à la place une syntaxe du type
Code : Tout sélectionner
<script language="JSP"> [...] </script>
sans perturber le fonctionnement coté serveur ?
Non, cette notation sera interprétée comme du simple texte.

Dsl ta réponse est arrivée pendant que je rédigeais le message précédent

Merci pour cette précision. Il va falloir que je médite là-dessus maintenant...

Kaze a écrit :...htmlTidy ... XML...

Il ne te mets même pas un avertissement ? C'est pas normal ça. Essaye le validateur du W3C pour voir

Cela dit si c'est son utilisation... pourquoi pas ? Vu que de toutes façons le but n'est pas d'envoyer la page telle quelle au client, tu peux faire ce que tu veux de ton côté

La validation, c'est uniquement pour avoir une certaine garantie d'interprétation plus ou moins correcte côté client, ce n'est pas pour qu'au cours du développement ça soit valide

Kaze a écrit : * je cherche une méthode qui puisse être utilisée de la même façon pour ASP et JSP ; existe-t'il une balise du style <asp:scriptlet> ?
* si le code ASP/JSP est inclus dans une balise <jsp:scriptlet>, le contenu du script sera visible et modifiable dans la fenêtre d'édition de Nvu, ce que je trouve dangereux
* je comptais réutiliser le mécanisme qui permet à Nvu d'éditer des commentaires et des processing instructions... comme pour <?php ?>

Si j'ai bien compris, le but est que NsmConText prenne la page de Nvu, la transforme pour aller dans un éditeur, que l'utilisateur édite la page manuellement, et que NsmConText fasse la transformation inverse vers Nvu c'est ça ? (c'est sacrément compliqué, et je dois avouer ne pas trop comprendre le but... pourquoi ne pas faire de l'édition HTML directement ?

)

Dans ce cas, à toi de voir :

Pour chaque langage ce qu'il est nécessaire d'avoir sur le serveur
Ce que l'éditeur de texte supporte
(et accessoirement que ce soit compatible avec Nvu et qu'il ne le modifie pas)

À partir de là, qu'est-ce que ça change que ce soit <?jsp ?>, <jsp:script /> ou <script type="application/jsp" /> ?

À méditer

PS : l'attribut "language" sur script est déprécié, il faut utiliser type

Mais de là je ne vois pas en quoi il serait interprété comme du texte...

Ce sera simplement un script que Nvu ne sera pas capable d'interpréter (comme tous les autres je crois)

calimo a écrit :La validation, c'est uniquement pour avoir une certaine garantie d'interprétation plus ou moins correcte côté client, ce n'est pas pour qu'au cours du développement ça soit valide

Bien sûr. Mais comme Nvu est capable d'éditer n'importe quelle page valide xHTML (pour autant que je sache !), je me dis que si le template est valide xHTML, il est éditable par Nvu.

calimo a écrit :Si j'ai bien compris, le but est que NsmConText prenne la page de Nvu, la transforme pour aller dans un éditeur, que l'utilisateur édite la page manuellement, et que NsmConText fasse la transformation inverse vers Nvu c'est ça ? (c'est sacrément compliqué, et je dois avouer ne pas trop comprendre le but... pourquoi ne pas faire de l'édition HTML directement ? )

Nvu ne permet pas d'éditer une page contenant du code sous la forme <%...%>, alors qu'il permet d'éditer un template PHP si le code PHP est inclus dans le document HTML sous la forme <?php...?>.

L'idée serait donc de se rapprocher de ce type de fonctionnement (cf. ce message consacré au support ASP/JSP dans NsmConText), pour permettre l'édition WYSIWYG d'un template ASP/JSP.

[EDIT]

Le but est de transformer le document pour pouvoir l'éditer avec Nvu ; et si possible de pouvoir éditer des bouts de code ASP/JSP comme on peut le faire avec le code PHP.
NsmConText permet déjà de lancer un éditeur de code sur un fichier PHP, ASP, JSP ou autre, auquel cas le document est édité tel quel, et ne doit évidemment pas être transformé pour ça.

[/EDIT]

calimo a écrit :À partir de là, qu'est-ce que ça change que ce soit <?jsp ?>, <jsp:script /> ou <script type="application/jsp" /> ?

Rien, aucune de ces formes n'étant à la fois éditable par Nvu et utilisable par un serveur ASP ou JSP.
C'est pour cette raison que je pense utiliser la forme <?jsp...?>

Simplement, ça aurait été pratique que ça soit valide HTML/XML et reconnu par le serveur ; pas seulement pour la beauté du geste, mais surtout pour permettre un minimum d'intéropérabilité (ne serait-ce que pour lancer htmlTidy par exemple).

calimo a écrit :PS : l'attribut "language" sur script est déprécié, il faut utiliser type

noté !

calimo a écrit :Mais de là je ne vois pas en quoi il serait interprété comme du texte... Ce sera simplement un script que Nvu ne sera pas capable d'interpréter (comme tous les autres je crois)

Je pense que ce que Gilles veut dire, c'est que ça ne déclencherait pas l'interprétation par le serveur JSP.

Kaze a écrit :
calimo a écrit :Mais de là je ne vois pas en quoi il serait interprété comme du texte... :roll: Ce sera simplement un script que Nvu ne sera pas capable d'interpréter (comme tous les autres je crois)
Je pense que ce que Gilles veut dire, c'est que ça ne déclencherait pas l'interprétation par le serveur JSP.

C'est bien ce que je voulais dire.

Kaze a écrit :Bien sûr. Mais comme Nvu est capable d'éditer n'importe quelle page valide xHTML (pour autant que je sache !), je me dis que si le template est valide xHTML, il est éditable par Nvu.

Non, il est éditable par Nvu s'il est lisible par un parser XML. Mais la validité HTML n'est vérifiée nulle part dans Nvu.

Benoit a écrit :
Kaze a écrit :Bien sûr. Mais comme Nvu est capable d'éditer n'importe quelle page valide xHTML (pour autant que je sache !), je me dis que si le template est valide xHTML, il est éditable par Nvu.
Non, il est éditable par Nvu s'il est lisible par un parser XML. Mais la validité HTML n'est vérifiée nulle part dans Nvu.

Bah s'il faut que le fichier contienne du HTML et soit "parsable" en XML pour être édité avec Nvu, est-ce que ça n'implique pas qu'une page valide XHTML est toujours éditable par Nvu ?

Ou j'ai encore raté un truc ???

C'est exact, mais l'inverse n'est pas vrai : une page éditable par Nvu n'est pas toujours valide XHTML (encore qu'il s'attèle à la rendre valide

).

Maintenant je ne connais pas suffisemment le XML pour savoir ce qui est parsable ou pas

calimo a écrit :C'est exact, mais l'inverse n'est pas vrai : une page éditable par Nvu n'est pas toujours valide XHTML

Là d'accord (ouf, il y a quand même deux ou trois trucs que j'ai compris) 8)

Personnellement, j'ai constaté que toute page, si elle est reformattée par htmlTidy sans être corrompue, était éditable par Nvu (qu'elle soit validée par le W3C ou non). En plus htmlTidy reconstitue la mise en page du code (indentation et line wrapping), à laquelle je demeure sensible...

Ca devrait être suffisant pour me permettre d'implémenter un minimum de support ASP/JSP dans Nvu : il suffit de transformer les balises <%...%> en quelque chose de compatible XML pour pouvoir l'éditer avec Nvu... quitte à le retransformer en <%...%> au moment de la sauvegarde. C'est du bricolage, mais si ça permet d'éditer des templates PHP/ASP/JSP ça me suffira bien ! Pour le reste il y a des éditeurs de code.

Merci encore pour toutes ces précisions qui m'ont aidé à avoir une vision plus claire de tout ça !!

Geckozone

[résolu] ASP, JSP et balises <% [...] %>

[résolu] ASP, JSP et balises <% [...] %>

Re: ASP, JSP et balises <% [...] %>

Re: ASP, JSP et balises <% [...] %>

Re: ASP, JSP et balises <% [...] %>

Re: ASP, JSP et balises <% [...] %>

Re: ASP, JSP et balises <% [...] %>

Re: ASP, JSP et balises <% [...] %>

Re: ASP, JSP et balises <% [...] %>