Newsgroup: it.comp.java
Titolo: Considerazione best pattern jsf

Salve a tutti,
volevo condividere con voi una riflessione che (spero) molti di voi
avranno già fatto per avere un consiglio:
ho sempre lavorato con Struts, ora sono passato a Jsf.
La filosofia con cui lavoravo prima era quella in base alla quale,
tanto per fare un esempio, se dovevo - per esemplificare - mostrare
tre combo su una jsp, frutto di tre interrogazioni su tre tabelle,
creavo un oggetto Command,  lo passavo ad un ejb che chiamava
attraverso il business il model; mi venivano fatte le 3 query, le
mettevo nel command che ritornava a web.
Con jsf, invece, se io "volessi" potrei semplicemente legare ai tre
tag relativi i tre metodi per la chiamata a ejb per l'interrogazione
della specifica risorsa e basta.
Da cui due domande:
1) Ma a fare così non ci sono problemi di performance? Ossia, così non
avrei 3 chiamate a ejb? Cosa mi vieta, dal punto di vista del best
practice jsf di fare come prima?
2) Qualora, faccio un esempio, la composizione di una combo dipenda
dai valori delle altre due, per particolari ragioni di business,
questo non comporterebbe dover portare logica di business lato web
visto che solo lì mi trovo le tre liste insieme?
Grazie

practice jsf di fare come prima?
Guarda, puoi scordatelo di mettere la logica dentro il get: mi sembra che 
vuoi invicare la logica contenuta nei tuoi session bean attraverso un metodo 
get del managed bean.
Quel metodo puo' essere invocato piu' di una volta durante un ciclo di 
richiesta JSF.
La logica, percio', non dovrebbe essere invocata in questa maniera, ma in un 
punto comune, prima del caricamente della pagina.
Quindi non cambia niente rispetto a Struts. Solo riesci ad agganciare il 
data model all'interfaccia web con molta piu' facilita'.
In generale prima di arrivare alla pagina che contiene le 3 combo avrai una 
action che ti ci porta. Ecco quella puo' essere un punto dove inizializzare 
la pagina.
In alternativa puoi invocare questa logica di inizializzazione subito prima 
del rendering della stassa (tramite phase listener, o usando vari framework 
che consentono cio'..Shale o Seam ad esempio).


Ecco...questa me la puoi spiegare meglio?

Ecco...questa me la puoi spiegare meglio?
Con Struts hai diversi inutili passaggi:
-validazione automaica ma definita in un xml a parte
-conversione manuale dei dati ottenuti da request
-popolamento manuale dell'action bean
-operazioni varie
-push dell'oggetto nello scope opportuno.
Con JSF invece e' quasi tutto autmatico:
-validazione definita nella pagina
-conversione automatica o definita nella pagina attraverso converter
-impostazione automatica della proprieta' nel manged-bean
-invocazione action
-push non necessario perche' la action agisce sulle proprie properties 
(solitamente ma non sembre ok.)
Comunque sia e' un bel po' di lavoro in meno per il programmatore, un bel 
po' di xml in meno da configurare e leggibilita' del codice migliore.

 componenti statefull.
Credo che qua sia tutta la questione :-)
Suggerisco al mittente di approfondire il lifecycle di JSF per capire come
lavorano e quindi per poterle usare correttamente e semplicemente
ciao Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/


Questo è vero...grosso vantaggio

Questo è vero...grosso vantaggio
Questo era l'unico punto che considervo equivalente veramente ;)
Perche'...con Struts non invochi la action?! A me pare di si!
Comunque sia anche qua un managed-bean puo' contenere un sacco di action, 
mentre Struts incoraggiava un paradigma piu' macchinoso:
una action per ogni classe. E ogni volta ti toccava scrivere la nuova 
classe, scrivere il metodo, configurare la classe. Non proprio il massimo 
secondo me. 


E no! Struts rispettava il form html che ha l'attributo action. Ciò
vuol dire che a fronte dello stesso form html, a meno di usare il
"trucco" della chiamata via href direttamente della action passando i
parametri con la query string, tu avevi un solo modo per invocare la
action e cioè facendo submit.
Ma il metodo della action che invochi è sempre uno solo (execute). Ciò
significa che, come spesso accade, se alla stessa action per lo stesso
form tu volevi far fare operazioni diverse a seconda dell'operazione
desiderata (ad esempio, inserimento o aggiornamento?), ti dovevi
impostare un campo hidden che faceva da "segnalatore" ad execute di
cosa dovesse fare.
Con jsf tutto questo non c'è più. Tu nel managed bean puoi mettere
quanti metodi ti pare ed invocarli dalla jsp. Viene sempre fatto un
submit ma è jsf a farsi carico poi della chiamata del metodo corretto.

submit ma è jsf a farsi carico poi della chiamata del metodo corretto.
Concordo.


Tu parli di Utente e UtenteBean come se fossero separati mentre in
realtà (al di là del fatto che poi il primo è un attributo del
secondo) è tutto dentro il managed bean. Ecco perchè dico che secondo
me era più Struts a tenerli separati.

me era piů Struts a tenerli separati.
Utente e UtenteBean sono assolutamente separati. Il fatto che UtenteBean 
utilizzi Utente non significa che non c'e' separazione.
Altrimenti a che ti serve Utente se nessuno lo usa? ;)
In Struts Utente sta dentro la session o dove vuoi tu . Quindi dovrai fare:
            Utente utente = (Utente) session.getAttribute("utente")
Beh, questa sarebbe una migliore separazione? Non credo proprio.
La mancata separazione si avrebbe se UtenteBean contenesse le proprieta' di 
Utente (nome, comgnome ecc..). Allora si che ne uscirebbe qualcosa di 
veramente poco chiaro.
class UtenteBean {
  private String nome;
  private String cognome;
 public String register() {
    database.persist(this);
    return "success";
 }
...
}
Questa si che e' una schifezza.
Invece
class UtentiBean {
  private Utente utente;
  public String register() {
    database.persist(utente);
    return "success";
 }
 ...
}
qui c'e' separazione assoluta. Solo che UtenteBean dichiara esplicitamente 
di voler operare su un utente. 

 di voler operare su un utente.
...così come nello struts-config dichiari la action sul form
Bella discussione, lo dico sinceramente.