Newsgroup: it.comp.java
Titolo: utilizzo variabili di sessione in jsp

in un sito fatto in jsp utilizzo una variabile di sessione per
memorizzare dei dati relativi alla singola pagina in cui mi trovo(dati
che mi servono per creare un menu laterale).
in pratica in ogni pagina del sito c'è una riga tipo questa:
session.setAttribute("valoreMenu", variabile contenente il valore per
tale pagina);
avrei potuto passare dei parametri nell'url ma sarebbe stato molto
complicato data la struttura del sito.
rallenta molto il sito la soluzione che utilizzo(con le variabili di
sessione)???

 ha scritto nel messaggio
news:5a9281e8.04081...@posting.google.com...

Nn credo, cmq dipende dal appl server che utilizzi, immagina PER ASSURDO se
la sessione l'apll server la gestisca scrivendo su un file temporaneo sul fs
:D:D:D:D.
Cmq l'architettura che si utilizza solitamente per mem oggetti in sessione è
quella della hasmap che è piuttosto performante e adatta a questo tipo di
lavoro.
Sempre dipendentemente dal architettura su cui sti lavorando e di riflesso
dallo scope che vuoi dei tuoi parametri che metti in sessione potresti
passare dalla setAttrbute sulla request senza scomodare la sessione....
Pr quello che stai facendo ti suggerisco cmq tiles(o framwork simili...) che
utlilizzo proprio a questo scopo per il prog su cui sto lavorando e in
generale per renderizzare logicamente il layout della tua appplicazione..
Spero di esserti stato di aiuto..
-- 
Ciao e buon lavoro,
  Renato
---- 
Renato Eschini
   Inera srl
   Via Vespucci 41
   56100 Pisa
   Tel:         (+39) (0)50 2201218
   WWW:         
http://www.inera.it

 sessione)???
No, non mi preoccuperei molto della velocita'
le considerazioni da fare sono le seguenti:
-) Tasto back / aggiungi a preferiti
con la session perdi il tasto back e il bookmark
mentre con la URL vanno sempre
-) memoria
se hai molti accessi la session puo' diventare perocolosa per la
memoria.
Se e' una intranet o un portale a bassi accessi il problema non c'e'
e puoi usare ad esempio le hasmap come ha giustamente suggerito Reny.
altrimenti Occhio e fai molta attenzione a minimizzare i byte
in session, ad esempio utilizzando delle codifiche del menu con degli interi
o tecniche del genere
-) tiles
sempre ripigliando Reny che suggerisce Tiles.
concordo appieno soprattutto sei sei in ambito Enterprise e vuoi
buona Manutenibilita' e omogeneita'
Non ho mai provato tiles con tanti Accessi
  cya Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Non ho mai provato tiles con tanti Accessi
Neppure io lo provato con tanti accessi, pero' anche qui come per le
Session, do per scontato l'utilizzo di strutture dati performanti quali
hashmap e derivati per l'infrastruttura di gestione del rendering del
layout, se no tutto il nostro lavoro andrebbe a farsi friggere se con
qualche accesso in piu' le performance decadessero vistosamente :-D.
Se no, una bella web app in assembler iper-ottimizzato e sei una scheggia ;)
o ancora meglio si implementa il tutto direttamente in
hardware.:D:D:D:D:D:D:D:D


> Osservazioni che nn ho considerato ma che concordo in pieno!
Concordo pienamente e infatti utilizzando delle variabili di sessione 
per creare dei valori di menù....ad esempio nella homepage alla fine si 
ha come risultato che se hai troppi utenti ti vanno a saturare la 
memoria con un grosso calo delle prestazioni! Anche se come hanno già 
detto gli altri anch'io non mi sono mai trovato in una situazione 
simile! :-D
Invece scusata la domanda (non troppo OT) che differenze sostanziali si 
avrebbero con un HaspMap e con un Tiles?!
(Però mi viene il dubbio a seconda della scelta H o T alla fine le due 
realizzazioni o implementazioni sono comunque diverse?!)
 > session.setAttribute("valoreMenu", variabile contenente il valore per 
tale pagina);
Questo lo fai per ogni voce o per una sola!? Perchè altrimenti potresti 
codificarti il tutto in una switch tenuta in un file .jsp esterno che 
poi vai ad includere e tramite query string passi solo un valore di tipo 
numerico...o al max nella sessione. Ma questa soluzione è sporchissima e 
proprio da "sottobanco"!  Io preferirei una cosa più elegante e 
funzionale con una Hashmap o Tiles ma le soluzioni vanno sempre 
osservate tutte!

 (Però mi viene il dubbio a seconda della scelta H o T alla fine le due
Hashmap è un interfaccia di una struttura dati, tiles un frameork di
rendering per layout per jsp/html.
Hashmap è una struttura dati, o meglio , una interfaccia che rappresenta una
struttura dati: Hashtable è una implementazione di tale interfaccia. La mia
era semplicemente una supposizione di come fossero realizzati gli oggetti di
tipo Session che si ottengono in una servlet/jsp con request.getSession() :
immagino che l'implemntazione, quindi l'oggetto session sia "scritto" con al
interno un field privato di tipo Hashmap e che il metodo
.setAttribut(chiave, valore) utilizzi i metodi del suo field privato hashmap
per salvarsi al suo interno gli oggetti salvati, da qui le mie
considerazioni sulle performance.
Per tiles è il solito discorso: hai un file xml in cui è scritta la
struttura dei layout, un parser carica allo startup il file xml e lo
memorizza in qualche struttura interna (che ho ipotizzato essre qualcosa di
molto performante) , dopo di che quando tu chiami una  jsp che incontra il
tag di include del layout (o sfrutti i plug in di struts) il framework di
tiles si recupera tutte le info dalla struttura dati che rappresenta i
layout.Tutto qui :)
Nulla vieta che tu ti renderizzi le pagine a mano e ti costruisca un tuo
framework a mano.....
Spero di essere stato chiaro stavolta :D



Sinceramente la situazione dello switch e' proprio quella che suggerivo io
in caso di
accessi elevati.
Se hai 30000 accessi al giorno puoi farla +o- sporca, cioe'
puoi fare una codifica super violenta, come una singola stringa con tutte le
info
oppure un vettore di interi o , a tua scelta, qualsiasi cosa ti venga in
mente che sia un compromesso fra leggibilita' e compattamento
A quel punto se fosse ad esempio una stringga verrebbe la tentazione di
spararla in URL.
he he
La hash map:
Reny ha spiegatao bene:
metti nome variabile valore.
giustamente lui ha detto che la stessa session e' una hashmap
ora non so la dimensione della hashmap vuota, ma ricordo che la vecchia
hashtable vuota era 250k+
uno sporposito.
Tiles non e' una classe come la hasmap.
e' un plugin di struts
quindi un framework del frramework
ti da un supporto per standardizzare il rendering delle interfacce
utente
detto in 4 parole + semplici, crei dei "componenti" fatti per esempio da 1
jsp, una collection di oggetti, 1 chiamata javascript, un menu, quello che
vuoi insomma.
se poi li usi uno dentro l'altro ( credo che il nome "tiles" stia proprio ad
indicare
l'"accodamento) ti ritrovi in pratica tutto gia' fatto e pronto per l'uso
alla 2. volta che vuoi fare una pagina simile a una che hai gia' fatto.
Scusa ma non ho tempo per scrivere meglio.
una cosa pero' e' certa, non conviene usare tiles se non sei su un
progettone di lunga durata con un team ceh ci lavora su e magari molte
releas e installazioni,
altrimenti per fare il classico hello ward ci perdi una settimana e non hai
il
ritorno dovuto al riuso dei component e alla standardizzazione.


azz sei + veloce del west oggi
comunque si trova 2 risposte
(anche se simili)
       cya


azz sei + veloce del west oggi
comunque si trova 2 risposte
(anche se simili)
       cya
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 (anche se simili)
A che t rifersci di preciso?
p.s.
scusa il ritardo della rsiposta ma ero in pausa pranzo :D


clockdva wrote:

Non la vedo sotto questo puunto di vista. Il fatto è che IMHO la 
sessione non è il posto adatto per memorizzare le informazioni della 
singola pagina. Meglio sull'url, per quanto complesso la generazione dei 
link la fai da codice.

> Già. Fra due settimane divento papà per la prima volta :D:D:D:D:D:D:D:D:D:D
public void Auguri(){} :-D


che gli abbiamo risposto assieme e cosi' ha 2 risposte su tiles
comunque anchio ferie ne ho prese pochine
3 giorni ad agosto
e sto c****o di clear case mi sta scassando i m******i
da 2 giorni
cosi' mi distraggo pure io sul NG


...


   Nicola
Ciao ;)



he he gia'
tails ( code ) in effette mi suonava strano
"pezzi" rende perfettamente l'idea
cya


dunque il discorso su Tiles ecc. lo approfondiro' quando avro' un po'
di tempo e una conoscenza maggiore dell'argomento(č poco che uso le
jsp e tra l'altro uso un programma per generarle
-
http://www.codecharge.com/index2.php-
 che utilizza delle proprie
classi particolari).
Mi interessava pero' quanto detto da Reny qualche post fa:"...Sempre
dipendentemente dal architettura su cui sti lavorando e di riflesso
dallo scope che vuoi dei tuoi parametri che metti in sessione potresti
passare dalla setAttrbute sulla request senza scomodare la
sessione...."
mi son letto qualcosina sull'oggetto request e mi chiedo:
utilizzare
request.setAttribute("valoreMenu", variabile contenente il valore per
tale pagina);
e poi recuperare tale valore dalla mia pagina inclusa(pagina che
rappresenta il menu) con un getAttribute č + corretto rispetto a
quello che ho fatto fino ad ora, cioč fare la stessa cosa con
sessione.setAttribute e session.getAttribute?
se si perchč?
grazie


Dipnde dallo scope che vuoi dare alle variabili.
Se lo scope e' della Singola richiesta TI conviene assolutamente usare la
Request
altrimenti la Session


dunque, correggetemi se sbaglio: 
poichè io devo settare un valore per ogni pagina,
pagina A
request(oppure session).setAttribute("valoreMenu", valore per la
pagina A);
pagina B
request(oppure session).setAttribute("valoreMenu", valore per la
pagina B);
pagina C
request(oppure session).setAttribute("valoreMenu",  valore per la
pagina C);
e poi recuperare tale valore con un getAttribute dalla pagina del
menu(che è inclusa nelle pagine A,B,C ecc.)
mi conviene usare request perchè lo scope di ogni singolo settaggio di
valoreMenu è per la singola richiesta di quella pagina, giusto?
mi chiedo poi un'altra cosa:
il metodo setAttribute(dell'oggetto request) memorizza l'attributo
specificato nella richiesta corrente.
ma quando la pagina jsp (che contiene request.setAttribute(..))viene
eseguita la richiesta corrente non è gia terminata??
che signfica quindi, che setAttribute 'aggiunge' tale attributo alla
richiesta che è già stata inoltrata??
forse faccio unpo' di confusione ma faccio fatica a figurarmi tale
cosa; se qualcuno mi spiegasse.
gazie.

 gazie.
si hai fatto un po' di confusione riguardo agli oggetti impliciti da 
utilizzare. ;-)
Dunque request si riferisce alla richiesta ovvero ai dati che vanno da 
browser a server mentre l'oggetto che cerchi tu è il suo opposto ovvero 
response che si riferisce alla risposta ovvero ai dati che transitano da 
server a broweser.
Potresti giostrarti un po' con la query string e lavorare con l'oggetto 
request nelle singole pagine ma se il sito è articolato come hai detto 
tu diventa un po' difficile ma non impossibile. 
(request.getParameter(String parameterName) e ottieni il valore dei 
parametri passati nell'URL!)
Ciao,
jRed ;-)

orca non riesco a farmi capire ma comincio a capirci qualcosa io.
dunque lasciamo stare la questione del metodo setAttribute che ho
capito.
io intendo usare request e non session visto che cmq la variabile
andrà settata in ogni pagina e quindi ha come scope solo la
singolarichiesta. penso sia giusta come idea, visto  quanto detto da
n.n.
ringrazio tutti x l'aiuto e scusate la confusione che ho creato


Se proprio vuoi che te lo dica
quando hai ben chiara la difefrenza sai tutto del Web Programming
quindi non farti problemi e riflettici bene su
Qello che ti ha risposto prima ha risposto benissimo :
Request = vita dal browser fino al server
o, detto in un altro modo, dal click fino alla generazione(e
visualizzazione) della pagina.
Questo significa che dopo se riusi la request non trovi +
nulla, o peggio trovi roba di altre pagine, ma questa e' un'altra storia
Session =
a) vita fino a quando tu non chiudi il browser, anche se ti fai un giro a
vedere le conigliette di playboy, la session rimane attiva, valida, con
tutti i dati dentro, e' una banale hashmap sul server linkata con una chiave
che si riferisce solo e unicamente alla tua instanza di browser,
puo' essere un cooky o l'IP number, o un hashcode generato dal browser, a
dire il vero non lo so ma roba simile.
quindi va limitato il suo uso se sei in presenzza di carico, assolutamente
b) se non cliccky + per il tempo di durata della session, settabile su ogni
Server in modo impostato dal vendor, la session scade e viene eliminata dal
server, Per esempio 20 min il default di tomcat
   cya buona giornata
          Nicola


ok la diff. tra request e session ora mi è strachiara(mi era chiara
anche prima ma facevo fatica a inquadrare bene la durata di request).
ma quando dico:"io intendo usare request e non session visto che cmq
la variabile andrà settata in ogni pagina e quindi ha come scope solo
la
singola richiesta. penso sia giusta come idea, visto  quanto detto da
n.n.", dico bene o dico una c*******?
ciao, grazie

Abbiamo adottato un'altra soluzione x il mio menu.
Ho creato una tabella del db dove ho 1 campo A che contiene il nome
delle pagine del mio sito(quelle che includono la pagina col menu) e
un altro campo B che contiene il valore adatto(per quella pagina)da
passare al menu.
Nella pagina del menu(quella inclusa) faccio una select usando come
parametro(da confrontare con il campo A della mia tabella) della where
il nome della pagina in cui mi trovo(che mi ricavo con un
getRequest().getRequestURL()) e mi ricavo cosi il mio valore
(contenuto nel campo B) per il menu quando viene incluso anella pagina
che è visualizzata in quel momento.
Cosi faccio tutto direttamente da 1 sola pagina, appunto quella che
contiene il menu.

 contiene il menu.
Ottimo, spero che la discussione sia stata utile
Ricorda pero' che se mettono i menu di Yahoo nel db
prendono fuoco i database he he.
   buon lavoro e ci si becca al prssimo problema
 ciao Nicola


 > che è visualizzata in quel momento.
