Page History

Table of Contents

Related Documents

• Regions Guide
• JSP Tag Library Guide (need to move to the wiki)

Introduction

The Open For Business Controller is a group of classes use to manage the presentation of a web application designed around the Open For Business framework. The Controller is designed to work along with the Entity Engine by keeping a constant state with the Entity Delegator, as well as the Services Framework by keeping a state with the Local Service Dispatcher. The goal of the Controller is to provide a clean mechanism of separating presentation logic from the actual display.

This Controller makes use of several J2EE Presentation Tier design patterns. The Context Security Filter is modeled after the Decorating Filter pattern. The CSF runs at the context root and is able to restrict direct access to JSP templates as well as open doors for future services such as debugging, logging and compression. The Control Servlet is modeled after the Front Controller pattern. This Servlet is where the web application's request processing begins. It makes use of helper classes which process security and events, then dispatches to a defined view. The Views are JSP templates which are very similar to those described in the Composite View pattern. These templates use helper files to limit the amount of logic found in the actual display page. These helper files are Java classes which perform the logic for a specific group of views. This process is based on the View Helper pattern.    Note

As stated above, the main purpose of the Controller is to separate logic from display. This is accomplished by:

• Using a Filter to secure JSP template in the web application
• Using a Servlet to manage application flow
• Using Events (commands) and View Helpers for presentation logic

...

Context Security Filter

The Context Security Filter (CSF) defined in /WEB-INF/web.xml is used to restrict access to the web application files. In the future it may be used for debugging and/or logging requests. This is the starting point for all web requests to the application. By default all paths are rejected and only paths specifically defined are allowed direct access. The CSF is set to allow all requests to the Control Servlet by setting the mount point of the Servlet in the 'allow list'. The allow list is defined as an init-param named allowedPaths.The value is a single string of paths separated by a colon. The example webapps allow '/control:/index.html:/index.jsp:/default.html:/default.jsp:/images' paths. A path may be a directory name (starting from the root directory of the webapp) or a path to a specific file.

Example: '/images' will allow all files in the /images directory to be directly accessed.
Example: '/site-pages/contactus.html' will allow only the contactus.html file found in the /site-pages directory to be directly accessed.
Example: '/site-pages/info/*' will allow only the files in the subdirectory 'info' to be directly accessed.

When a direct request to a protected path is made the filter will do one of two things. One, the filter can redirect the user to a page defined in web.xml. This is defined by setting the init-param redirectPath to properly formatted URL. Two, the filter will throw a server error which can be defined by the init-param errorCode. The error is thrown only if there is no redirect defined. If no errorCode is defined, the filter will throw a 404 server error.

The configuration looks like this:

<filter> 
  <filter-name>ContextSecurityFilter</filter-name>
  <display-name>ContextSecurityFilter</display-name> 
  <filter-class>org.ofbiz.webapp.control.ContextSecurityFilter</filter-class>    
  <init-param> 
    <param-name>allowedPaths</param-name> 
    <param-value>/control:/index.html:/index.jsp:/default.html:/default.jsp:/images</param-value>    
  </init-param> 
  <init-param> 
    <param-name>errorCode</param-name>    
    <param-value>403</param-value> 
  </init-param> 
</filter>    
<filter-mapping> 
  <filter-name>ContextSecurityFilter</filter-name>    
  <url-pattern>/*</url-pattern> 
</filter-mapping> 

Control Servlet

Anchor
control servlet control servlet

The Control Servlet is at the heart of all request processing. Valid requests which pass through the Context Security Filter begin processing here. When a request is received, the Control Servlet first sets up an environment for the helper classes. This environment includes (but is not limited to) setting up an initial session object and storing useful information about the initial request and setting a reference to the Entity Delegator, Service Dispatcher, and Security Handler for use by the helper classes. The request is then passed to the Request Handler for processing. The Request Handler processes the request and  returns to the ControlServlet when finished.

When the Control Servlet is first loaded it will create objects used by the web application and store them in the application context (ServletContext). These objects can be found by accessing the property in the context or via a JSP <useBean> tag. These objects include: Entity Delegator, Security object, Service Dispatcher, and the Request Handler.

Request Handler

The Request Handler makes use of a RequestManager helper class to gather a list of request mappings defined in an XML configuration file. The configuration file lives in /WEB-INF/controller.xml for the appropriate context. The mapping consists of a request URI and an optional VIEW name. View names are mapped to in the configuration file as well. A request URI can also be associated with an Event. Events are used to process web related logic by either working directly with the Entity Engine through the Entity Delegator or invoking service(s) to handle the logic through the Service Dispatcher.

...

Java events are processed by locating the path of the event (package and classname); then, by using the Reflection API, the Event Handler invokes the method defined. A String object is returned to the Request Handler which is mapped to the response element of the request definition.

...