Datasheet

identification number). This attribute name prevents namespace collision with other portlets storing their
session variables with similar names.
Despite having a special system for naming its attributes,
PORTLET_SCOPE doesn’t protect its attributes
from other Web components. In addition, the namespace application is done completely under the hood.
You just call
getAttribute and setAttribute specifying PORTLET_SCOPE and the namespace conver-
sion is done by the
PortletSession object. To make it even more convenient, other Web components
can receive this feature through the
PortletSessionUtil.decodeAttribute method by passing the
simple attribute name, such as “city.name”.
Calling JSPs and Servlets
Because portlet applications are a complementary extension to Web applications, there must be a
mechanism to include Java Server Pages and servlets in a portlet. Upon first examination of the
GenericPortlet class, many Web developers cringe and think, “Oh, no! We are back to the old
servlet days of embedding markup!” However, much like servlet developers found using a
RequestDispatcher helpful in avoiding the “all your eggs in one basket” problem of placing all of
your markup in your servlet, or all of your Java code in a JSP, a portlet developer can use a
PortletRequestDispatcher.
When implementing the
render method of the Portlet interface or, more likely, implementing one of
the “do” methods of the
GenericPortlet class (for example, doView, doEdit, and so on), the devel-
oper can use a
PortletRequestDispatcher as follows:
String reqPath = “/calView.jsp”;
PortletRequestDispatcher prd = portContext.getRequestDispatcher(reqPath);
prd.include(req, resp);
In this case, we have specified our JSP, calView.jsp, which is located in the root of the portlet applica-
tion, which we refer to with a leading slash. You must always start the path with a leading slash, and
provide a path from the
PortletContext root (usually the root directory of your portlet application).
From there, you get a
PortletRequestDispatcher (prd) from your PortletContext (portContext).
Then you pass your
RenderRequest (req) and your RenderResponse (resp) as parameters to the
include method of the PortletRequestDispatcher (prd).
Similarly, we can call a servlet by its declared name (in the Web application deployment descriptor, also
known as
web.xml). For example, we might have specified a servlet such as the following in the web.xml:
<servlet>
<servlet-name>chart</servlet-name>
<servlet-class>org.opensourceportals.ChartServlet</servlet-class>
<load-on-startup>0</load-on-startup>
</servlet>
Because we have named our servlet “chart,” we can specify it as follows:
String reqName = “chart”;
PortletRequestDispatcher prd = portContext.getNamedDispatcher(reqName);
prd.include(req, resp);
19
The Java Portlet API (JSR 168)
04 469513 Ch01.qxd 1/16/04 11:04 AM Page 19