[Java] Filosofia dietro la programmazione di form con JSF 2.0

[supertarmax]

Salve a tutti, mi sono avvicinato da poco alla programmazione Java usando JSF 2.0.
Questa discussione non sarà molto tecnica, vorrei semplicemente avere delle conferme relative alla filosofia che sto utilizzando per la programmazione di interfacce per l'inserimento dati.
Allora, ecco come mi muovo:
1)Creo un DB che verrà utilizzato per l'inserimento ed il recupero dei dati.

2)Costruisco delle semplici classi java che fungono da modello per i risultati delle query che effettuerò nel programma.
Tra queste classi ci sono sempre quelle che modellano i record generici delle tabelle del database con i classici metodi get/set, ad esempio se nel DB ho una tabella con due campi varchar creo una classe java con due attributi String e i 4 metodi get/set in modo tale da poter effettuare query che ritornano dati che possono essere modellati come liste di istanze di queste classi.

3)Costruisco i managed bean che prendono i dati da input e sulla base di questi effettuano le query al DB, il costruttore del generico managed bean ha solo il codice per la connessione al db.
Quindi un generico bean avrà gli attributi che si riferiscono ai dati presi in input, una serie di metodi per effettuare le query e un costruttore con la sola connessione al db.
Qui avrei delle domande più specifiche: non invoco mai il managed bean (con la new) uso semplicemente i metodi che effettuano le query (invocandoli dalle pagine xhtml), ovviamente però se cancello il costruttore il bean non viene caricato, mi domando quindi:
-Chi è che lo istanzia?
-Ci sono altre invocazioni che vengono effettuate "senza consenso"? Ovvero c'è qualcosa che regola il ciclo di vita dei beans?
-E' giusto inserire il codice per la connessione al DB nel costruttore di ogni managed bean?
-i bean sono request scope, ma apparentemente cambiando lo scope non cambia niente nell'applicazione, che scope mi suggerite?

4)Uso pagine xhtml per creare i form che mi serviranno per prendere e inviare i dati verso i managed beans, l'invio ed il prelievo dei dati viene effettuato riferendosi agli attributi (per l'invio) e ai metodi (per la richiesta) dei managed beans.


Spero di essere stato chiaro, in caso contrario fatemi sapere.
grazie a tutti per le dritte.

[valia]

programmazione Java usando JSF....in pratica crei un sito web sfruttando il framework JSF. All'interno delle pagine jsp (quelle che in realtà crei) avrai delle parti che rispettano lo standard java...tecnicamente lavori in jsp e non java.

1. Le applicazioni web molto spesso si appoggiano a dei database esterni (MySQL, Postgres ecc), per poter interagire con il database ovviamente devi crearlo!!!
Ma il tuo database può essere un foglio di testo, il file system...in generale devi solo creare il repository dei dati.

2. costruisci dei bean. In realtà è molto più complesso di come lo hai descritto. Il bean non è strettamente legato al database (io ne ho per classi che non mappo su database). Una qualsiasi classe con all'interno dei parametri e i soli metodi getter/setter è definita come bean. deve avere ovviamente il costruttore vuoto in aggiunta a costruttori da te desiderati.
Il concetto di bean si lega bene al concetto di tabella perché semplicemente mappi i campi di una tabella in una classe java con i relativi getter/setter.
A voler essere precisi, dovresti costruire i DTO e DAO per ogni tua tabella, in modo da poter interagire in modo semplice con il database.

3. non so cosa intendi per managed bean, ma se torni sopra ti rispondi.

4. nel caso di bean legati alla vista jsp, il ciclo di vita dei bean è regolato dal framework e da come vai a specificare il bean (es. bean di sessione, bean di richiesta ecc).
Non è corretto inserire codice di accesso al bean nel costruttore, il costruttore deve limitarsi a darti un'istanza vuota o un'istanza partendo dai tuoi parametri (non certo la connessione al db).
Se hai bisogno di valorizzarli, devi farlo con una funzione esterna al bean. Non è nella logica del bean reperire da solo i dati dal db

5. rivedi html post/get con le relative request passate alla servlet

In definitiva dovresti avere una buona manualità in java per poter poi sfruttarla all'interno delle pagine jsp.
Devi avere una discreta conoscenza del framework JSF per capire come funziona e come ti torna utile.

[supertarmax]

Ti ringrazio molto per la risposta.
Ad ogni modo sto utilizzando JSF 2.0, dove al posto delle JSP si usano pagine xhtml.
Conosco le servlet, ma credo che quel tipo di programmazione non sia necessaria con la seconda versione delle JSF, almeno per la programmazione di interfacce (form).

[valia]

MVC: è questo il pattern che usa JSF.
I form sono solo la vista, model e controller dove li metti? Mica fai tutto nei bean (che è sbagliato)

[supertarmax]

hai ragione...
ma apparentemente (e quindi magari sbaglio), con la versione 2.0 si usano principalmente pagine xhtml e backing bean (che nel post ho chiamato managed beans).

[valia]

xhtml

linguaggio di marcatura, ho preso solo wikipedia perché mi scocciava andare oltre. quindi hai un meta linguaggio di formattazione che rispetta le regole dell'XML

backing bean 1 e backing bean 2

di che stiamo a parlare?

Il pattern MVC resta sempre applicato, infatti se tu devi elaborare dati oltre la validazione, hai sicuramente un agente esterno che non è il bean che fa il tuo lavoro.

[supertarmax]

ti ringrazio

[Caiodark]

Originariamente inviato da supertarmax
Salve a tutti, mi sono avvicinato da poco alla programmazione Java usando JSF 2.0.
Questa discussione non sarà molto tecnica, vorrei semplicemente avere delle conferme relative alla filosofia che sto utilizzando per la programmazione di interfacce per l'inserimento dati.
Allora, ecco come mi muovo:
1)Creo un DB che verrà utilizzato per l'inserimento ed il recupero dei dati.

2)Costruisco delle semplici classi java che fungono da modello per i risultati delle query che effettuerò nel programma.
Tra queste classi ci sono sempre quelle che modellano i record generici delle tabelle del database con i classici metodi get/set, ad esempio se nel DB ho una tabella con due campi varchar creo una classe java con due attributi String e i 4 metodi get/set in modo tale da poter effettuare query che ritornano dati che possono essere modellati come liste di istanze di queste classi.

Devi anche creare i DAO (data access object) che sono le classi deputate a fare le query al database. Anche se concettualmente qualsiasi bean a cui inietti il PersistenceContext può fare query non è bene se disperdi le interrogazioni al database in mille classi diverse.

3)Costruisco i managed bean che prendono i dati da input e sulla base di questi effettuano le query al DB, il costruttore del generico managed bean ha solo il codice per la connessione al db.
Quindi un generico bean avrà gli attributi che si riferiscono ai dati presi in input, una serie di metodi per effettuare le query e un costruttore con la sola connessione al db.

No, i ManagedBeans dovrebbero solo occuparsi di gestire la navigazione delle viste, la gestione degli eventi dei componenti JSF, la validazione dei form, eventi di cambiamento di dati.
La logica dell'applicazione andrebbe affidata agli EJB, mentre le query ai DAO.
Tecnicamente tutto è possibile, ma se non rispetti i ruoli per cui il framework JAVA EE è stato pensato ti troverai successivamente in difficoltà.

Qui avrei delle domande più specifiche: non invoco mai il managed bean (con la new) uso semplicemente i metodi che effettuano le query (invocandoli dalle pagine xhtml), ovviamente però se cancello il costruttore il bean non viene caricato, mi domando quindi:
-Chi è che lo istanzia?
-Ci sono altre invocazioni che vengono effettuate "senza consenso"? Ovvero c'è qualcosa che regola il ciclo di vita dei beans?

A controllare il ciclo di vita dei beans ci pensano l'application server e il garbage collector, a noi interessa di più lo scope di visibilità ossia quando un bean può svolgere il suo lavoro utile.
Il framework ci offre diversi scope:
-Application, il bean è sempre visibile e disponibile con l'avvio dell'applicazione sul server.
-Session, il bean è visibile da quando si crea la sessione utente fino a quando la si invalida.
-Conversation, il bean è visibile all'interno di una conversazione, è un concetto simile alla sessione grazie alla quale più viste possono collaborare tra di loro (per esempio per creare un wizard).
-View, il bean è visibile dalla creazione della vista fino alla transizione ad un'altra vista.
-Request, il bean è visibile dalla transizione di una vista fino alla renderizzazione di quella successiva.

Per decidere lo scope desiderato basta annotare opportunamente il Managed Bean.

Una volta creati i Bean rimangono in vita finché non vengono distrutti dal garbage collector. Se necessiti di una inizializzazione specifica, quando questi entrano nel loro scope, devi creare un metodo senza parametri e annotarlo opportunamente. Puoi anche creare dei metodi, sempre da annotare, per rilasciare le risorse quando il bean esce dal suo scope.

-E' giusto inserire il codice per la connessione al DB nel costruttore di ogni managed bean?

No, prima di tutto perché se usi API come le JTA queste non sono disponibili al momento in cui un bean viene istanziato.
I managed bean non sono pensati per connettersi al db. Ogni utente collegato potrebbe avere diversi bean istanziati per lui. Cosa succederebbe se ognuno di questi bean si collegasse autonomamente al db?
La connessione al db è solitamente gestito direttamente dall'application server, per accederci questo mette a disposizione delle API come JTA. L'applicazione utilizza le API grazie ad un contesto di persistenza, un insieme di classi che forniscono l'interfaccia verso il DB.

-i bean sono request scope, ma apparentemente cambiando lo scope non cambia niente nell'applicazione, che scope mi suggerite?

I bean hanno 4 scope diversi ognuno progettato per un uso specifico. Lasciando perdere gli application e conversation scoped bean che sono particolari abbiamo:

I session scoped bean sono bean che servono a gestire i dati degli utenti che devono essere disponibili per tutta la durata della loro sessione di lavoro.

I request scoped bean sono bean che gestiscono i metodi di navigazione da una vista all'altra e la validazione dei dati.

I view scoped bean sono bean che gestiscono gli eventi dei componenti JSF.

Non c'é quindi uno scope consigliato, dipende da cosa deve fare quel bean. Questo è quanto faccio di solito:

- Nei session bean gestisco dati che mi servono per tutta la sessione di lavoro e che cambiano di rado. Sono ideali se questi dati sono piuttosto pesanti da recuperare, perché puoi impostarli per fare la query una volta sola al login. Il lato negativo è che questi dati saranno contenuti nella session del browser dell'utente, non abusarne o finirai la ram del client.

- I View scoped bean sono necessari se associ eventi Ajax o listener ai componenti JSF in quanto i Request scoped bean non sono visibili dopo che una vista è stata renderizzata.

- Per tutto il resto uso Request Scoped bean.

4)Uso pagine xhtml per creare i form che mi serviranno per prendere e inviare i dati verso i managed beans, l'invio ed il prelievo dei dati viene effettuato riferendosi agli attributi (per l'invio) e ai metodi (per la richiesta) dei managed beans.


Spero di essere stato chiaro, in caso contrario fatemi sapere.
grazie a tutti per le dritte.

In realtà l'architettura è più complessa, ma se la rispetti le classi saranno più gestibili:
- Al database ci accede l'application server che ti mette a disposizione delle API;
- Su queste API tu crei le classi entità e DAO per la gestione delle query;
- Crei gli EJB per gestire la parte intelligente dell'app (E qui scegli se Stateless o Stateful).
- Managed Beans per gestione navigazione, eventi, validazione e eventi su dati
- JSF per templating e viste
- Ti "stufi" e passi a RoR