Antes de empezar, debe realizar el Ejercicio 1.4: Comparar diferencias del descriptor de despliegue.
En este ejercicio se mostrarán las diferencias en la codificación de archivos JSP entre las dos API de portlet. Examine ambas versiones de los archivos JSP Edit y View. Las diferencias básicas se exponen a continuación.
Los códigos de la API de portlet de IBM se declaran en la biblioteca de códigos
portlet.tld
. Los códigos utilizan el prefijo portletAPI. La API de portlet de
JSR 168 utiliza la biblioteca de códigos std-portlet.tld
y el prefijo portlet.
Otras bibliotecas de códigos, como por ejemplo JavaServer Pages Standard Tag Library (JSTL),
definida en fmt.tld
también pueden utilizarse. Tal como se muestra en el código de
ejemplo siguiente, la biblioteca de códigos JSTL utiliza el prefijo fmt.
<%@ taglib uri="/WEB-INF/tld/portlet.tld" prefix="portletAPI" %>
<portletAPI:init />
<%@ taglib prefix="fmt" uri="/WEB-INF/tld/fmt.tld" %>
<fmt:setBundle basename="nls.Text" />
<%@ taglib uri="http://java.sun.com/portlet" prefix="portlet" %>
<portlet:defineObjects />
<%@ taglib prefix="fmt" uri="/WEB-INF/tld/fmt.tld" %>
<fmt:setBundle basename="nls.Text"/>
En la API de portlet de IBM, el código <portletAPI:init> pone los objetos PortletRequest, PortletResponse y PortletConfig a disposición de los archivos JSP. En la API de portlet de JSR 168, el código <portlet:defineObjects> pone los objetos RenderRequest, RenderResponse y PortletConfig a disposición de los archivos JSP.
<portletAPI:init />
<portlet:defineObjects />
Las dos API difieren en la manera de establecer el tipo MIME para la respuesta de representación. Los portlets de IBM declaran el tipo MIME en la directiva de página del archivo JSP. Los portlets de JSR 168 declaran el tipo MIME utilizando el método setContentType() del objeto RenderResponse en los métodos de representación (doView(), doEdit()).
<%@ page contentType="text/html"
import="java.util.*,
com.ibm.etools.portal.portletexamples.bookmark.legacy.*,
org.apache.jetspeed.portlet.*"
session="false"%>
response.setContentType("text/html");
Las referencias a un portlet, una página de portlet o un recurso de portlet deben codificarse en un URI de portlet (JSR 168 utiliza el término URL). La API de portlet de IBM utiliza el URI para señalar al portlet de llamada en la modalidad actual y createReturnURI para señalar el portlet de llamada en la modalidad anterior. La API de portlet de JSR 168 crea URL para la fase de acción (actionURL) y la fase de representación (renderURL).
en un archivo JSP: <portletAPI:createURI/>
<portletAPI:createReturnURI/>
En una clase Java: PortletResponse.createURI()
PortletResponse.createReturnURI()
en un archivo JSP: <portlet:actionURL/>
<portlet:renderURL/>
en una clase Java: RenderResponse.createActionURL()
RenderResponse.createRenderURL()
Los archivos JSP de portlet deben codificar los URL que hacen referencia a recursos en el archivo WAR asociado como por ejemplo imágenes, applets y otros archivos JSP. La API de portlet de JSR 168 también requiere que la vía de acceso de contexto esté incluida en el URL.
<%= response.encodeURL("images/photo01.jpg") %>
<%= renderResponse.encodeURL(renderRequest.getContextPath() + "/images/photo01.jpg") %>
La codificación de espacio de nombres para las clases Java y los archivos JSP se trata en el apartado Codificación de espacio de nombres en el ejercicio 1.3.
El código de ejemplo para ambas API muestra la utilización del código JSTL <fmt:setBundle>.
Este código hace referencia a un paquete de recursos Java estándar, Text.properties
,
en el directorio JavaSource/nls
de los ejemplos. Compare esto con los
paquetes compuestos de recursos que definen el portlet.
<fmt:setBundle basename="nls.Text" />
<fmt:setBundle basename="nls.Text" />
Ahora está preparado para iniciar el Ejercicio 1.6: Cómo decidir qué API utilizar.