WebLogic Portal 8.1 Service Pack 2 has been out for several months. By the time this article is published, Service Pack 3 may also be out. Having worked on a couple of WebLogic Portal projects with this version, I have come across several small and large issues.
This article will provide several tips and tricks to solve these problems, with appropriate code snippets to help Portal developers. Please note that several of these snippets can be found on the BEA newsgroup and/or as part of the BEA WebLogic Portal samples that come with the WebLogic Platform download. However, I have taken most of those snippets and modified them to suit the use cases that I will apply them to in this article. So let's jump right in...
Tip 1: Log in to Your Portal The BEA samples kit provides several login examples. There are a few things to bear in mind when choosing the login type that you want: Do you want to support automatic login using cookies, login using a controller or a backing file, etc.? One thing to remember is that you always want the portal to refresh after login, so that entitlements can kick in. The two samples worth looking at are the AutoLoginBacking.java and the LoginBacking.java file under the tutorial portal directory. I like using a backing file for the login process so that I can perform an automatic login, and other login checks regardless of the exact page URL that the user bookmarks. Listing 1 shows AutoLoginBacking.java. I have taken the original AutoLoginBacking.java provided by BEA and merged it with the LoginBacking.java. I had some issues with deleting the cookies on logout. You will see a complete working implementation in this example (the code for this article is online at www.sys-con.com/weblogic/sourcec.cfm).
Tip 2: Working with Portlet Maximize and Minimize You will often feel the need to control the maximizing and minimizing behavior of your portlets. I'll show you a single snippet of code that can be tweaked for almost all scenarios where you need to do this. Let's look at the code and then I will talk about when and where to use this.
The first thing you need to do is get a PortletBackingContext:
PortletBackingContext context = PortletBackingContext.getPortletBackingContext(request);
On the context object you can do things like change the mode (View Mode or Edit Mode), or change the state (Normal, Minimized, or Maximized). You will need code such as
context.setupModeChangeEvent(WindowCapabilities.VIEW.getName()); context.setupStateChangeEvent(WindowCapabilities.MAXIMIZED.getName());
You can also hide the buttons programmatically. For example, to hide the maximize button, you can use the following code:
context.setCapabilityVisible(WindowCapabilities.MAXIMIZED, getName(), false);
The lines of code shown above are all you need to work with the state, mode, and visibility of your portlets. I have used them from backing files as well as controllers. For example, consider the following use cases.
- You have four pages, each with some portlets. Let's say the user is on Page 1, and they maximize a Portlet. Then they go to Page 2. When they come back to Page 1, by default the Portlet that was maximized will remain maximized. If you want it to be restored, you will need to use a backing file at the page or Portlet level.
- You have enabled the EDIT button on the Portlet title bar. If you want the edit page to always show in a maximized view, again you will need a backing file. In this case, you will need to check the mode and if the mode is EDIT, you will need to maximize the portlet. Similarly, if the mode is VIEW, you will need to restore the portlet to its original state.
- You don't want to show the maximize button to the user, but you still support use case 2 above. In this case, you cannot turn off the maximize capability, but you can hide the icon using the code above.
- You can also use this code in the beforeAction() and afterAction() methods of your controller to control the behavior of your portlets.
Tip 3: Refresh Action for Controllers In Service Pack 2, a patch was released that forced the controller to re-execute each time the page was refreshed. Without this patch, a controller would not get executed on a refresh (patch number CR129301 from BEA). I recommend getting this patch, as you will almost surely need it. Hopefully this will be part of Service Pack 3.
Tip 4: IconUrl in JSR 168 Portlets You cannot use the iconUrl property in WebLogic Workshop to set a graphic in the titlebar for a JSR 168 portlet. You need to do it by editing the weblogic-portlet.xml file. See the code snippet below.
<portlet>
<portlet-name>myPortlet</portlet-name>
<supports>
<mime-type>text/html</mime-type>
<titlebar-presentation>
<id>jsr-titlebar</id>
<icon-url>window-icon.gif</icon-url>
</titlebar-presentation>
</portlet>
Tip 5: DotPortal Versus Streaming Mode The basic difference between these modes is whether you read the portal definitions from the XML files that are bundled in the EAR or whether you read them from the database. It is a good idea to deploy in streaming mode so that you can define entitlements for your portlets. Also, in streaming mode you have dynamic control of the layout of the portlets, look and feel, and other such user attributes.
From a development standpoint, the real tip here is to keep all your URLs relative. In streaming mode all the URLs will change so you need to watch out for that. Here is a code snippet you can use to check whether you are in the DotPortal or Streaming mode.
<%@ page import="com.bea.netuix.servlets.manager.AppContext"%>
if (session.getAttribute("DOT_PORTAL") == null)
{
AppContext appContext = AppContext.getAppContext(request);
if (appContext.isDotPortal())
{
session.setAttribute("DOT_PORTAL", new Boolean(true));
}
else
{
session.setAttribute("DOT_PORTAL", new Boolean(false));
}
}
Summary This article provides some simple tips and tricks for common issues that I faced when building a portal application. Many of these are related to patches and bugs that should be a part of Service Pack 3. Others are just simple tweaks based on your specific use cases. |