Login
Cerca all'interno di JavaPortal
Help
Home Page Documentazione Forum Progetti Partner Pubblica!
Documentazione > Tutorial > JSTL -parte 1-
Modifica Impostazioni
Hide
Best Practices
EJB
Frameworks
Howto
J2EE
J2ME and Wireless
J2SE
JSP e Servlet
Java Application Server
Java IDE/Tools
Java Media
Java Security
Java Sys Admin
Java e XML
Java e SQL
OpenSource Java
Patterns
Repository
Tesi
UML
Web Services
Slide
White Paper di jws.it
project management
Eventi
Groovy

Hai una tesi in Java?
Tesine preparate
per esami?
Pubblica tutto su
JavaPortal!

Scrivi al nostro staff


La lista delle risorse java essenziali


Publio Cornelio Tacito
Tutte le cose che ora si credono antichissime furono nuove


Multi Threading in JAVA


Rss Feed
Home Page
Articoli
News
Forum
Classi

  Visualizza Commenti (0) Aggiungi Commento    
Add to Shortcuts
 
Vota l'articolo
JSTL -parte 1-
By Gabriele Folchi
1 luglio 2005
Valutazione Acquisita: 30

  JSTL -parte 1-
Program JSP Standard Tag Library (JSTL)
Program Cosa fa JSTL?
Program Expression Language
Program Librerie gemelle
Program CONCLUSIONI

TAG LIBRARIES

Come noto i Custom Tag permettono di definire in forma dichiarativa (ossia sottoforma di tag ) funzionalità programmatiche modulari. Si riduce quindi, anche se non si elimina del tutto, la necessità di inserire scriptlet nelle pagine, spostando la logica dalla pagina jsp a particolari classi di implementazione definite Tag Handler, ed esponendo sulla pagina jsp soltanto tag in sintassi di tipo xml.

Così facendo, si semplifica la realizzazione e la manutenzione delle pagine jsp, si ottengono unità di logica riutilizzabile, e si mantengono separati i compiti degli sviluppatori java da quelli dei designers html: i primi si concentrano sulla risoluzione di problemi programmatici, i secondi sul layout e la formattazione della pagina html.

Tutto ciò ha fatto velocemente crescere una grande attenzione intorno a questa tecnologia, con infinite implementazioni proprietarie. 



JSP Standard Tag Library (JSTL) top

The JavaServer Pages Standard Tag Library (JSTL)è un progetto nato in seno al Java Community Process , le cui specifiche sono state rilasciate nel Giugno di quest'anno, e che verrà supportato in forma standard da JSP a partire dalla specifica 2.0 (attualmente a sua volta allo stato di Proposed Final Draft).

Sviluppata in parallelo anche da Jakarta Project, è inoltre disponibile una distribuzione di JSTL anche dal sito di apache.org, inserita all'interno del più vasto progetto denominato Taglibs.

Con JSTL Sun intende evidentemente colmare la carenza di actions standard JSP in grado di gestire, direttamente dall'interno della sua piattaforma e quindi senza ricorrere a Tag Libraries di terze parti, alcuni fra i più comuni task di tutti i progetti web, che non siano l'istanziazione di un bean o l'inclusione o il forward ad un'altra pagina dell'applicazione:

con i suoi tag JSTL offre la possibilità di eseguire operazioni tipo processamento condizionale, internazionalizzazione, accesso a database e manipolazione di file e dati  XML; tutti aspetti che, ove non si ricorra a librerie di terze parti,  portano normalmente allo sviluppo di lunghi scriptlet, implicando parallelamente debug difficoltosi e tempi prolungati per lo sviluppo di librarie di tag handlers proprietarie.

In più, in quanto standard a partire dalla release 2.0 di JSP, una volta appreso l'uso di tali set di tag, queste features saranno accessibili allo sviluppatore su tutti i container, al pari delle attuali jsp actions.

Parallelamente e per le stesse motivazioni, le classi handler che gestiscono tali tag potranno essere ottimizzate da tutti i produttori dei container.



Cosa fa JSTL? top

JSTL fornisce come detto supporto per iterazione di base, controllo del flusso di esecuzione, inclusione di testo (caratteristica finora limitatamente fornita da <jsp:include>), tag per l'internazionalizzazione e per la manipolazione di documenti XML.

Iterazione

Il tag principale è <c:forEach>, itera su Collections e oggetti simili.

Per iterare invece su tokens di una String è disponibile <c:forTokens> : permette di specificare la String e i delimitatori.

Controllo condizionale

Funzionalità supportata dal tag <c:if> assieme ad una serie di altri tag < c: choose>, < c: when>, e < c: otherwise> che permettono selezioni mutualmente esclusive, tipo strutture  if/else if/else

Tag di scopo generico

< c: out> stampa il valore di una particolare espressione, così come fa il tag jsp <%= ... %>. < c: set> invece permettere di settare un attributo allo scope indicato (es., un valore in request, page, session, or application scope),  con il valore di una espressione.

Inclusione di testo

Complementarmente all'action JSP < jsp:include> , che però include soltanto url relativi, JSTL introduce il tag < c:import> , che permette di recuperare url assolute. Per esempio si può usare < c:import> per recuperare informazioni dal web usando un URL HTTP, o da un server di file usando un URL FTP.

Formattazione i18n

Supporto all'internazionalizzazione dei dati

Gestione XML

Supporto al parsing dei documenti XML, all'utilizzo di XPath per selezioni del contenuto, e a XSLT per la trasformazione e formattazione dei dati xml

Accesso a Database

JSTL fornisce tag per il collegamento a database relazionali, per effettuare queries, accedere a resultsets, eseguire update, e raggruppare azioni in transazioni.

Tali funzionalità, poichè intrinsecamente diverse tra loro sono raggruppate in namespaces separati (ossia in tag library descriptors diversi) e definite come:

  • Core (<c:...>), cui appartengono i tag per iterare, per flusso condizionale e supporto per EL, il nuovo Expression Language, di cui si parlerà appresso. La dichiarazione jsp del suo taglib è <%@  taglib prefix="c" uri="http://java.sun.com/jstl/ea/core" %> .
  • XML (<x:...>) cui appartengono i tag per la gestione di files XML. La dichiarazione jsp del suo taglib è <%@ taglib uri=" http://java.sun.com/jstl/ea/xml" prefix =" x")
  • I18N (<fmt:...>), cui appartengono i tag per l'internazionalizzazione . La dichiarazione jsp del suo taglib è <%@ taglib uri=" http://java.sun.com/jstl/ea/fmt" prefix =" fmt" )
  • SQL (<sql:...>), cui appartengono i tag SQL. La dichiarazione jsp del suo taglib è <%@ taglib uri=" http://java.sun.com/jstl/ea/sql  prefix =" sql"

Naturalmente le indicazioni di uri e prefix per le direttive taglib delle pagine jsp sono da considerarsi puramente indicative, in quanto come noto il percorso specificato dall'attributo uri è liberamente mappabile ad un nome logico qualsiasi, con le opportune modifiche presso il web.xml. Di fatto la distribuzione Jakarta (RI) fornisce oltre ai jar contenenti le librerie di implementazione anche i files tld, che possono quindi collocati liberamente entro la nostra applicazione.

Oltre a ciò JSTL introduce infine il linguaggio EL (Expression Language) per semplificare lo sviluppo delle jsp eliminando anche la necessità (e quindi la presenza) di expression jsp dalla pagina.

Tale articolo si occuperà principalmente di questa novità, rimandando ad una seconda pubblicazione l'analisi in dettaglio dei singoli tag delle librerie JSTL.

Installare JSTL

Col tempo tutte le release dei web container includeranno le librarie JSTL, così che non ci sarà bisogno di installare alcuna libreria aggiuntiva, ma fino ad allora si può scaricare ed installare la Reference Implementation (RI) dal sito di Apache Taglibs, denominata jakarta-taglibs-standard-1.0.zip.

Il link è The JSTL RI: the Standard Library at Apache Taglibs Anche il WSDP (Web Services Developer Pack) di Sun contiene, nell'implementazione dell'applicazione di esempio Duke's Bookstore, librerie e riferimenti a JSTL. Per installare la versione RI di Jakarta, compressa in un jar denominato Standard.jar , copiare tutti i jar dalla cartella di distribuzione /lib contenuta nello standard.jar,  nella cartella WEB-INF/lib della nostra applicazione o in /lib del nostro server.

Si noterà infatti che la distribuzione di Jakarta include oltre a jstl.jar anche alcune ulteriori librerie di supporto necessarie al funzionamento delle principali feature della loro release: Jaxen e Saxpath per il processing Xpath, Crimson, Dom, Xerces per il parsing XML e Xalan per il processing XSLT. Ultima nota: JSTL richiede un container JSP 1.2, quindi fare attenzione che quello da noi utilizzato sia compatibile con tale richiesta. Tomcat a partire dalla versione 4.0.4 soddisfa tali esigenze.

Una volta copiati i jar in WEB-INF/lib , per usare le librerie Standard 1.0 basterà quindi inserire nella pagina jsp la direttiva taglib specifica per la library prescelta, ossia:     <%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>

Ovviamente - come già ricordato - disponendo liberamente dei files .tld  il valore di tale uri è puramente indicativo, essendo rimappabile a piacere con un nome logico specificato a sua volta presso il web.xml, entro il tag Esempio: In jsp: <%@ taglib uri="miaJSTL" prefix="c" %> ....... Nel web.xml: <taglib> <taglib-uri>miaJSTL</taglib-uri> <taglib-location>/WEB-INF/c.tld</taglib-location> <taglib>

Stesso discorso dicasi per il valore del prefix: tale suggerimento è da considerarsi una prassi piuttosto che un obbligo.

 



Expression Language top

Overview

Prima di analizzare le caratteristiche dei singoli tag, è bene esaminare il nuovo linguaggio introdotto da JSTL in quanto utilizzato, per la valutazione runtime di espressioni, da tutte le sue librerie di tag: EL, un linguaggio che promette di sempificare l'accesso ai dati di applicazione poichè non utilizza scriptlets e/o expressions jsp.

Inoltre probabilmente il supporto a EL sarà standard nella prossima versione finale 2.0 delle  specifiche JSP. Se così dovesse essere, si potrà usarlo al posto delle expression jsp non soltanto per passare valori a runtime agli attributi dei custom tag JSTL, ma di tutte le action jsp, e persino nel testo template.

Una nota preliminare sull'utilizzo del termine attributo: da qui in poi esso è utilizzato, a seconda del contesto,  per indicare sia un attributo di un tag, che un oggetto memorizzato in uno scope jsp (page,request, session, application).


Finora per valorizzare a runtime un attributo di un tag col valore, es., di un bean, si è utilizzato una expression jsp:

<x:aTag att="<%= pageContext.getAttribute("aName") %>">

Adesso EL permette di accedere ad un oggetto con una sintassi semplificata:

<x:atag att="${aName}">

 
Come visto per prima cosa una espressione EL deve essere dunque racchiusa dai delimitatori ${ e } . Ogni valore che non comincia con ${ è trattato come literal e parsato come tale.

<c:if test="true" />

EL utilizza poi una sintassi simile a quella di JavaScript, nel senso che accede a strutture dati

  • sia rappresentandole come proprietà di un oggetto o di uno scope - come si vedra in seguito- (con l'operatore .)
  • che come elementi di un vettore associativo la cui chiave è il name della property stessa (con l'operatore ["name"] ),
  • sia infine come elementi di una lista, specificando con l'operatore [] l'index dell'elemento richiesto.

Così le proprietà di JavaBeans e le entry di tipo java.util.Map possono essere accedute in questo modo:

   ${myObj.myProperty}  

   ${myObj["myProperty"]}  

   ${myObj[varCheContieneIlNome]}  

Le prime due accedono alla property myProperty dell'oggetto myObj, mentre la terza accede ad una property dello stesso oggetto, il cui nome però è conservato in una variabile, e valutato perciò a runtime.

Nel caso in cui l'oggetto sia invece del tipo java.util.List, o un array, si potrà accedere ai suoi elementi interni soltanto col secondo operatore ([]), specificando l'index (int) dell'elemento stesso:

   ${myList[2]}$  

   ${myList[aVar + 1]}$  

cart memorizzato in session scope: 


<c:if test="${sessionScope.cart.numberOfItems > 0}">

</c:if>

Cosa può fare EL

Entro i suoi delimitatori, EL può gestire espressioni che contengono come operandi puntatori ad oggetti -custom ed impliciti- e/o letterali, e gli operatori  più comuni:

Per esempio : <c:if test="${bean1.a < 3}" />

Letterali invece contenuti in una espressione EL e che devono essere ritornati come String devono essere messi a loro volta entro delimitatori di stringa, che per EL sono sia singoli che doppi apici

<mytags:example attr1="an expression is ${'${'}true}" />

Accesso ad attributi custom di page, request, session, application

Qualsiasi ogetti memorizzato in uno scope JSP valido (page, request, session, or application)  può essere acceduto da EL, compresi gli oggetti impliciti, come vedremo.

Per esempio si può accedere ad una proprietà firstName di un bean customer che è memorizzato come attributo di request, con questa espressione:

${customer.firstName}  

Gli attributi sono acceduti per nome, con uno scope opzionale, nel senso che EL valuta un nome di variabile cercandolo come attributo di PageContext, ossia eseguendo PageContext.findAttribute(String) . Il che equivale ad una rucerca su tutti gli scope jsp, da page fino ad application

Se non trova nulla ritorna null.

Accesso ad oggetti impliciti jsp

JSTL ridefinisce un set di oggetti impliciti, la maggior parte dei quali trattati come java.util.Map ossia Vettori associativi:

  • pageContext - l'oggetto PageContext
  • pageScope - per l'accesso agli attributi in page scope
  • requestScope - per l'accesso agli attributi memorizzati in request scope
  • sessionScope - per l'accesso agli attributi memorizzati in session scope
  • applicationScope - per l'accesso agli attributi memorizzati in application scope
  • param - per l'accesso al singolo parametro di request (equivale a ServletRequest.getParameter(String) )
  • paramValues - per l'accesso a tutti i parametri di request (equivale a ServletRequest.getParameterValues(String))
  • header - per l'accesso al singolo header di request (equivale a ServletRequest.getheader(String) )
  • headerValues - per l'accesso a tutti gli header di request (equivale a ServletRequest.getHeaders(String))
  • cookie - per l'accesso al singolo Cookie (equivale a HttpServletRequest.getCookie(String) )
  •  initParam - per l'accesso al singolo parametro di inizializzazione della jsp (equivale a ServletRequest.getInitParameter(String) )

Esempi

${pageContext.request.contextPath}

ritorna il contextPath (ottentuo da HttpServletRequest )

${sessionScope.cart.numberOfItems}

ritorna il valore della property numberOfItems dell'attributo denominato cart, memorizzato in session

${param["mycom.productId"]}

ritorna il valore del parametro di request mycom.productId


${header['User-Agent']}  

ritorna il valore dell'header di request "User-Agent"

Grazie a tali oggetti impliciti, per esempio, nel caso  esempio di ${customer.firstName } si può restringere l'ambito di ricerca specificando subito lo scope richiesto: in pratica se esiste un attributo customer in session, le prime due espressioni seguenti ritorneranno lo stesso oggetto mentre la terza ritornerà null:

   ${customer}  

   ${sessionScope.customer}  

   ${requestScope.customer}  

Letterali EL supporta i seguenti tipi di letterali: String
  • Racchiuso in singoli o doppi apici . Apici che devono essere trattati come tali e non come delimitatori devono essere preceduti dal carattere di escape ( \' in a string enclosed with single quotes; \" in a string enclosed with double quotes).
Integer
 
Floating Point
  • Il separatore decimale è il punto (.) . Può essere specificato un esponente con e o E, seguita da un int
Boolean
  • true o false

Null

Operatori

Sono disponibili i seguenti operatori:

Aritmetici: + , - , * , / e div , % e mod , -

Logici: and , && , or , || , not , !

relazionali: == , eq , != , ne , < , lt , > , gt , <= , ge , >= , le .

empty: operatore prefisso che permette di verificare se un puntatore è null o p. es. un oggetto è vuoto

Da notare lo speciale operatore prefisso empty (es empty A ritorna true se il puntatore A è null o contiene una stringa "" oppure se è una Lista vuota)

Ciò che non è presente in EL sono le assegnazioni (=), e gli operatori condizionali if/else , o while . Per tali funzionalità ci sono le action, poichè  EL non è considerato un vero linguaggio di programmazione ma soltanto un linguaggio di accesso ai dati



Librerie gemelle top

Prima di congedarci (momentaneamente...) un ultima nota sulla release 1.0 di JSTL: per ogni libreria e descrittore (Core, XML, I18n e SQL) è inclusa anche una versione gemella identificabile dal file tld terminante col suffisso "-rt". Le versioni sono quindi EL e RT.

La differenza tra le due è unica, elementare ma non marginale: le versioni RT non supportano EL come linguaggio di valutazione runtime di espressioni, ma ancora l'usuale expression JSP (<%=...%>): utilizzando tali librerie e descrittori lo sviluppatore può quindi sfruttare i servizi dei nuovi Custom Tag senza però dover imparare il nuovo linguaggio.

Per esempio :

<c:forEach items="${sessionScope.myName}" />

nella versione RT diventa, o meglio, deve essere reso come....:-)

<c_rt:forEach items="<%=session.getAttribute("myName") %>" />

Come prevedibile, tale affermazione è vera anche al contrario: quando si usa la versione EL non si può usare per lo stesso scopo una expression JSP. In questo modo si permette la validazione della sintassi EL a translation time.



CONCLUSIONI top

JSTL ha permesso a Sun di integrare e completare lo standard JSP, includendo il supporto a quelle operazioni ritenute più ricorrenti ed ormai non evitabili, quali appunto l'accesso a database relazionali, la formattazione "localizzata" dei dati html, il parsing di file e dati in formato xml.

Di più, con EL, promette di semplificare ulteriormente la piattaforma eliminando del tutto gli scriptlet (o meglio le rt-expression) dalla pagina jsp, anche se per il momento limitatamente ai compiti di valorizzazione degli attributi dei tag JSTL, standard e/o custom.

Nella seconda parte di questo articolo approfondiremo i dettagli dei singoli tag delle quattro librerie JSTL.



Username:
Password:
To sign up for an account, click register... Register
Hide





Powered By



Campagna Anti-IF


Skin


PARTNER
Zio Budda
HostingJava


LICENZA



Eccetto dove diversamente specificato, i contenuti di questo sito sono rilasciati sotto licenza Creative Commons

Sitemap  © 2002-2004 Copyright Information. Privacy . Today is domenica 1 agosto 2010