Changes to the JSP Tag Library in Version 3.1

 

Note: Backward Compatibility Will Stop After Version 3.1. The tag libraries have been updated in WebLogic Personalization Server (WLPS) version 3.1 to comply with the JSP 1.1 specification. If you are upgrading from WebLogic Personalization Server 2.0.1, you can continue to use your existing code with WebLogic Personalization Server 3.1. However, future releases will no longer be backward compatible, so you will need to migrate to the new tags if you intend to continue to use your legacy code with the latest WebLogic Personalization Server releases.

The WebLogic Personalization Server 3.1 documentation has been revised to reflect the changes to the tag libraries. Until you migrate to the new tags, you can continue to use the WebLogic Personalization Server 2.0 JSP Tag Reference found at http://download.oracle.com/docs/cd/E13210_01/wlcs/p13ndev/jsptags.htm.

This topic includes the following sections:

• New JSP Tags in Version 3.1

  • New Property Set Management Tags

  • New Internationalization Tags

  • New WebLogic Utility Tag

• Changes to the JSP Tag Library

  • New JSP 1.1 Naming Conventions

  • Changes to Tag Attributes

  • Global Changes

  • Tag Migration Roadmap

  • Additional Notes About JSP Tags

 

---

New JSP Tags in Version 3.1

WebLogic Personalization Server 3.1 introduces five new tags:

<ps:getPropertyNames>

<ps:getPropertySetNames>

<i18n:localize>

<i18n:getMessage>

<wl:repeat>

New Property Set Management Tags

Two new Property Set Management JSP extension tags provide the following services:

• Lists all properties associated with a property set.

• Lists all property set names for a property set group name (for example, USER or CONTENT).

The two new Property Set tags are:

<ps:getPropertyNames>

Returns a list of property names for a given property set in a String array.

<ps:getPropertySetNames>

Returns a list of property set names for a given schema group name in a String array.

New Internationalization Tags

In earlier releases of WebLogic Personalization Server, Internationalization ( I18N) was applied from JSP beans that supported sample portal pages, and administration tools pages. The JSP beans employed a simple MessageBundle Java class that allowed access to localized text labels and messages.

For this release, this basic MessageBundle has been extended using a simple framework that is accessible from JSPs via a small I18N extension tag library. The JSP extension tag library provides the following services:

• Retrieves a static text label or a message from a resource bundle (implemented as a property file).

• Initializes a page context with a particular language, country, and variant for label and message retrieval throughout a page.

• Properly sets the content type (text/html) and character encoding for a page.

The following new tags are included in the I18N framework:

<i18n:localize>

Allows you to define the language, content type, and character encoding to be used in a page. It also allows you to specify a country, variant, and resource bundle name to use throughout a page when accessing resource bundles via the <i18n:getMessage> tag described below.

<i18n:getMessage>

Retrieves a localized label, or message (based on the absence/presence of an "args" attribute). This tag optionally takes a bundle name, language, country, and variant to aid in locating the appropriate properties file for resource bundle loading.

New WebLogic Utility Tag

<wl:repeat>

This WebLogic Server tag is used to iterate over a variety of Java objects that includes:

• Enumerations

• Iterators

• Collections

• Arrays

• Vectors

• Result Sets

• Result Set MetaData

• Hashtable keys

 

---

Changes to the JSP Tag Library

The tag libraries have been updated in WebLogic Personalization Server version 3.1 to comply with the JSP 1.1 specification. If you are upgrading from WebLogic Personalization Server 2.0.1, you can continue to use your existing code with WebLogic Personalization Server 3.1. However, future releases will no longer be backward compatible, so you will need to migrate to the new tags if you intend to continue to use your legacy code with the latest WebLogic Personalization Server releases.

The WebLogic Personalization Server 3.1 documentation has been revised to reflect the changes to the tag libraries. Until you migrate to the new tags, you can continue to use the WebLogic Personalization Server 2.0 JSP Tag Reference located at http://download.oracle.com/docs/cd/E13210_01/wlcs/p13ndev/jsptags.htm.

New JSP 1.1 Naming Conventions

Beginning with WebLogic Personalization Server version 3.1, all tags use the JSP 1.1 naming conventions. Old style tags that were used in previous WebLogic Personalization Server releases have been changed to reflect the new camel case naming conventions.

For example, the old-style tag <um:getgroupnamesforusers> is now <um:getGroupNamesForUsers>.

Old tag names can still be used in the WebLogic Personalization Server 3.1 release. However, old style tag names will not be supported in future releases of WebLogic Personalization Server.

Note: Each time you use a deprecated tag, a message is logged to WebLogic Server. To turn off the deprecation messages, add the following property to weblogiccommerce.properties: commerce.log.display.deprecated=false

For consistency, the Portal Management tags <pt:*> have a new esp: prefix. For example, the old-style tag <pt:eval> is now called <esp:eval>, and the old <pt:portalmanager> is now <esp:portalManager>. When you change to the new prefix, you will need to update each Portal Management tag invocation in the page to use the new prefix.

Note: The es: prefix stands for e-commerce services.
The esp: prefix stands for e-commerce services portal.
The pz: prefix stands for personalization.

Changes to Tag Attributes

The User Management and WebLogic Personalization Server Utility tags have been changed as follows:

• For the User Management <um:*> tags, the resultId attribute has been changed to result, and is now an Integer instead of an int. Usage and functionality remain the same.

• For the User Management tags <um:getProperty> and <um:setProperty>, the usecache attribute has been dropped.

• For the WebLogic Personalization Server Utility tags <es:isNull> and <es:notNull>, the id attribute has been changed to item.

• For the WebLogic Personalization Server Utility tag <es:preparedStatement>, the pool attribute has been dropped. (See Note 4: <es:preparedStatement>.)

Tag attributes also require camel casing. All of the tag attributes used in previous WebLogic Personalization Server releases already use the camel-case convention, with a few exceptions. The tags that do not already use camel-cased attributes are the three Advisor tags (formerly called Personalization Advisor) <pz:*>, and the single WebLogic utility <wl:process>.

Table 2-1 lists the attributes that you will need to camel case. Note that all of these attributes are optional, so it is possible that you did not use them in your existing code.

Table 2-1 Camel-cased Attributes

Tag	Property
<pz:div>	ruleSet
<pz:contentQuery>	sortBy contentHome
<pz:contentSelector>	ruleSet sortBy contentHome
<wl:process>	notName notValue

Any JSP migrating from old-style tags to new-style tags will need to point to new library descriptors.

• For Portal Management <pt:*> tags, change "lib/esportal.jar" to "esp.tld".(Also, change prefix="pt" to prefix= "esp". Update each invocation of a Portal Management tag on the page to use the "esp" prefix.)

• For User Management <um:*> tags, change "lib/um_tags.jar" to "um.tld".

• For Personalization Utilities <es:*> tags, change "lib/esjsp.jar" to "es.tld".

• For the WebLogic Utility <wl:process> tag, change "lib/wljsp.jar" to "weblogic.tld".

For example:

In the JSP page, <%@ taglib uri="lib/um_tags.jar" prefix="um" %>
would change to <%@ taglib uri="um.tld" prefix="um" %>.

Note: The Personalization Advisor is now simply called the Advisor.
The Advisor <pz:*> tags already use taglib uri="pz.tld", so these do not need to be changed.

The Content Management <cm:*> tags already use taglib uri="cm.tld", so these do not need to be changed.

Global Changes

Tags no longer return primitive types, they only return objects.
For example, <es:counter> used to return an int, and now it returns an Integer object.

Any tags (es, um, wl, etc.) with a <jsp:include page=.../> in their body must be replaced with their scriptlet equivalent. (See Section 5.4.5 of the JSP 1.1 specification.)

Old Usage:

<es:notNull item="renderer">
  <jsp:include page="<%=reconcileFile(request, renderer)%>"/>
</es:notNull>

New Usage:

<% if (renderer != null) { %>
  <jsp:include page="<%=reconcileFile(request, renderer)%>"/>
<% } %>

Tag Migration Roadmap

Table 2-2 maps the old tag names to the new JSP 1.1 camel-cased tag names. In addition, changes made to the tags in the WebLogic Personalization Server 3.1 release are noted in the Change column.

Table 2-2 Tag Changes for WebLogic Personalization Server 3.1

Library	Old Style Tag Name	Change	New JSP 1.1 Tag
Advisor	<pz:contentquery>	Camel case Attribute sortby = sortBy Attribute contenthome = contentHome It is no longer necessary to extend the JSP. See below - Note 1: <pz:> tags.	<pz:contentQuery>
	<pz:contentselector>	Camel case Attribute ruleset = ruleSet Attribute sortby = sortBy Attribute contenthome = contentHome	<pz:contentSelector>
	<pz:div>	ruleset = ruleSet It is no longer necessary to extend the JSP. See below - Note 1: <pz:> tags.	<pz:div>
Content Mngmt	<cm:printproperty>	Camel case	<cm:printProperty>
	<cm:printdoc>	Camel case	<cm:printDoc>
	<cm:select>	No change	<cm:select>
	<cm:selectbyid>	Camel case	<cm:selectById>
I18N	---	New	<i18n:initialize>
	---	New	<i18n:getMessage>
Property Set	---	New	<ps:getPropertyName>
	---	New	<ps:setPropertyName>
Portal	<pt:eval>	taglib uri="esp.tld" Change preface pt: to esp:	<esp:eval>
	<pt:get>	taglib uri="esp.tld" Change preface pt: to esp:	<esp:get>
	<pt:getgroupsforportal>	Camel case Change preface pt: to esp: taglib uri="esp.tld"	<esp:getGroupsForPortal>
	<pt:monitorsession>	Camel case taglib uri="esp.tld" Change preface pt: to esp:	<esp:monitorSession>
	<pt:portalmanager>	Camel case taglib uri="esp.tld" Change preface pt: to esp:	<esp:portalManager>
	<pt:portletmanager>	Camel case taglib uri="esp.tld" Change preface pt: to esp:	<esp:portletManager>
	<pt:props>	taglib uri="esp.tld" Change preface pt: to esp:	<esp:props>
User/ Profile	<um:getprofile>	Camel case taglib uri="um.tld"	<um:getProfile>
	<um:getproperty>	Camel case taglib uri="um.tldv"	<um:getProperty>
	<um:getpropertyasstring>	Camel case taglib uri="um.tld"	<um:getPropertyAsString>
	<um:removeproperty>	Camel case taglib uri="um.tld"	<um:removeProperty>
	<um:setproperty>	Camel case taglib uri="um.tld"	<um:setProperty>
User/ Group	<um:addgrouptogroup>	Camel case taglib uri="um.tld" Attribute resultId = result	<um:addGroupToGroup>
	<um:addusertogroup>	Camel case taglib uri="um.tld" Attribute resultId = result	<um:addUserToGroup>
	<um:changegroupname>	Camel case taglib uri="um.tld" Attribute resultId = result	<um:changeGroupName>
	<um:creategroup>	Camel case taglib uri="um.tld" Attribute resultId = result	<um:createGroup>
	<um:createuser>	Camel case taglib uri="um.tld" Attribute resultId = result	<um:createUser>
	<um:getchildgroupnames> (previously undocumented)	Camel case taglib uri="um.tld"	<um:getChildGroupNames>
	<um:getchildgroups>	Camel case taglib uri="um.tld"	<um:getChildGroups>
	<um:getgroupnamesforuser>	Camel case taglib uri="um.tld"	<um:getGroupNamesForUser>
	<um:getparentgroupname>	Camel case taglib uri="um.tld"	<um:getParentGroupName>
	<um:gettoplevelgroups>	Camel case taglib uri="um.tld"	<um:getTopLevelGroups>
	<um:getusernames>	Camel case taglib uri="um.tld" attribute resultId = result	<um:getUsernames>
	<um:getusernamesforgroup>	Camel case taglib uri="um.tld"	<um:getUsernamesForGroup>
	<um:removegroup>	Camel case taglib uri="um.tld" attribute resultId = result	<um:removeGroup>
	<um:removegroupfromgroup> (previously undocumented)	Camel case taglib uri="um.tld" attribute resultId = result	<um:removeGroupFromGroup>
	<um:removeuser>	Camel case taglib uri="um.tld" attribute resultId = result	<um:removeUser>
	<um:removeuserfromgroup> (previously undocumented)	Camel case taglib uri="um.tld" attribute resultId = result	<um:removeUserFromGroup>
User / Security	<um:login>	Camel case taglib uri="um.tld" Attribute resultId = result	<um:login>
	---	New	<um:logout>
	<um:setpassword>	Camel case taglib uri="um.tld" Attribute resultId = result	<um:setPassword>
WLPS Utilities	<es:condition>	Tag no longer supported. Requires manual replacement. See below - Note 2: <es:condition>.
	<es:counter>	taglib uri="es.tld" Attribute id returns an Integer or Long object. You can no longer change the value of the counter variable "id".See below - Note 3: <es:counter>. Optional attribute type can be 'long' or 'Long' or 'Integer' or if not specified is assumed to be 'Integer'.	<es:counter>
	<es:date>	taglib uri="es.tld"	<es:date>
	<es:foreachinarray>	Camel case taglib uri="es.tld" Attribute array must be a runtime expression (<%=expression%>) Attribute counterId returns an Integer object (use id.intValue())	<es:forEachInArray>
	<es:isnull>	Camel case taglib uri="es.tld" Attribute id = item Attribute item must be a runtime expression. An empty string is now treated as a value. (An empty string is not null.)	<es:isNull>
	<es:monitorsession>	Camel case taglib uri="es.tld"	<es:monitorSession>
	<es:notnull>	Camel case taglib uri="es.tld" Attribute id = item Attribute item must be a runtime expression. An empty string is now treated as a value. (An empty string is not null.)	<es:notNull>
	<es:preparedstatement>	Camel case taglib uri="es.tld" Add two new scriptlets. See below - Note 4: <es:preparedStatement>. Attribute pool no longer supported. See below - Note 4: <es:preparedStatement>.	<es:preparedStatement>
	<es:simplereport>	Camel case taglib uri="es.tld" Attribute resultSet must be a runtime expression.	<es:simpleReport>
	<es:transposearray>	Camel case taglib uri="es.tld" Attribute array must be a runtime expression.	<es:transposeArray>
	<es:usertransaction>	Tag no longer supported. Replace with new scriptlets. See below - Note 5: <es:usertransaction>.
	<es:uricontent>	Camel case taglib uri="es.tld"	<es:uriContent>
WLS Utilities	<wl:process>	taglib uri="weblogic.tld" notname = notName notvalue = notValue	<wl:process>
	---	New	<wl:repeat>

Additional Notes About JSP Tags

Note 1: <pz:> tags

To use the <pz:div> and <pz:contentSelector> tags, you no longer need to have the JSP extended. You are no longer required to insert the following directive into your code:

 <%@ page extends="com.beasys.commerce.axiom.p13n.jsp.P13NJspBase" %>.

(If you have already added this code, it does no harm to leave it.)

Note 2: <es:condition>

The <es:condition> tag is no longer supported. Replace it manually with a scriptlet, creating your own if statement.

Old Usage

<es:condition test="schemaPortletNames.length>0"> </es:condition> 

New Usage

<% if (schemaPortletNames.length>0) { %>
<% } %> 

Note 3: <es:counter>

If you were manipulating the counter variable within the <es:counter> tag, you will now need to use a scriptlet instead.

Old Usage

<es:counter id="colIter" minCount="0"
maxCount="<%=numOfCols%>">
colIter++;
</es:counter>

New Usage

<% 
for (int colIter = 0; colIter<numOfCols; colIter++) { 
colIter++; 
} 
%>

Note 4: <es:preparedStatement>

The new <es: preparedStatement> tag includes two new scriptlets. In addition, this tag no longer supports the "pool" attribute. (The pool defined in commerce.propeties as "commerce.jdbc.pool.name" is used for connections.)

Old Usage

<es:preparedstatement id="ps" sql"<%=bookmarkBean.QUERY%>" pool="commercePool">
<%
    bookmarkBean.createQuery(ps, owner);
    java.sql.ResultSet resultSet = ps.executeQuery();
    bookmarkBean.load(resultSet);
%>
</es:preparedstatement>

New Usage

<es:preparedStatement id="ps" sql="<%=bookmarkBean.QUERY%>">
<%@ include file="startPreparedStatement.inc" %>
<%
    bookmarkBean.createQuery(ps, owner);
    java.sql.ResultSet resultSet = ps.executeQuery();
    bookmarkBean.load(resultSet);
%>
<%@ include file="endPreparedStatement.inc" %>
</es:preparedStatement>

Note 5: <es:usertransaction>

The old <es:usertransaction> tag is no longer supported. The following code illustrates how to create equivalent functionality.

Old Usage

<es:usertransaction> 
---- body of page -------- 
</es:usertransaction> 

New Usage

<% 
setSessionValue(com.beasys.commerce.axiom.jsp.JspConstants.
USER_TRANS_TIMEOUT, "500",request);
// tx timeout defaults to 600 sec. without above line 
%> 
<%@ include file="startUserTransaction.inc" %> 
---- body of page -------- 
<%@ include file="endUserTransaction.inc" %>