6.1 Cosa sono i JavaBean
Già alla fine degli anni '90, il linguaggio Java iniziò ad essere utilizzato attivamente per applicazioni server di grandi dimensioni, dove il numero di classi è misurato in decine e centinaia di migliaia. È stato allora che è nata l'idea di standardizzare l'aspetto degli oggetti Java.
L'intero linguaggio Java non è stato toccato, per non privarlo di flessibilità. Bene, retrocompatibilità e tutto il resto. Quindi hanno sviluppato una serie di criteri per oggetti Java di nuova generazione e hanno chiamato tali oggetti Java Beans. Java prende il nome da una famosa marca di caffè, quindi Java Beans si traduce letteralmente in "chicchi di caffè".
I criteri più importanti erano:
- L'accesso ai campi interni della classe avviene tramite il
getProperty()
. - La scrittura dei dati nei campi di classe passa attraverso il formato
setProperty(value)
. - La classe deve avere un costruttore pubblico senza parametri .
- La classe deve essere serializzabile.
- La classe deve avere i metodi
equals()
,hashCode()
e sovrascrittitoString()
.
Questo approccio ha reso le applicazioni meno coerenti. Sempre chiaro:
- come creare un oggetto - esiste un costruttore predefinito pubblico;
- come ottenere/impostare il valore della proprietà;
- come trasferire/salvare un oggetto (usiamo la serializzazione);
- come confrontare oggetti (usando equals() e hashCode());
- come visualizzare le informazioni sull'oggetto nel registro (utilizzare toString).
Ora è in realtà lo standard del settore, ma una volta era una nuova tendenza. Sembra che tutti scrivano già così, anche se se ricordi HttpClient e i suoi Builder, puoi vedere che il nuovo standard è difficile per qualcuno.
Tali oggetti sono ampiamente utilizzati dove il loro principale carico semantico è l'archiviazione dei dati. Ad esempio, nelle GUI, nei database e nelle pagine JSP.
6.2 JSP e JavaBean
Uno dei motivi per JSP era che poteva essere esternalizzato a sviluppatori front-end. E cosa? Hai una persona che capisce l'HTML, lascia che scriva JSP. I programmatori Java scrivono la loro parte, gli sviluppatori front-end scrivono la loro: va tutto bene.
E tutto è andato bene finché gli sviluppatori front-end non hanno dovuto comprendere il codice Java scritto incorporato nel JSP. O, peggio ancora, scrivi tu stesso tale codice.
Anche i programmatori Java non erano contenti di questo. Bene, per favore dimmi, quali progettisti di layout sono sviluppatori di back-end? Sì, non possono scrivere altro che script. Sì, e l'intero paradigma di programmazione afferma che mescolare lingue diverse in un file è una cattiva forma.
Poi è nata l'idea che dicono di dare agli sviluppatori front-end l'opportunità di lavorare con oggetti Java, come con il codice HTML. Ogni tag HTML è anche un oggetto con i propri campi, perché non lavorare con gli oggetti Java in modo simile?
Detto fatto. Aggiunti tag speciali e via.
Creazione oggetto:
<jsp:useBean id="Name" class="Object type" scope="session"/>
Questo comando ha creato un oggetto con il tipo object
e lo ha inserito session
con il nome Name
.
Gli oggetti possono essere archiviati in uno dei quattro archivi: applicazione (globale), sessione, richiesta e pagina. Era anche possibile impostare una proprietà di tali oggetti:
<jsp:setProperty name="Name" property="propName" value="string constant"/>
Potresti ottenere la proprietà di tali oggetti come questo:
<jsp:getProperty name="Name" property="propName"/>
Un esempio di utilizzo dei tag:
<body>
<center>
<h2>Using JavaBeans in JSP</h2>
<jsp:useBean id = "test" class = "com.example.TestBean" />
<jsp:setProperty name = "test" property = "message" value = "Hello JSP..." />
<p> What-to do important</p>
<jsp:getProperty name = "test" property = "message" />
</center>
</body>
GO TO FULL VERSION