Due to the fact, that the framework is designed to run in bootstrap mode, all content is delivered
with one single file. The more modules an application consists of, the greater is the desire to
deliver also popup windows content or media files with this mechanism. Merely, the popup windows
contain print views or forms or media files like PDF or ZIP files.

To achieve this goal, another bootstrap file can be created, that handles the different kind of
requests. Unfortunately, this procedure generates code redundancy.

With aid of the front controller, exacting front controller actions, the problem of redundant code can be solved
clearly. The timing model of the front controller's dispatching process allows you to execute a front controller
action before the page controller page is created (TYPE_PRE_PAGE_CREATE, see Front controller).
Thereby, the developer can decide himself, whether the requested page (including the front controller action call)
is displayed within the current browser window or in a now one. Another advantage is, that the program code
responsible for the additional content can be delivered directly with the module package. This does not only lead
to a better code quality but also the delivery is made easier. Further, within an front controller action a
page controller page can be created and displayed.

As described in the front controller documentation, a front controller action is described by a
section in the action configuration file. The configuration includes the definition of the location
and name of the action and input class implementation. The complexity of the input class depends on
the amount of the application's code or the tasks to be done. The socialbookmark
module, that is delivered with each release, contains a action, that is intended do deliver the
bookmark provider symbols. This action is now described in detail.

The file DEFAULT_actionconfig.ini in the
/APF/config/modules/socialbookmark/action/sites/demosite folder (please refer to the
current apf-demopack-* release file) defines the action's parameters. The
InputParams attribute defines the default values of the input object. The
configuration file looks as follows:

The file ShowImageAction.php (see ActionFile) contains the program
code of the action. In case of the image delivery, tha path to the desired image is build up and
afterwards the image itself is delivered to the browser. To stop execution of further actions or
the creation of the front controller page, the action contains an exit() at the end
of the run() method. If the exit() is not present, the defined
page controller page will be delivered. This causes the browser to display a broken image. The
complete source code of the image delivery action is printed in the following code box:

As a rule, front controller actions are used to create and fill a application model - a model represents
the status of an application - before the presentation layer is created. For this task, the action
can revert to it's input object, that is procured by the front controller. If desired, the action
definition can already define default values for certain input parameters. These parameters are then
default values during action execution.

The main challenge of the "login check action" is to validate login information included in the
request, a session or a cookie and to provide this information to the application. This information
is then used by the business and presentation layer to control the application and to build the GUI.
Front controller actions are defined to be business layer members.

The scenario described in the last break contains two main "business cases": login information are
included in the request and second, login information must be gathered from other sources like sessions
or cookies. To provide the ability to login via cookies, the action must be executed with each request.
For these purposes, the action handling the login functionality can be registered to the front
controller as a "permanent" action. To do so, the bootstrap file must be changed like this:

The implementation of the action contains of three components as well. When dealing with MVC, front
controller and three tier based applications, it is advisable for us to define a central application
model class, that holds the current status of the application. This object can be used for flow
control or business layer functionality and to build the GUI, later on.

For this example, the class described in the following code box is intended to be the application
model. To make the example not too complex, the model defines only few attributes:

As you can see, the model uses the private member variable $attributes to store
the information. That brings the advantage, that the model attributes can be used in the
<fcon:importdesign /> tag to influence the GUI structure. Details on the tag
can be read about in section Standard taglibs.

This private method validateCredentials() encapsulates the validation of the login credentials, that must be
implemented by the business component.

In order to hold the model information within the entire session, the model can be created
in SESSIONSINGLETON mode. This opens the possibility, to have the action only executed at login or
logout, because the login information is already available in the session. To mime this behavior,
the model must be created as follows:

The following example describes how a front controller action can be used to change the language of an application.

The language of an application is injected into all objects that derive from APFObject. You can use the
$this->language variable within all of your components to determine the currently selected language or to
display language dependent content.

The following code assumes that the language to set is passed by the URL parameter language. The current
selection is stored using the to allow the selection to be memorized during the session.
In case no information is present, en is used as a standard value.

The last few lines of the implementation show how the language is configured for already created components - actions
and the Front controller itself - are applied the new language selection. It is important to re-configure all
existing actions since they potentially contain logic that depends on the language of the application.