JAVA WEB - Passare oggetti a FreeMarker

[cataDesign]

Serve a far sì che la classe sia accessibile da qualunque altra classe in qualunque altro package. E questo serve a FreeMarker, che accede al tuo bean tramite reflection.

Già che ci sono ti segnalo anche una cosa: hai usato FreeMarker come "template" per pagine HTML. FreeMarker è generico, di per sé non "sa" nulla di HTML o altro linguaggio di markup. Se il tuo title (o qualunque altra property che esponi) contiene dei caratteri speciali per HTML es. '<' o '>', il tuo HTML complessivo risulta sballato.
Per l'escaping serve dell'altro, vedere sul manuale: http://freemarker.org/docs/dgui_temp...insertion.html

http://it.wikipedia.org/wiki/Spring_framework
http://en.wikipedia.org/wiki/Spring_Framework

Grazie mille ancora una volta ) molto utile l'escape ), per il framework spring mi sa che come dice Alex'87 devo studiare un po di più java e i java bean

Ehm... Prima di metterti ad usare un framework come Spring (che fa TANTE cose, ha un sacco di moduli...) forse ti conviene studiarti bene Java (in particolare vita morte e miracoli dei java bean)

Si, faccio tesoro di questo consiglio!
Per caso avete qualche fonte dove leggere più in dettaglio cosa sono i java bean?
Praticamente spring non usa i java bean classici ma bensi un altro tipo di oggetto proprietario con un funzionamento simile ma migliore, dico bene?

[andbin]

Praticamente spring non usa i java bean classici ma bensi un altro tipo di oggetto proprietario con un funzionamento simile ma migliore, dico bene?

No, Spring tecnicamente è in grado di gestire qualunque tipo di oggetto, sebbene è ovvio che ha senso ed è tipico gestire oggetti che sono dei POJO (Plain Old Java Object) che a livello pratico vuol dire la stessa cosa dei Java Bean.
A livello basilare un Java Bean=POJO è semplicemente e banalmente una classe che definisce oggetti che hanno "proprietà", accessibili usando una serie di convenzioni sui nomi dei metodi. Tutto qui. Poi le specifiche Java Bean effettivamente sono più complesse e contemplano ad esempio anche la gestione degli eventi. All'inizio infatti sono state pensate nell'ottica di definire "componenti" (specialmente quelli grafici GUI) che fossero riutilizzabili, "introspezionabili" e configurabili.
Al giorno d'oggi quest'ultimo uso, cioè per componenti "grafici", non è più molto comune.

Forse ti è utile anche: http://www.shaunabram.com/beans-vs-pojos/

[cataDesign]

Poi le specifiche Java Bean effettivamente sono più complesse e contemplano ad esempio anche la gestione degli eventi.

Con questa frase intenti queste specifiche?

1. Have a public default (no argument) constructor
2. allows access to properties using accessor (getter and setter) methods
3. Implement java.io.Serializable

onestamente ho letto l'articolo da te suggeritomi, che semplicemente dice che i POJOs sono dei Java Bean ma allo stesso tempo sono Spring Bean... cioe, come hai detto tu, sono delle normalissime classi che istanziano degli oggetti; ad esempio una classe Book istanzia un Bean "libroJava" che rappresenta un libro.

La cosi tanto semplice affermazione (se corretta) mi porta a pensare che un POJO è un oggetto che non seguele le specifiche dei Bean (sopra scritte), mentre uno Spring Bean è un oggetto che rispettale specifiche dei Bean ma è gestito dal Framework e non dalla classe a cui ne affida i servizzi...

Spero di non aver confusione nel mio cervello

[andbin]

Con questa frase intenti queste specifiche?

1. Have a public default (no argument) constructor
2. allows access to properties using accessor (getter and setter) methods
3. Implement java.io.Serializable

No, quelle che hai appena detto sono solo le caratteristiche più basilari/fondamentali dei Java Bean. Le specifiche Java Bean sono più complesse, le trovi a partire da qui:
http://www.oracle.com/technetwork/ja...ec-136004.html

Nella pagina di download, scarica il PDF di 114 pagine e te ne renderai conto ....

La cosi tanto semplice affermazione (se corretta) mi porta a pensare che un POJO è un oggetto che non seguele le specifiche dei Bean (sopra scritte), mentre uno Spring Bean è un oggetto che rispettale specifiche dei Bean ma è gestito dal Framework e non dalla classe a cui ne affida i servizzi...

Dalla pagina: http://en.wikipedia.org/wiki/Plain_Old_Java_Object

"The term "POJO" is mainly used to denote a Java object which does not follow any of the major Java object models, conventions, or frameworks."

Questa in effetti è la spiegazione corretta del termine POJO, ovvero oggetti Java che non seguono un modello particolare, nemmeno convenzioni o framework particolari.

I Java Beans invece seguono delle convenzioni, già anche solo per i nomi dei metodi "accessori". Ma anche qui non è sempre tutto nero o bianco. Non sei obbligato a seguire tutte le specifiche Java Bean. La tua classe banquet non l'hai marcata Serializabile. Non serve, ti funziona lo stesso. Ma a livello basilare segue almeno le convenzioni Java Bean per definire le "proprietà", perché questo è quello che richiede FreeMarker.

Nel libro Spring in Action, Third Edition c'è un paragrafo che forse ti può illuminare:

"Although Spring uses the words bean and JavaBean liberally when referring to application components, this doesn’t mean that a Spring component must follow the JavaBeans specification to the letter. A Spring component can be any type of POJO. In this book, I assume the loose definition of JavaBean, which is synonymous with POJO."

Alla fin fine puoi chiamarli solo "bean" o "Java Bean" o POJO ... anche per me almeno al livello più basilare sono abbastanza equivalenti.

In un file di configurazione dei bean di Spring puoi mettere:

<bean id="myBook" class="xyz.Book">
    <property name="title" value="Spring in Action"/>
</bean>

Questo è un comunissimo bean, Spring a runtime istanzierà Book e lo inserirà nel suo container dei bean. Ma vedi bene quel <property>, qui segue e deve seguire le convenzioni Java Bean, almeno a livello basilare, ovvero un metodo setTitle con un parametro compatibile con il value. Tutto qui.

Quell'oggetto identificato da myBook lo puoi "iniettare" in un altro oggetto gestito da Spring. Ma alla fin fine cosa ci fa la applicazione con questi oggetti sono affari della applicazione ... non di Spring. Una volta che la applicazione riesce ad ottenere la istanza di quel Book, ci fa quello che vuole, anche invocare metodi particolari definiti in Book, es. dumo() o altro che non centrano nulla con i "Java Bean".