This page tries to summarize the key aspects of the Jaffa Presentation layer. This is done from a 'how does this differ from Struts' perspective, since at the core of the Jaffa Presentation layer is the Struts MVC architecture. We've just added pieces to it to solve specific issues with building rapid web applications

The PortletServlet is the front controller servlet for the Jaffa Presentation Layer.

• Replaces the standard struts ControlServlet for mapping *.do files

• Sets the locale on the request thread, so that any widgets, parsers or formatters that are based on locale can use this information

• Sets the 'variation' on the request thread for use when the rules engine is invoked.

• Switches the thread of execution to run within the security context defined for this user. This is needed so that and code protected via the Jaffa Security Manager can use this context to see if the code may be executed

• Performs UserSession validation and initialization (deprecated, as of v1.2 use the UserSessionFilter)

  <!-- Standard Action Servlet Configuration (with debugging) -->
  <servlet>
    <servlet-name>action</servlet-name>
    <servlet-class>org.jaffa.presentation.portlet.PortletServlet</servlet-class>
    <init-param>
      <param-name>application</param-name>
      <param-value>ApplicationResources</param-value>
    </init-param>
    <init-param>
      <param-name>config</param-name>
      <param-value>/WEB-INF/struts-config.xml</param-value>
    </init-param>
    <init-param>
      <param-name>debug</param-name>
      <param-value>0</param-value>
    </init-param>
    <init-param>
      <param-name>detail</param-name>
      <param-value>0</param-value>
    </init-param>
    <init-param>
      <param-name>validate</param-name>
      <param-value>true</param-value>
    </init-param>
    <init-param>
      <param-name>listings</param-name>
      <param-value>false</param-value>
    </init-param>
    <load-on-startup>3</load-on-startup>
  </servlet>

StartComponentAction is an Action class that we use as the main entry point for executing a Component.

http://localhost:8080/SampleApp/startComponent.do?component=Jaffa.SessionExplorer&finalUrl=jaffa_closeBrowser

The Key Features of the StartComponentAction are...

• Action bean normally called with /startComponent.do?component=

• Consumes any special other parameters in the URL (like finalUrl=)

• Lookup up a logical name for a component (from components.xml)

• Validates security access to the component

• Create an instance of the component controller

• Reflects any other URL parameters onto the 'getters' of the component

• Invokes the display() method of the component

A FormKey is an object that represents an instance of a form object. With JAFFA we allow for an application to run two independent copies of the same web page (aka component) within the same session. It is therefore not enough for us to just know the form name of the page when we process requests, we also need to know the component id.

To make the coding simple we made an object FormKey that contains both these fields. When we render JSP's the <Portlet:Form> tag embeds the component id in the page, so on a re-post we know which instance of the form to process.

The component model is based around these FormKeys. When you start a component it tries to execute the display() method which returns a FormKey to indicate what form should be displayed for this component.

All of the do_xx_xx() methods in the Action Classes also return a FormKey to indicate the next page to be displayed on return from handling the event.

public FormKey do_Close_Clicked() {
    return component.quitAndReturnToCallingScreen();
}

public FormKey do_Refresh_Clicked() {
    return new FormKey(MyFormBean.NAME, component.getComponentId());
}

In JAFFA, we typically use 'request' scope for FormBeans, that means they hold no state between requests. The reason for this as mention in the 'FormKey' section is that we allow multiple instances of the same form, so storing the form in the HttpSession with just the formname as a key is not a viable option.

So, as we re-create the FormBean, we don't want to have to rebuild the widget models, which in the case of things like a UserGrid many contain thousands of inner widgets. So, to avoid this we provide a component instance based widget cache which stores the widgets models for the form bean in the UserSession object.

The key features of the widget cache are ...

• Stored in UserSession
• There is one cache per component instance (componentId)
• Within the cache each widget needs a unique name
• The FormBase exposes a convenient interface for adding and reading component from the cache

This is a typical example of a widget using the cache. In this case if the widget does not exits, it looks for it in the cache. If its not cached, it gets constructed and stored in the cache for next time.

public GridModel getSessionsWM() {
  if (w_sessions == null) {
    w_sessions = (GridModel) getWidgetCache().getModel("sessions");
    if (w_sessions == null) {
      w_sessions = createSessionsModel();
      getWidgetCache().addModel("sessions", w_sessions);
    }
  }
  return w_sessions;
}

Note: The name used to store the object in the cache is unique to that component instance. What this means is that if a given component has multiple JSP's (and FormBean) associated with it and you want to share widget models across pages, you can by using the same name. HOWEVER, if you accidentally use the same field name on two forms in the same component and use the same name to cache them, you will get huge problems with the most recent post overwriting that of the other form. If they are the same name and different models, chances are you start getting ClassCastExceptions!