Ing. Tarin Gamberini

Menu

• Home
• Curriculum Vitae
• State Exam
• University Studies
• Java
• Site's Map
• Email
• PGP/GPG key

Citazione

Counter

Languages

• Italiano
• English

Standards

Campagne

Barra di navigazione

Home > Java > Lavorare con la JSTL

This page is under translation...

Lavorare con la JavaServer Pages Standard Tag Library (JSTL)

Sommario

• Breve introduzione alla JSTL
• Cosa serve per lavorare con la JSTL
• Le JSTL non funzionano
• Configurare la JSTL in una applicazione web
• Le espressioni EL non funzionano
• Dichiarare la versione del web.xml
• Tomcat e la directory di lavoro: work
• La direttiva isELIgnore
• Bibliografia

Breve introduzione alla JSTL

Oltre ai tag html esistono anche i custom tag JSP, conosciuti anche come tag personalizzati, che sono sostanzialmente legati alla tecnologia JSP. In altre parole i tag personalizzati sono utilizzati nell'implementazione di web application che adottano la tecnologia JSP per il disegno delle pagine web.

Un tag personalizzato incapsula una funzionalità collocata in una classe java detta tag handler. Alcuni vantaggi derivanti da tale approccio sono:

• la pagina JSP risulta più leggibile: invece che presentare codice html inframezzato da scriplet Java, essa presenta tag html e tag personalizzati;
• un tag personalizzato è riusabile: la funzionalità contenuta nella classe tag handler è richiamabile più volte all'interno di pagine JSP.

La JavaServer Pages Standard Tag Library (JSTL) è una raccolta standard di tag personalizzati che gestiscono: controllo di flusso condizionale ed iterativo, manipolazione di file XML, accesso a database tramite SQL, ed altre comuni funzionalità.

La definizione di uno standard ha avuto due importanti conseguenze. La prima ha permesso ai costruttori di server di progettare web container che supportino tale standard. La seconda ha permesso ai progettisti di web application di adottare la JSTL invece che un insieme di tag personalizzati provenienti dai più diversi venditori, offrendo maggiori garanzie di portabilità dell'applicazione attraverso diversi web container.

Cosa serve per lavorare con la JSTL

Per lavorare con la JSTL dovremo procurarci un'opportuna distribuzione della libreria. Nel corso di questo breve articolo faremo riferimento alla JavaServer Pages Standard Tag Library versione 1.1. Essa richiede un container JSP che supporti le specifiche Java Servlet versione 2.4 e JavaServer Pages versione 2.0 come, per esempio, Tomcat 5.5.

Le JSP versione 2.0 supportano un expression language (EL) [1] in grado di valutare espressioni aritmetico-logiche e di accedere agilmente alle proprietà dei bean. Affinchè una espressione EL sia valutata occorre indicarla fra i simboli ${ e }.

Le JSTL non funzionano

Sono vari i motivi per cui le JSTL possono non funzionare. Per i problemi di sintassi dei tag si veda la documentazione relativa alla JavaServer Pages Standard Tag Library versione 1.1, mentre per i problemi di configurazione della libreria si veda la sezione seguente Configurare le JSTL in una applicazione web.

Configurare la JSTL in una applicazione web

Affinchè una una pagina JSP possa utilizzare un tag personalizzato della JSTL occorre configurare opportunamente i vari componenti [2] della tag library come indicato nel seguito.

Il file Tag Handler

Il tag handler è una classe java il cui codice implementa il comportamento del tag. Nella distribuzione JSTL versione 1.1 i tag handler si trovano nel file jstl.jar, che deve essere copiato nella directory \WEB-INF\lib della propria web application.

Il file Tag Library Descriptor

Il file Tag Library Descriptor (TLD) è il descrittore della libreria di tag. E' un file xml che contiene alcune metainformazioni: il nome della libreria, l'uri della libreria, i nomi dei tag, i nomi dei relativi tag handler, ecc... A titolo puramente indicativo riportiamo un breve estratto dal descrittore dalla libreria core, il file c.tld:

<taglib ... > 
 <description>
  JSTL 1.1 core library
 </description>
 <display-name>
  JSTL core
 </display-name>
 <tlib-version>1.1</tlib-version>
 <short-name>c</short-name>
 <uri>
  http://java.sun.com/jsp/jstl/core
 </uri>
 ...
 <tag>
  <description>
   Simple conditional tag, which evalutes 
   its body if the supplied condition is 
   true and optionally exposes a Boolean 
   scripting variable representing the 
   evaluation of this condition
  </description>
  <name>if</name>
  <tag-class>
   org.apache.taglibs.standard.tag
   .rt.core.IfTag
  </tag-class>
  ...
 </tag>
 ...
</taglib>

I file TLD vanno copiati in una cartella della propria applicazione web: tipicamente in \WEB-INF\tld.

Il file web.xml

Il file web.xml va obbligatoriamente configurato solo se si utilizza una versione inferiore alla JSP 1.2 [3]. Infatti a partire dalla versione 1.2, all'avvio del server, il container va automaticamente alla ricerca dei TLD contenuti nell'albero WEB-INF e contenuti nei jar. Preleva poi l'uri della tld e memorizza in una Map il nome di ogni tag associandolo al relativo tag handler.

Pertanto per versioni inferiori alla JSP 1.2 occorre indicare nel descrittore di deploy della web application quali librerie vogliamo utilizzare. Nell'ipotesi di utilizzare solamente la core library scriveremo nel web.xml il seguente codice:

<web-app>
 ...
 <taglib>
  <taglib-uri>
   http://java.sun.com/jsp/jstl/core
  </taglib-uri>
  <taglib-location>
   /WEB-INF/tld/c.tld
  </taglib-location>
 </taglib>
   ...
</web-app>

La taglib-location deve indicare il descrittore di libreria attraverso un percorso relativo. Il taglib-uri indica una nome simbolico utilizzato nelle pagine JSP per importare la libreria. Il taglib-uri deve essere un nome univoco all'interno dell'intera applicazione web. Per cercare di garantire tale unicità i produttori di TLD hanno adottato la convenzione di utilizzare come uri un indirizzo http, per esempio: http://java.sun.com/jsp/jstl/core.

In altre parole nel web.xml ogni taglib mappa un uri ad un TLD.

La pagina JSP

La pagina JSP che vuole utilizzare una tag library, per esempio la core, deve importarla attraverso la seguente direttiva:

<%@ taglib 
 uri="http://java.sun.com/jsp/jstl/core" 
 prefix="c" %>

in cui l'uri coincide con il nome simbolico indicato nel tag taglib-uri del web.xml. La JSP non cerca il TLD in internet, quest'ultimo è già stato caricato dal container all'avvio del server ed è pertanto già disponibile alla JSP.

Le espressioni EL non funzionano

Un altro problema che può incontrare lo sviluppatore che si avvicina per le prime volte alla JSTL versione 1.1, e quindi indirettamente alle JSP versione 2.0, è quello di non vedere interpretate le espressioni EL. Per esempio supponiamo di aver creato la pagina index.jsp seguente:

<!DOCTYPE HTML PUBLIC 
 "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
 <head>  
  <title>
   Esercitazione con JSP 2.0
  </title>
 </head>
 <body>
  ${ 3 + 2 }
 </body>
</html>

Richiedendo la pagina al server potrebbe accadere che il browser riceva un risposta visualizzata come:

${ 3 + 2 }

mentre ci si sarebbe aspettato che il server, interpretando l'espressione EL, rispondesse con una pagina così:

5

Per risolvere questo problema si legga la sezione seguente Dichiarare la versione del web.xml.

Dichiarare la versione del web.xml

La valutazione delle espressioni EL dipende della versione del descrittore di deploy della web application [4].

Tomcat 5.5, che ricordiamo supporta le specifiche Java Servlet versione 2.4 e JavaServer Pages versione 2.0, lascia la possibilità al progettista di definire la versione del descrittore di deploy. Definendo nel web.xml il tag web-app senza versione:

<web-app>
    ...
</web-app>

Tomcat 5.5 considererà il descrittore di deploy di versione 2.3, pertanto le espressioni EL non saranno valutate. Definendo nel web.xml il tag web-app con versione 2.4:

<web-app version="2.4">
    ...
</web-app>

o per maggior completezza:

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com
/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001
/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com
/xml/ns/j2ee 
http://java.sun.com/xml/ns/j2ee
/web-app_2_4.xsd"
version="2.4">
...
</web-app>

Tomcat 5.5 considererà il descrittore di deploy di versione 2.4, pertanto le espressioni EL saranno valutate.

Se, anche dopo aver configurato il web.xml con <web-app version="2.4">, si continui ad ottenere una pagina in cui le espressioni EL non sono valutate si legga la sezione seguente Tomcat e la directory di lavoro: work.

Tomcat e la directory di lavoro: work

L'ambiente in cui stiamo sviluppando l'applicazione avrà definito una directory di lavoro in cui Tomcat 5.5, sfruttando Jasper, tradurrà le pagine JSP in servlet. Tipicamente tale directory è chiamata col nome work.

Supponiamo di aver configurato il descrittore di deploy di versione 2.3, cioè con <web-app>, e di aver richiesto la pagina index.jsp. Nella directory di lavoro esisterà una servlet, con un nome simile ad index_jsp.java, le cui espressioni EL non saranno state tradotte da Tomcat.

Ora correggiamo il web.xml con <web-app version="2.4">, riavviamo il server e richiediamo nuovamente la pagina index.jsp. Tomcat 5.5 controlla la directory di lavoro accorgendosi che index.jsp non è stata modificata dall'ultima richiesta, quindi non ritradurrà la JSP in una servlet ma riuserà quella precedentemente ottenuta con il descrittore di deploy di versione 2.3. In altre parole, anche dopo aver configurato il web.xml con <web-app version="2.4"> si osserverà una pagina ottenuta senza valutazione delle espressioni EL.

Per risolvere questo problema è sufficiente cancellare il contenuto della directory di lavoro.

Riavviamo il server e richiediamo la pagina index.jsp. Tomcat 5.5 controlla la directory di lavoro accorgendosi che index.jsp è assente, quindi la tradurrà in una servlet ma considerando il web.xml appena corretto con <web-app version="2.4">. Pertanto si osserverà finalmente una pagina ottenuta con la valutazione delle espressioni EL.

Per completezza riportiamo un breve estratto della servlet index_jsp.java tradotta da Jasper a partire dalla index.jsp, avviando il server quando il web.xml è configurato con <web-app>:

...
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;

public final class index_jsp 
 extends 
 org.apache.jasper.runtime.HttpJspBase 
 implements 
 org.apache.jasper.runtime
 .JspSourceDependent {
  ...
  out.write("${ 3 + 2 }");
  ...
}

Si osserva che, nella scrittura della response, l'espressione EL non viene valutata. Analogamente riportiamo un breve estratto della servlet index_jsp.java quando il web.xml è configurato con <web-app version="2.4">:

...
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;

public final class index_jsp 
 extends 
 org.apache.jasper.runtime.HttpJspBase
 implements 
 org.apache.jasper.runtime
 .JspSourceDependent {
  ...
  out.write((java.lang.String) 
    org.apache.jasper.runtime
    .PageContextImpl.proprietaryEvaluate(
      "${ 3 + 2 }", 
      java.lang.String.class, 
      (PageContext)_jspx_page_context, 
      null, 
      false)
    );
  ...
}

osservando che, nella scrittura della response, l'espressione EL viene valutata invocando il metodo proprietaryEvaluate.

La direttiva isELIgnore

Se la propria web application è conforme alle specifiche Java Servlet versione 2.3 ed esegue all'interno di un container che supporta le specifiche Java Servlet versione 2.4 è comunque possibile ricorrere alle espressioni EL dichiarando all'interno della pagina JSP la direttiva isELIgnore:

<%@ page isELIgnored ="false" %>
      

Tale direttiva sovrascrive l'impostazione per l'interpretazione delle espressioni EL che il container aveva caricato dal descrittore di deploy all'avvio del server.

In questo modo è garantita la retro-compatibilità della JSTL con applicazioni il cui web.xml sia di versione 2.3 od inferiore [5].

Bibliografia

[1]

The J2EE (TM) 1.4 Tutorial - For Sun Java System Application Server Platform Edition 8.2 - Eric Armstrong, Jennifer Ball, Stephanie Bodoff, Debbie Bode Carson, Ian Evans, Dale Green, Kim Haase, Eric Jendrock - 7 Dicembre 2005 - Capitolo 12 "JavaServer Pages Technology" - Paragrafo "Expression Language" - pag 499.

[2]

Programmare con Jakarta Struts - Chuck Cavaness - Ulrico Hoepli Editore - Capitolo 8 "Librerie di Tag JSP personalizzati" - Paragrafo "Che cosa è una libreria di tag?" - pag 190.

[3]

Java Server Pages - 3^ edizione - Hans Bergsten - Editore Hops-Tecniche Nuove - Capitolo 7.

[4]

The J2EE (TM) 1.4 Tutorial - For Sun Java System Application Server Platform Edition 8.2 - Eric Armstrong, Jennifer Ball, Stephanie Bodoff, Debbie Bode Carson, Ian Evans, Dale Green, Kim Haase, Eric Jendrock - 7 Dicembre 2005 - Capitolo 12 "JavaServer Pages Technology" - Paragrafo "Deactivating EL Expression Evaluation" - pag 522.

[5]

The J2EE (TM) 1.4 Tutorial - For Sun Java System Application Server Platform Edition 8.2 - Eric Armstrong, Jennifer Ball, Stephanie Bodoff, Debbie Bode Carson, Ian Evans, Dale Green, Kim Haase, Eric Jendrock - 7 Dicembre 2005 - Capitolo 12 "JavaServer Pages Technology" - Paragrafo "Deactivating Expression Evaluation" - pag 500.