Reprise du message précédent :

c'est quoi comme donnée à passer ?
 
en quoi ca te fait chier ?

je vois pas en quoi ça fait désordre. déjà, ta servlet, dans ce cas, n'est absolument pas *incluse*. Tu appelles une autre servlet depuis le client, c'est du bete html, et si y'a vraiment un probleme a passer tes trucs par la query string, ça sent le souffre au niveau du design de ton appli, si tu veux mon avis.

(je sens bien la servlet qui genere un graphique à points, et lui qui doit mtnt passer les coordonnées de tous les points dans l'url )

ca peut aussi être un problême de sécurité : t'as pas forcément envie de laisser visible les paramètres permettant de créer l'image ...

ben oui, donc, probleme de design

Un triplet de dates. La JSP avait justement une référence à l'objet encapsulant les dates + données associées.
 
J'aurais préféré passer l'objet directement.

Non quand même pas.
 

J'pense que ce problème doit naturellement se poser quand tu veux générer une vue complexe de tes données. Je ne vois pas bien la solution d'ailleurs.

"?d1="+d1.getTime()+"&d2="+d2.getTime()+"?d3="+d3.getTime()
ça va quoi
pas super beau mais bon ça passe.
sinon tu passes l'identité d'un objet métier, que ton ImageServlet ira rechercher là ou il faut (db, cache, ...)

Effectivement, l'id c'est plus court, mais ça ressemble fort à un trou de sécu.

je vois pas en quoi ?

Et puis, je suis en JSTL monsieur !
<img src="BarChart?release=<c: out value="${task.release}"/>&deadline=<c: out value="${task.deadline}"/>&completion=<c: out value="${task.completion}"/>" alt="Bar Chart"/>

quelle horreur

Ben mon bonhomme peut réclamer d'afficher les dates d'une tâche qu'il est pas supposé avoir le droit d'afficher. Je suppose qu'avec les filters ça peut se résoudre, mais bon, j'ai pas envie de rentrer là-dedans. De toutes manières, dans mon cas, il n'y a pas d'authentification.

Accordé.

ben euh, soit tu as le meme mecanisme pour la jsp en question (j'imagine que tu passes au minimum un identifiant de task ou de projet ou qqchose dans le style à ta jsp....) et tu l'utilises pour ta servlet, soit t'en as pas non plus, et donc bah euh voilà quoi.
je vois pas ou est le trou de secu si t'as pas d'authentification

c'est quand même plus propre

tout est relatif
6 lignes pour une pauvre image

tu veux vraiment que je te l'écrive en une ligne ?

Wahoo. Heu, c'est valable en JSTL 1.0 ? Je vois le commentaire JSP 2.0, mon web container est 1.2 ; je me doute que dmc.

benou: ben non, ça sera pareil mais en illisible...
perso, je taperais plutot dans un truc du genre:

ou, si on peut pas changer la servlet pour qu'elle prenne un task id:

 
 
(dans vos examples, vous oublier de passer par le getTime() de l'objet Date il me semble)
 
 
... bon, évidement, ça veut dire faire ses view en velocity, mais c'est tellement mieux que les jsp

Alors, n'y connaissant rien en velocity, je brandis mon joker.

c'est juste un moteur de template, integré à pas mal de (bons) frameworks web, comme webwork par exemple

le c:url c'est du jstl. C'est juste le ${} à l'exterieur d'une balise JSTL qui est JSP2

Ah ben oui, forcément. /o\ J'avais même pas vu.
Merci benou.

Une idée de la raison pour laquelle ce snippet :

me produit ça ?

J'utilise jakarta-taglibs-standard-1.0.6.zip et le container est un Tomcat 4.1.31.
Perso je vois pas pourquoi, il s'en fout de mon param.
 
EDIT: OK je suis une merde ! C'est le c: qui manque devant param.

drapal