<?xml version="1.0" encoding="UTF-8"?>
<portal:root
xmlns:netuix=" xmlns:portal=" xmlns:xsi=" xsi:schemaLocation="http://www.bea.com/servers/netuix/xsd/portal/support/1.0.0 portal-support-1_0_0.xsd">
<netuix:javaPortlet
definitionLabel="first" title="First"/>
</portal:root>
<portlet:actionURL var="aURL">
<portlet:param name="cmd" value="LOGOUT" />
</portlet:actionURL>
<form action="<%= aURL %>" method="post">
public void processAction(ActionRequest aRequest, ActionResponse aResponse)
throws PortletException, IOException
{
HttpServletRequest aHttpServletRequest = (HttpServletRequest) aRequest.getAttribute("javax.servlet.request");
String aCommand = aRequest.getParameter("cmd");
}
request.getParameter("");
public void doView(RenderRequest aRequest, RenderResponse aResponse)
throws PortletException, IOException
{
String aUser = aRequest.getRemoteUser();
PortletRequestDispatcher aDispatcher = null;
if (aUser == null) {
aDispatcher = getPortletContext().getRequestDispatcher(
"/LoginLogoutPortlet/login.jsp"
);
aResponse.setTitle("Login");
} else {
aDispatcher = getPortletContext().getRequestDispatcher(
"/LoginLogoutPortlet/logout.jsp"
);
aResponse.setTitle("Logout");
}
aDispatcher.include(aRequest, aResponse);
}
Any object stored in the session using the APPLICATION_SCOPE is available to any other
portlet that belongs to the same portlet application and that handles a request identified as
being a part of the same session.
PortletSession session = request.getSession(true);
URL url = new URL(?°http://www.foo.com?±);
session.setAttribute(?°home.url?±,url,PortletSession.APPLICATION_SCOPE);
session.setAttribute(?°bkg.color?±,?±RED?±,PortletSession.PORTLET_SCOPE);
<!?a- Portlet Preferences -->
<portlet-preferences>
...
<validator>com.foo.portlets.XYZValidator</validator>
</portlet-preferences>
<portlet>
...
<!?a- Portlet Preferences -->
<portlet-preferences>
<preference>
<name>PreferredStockSymbols</name>
<value>FOO</value>
<value>XYZ</value>
<modifiable>0</modifiable>
</preference>
<preference>
<name>quotesFeedURL</name>
<value>http://www.foomarket.com/quotes</value>
</preference>
</portlet-preferences>
</portlet>
PortletPreferences prefs = req.getPreferences();
String[] symbols = prefs.getValues(?±preferredStockSymbols?±,new String[]{?±ACME?±,?±FOO?±});
String url = prefs.getValue(?±quotesFeedURL?±,null);
int refreshInterval = Integer.parseInt(prefs.getValue(?±refresh?±,?±10?±));
<select name="contactPreference" size="1">
<option>Email</option>
<option>FAX</option>
<option>Phone</option>
<option>Mail</option>
</select>
String aValue = aRequest.getParameter("contactPreference");
sLogger.info("selected contact preference is:\t" + aValue);
if ((aValue != null) && (!"".equals(aValue.trim()))) {
PortletPreferences aPreferences = aRequest.getPreferences();
aPreferences.setValue("contact-preference", aValue);
aPreferences.store();
}
...
PortletURL url = response.createActionURL();
url.addParameter(?°paymentMethod?±,?±creditCardInProfile?±);
url.setWindowState(WindowState.MAXIMIZED);
writer.print(?°<FORM METHOD=\?±POST\?± ACTION=\?±?±+ url.toString()+?±\?±>?±);
...
Using the setRenderParameter and setRenderParameters methods of the
ActionResponse interface portlets may set render parameters during an action request.
These parameters will be used in all subsequent render requests until a new client request
targets the portlet. If no render parameters are set during the processAction invocation,
the render request must not contain any request parameters.
Portlet developers do not need to ?°x-www-form-urlencoded?± encode render parameters
names and values set in the ActionResponse.
setPortletMode
setWindowState
All backing files are executed before and after the JSP is called. In its lifecycle, each backing file calls these methods:
init()
handlePostBackData()
raiseChangeEvents()
preRender()
dispose()
On every request, the following occurs:
All init() methods are called on all backing files on an "in order" basis (that is, in the order they appear in the control tree; for more information on the control tree and its lifecycle please see Controls in the white paper). This method gets called whether or not the control (that is, portal, page, book, or desktop) is on an active page.
Next, if the operation is a postback and the control (a portlet, page, or book) is on a visible page, all handlePostbackData() methods are called. In other words if portlet is on a page but its parent page is not active, then this method will not get called.
If _nfpb="true" is set in the request parameter of any handlePostbackData() methods called, raiseChangeEvents() is called. This method causes events to fire.
Next, all preRender() methods are called for all controls on an active (visible) page.
Next, the JSPs get called and are rendered on the active page by the <render:beginRender> JSP tag. Rendering is stopped with the <render:endRender> tag.
Finally, the dispose() method gets called on the backing file.
Add the Struts application to the portal Web project.
Copy any JSP, HTML, or image files into the portal Web project following the standard Struts module directory structure (the module path is the directory path relative to the Web application root).
Copy any supporting Java source used by the Struts application into the project's WEB-INF/src.
Copy any necessary custom JARs for the Struts application into WEB-INF/lib.
Copy the Struts application's struts-config.xml or module configuration file into WEB-INF, but rename it struts-auto-config-<module-path>.xml, where <module-path> is the module path to the Struts application relative to the Web application root, with all instances of '/' or '\' changed to '-'.
For example, if the module path is /struts/my/module, struts-config.xml should be renamed to struts-auto-config-struts-my-module.xml. Naming the module configuration file in this manner enables the PageFlowctionServlet used as the Action Servlet to automatically register the module without explicitly registering it with an init-param in web.xml. If you don't want to take advantage of this functionality, you can rename struts-config.xml arbitrarily, but you must manually register the module in web.xml as usual for a Struts 1.1 module.
In the module configuration file, add the following line to configure the RequestProcessor that is required for portal integration:
<controller processorClass="com.bea.struts.adapter.action.AdapterRequestProcessor"/>
(unless the Struts application requires a custom RequestProcessor).
<portlet>
...
<expiration-cache>300</expiration-cache>
...
</portlet>
...
Map userInfo = (Map) request.getAttribute(PortletRequest.USER_INFO);
String givenName = (userInfo!=null)
? (String) userInfo.get(“user.name.given”) : “”;
String lastName = (userInfo!=null)
? (String) userInfo.get(“user.name.family”) : “”;
...
<portlet-app>
…
<user-attribute>
<description>User Given Name</description>
<name>user.name.given</name>
</user-attribute>
<user-attribute>
<description>User Last Name</description>
<name>user.name.family</name>
</user-attribute>
<user-attribute>
<description>User eMail</description>
<name>user.home-info.online.email</name>
</user-attribute>
<user-attribute>
<description>Company Organization</description>
<name>user.business-info.postal.organization</name>
</user-attribute>
…
<portlet-app>
<portlet-app>
...
<portlet>
...
<security-role-ref>
<role-name>FOO</role-name>
<role-link>manager</manager>
</security-role-ref>
</portlet>
...
...
</portlet-app>
<portlet-app>
...
<portlet>
<portlet-name>accountSummary</portlet-name>
...
</portlet>
...
<security-constraint>
<display-name>Secure Portlets</display-name>
<portlet-collection>
<portlet-name>accountSummary</portlet-name>
</portlet-collection>
<user-data-constraint/>
<transport-guarantee>CONFIDENTIAL</transportguarantee>
</user-data-constraint>
</security-constraint>
...
</portlet-app>
Implementation-Title: myPortletApplication
Implementation-Version: 1.1.2
Implementation-Vendor: SunMicrosystems. Inc.
? RenderRequest renderRequest
? RenderResponse renderResponse
? PortletConfig portletConfig
<portlet:actionURL state=”maximized” portletMode=”edit”>
<portlet:param name=”action” value=”editStocks”/>
</portlet:actionURL>
The example creates a URL that brings the portlet into EDIT mode and MAXIMIZED
window state to edit the stocks quote list.
<portlet:renderURL mode=”view” windowState=”normal”>
<portlet:param name=”showQuote” value=”myCompany”/>
<portlet:param name=”showQuote” value=”someOtherCompany”/>
</portlet:renderURL>
The example creates a URL to provide a link that shows the stock quote of myCompany
and someOtherCompany and changes the portlet mode to VIEW and the window state to
NORMAL.
<portlet-app>
...
<custom-portlet-mode>
<description>Creates content for Cut and Paste</description>
<name>clipboard</name>
</custom-portlet-mode>
<custom-portlet-mode>
<description>Provides administration functions</description>
<name>config</name>
</custom-portlet-mode>
...
</portlet-app>
PortletURL url = response.createRenderURL();
url.addParameter(“customer”,”foo.com”);
url.addParameter(“show”,”summary”);
writer.print(“<A HREF=\””+url.toString()+”\”>Summary</A>”);
...
PortletURL url = response.createActionURL();
url.addParameter(“paymentMethod”,”creditCardInProfile”);
url.setWindowState(WindowState.MAXIMIZED);
writer.print(“<FORM METHOD=\”POST\” ACTION=\””+ url.toString()+”\”>”);
...
The portlet API defines the PortletURL interface. Portlets must create portlet URLs
using PortletURL objects. A portlet creates PortletURL objects invoking the
createActionURL and the createRenderURL methods of the RenderResponse interface.
The createActionURL method creates action URLs. The createRenderURL method
creates render URLs.
Because some portal/portlet-containers implementations may encode internal state as part
of the URL query string, portlet developers should not code forms using the HTTP GET
method.
A render URL is an optimization for a special type of action URLs. The portal/portletcontainer
must not invoke the processAction method of the targeted portlet.
Render URLs should not be used within forms as the portal/portlet-container may ignore
form parameters.
Render URLs should not be used for tasks that are not idempotent from the portlet
perspective. Error conditions, cache expirations and changes of external data may affect
the content generated by a portlet as result of a request triggered by a render URL.
Render URLs should not be used within forms as the portal/portlet-container may ignore
form parameters.
Portlets can add application specific parameters to the PortletURL objects using the
addParameter method. All the parameters a portlet adds to a PortletURL object must be
made available to the portlet as request parameters.xxviii It is the responsibility of portlet
developers to "x-www-form-urlencoded" encoding parameter names and values when
necessary. If a portal/portlet-container encodes additional information as parameters, it
must encode them properly to avoid collisions with the parameters set and used by the
portlet.xxix
Using the toString method, a portlet can obtain the string representation of the
PortletURL for its inclusion in the portlet content.
Portlet developers should be aware that the string representation of a PortletURL may not
be a well formed URL but a special token at the time the portlet is generating its content.
Portal servers often use a technique called URL rewriting that post-processes the content
resolving tokens into real URLs.