FemtoWeb/Actions

From LoadingByte Wiki
Jump to navigation Jump to search

Action classes are the core heart of FemtoWeb. When a user makes a request, the request isn't handled by a dynamic page like a JSP. Instead, FemtoWeb executes the action class which is mapped to the requested URI. That action class can then do everything related to logic. Finally, the action hands the request over to a view (like JSP) in order to display the page.

Request Flow

The following diagram depicts the flow of a request through the FemtoWeb system, which is described above:

        Client         ┆                 Server
                       ┆
                       ┆
User ──── Request ───▶ ┆ FemtoWeb Filter ────▶ Action ────▶ JSP
  ▲                    ┆                                     │
  └────── Response ─── ┆ ────────────────────────────────────┘
                       ┆

As you can see, the action has a chance to process the request before the JSP even starts rendering the final HTML output. The action could, for example, do the following things:

  • Parse request parameters (e.g. ...?product=FemtoWeb&page=2)
  • Read values from a database
  • Do calculations
  • "Push" any results, so they can be used by the JSP through the EL language

Architecture

Each action class must somehow implement the com.quartercode.femtoweb.api.Action interface. In most cases, you want to extend the com.quartercode.femtoweb.api.ActionSupport class, because it already provides lots of useful methods and fields (e.g. to make pushing easier).

Action Base Package

All action classes must be located in the so called "action base package" or a subpackage of it. It can be configured in the web.xml, see the setup page. Each active action is automatically mapped to a URI. The following examples explain the way the mapping works if the base package is configured to com.quartercode.mywebapp.actions:

Action class URI
com.quartercode.mywebapp.actions.IndexAction /index
com.quartercode.mywebapp.actions.LoginAction /login
com.quartercode.mywebapp.actions.products.ViewAction /products/view
com.quartercode.mywebapp.actions.products.edit.BasicAction products/edit/basic
com.quartercode.mywebapp.actions.Home This class isn't an action because it doesn't end with "Action"
com.quartercode.mywebapp.util.StringUtils This class isn't an action because it is located outside the action base package

Note that you can also disable action classes by annotating them with the @com.quartercode.femtoweb.api.IgnoreAction annotation. Inactive actions are not reachable from the outside. They are treated like pure Java classes which don't implement the Action interface.

Usage

Important: Most likely, you don't want to implement actions without any of the useful methods and fields ActionSupport offers. In that case, visit the page about ActionSupport and ignore the following section.

Creating a new action is quite easy. You just have to create a new class called XyzAction (of course, Xyz can be freely chosen) somewhere in the action base package or a subpackage of it. The new class must implement the Action interface:

public class XyzAction implements Action {

    @Override
    public Action execute(HttpServletRequest request, HttpServletResponse response, Context context) throws Exception {

        // Do stuff ...

        return new View(getClass(), "xyz.jsp");
    }

}

Behavior

The method execute(...) is called each time a user makes a request to the URI the action is mapped to. Note that a new instance of the action class is created for each request as well. The execute method should do everything that is required for the final JSP to work (e.g. contact the database, parse parameters, "push" request attributes) and then return a resolution (in most cases, a View).

Visit the pages about resolutions and ActionSupport for more information and tips related to creating actions. This section is so short because only a small portion of people really want to code raw actions.