Discussion :

[grunt2000]

Bonjour,


Je souhaite afficher un lien porteur d'un attribut title, dont le texte est dans un fichier de propriétés.

Code :

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

1
2
3
<h:outputLink title="${rsc.txt_tp02_title}" 
value="jsf/introductionJava.jsp?#TP02">${rsc.txt_tp02}</h:outputLink>

Je prend une exception à l'affichage: "D'après la TLD, l'attribut title n'accepte aucune expression" (en rouge: la partie fautive).

Drôlement fûté, je me dis. J'aurais dû rester avec une balise <a>, parce que ça, ça marchait:

Code :

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

1
2
3
 
<a title="${rsc.txt_tp02_title}" 
value="jsf/introductionJava.jsp?#TP02">${rsc.txt_tp02}</a>

Comment JSF arrive à rater ça? Ou plutôt comment l'ai-je si mal compris pour ne pas parvenir à faire quelque-chose à la fois d'aussi badin et essentiel?

Il faut coder toutes les chaines en dur dans toutes les JSP pour avoir le droit d'utiliser les balises JSF? Car je vois peu comment je vais lire un fichier de propriétés ou construire une chaîne de caractères dynamique sans l'employer ensuite par une expression.

Qu'est-ce que c'est que cette intrigue?


En vous remerciant,

Grunt.

[adiGuba]

Salut,


Quelle URI/version tu utilises pour la taglib JSF ?
Les premières taglis utilisaient un moteur d'EL intégré qui ne fonctionne pas avec les JSP 2.0 qui intégré son propre moteur d'EL.

a++

[grunt2000]

Par défaut, j'utilise le jeu de jars JSF fournis avec JBoss 5.0.1.GA, un JSF 1.2.

Je ne crois pas avoir donné une indication particulière de version à employer au niveau de la déclaration de mes tags, mais je pourrai vérifier dans l'après-midi.

Que dois-je vérifer de bien trouver comme déclaration?
Ou plutôt, que dois-je m'assurer de ne pas voir, et où?

[adiGuba]

Heu... Je peux me tromper mais faut peut-être utiliser les expressions de JSF, donc avec un # à la place du $ :

Code :

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

1
2
<h:outputLink title="#{rsc.txt_tp02_title}" 
value="jsf/introductionJava.jsp?#TP02">${rsc.txt_tp02}</h:outputLink>

a++

[tchize_]

La notation ${} (évaluation par le conteneur) pour les JSF ne fonctionne que si tu utilise des JSP 2.1 ainsi que JSF >=1.2. La version de JSP que tu utilise est déterminée par les entetes de ton web.xml. Peux tu nous montrer le contenu de ton web.xml? Assure toi aussi que tu n'a nis jar de JSF ni tld qui traineraient et cacheraient celles de JBOSS.
Dans tous les cas, la notation #{} devrais fonctionner

[grunt2000]

Je vous remercie et je vais faire ces expérimentations et vérifications très bientôt.

Mais je reste perplexe, car je ne comprends plus la finalité ou le rôle de "l'opérateur" # ici.

Je le comprenais comme: il existe un getter, mais aussi un setter.

mais dans le cas de:

Code :

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

<h:outputLink title="#{rsc.txt_tp02_title}" ...

où rsc désigne un ResourceBundle, j'ai du mal à me représenter ce que cela signifie en "phase setter".
Mais peut être que je m'égare, et que ce qui me donne mes ressources n'est pas un ResourceBundle comme je le crois, mais un objet spécifique de JSF. Mais même ainsi, ma compréhension reste extrêmement floue.

Il y a visiblement quelque chose que je me représente mal entre ${x} et #{x}.

Dans mon esprit, ${x} disait: getX();
#{x} disait getX(), setX() voire symbolisait une méthode et était x().

Mais là... je suis perdu.
#{rsc.txt_tp02_title} =
rsc.getString("txt_tp02_title") + rsc.setString("txt_tp02_title", value) ?
txt_tp02_title() ?

.... je suis vraiment aux fraises niveau comprenette.

[tchize_]

au début JSF avait sont propre interpréteur d'expression, pas compatible avec les système d'EL de JSP, car JSP faisait l'évaluation et renvoyais une String évaluée, pas très utile pour JSF. Donc pour que l'EL de JSF recoive bien son expression et puisse l'interpréter, le caractère # à été choisi, car il était différent du $ utilisé par JSP. Ensuite JSF faisait lui même sa soupe avec ça.

On avance dans le temps, dans JSP 2.1 / JSF 1.2, le système de gestion de EL a été unifié et des mécanismes mis en place pour que les EL de JSP soient utilisable par JSF. Donc l'expression ${} est devenue utilisable en JSF en même temps qu'elle est devenue utilisable sur la page JSP en dehors de tout tag. La notation #{} a cependant conservée par compatiblité avec les anciennes pages. D'ou ma réponse: "#{} marchera dans tous les cas"

Dans ton cas, la notation ${} ne semble pas prise en charge par JSF, donc soit t'es à une spécification ancienne de JSP (spécification qui dépend de l'entete de ton web.xml), soit t'as une vielle taglib JSF qui traine et qui déclare que les tag JSF ne supportent pas le EL JSP.

[grunt2000]

Je vous remercie pour les explications concernant #, car j'y perdais mon latin.

Effectivement, quand je le place, il fonctionne.


Concernant la possibilité que je sois entrain d'utiliser la mauvaise spécification JSF à mon insu:
L'entête de mon fichier web.xml est celui-ci:

Code :

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

1
2
3
4
5
6
7
8
9
 
<?xml version="1.0" encoding="ISO-8859-1" ?>
 
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns="http://java.sun.com/xml/ns/javaee" 
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" 
version="2.5">

et mes JSP débutent ainsi:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<%@page language="java" contentType="text/html; charset=UTF-8" 
pageEncoding="ISO-8859-1" %>
 
<%@taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>

A priori, derrière moi, je ne peux avoir en ligne que les jars JSF de JBoss 5.0.1.GA qui sont "de base" chez lui, et que je ne transporte pas, moi. Mais se pourrait-il que mes déclarations de taglibs ne "demandent pas assez", et que ça ait été la cause de mes troubles?

[tchize_]

ca a l'air correct coté web.xml. Une dernière chose, aurais-tu inclu des fichiers .tld dans ta webapp? Si tu a installé les .tld d'une mauvaise version de JSF, ceux-ci déclarent probalbement ne pas gérer les EL

[grunt2000]

J'ai cherché, mais je n'ai pas vu de .tld mentionnées directement pour jsf, ni placées dans le WEB-INF.

Existe t-il une vérification que je peux faire, avec un mot-clé JSF pas trop compliqué à mettre en place, qui me montrerait tout de suite si je suis en JSF 1.2 ou plus bas que cela? Même à la limite en provoquant un plantage sauvage en cas d'échec: c'est juste pour mettre au clair les choses.

Ai-je également un moyen de détecter la version de mon EL par un test qui me montre par son résultat que je suis dans sa bonne version et pas dans une obsolète? Par un résultat singulier que l'on attend dans une version et pas dans une autre, par une fonction ou manipulation qui se révèle possible dans un cas, inaccessible dans l'autre?

Je voudrais le vérifier concrètement à l'exécution. Est-ce possible?

[tchize_]

Existe t-il une vérification que je peux faire, avec un mot-clé JSF pas trop compliqué à mettre en place, qui me montrerait tout de suite si je suis en JSF 1.2 ou plus bas que cela?

tu peux faire ceci:

Code :

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

1
2
3
4
5
6
7
8
 private final static int specifyVersion() {
	try {
	  Application.class.getMethod("getExpressionFactory", null);
	} catch (NoSuchMethodException e) {
	  return 11;
	}
	return 12;
}

Sinon, tu peux toujours rechercher un des jars de jsf (suffit de faire une recherche sur le nom d'un classe JSF sur tous les .jar), l'ouvrir avec un archiveur et regarder le contenu de MANIFEST.MF pour connaitre à la fois la version de JSF et son implémentation (sun, myfaces,...)

Pour ce qui est du tld, une recherche sur "*.tld" dans ton WEB-INF/ ainsi que sur ".tld" à l'intérieur de WEB-INF/lib/*.jar te donnera la liste des tld. Si des tld existent en double version différentes, il n'y a aucun moyen de connaitre à priori quelle version sera utilisée par le conteneur, il faudra donc purger les mauvaises version.