How to access page parameters from a WebSphere Portal theme


When editing a portal page, you can add custom page parameters (metadata) to the page. The value of a custom page parameter can then be retrieved from your theme code. This explains how.

First, you must add a custom parameter to one or more portal pages.

This is done in the Edit Page view > Advanced options > I want to set parameters.

You can then access the named parameters in your theme code.

Take the following parameter name for example:




Following is an example where this technique is used to determine whether or not a tab for a portal page should be rendered in the UI. This is taken from a theme file called topNav.jspf.


	boolean isPageHidden = false;

	ContentNodeType nodeType = wpsNavNode.getContentNode().getContentNodeType();

	if (wpsNavNode instanceof { iMetaData = (( wpsNavNode).getMetaData();
			Object hiddenValue = iMetaData.getValue("");
			if (hiddenValue != null && hiddenValue.toString().equalsIgnoreCase("true") ){
					isPageHidden = true;
	if (!isPageHidden) {


	<% } // end isPageHidden %>

Side Note

To access the custom unique name for the page, try this using the same wpsNavNode object that is shown as available within the portal-navigation loop above:

<%= wpsNavNode.getContentNode().getObjectID().getUniqueName() %>

A different approach

By using the <portal-logic:pageMetaData> tag we can obtain all the parameters on a page. The following example outputs a table with all names and values of the aggregated meta data of the current page.

<portal-logic:pageMetaData varname="pageMetaData">
    <c:forEach var="metaItem" items="${pageMetaData}">

Below is a similar snippet that is useful for setting one or more EL variables for use throughout the theme. With the following approach, one can use one parent label node or page to configure several parameters for the theme. This is, in my opinion, the very best way to make your theme configurable (that is to say, it's better than using properties files, resource environment providers, or custom JVM properties). In the code below, note that the request scope is used when setting variables, which is necessary if you want the variables to be shared amongst included JSP pages (the default page scope would make the EL variable applicable only to the current JSP and thus, unavailable to the others).

<portal-logic:pageMetaData varname="pageMetaData">
    <c:set var="myParam1" scope="request">
      <c:out value="${pageMetaData.myParam1}" default="some default value"/>
    <c:set var="myParam2" scope="request">
      <c:out value="${pageMetaData.myParam2}" default="some default value"/>
    <c:set var="myParam3" scope="request">
      <c:out value="${pageMetaData.myParam3}" default="some default value"/>
    <c:set var="myParam4" scope="request">
      <c:out value="${pageMetaData.myParam4}" default="some default value"/>
    <c:set var="myParam5" scope="request">
      <c:out value="${pageMetaData.myParam5}" default="some default value"/>

<!-- Then, later in the theme, one one of these can be used in JSTL tags or just as EL variables. For example: -->

	<li>My Parameter 1: ${myParam1}</li>
	<li>My Parameter 2: ${myParam2}</li>
	<li>My Parameter 3: ${myParam3}</li>
	<li>My Parameter 4: ${myParam4}</li>
	<li>My Parameter 5: ${myParam5}</li>

A good place to put the code above is in a head.jspf file, which can be included just after the bootstrap.jspf file in Default.jsp. For example:

<%@ include file="./bootstrap.jspf" %><%@ include file="./head.jspf" %>

The <portal-logic:pageMetaData> tag is used to access meta data of the currently rendered page. The tag will also access meta data that is inherited by the currently rendered page from a parent page. The tag has two attributes:

varname - mandatory and specifies the name of the variable that exposes the meta data inside the body of the tag. The variable provides an object that implements
type - optional. Allowed values are direct and aggregated. The value aggregated is the default. If the type attribute is set to direct, only the meta data specifically set for the page are exposed, otherwise the meta data of the page as provided by the content meta data model are used.

The Content meta data model is described in more detail in the Model SPI overview topic.

Note that this tag will only give you the page meta for the currently active page (the one the user is on), so it is not useful for setting parameters to retrieve from multiple pages in a navigation loop.To do that, you can add the following snippet inside the class of the navigation's HTML element (such as the li tag):

<c:if test="${node.metadata['baselineTheme.cssClass'] != null}"> ${node.metadata['baselineTheme.cssClass']}</c:if>

For example, in the dynamicSpots/navigation.jsp file of a Portal theme or greater, you could modify the original stanza so it includes that snippet like this:

<c:if test="${!node.metadata['']}">
	<li class="wpthemeNavListItem wpthemeLeft<c:if test="${wp.selectionModel[node] != null}"> wpthemeSelected</c:if><c:if test="${node.metadata['baselineTheme.cssClass'] != null}"> ${node.metadata['baselineTheme.cssClass']}</c:if>">
		<a href="?uri=nm:oid:${nodeID}"><c:choose><c:when test="${wp.selectionModel[node] != null}"><strong><span lang="${node.title.xmlLocale}" dir="${node.title.direction}"><c:out value="${node.title}"/><c:if test="${selectedNodeID == nodeID}"><span class="wpthemeAccess"> <portal-fmt:text key="currently_selected" bundle="nls.Theme"/></span></c:if></span></strong></c:when><c:otherwise><span lang="${node.title.xmlLocale}" dir="${node.title.direction}"><c:out value="${node.title}"/></span></c:otherwise></c:choose></a>

If the baselineTheme.cssClass parameter exists on the page node that we're iterating over, then the value of that parameter will be rendered inside the value of the li tag's class attribute.

Enterprise Solution Architecture
Cody Burleson is an Enterprise Web Architect, entrepreneur, and writer. He designs and builds solutions with his team at Base22 using IBM WebSphere Portal, IBM Web Content Manager, IBM Connections, and Java/J2EE. He is a tireless student of information technology who loves to invent things, improve things, and share what he learns. You can find more at his blog,