Portal Framework

eXo PC 2.0 Portal Framework

1 Overview

To help customers develop their own portals easier and faster, there's eXo 2.0 portal framework. It contains a set of methods that a customer can use as blocks when creating his portal.

eXo PC 2.0 portal framework consists of the main class PortalFramework and a few helper classes. The class PortalFramework is an interface class of the eXo PC 2.0 portal framework. Before other actions we must create an instance of the class and then we may use its features. Below I will describe the step by step using of the portal framework and the process of portal building.

2 Preparation

2.1 Creation/initialization

Every time we invoke doFilter() (if we're in filter) or service() (if we're in servlet), we create/get and reinitialize our instance of the PortalFramework class. Instances should be different for each HTTP session.

We have these lines among class field definitions:

ThreadLocal frameworks = ...;
PortalFramework framework;

framework = (PortalFramework) frameworks.get();
if (framework == null) {
  framework = new PortalFramework(portalContainer);
  frameworks.set(framework);
}
framework.init(httpSession);

2.2 Setting/parsing parameters

So, now we want to use some parameters that our AS got from URL or form submission in the current HTTP request.

The next call used retrieves and parses request parameters from the HTTP request and also sets a mark-up type.

framework.setParams(httpRequest, "text/html");

3 Request processing

There's the place where we actually do the things we finally wanted to be done. Here we can learn what exact request we have just gotten from a user. The next piece of code shows us how to distinguish an action type:

if (framework.getAction() == Constants.resourceInt) {
  // resource request processing
  [..] 
} else if (framework.getAction() == Constants.actionInt) {
  // action request processing
  [..] 
}
if (framework.getAction() == Constants.renderInt) {
  // render request processing
  [..] 
}

How exactly we must act with all those actions, I'll decribe below in the appropriate parts of this review.

3.1 Resource URL processing

In fact all that we have to do in this part is to create a resource input object, to call the serveResource method of the target portlet and to get content generated by the portlet.

ResourceInput resourceInput = framework.createResourceInput(servletContext);
ResourceOutput resourceOutput = framework.serveResource(httpRequest, httpResponse, resourceInput);
String resourceData = new String(resourceOutput.getContent());

Or we can write even more beautiful and safe code like this:

String resourceData = "";
ResourceInput resourceInput = framework.createResourceInput(servletContext);
try {
  ResourceOutput resourceOutput = framework.serveResource(httpRequest, httpResponse, resourceInput);
  try {
    resourceData = new String(resourceOutput.getContent());
  } catch (Exception e) {}
} catch (Exception e1) {
  logger.error("error invoking serveResource() in " + framework.getTarget() + ": " + e1);
}

That's all! By now we have the resource call already processed! That's quite simple, isn't it?

3.2 Action URL processing

With the action URLs the things are even more simple. Here we don't need to retrieve any content or feedback.

ActionInput actionInput = framework.createActionInput(servletContext);
try {
  ActionOutput actionOutput = framework.processAction(httpRequest, httpResponse, actionInput);
} catch (Exception e) {
  logger.error("error invoking processAction() in " + framework.getTarget() + ": " + e);
}

3.3 Event processing

After we have called the serveResource() and/or processAction() method, we may want to process events generated by the target portlet while action/resource processing.

framework.dispatchEvents(servletContext, httpRequest, httpResponse);

3.4 Acting if we need to redirect

Some portlet calls may cause necessity to redirect. We can check this case and act in the appropriate way.

if (framework.getRedirect() != null) {
  httpResponse.sendRedirect(framework.getRedirect());
  // if we're in filter
  filterChain.doFilter(servletRequest, servletResponse);
  return;
}

3.5 Reflecting changes

serveResource() call may generate new events. processEvent() in its turn may do the same thing. It means that clicking the one and the only resource link on portal page a user can change states of a number of portlets simultaneously. If we want to dynamically reflect these changes, we can get a list of changed portlets in such a way:

Set keys = framework.getChanges();

to re-render them and renew their contents on the portal page.

3.6 Collecting all portlets

On the other hand, if we are inside render or action link processing, we may want to render the whole portal page. In this case we want to get a list of all registered portlets.

Set keys = framework.getPortletNames();

3.7 Render itself

And here, when we have at last gotten the list of portlets we want to render, we do that! Again we do that in the safe way catching exceptions ;-)

Iterator portlets2render = keys.iterator();
while (portlets2render.hasNext()) {
  String portlet = (String) portlets2render.next();
  String renderData = "";
  RenderInput renderInput = framework.createRenderInput(ctx, portlet);
  try {
    RenderOutput renderOutput = framework.render(httpRequest, httpResponse, renderInput);
    try {
       renderData = new String(renderOutput.getContent());
    } catch (Exception e) {}
  } catch (Exception e1) {
    logger.error("error invoking render() in " + framework.getTarget() + ": " + e1);
  }
[..]
}