Newsgroup: it.comp.java
Titolo: passaggio di parametri tra servlet

devo realizzare un procedura mediante servlet che funziona un pò come un
wizard, con più servletre ciascuna registrante qualche dato.
Ad esempio la prima videata (servlet) richiede allìuntente di inserire il
suo nome
la seconda di fare una scelta tipo con due radio button (es. scelta a o
scelta b)
e così via.
L'ultima servlte dovrebbe elaborare gli input dell'utente e rispondere
al'untente in base alle scelte dal lui effettuate.
Il mio problema è sapere come l'ultima servlete può cononscere tutte i vari
input e le secelte.
pensavo di passare dei parametri da una servlet alla successiva  così
la servlet A passa alla servlete B il suo parametro a
la servlet B passa alla servlete C il parametro a+b
la servlet C passa alla servlete D il parametro a+b+c
e così via
è giusto?


--
(
  Lucio Benfante
 
http://www.dei.unipd.it/~benfante
                                          )
Sent via Deja.com 
http://www.deja.com/
Before you buy.

 cui memorizzano i parametri a mano a mano che li raccolgono...
Meglio di no perchè non funzionerebbe in caso di accessi concorrenti (se i
metodi sono statici sono unici e quindi verrebbero mescolati ottenendo un
bel minestrone). Meglio creare una classe dalla quale ricavi varie istanze
più un ID unico che passi come parametro tra le servlet, e poi continui come
da te suggerito.
Ciao,
 Stefano
----------
"X WindowSSS, teSSSoro mio... lo odieremo per SSSempre"
Bill Gollum
----------

,

ok...d'accordo...pero' piu' che far passare i parametri fra le servlet,
io utilizzerei l'ID di sessione e un metodo che faccia da factory e da
gestore degli oggetti parametro.
La situazione sarebbe la seguente:
avremo una classe che contiene i parametri assemblati e condivisi dalle
varie servlet. Per ogni sessione viene creato un oggetto di tale classe.
Chi crea il suddetto oggetto? Avremo bisogno un metodo statico (e
sincronizzato per evitare i problemi di accesso concorrente :) ) che
associa ciascun session ID ad un oggetto parametro. Se l'ID e' nuovo
crea un nuovo oggetto, altrimenti semplicemente ne restituisce uno gia'
esistente.
In questo modo non dobbiamo aggiungere un nuovo parametro a tutte le
servlet e costruire gli url in modo che esso venga passato (fra l'altro
non e' altro che un parametro che mantiene una sessione comune a piu'
servlet), ma semplicemente utilizziamo la Session Tracking API.
Eventualmente i parametri potrebbero essere memorizzati nella sessione
stessa (e quindi sul client anziche' sul server).
Ciao
  Lucio


 piů un ID unico che passi come parametro tra le servlet, e poi continui


[...]
La tecnica piu' efficace e' quella di "salvare" gli oggetti in una sessione - 
che per definizione e' accessibile tra varie servlet. In genere gli oggetti 
sono "salvati" e recuperati tramite un nome - che dev'essere univoco per ogni 
sessione.
Tempo fa sviluppammo un SessionManager, accessibile via RMI (dato che usavamo 
una soluzione mista servlet/applet), che mette a disposizione un repository 
logico che viene preservato tra sessioni diverse.
Putroppo non ho ancora avuto tempo di mettere il software in linea - peraltro 
oggi vari servlet engines danno questa possibilita'. 
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun/

   Lucio
Non so se ho capito bene, ma io farei cosě:
- nella classe sceltaUtente metto tutti i metodi per settare e rivecere le
informazioni necessarie (ved msg presedenti)
- la prima servlet istanzia la classe e crea l'oggetto
- la stessa classe riceve la sessione corrente HTTSession e con
putvalue(keynome, oggetto) metto l'oggetto nella sessione (in tal modo si
risolvono i problemi di accesso concorrente in quanto la sessione č una per
ogni accesso )
- le altre servlet , sempre tramite HTTSession, ricevono la sessione
corrente e ricavano l'oggetto con getValue(keynome), se l'oggetto non esiste
lo creano
- impostano i valori di loro competenza e risalvano l'oggetto nella sessione
con putvalue
registrando l'oggetto scelteUtente nella sessione credo che non ci si debba
porre il problema dell'ID dell'oggetto stesso dato che qualunque sia la
servlet che chiama la sessione gli viene sempre restituita quella corrente
dove cioč l'utente (quello che ha creato l'oggetto e non un altro ) ha messo
l'oggetto scelteUtente

,

Io eviterei di mettere tutti i parametri in un oggetto registrandolo in
una sessione, a meno che i parametri non siano veramente pochi e di
piccole dimensioni. I motivi sono sostanzialmente due:
1. le varie servlet non utilizzano tutti i parametri, anzi mi pare di
aver capito che l'unica che li utilizza piu' o meno tutti e' l'ultima,
mentre le altre impostano solo i valori di un loro sottoinsieme. Averli
tutti memorizzati in un unico oggetto costringe a trasferirli sempre
tutti atraverso la rete (le sessioni sono memorizzate sul server).
2. le sessioni sono di solito implementate tramite i cookies (devono
esserlo almeno in questo modo) e i browser possono impostare dei limiti
sul numero e la dimensione dei cookies, quindi c'e' il rischio (tutto
sommato abbastanza remoto comunque dato che il limite minimo e' di 4Kb)
di sforare tali limiti.
Io quindi memorizzerei i parametri usando chiavi diverse della
sessione, magari raggruppandoli a seconda dell'utilizzo che ne fanno le
varie servlets.
Se poi la dimensione o il numero dei parametri sono elevati eviterei di
memorizzarli nella sessione ma li terrei sul server, usando solo l'ID
di sessione per scegliere l'oggetto giusto da usare. In questo caso
probabilmente conviene costruire una classe che contiene tutti i
parametri. Gli oggetti di tale classe saranno inseriti in qualcosa di
simile ad una hashtable, la cui chiave sara' l'id di sessione, e
recuperati al bisogno (molto velocemente data che saranno in memoria e
non dovranno essere trasferiti dal client).
Un saluto


 file per i motivi già esposti da Stefano)
servlet A istanzia un oggetto Scelte e ci infila un ID; ad es. 45. Poi genera la
pagina successiva:
... <form action=/servletB><input type=hidden name=id
value=45><...>...</...></form> ...
Allorché la pagina è costruita dinamicamente, fai scrivere l'ID della sessione
associata alla servlet x e lo fai ripescare alla servlet y. In questo modo
ciascuna servlet non ha bisogno di comunicare con le altre in quanto sa quale
istanza di Scelte ripescare, visto che gli viene passata come parametro. Tra
parentesi, per l'ID io finora ho usato System.currentTimeMillis().


 servlet), ma semplicemente utilizziamo la Session Tracking API.
Non mi sono mai fidato della Session Tracking. Anche perchč implementandola
con i cookie non mi soddisfa per nulla, visto che mi basterebbe disabilitare
i cookie per non far funzionare piů nulla. E siccome non voglio costringere
i miei utenti ad abiulitare i cookie, preferisco rinunciare alla Session
Tracking. :) Poi queste sono opinioni e teorie del tutto personali.



ma perchè utilizzare  HTTSession con anche i  cookies? Nel mio caso non mi
interessa riconoscere l'utente in quanto lui non viene registrato in un DB.
Tutte le volte che lui accede in sostanza inserisce semplicemente il suo
nome , tanto per rispodergli con un htm a lui intestato.
Diverso è il caso in cui bisogna essere sicuri che chi si collega
(intendendo il computer ) è proprio quello registrato nel DB.
Ho un altro dubbio ora. dalle pubblicazioni che ho letto le servlet sono
descritte come una panacea e comunque molto più produttive delle CGI. Ma
allora perchè la Sun nel suo sito usa le CGI e non le servlet? e perchè
molti siti commerciali usano le asp e non le servlet? forse perchè queste
ultime sono più complesse da sviluppare o c'e' dell'altro
Walter

 ultime sono più complesse da sviluppare o c'e' dell'altro
Si, se verso la mezzanotte stai programmando ti trasformi in un lupo mannaro.
La tecnologia asp è di Microsoft, è probabile che molti siti basati su NT
abbiano montato IIS che supporta le ASP, e siccome di programmatori improvvisati
ce ne sono parecchi, magari preferiscono usare qualcosa di già pronto; che
funzioni e sia sicuro o meno è un altro discorso. (Si vede quanto io AMI la M$,
eh? :) L'equivalente delle ASP sono le JSP - Java Server Pages.
Che la Sun usi le CGI mi torna nuovo, non mi ero mai posto la domanda.



...io continuero' a fidarmi della Session Tracking API :)
Fra l'altro da' maggiori garanzie che l'utente non provi a fare
ca..ate, ad esempio cambiando lui a mano l'id di sessione...con le
conseguenze che lascio immaginare...o con maggior complessita' del
codice per evitare tali conseguenze...
...fra l'altro mi piacerebbe proprio incontrarlo un utente che
disattiva i cookies...vuol dire che naviga molto poco...ormai
praticamente tutti i siti li richiedono...e, per dirla tutta, non c'e'
praticamente nessun pericolo nell'utilizzarli...personalmente trovo
molto piu' pericoloso permettere ad un ActiveX di installarsi...
(per favore non facciamo diventare questo thread una discussione sui
cookies...per quel che mi riguarda e' finita qui!!)
Tornando al problema di comunicazione fra servlet...
Io lo farei nella seguente maniera:
A. Classe per i parametri:
public class MyServletParams {
  // qui i vari parametri pubblici o privati con metodi di accesso..ecc
}
B. Classe che recupera i parametri della sessione
public class ParamsProvider {
  private static Hashtable myParams = new Hashtable();
  public synchronized static MyServletParams getParams
(HttpServletRequest req) {
    HttpSession session = req.getSession(true);
    String sessionId = session.getId();
    MyServletParams result = (MyServletParams)myParams.get(sessionId);
    if (result == null) {
       // non esiste ancora un oggetto parametro per
       // questa sessione, quindi ne viene creato uno nuovo.
       result = new MyServletParams();
       myParams.put(sessionId, result);
    }
    return result;
  }
}
Una servlet, per ottenere l'oggetto con i parametri, non deve far altro
che effettuare questa chiamata:
MyServletParams params = ParamsProvider.getParams(req);
dove req e' l'oggetto HttpServletRequest ricevuto dal metodo doGet (o
doPost) della servlet.
Fra l'altro la classe ParamsProvider potrebbe essere la servlet stessa,
estendendo quindi la classe HttpServlet: tutte le servlet derivate
ulteriormente da essa condividerebbero lo stesso insieme di parametri.



Interessante!.
questa discussione č stata molto piů utile che leggere il capitolo 15 di
Developing JAVA SERVLETS , che tutto puň essere four che semplice.
Saluti e grazie a tutti. A buon rendere.
Walter

 disattiva i cookies...vuol dire che naviga molto poco...
A me sembra di ricordare che le session tracking API funzionano comunque
anche con i Cookie disattivati, in quanto in questo caso cercano di
utilizzare la tecnica dell'URL rewriting (se il server lo permette). Mi
sembra di averlo anche testato (una volta sola, devo dire) e mi sembra
che abbia anche funzionato alla grande (con Apache). Secondo me, viva le
Session API, eleganti e ad un livello più alto di astrazione che
permette di "staccarsi" un po' dai vari dettagli implementativi. 
-- 
Ugo
__________________________________________________________________________
"La perfezione si ottiene non quando non c'è nient'altro da aggiungere, 
 bensì quando non c'è più niente da togliere." Antoine de Saint-Exupéry
__________________________________________________________________________
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Enterprise Java Consulting
@mail: Ugo.L...@Flashnet.it
Home Page: 
http://www.ugolandini.net
Mentoring: 
http://www.projectoo.com
Work Phone: 06/5814740
Fax Phone: 06/233207542 
Cell Phone: 0347/6310749 - 0347/4783580
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ma perche' non ne fai una sola servlet che prenda questi parametri?
spiegami l'esigenza di farne piu' di una forse per questo non mi e' chiaro..
