Presentation refers to the part of the application that is visible to the user - the user interface - and the handling of user interaction.


The presentation layer usually depends on underlying services like persistency, event handling, caching - just to name a few. These services typically exist as one instance that is created on application startup and is used throughout the whole application lifetime.

The preferred way to get access to a service instance in client code is to set the dependency explicitly or let it be injected, if the instance is not created explicitly (see Dependency injection). But there are also situations where this is not possible (e.g. a global function that is used by third party code). Since most of these services are registered with ObjectFactory, it's getInstance method may be used as a service locator.

The following example shows how to get the persistence service at any code location:

$persistenceFacade = ObjectFactory::getInstance('persistenceFacade');


Web applications typically implement a request-response pattern, where a client sends a (HTTP-)request to the application, which returns a response after processing it. wCMF encapsulates the described procedure inside the Application class. The following code demonstrates the usage of this class in the main entry script of the default application.

$application = new Application();
try {
// initialize the application
$request = $application->initialize('', '', 'cms');
// run the application
$response = $application->run($request);
catch (Exception $ex) {
try {
$application->handleException($ex, isset($request) ? $request : null);
catch (Exception $unhandledEx) {
echo("An unhandled exception occured. Please see log file for details.");

The example shows the three important methods of the Application class:

  • The initialize method is used to setup the Application. It returns a Request instance, that may be modified before execution.
  • The run method is called to execute the given request. The method returns a Response instance, that is not used in this example.
  • The handleException method is called, if an exception occurs. The method rolls back the database transaction and calls the failure action.

The details of request execution are the topic of the next section.

Request processing

The Request instance created on initialization of the application provides all information about the incoming HTTP request, that is necessary for execution. Upon execution, the following actions are performed:

  1. The Request instance is passed to ActionMapper for further processing.
  2. The Action Key is determined from the request parameters.
  3. PermissionManager is asked to authorize the action key for the current user (see Checking permissions).
  4. If authorization is successful, the request data is transformed into the internal application format (see Formats).
  5. The Controller instance matching the request is determined (see Routing) and executed.
  6. The Response instance is obtained after execution.
  7. The response data is transformed into the requested response format (see Formats).
  8. Execution returns to step 3, if a valid action key is contained in the response data and terminates, if no action key is found or the response is finalized by calling the method Response::setFinal.


wCMF is designed to be able to consume various request formats and produce several response formats. While some clients communicate using JSON format, others might prefer to encode data in XML. Formatter is used to determine the required format and delegate the actual formatting to the correct Format implementation. wCMF currently provides the following implementations:

  • HtmlFormat expects all data to be sent as key-value-pairs. Object data are transferred in parameters named value-name-oid (e.g. value-title-Book:3). Responses in this format are rendered as HTML views (see Views).
  • JsonFormat handles JSON encoded request data and encodes response data into the same format.
  • SoapFormat is used together with the NuSOAP library to implement a SOAP interface.
  • NullFormat is used internally, if no formatting is required, e.g. if one controller calls another controller.

If not explicitely set, the request and response format is automatically determined from the HTTP headers sent with the request:

  • The Content-Type header defines the request format
  • The Accept header defines the response format

To find the correct format, the Media Type value set in those headers is matched against the mime type of all registered formats (see Format::getMimeType).

Formats are defined in the Formats configuration section as shown in the following example:

1 [Formats]
2 html = $htmlFormat
3 null = $nullFormat
5 [HtmlFormat]
6 __class = wcmf\lib\presentation\format\impl\HtmlFormat
8 [NullFormat]
9 __class = wcmf\lib\presentation\format\impl\NullFormat


Routing is the process of selecting the correct Controller for a given request. wCMF distinguishes between internal and external routing.

Internal routing

Internal routing takes place after the Request instance is created and initialized. wCMF inspects the action key formed from it's sender, context and action parameters (see Action Key) to determine the controller to be executed for the request. The mapping of action keys to controllers is defined in the ActionMapping configuration section.

If the executed controller together with the context and action parameters of the response match another action key, the corresponding controller will be executed afterwards. This allows to chain several actions together. If no matching action key is found, the response is returned to the client.

The following code is taken from the default application configuration and shows the configuration of the indexing process (see Long running requests):

1 [ActionMapping]
2 ??indexAll = wcmf\application\controller\SearchIndexController
3 wcmf\application\controller\SearchIndexController??continue =
4  wcmf\application\controller\SearchIndexController
Controller methods

The previous example maps the action keys to a controller class without specifying a method to be called. In these cases, the framework calls the default method doExecute, which must then be defined in the controller class (see Controllers).

Alternatively a specific controller method to be called may be defined in the action mapping, like illustrated in the following example:

1 [ActionMapping]
2 ??indexAll = wcmf\application\controller\SearchIndexController::doBegin
3 wcmf\application\controller\SearchIndexController??continue =
4  wcmf\application\controller\SearchIndexController::doContinue

In this case SearchIndexController would have to define the methods doBegin and doContinue which are called for the appropriate action keys.

External routing

The mapping of the current request uri to an action key is called external routing. The default mapping logic is implemented in the DefaultRequest::initialize method. The method matches the path part of the request uri against the entries of the Routes configuration section to find an appropriate action key. Variables declared in path segments will be automatically passed as request parameters.

The following example configuration taken from the default application illustrates the concept:

1 [Routes]
2 / = action=cms
3 /rest/{language}/{className} = action=restAction&collection=1
4 /rest/{language}/{className}/{id|[0-9]+} = action=restAction&collection=0
  • The first entry is matched by the root path, which is then mapped to the cms action - corresponding to the action key ??cms.
  • The second entry defines the language and className variables (surrounded by curly braces) and would be matched by the request uris /rest/de/Author or /rest/en/Book. The executed action would be restAction.
  • The id variable in the third entry must be an integer because of the regular expression constraint [0-9]+.
HTTP methods

To restrict a path to one or more HTTP methods, they may be added in front of the route definition. In the following example the cms action is only available for the GET method, while the other actions accept GET, POST, PUT and DELETE requests:

1 [Routes]
2 GET/ = action=cms
3 GET,POST,PUT,DELETE/rest/{language}/{className} = action=restAction&collection=1
4 GET,POST,PUT,DELETE/rest/{language}/{className}/{id|[0-9]+} = action=restAction&collection=0

If no method is added to a route, all methods are accepted.


Controllers take the user input from the request and modify the model according to it. As a result a response is created which is presented to the user in a view or any other format. Which controller is executed on a specific request is determined in the routing process (see Routing).

wCMF provides Controller as abstract base class for controller implementations. There are three important methods defined in this class, which are called by ActionMapper in the following order:

  1. Controller::initialize is called directly after instantiation of the controller. The current Request and Response instances are passed as parameters and subclasses may override this method to implement task specific initializations.
  2. Controller::validate is called afterwards to check the validity of the request parameters. The default implementation returns true and subclasses are assumed to override this method if necessary to do task specific validations.
  3. Controller::execute is called finally. This method accepts a parameter, that defines the actual method to be called on the subclass. If the parameter is omitted it defaults to doExecute which must then be defined in the subclass.

Error handling

Errors are typically divided into fatal errors and non-fatal errors.

By definition the application is not able to recover from a fatal error, meaning that it's not functioning correctly. An example would be a programming error or a missing vital resource. These errors normally need to be fixed by the application maintainer. In case of non-fatal errors a notice to the user is sufficient in most cases. A typical example would be invalid user input, that can be fixed by the user itself.

In wCMF the following two strategies are recommended for handling these kind of situations:

  • In case of a fatal error, an exception should be thrown. If it is not caught inside the application code, it will bubble up to the main script (usually index.php). In case the application is set up like in the Application section, the method Application::handleException will be called. This method rolls back the current transaction and calls the failure action, which is executed by FailureController by default.
  • If a non-fatal error occurs, an instance of ApplicationError should be created and added to the response using the Response::addError method. The error class provides the ApplicationError::get method to retrieve predefined errors. The following example shows how to signal an invalid type parameter while request validation:
array('invalidParameters' => array('type'))));

Long running requests

There are situations where you want to split a long running process into parts, because it's exceeding memory or time limits or simply to give the user feedback about the progress. By subclassing BatchController the implementation of this behavior is as simple as defining the steps of the process in the BatchController::getWorkPackage method.

SearchIndexController is an example for a controller implementing a long running process. It is used to create a Lucene search index over all searchable entity objects. The process is split into collecting all object ids and then indexing them. In the final step the index is optimized.


Views are used to present application information to the user. In a web application they are typically HTML pages displayed in the browser.

In wCMF the response will be turned into an HTML page, if the Accept HTTP header is set to text/html (see Formats). The appropriate Format implementation is HtmlFormat. It renders the response into a template file using the configured View implementation. The format of the template files depends on the chosen that implementation. Since different actions may require different views to be displayed, a mapping of action keys to view templates is defined in the Views configuration section.

The following example shows the configuration of the SmartyView class and the mapping of action keys to views in the default application:

1 [View]
2 __class = wcmf\lib\presentation\view\impl\SmartyView
3 __shared = false
4 compileCheck = true
5 caching = false
6 cacheLifetime = 3600
7 cacheDir = app/cache/smarty/
9 [Views]
10 app\src\controller\RootController?? = app/src/views/cms.tpl

Since the default application only uses an HTML page to bootstrap the actual Dojo application, there is only one view mapping for RootController.

Device dependent views

HtmlFormat allows to provide different versions of a view template. This is especially useful, if you want to deliver device dependent content for the same action key.

To select a specific template version, the value html_tpl_format has to be set on the response instance. E.g. if the template file would be home.tpl, setting the value to mobile would select the template file home-mobile.tpl. If the requested version does not exist, it is ignored and the default template is used (home.tpl in this example).

Webservice APIs

Besides the user interface driven default application wCMF provides APIs for using the application as a web service. These APIs provide create/read/update/delete (CRUD) operations on all entity types.


The RESTful interface is implemented in RESTController, which basically acts as a facade in front of the application. That means the controller checks the request data only and delegates the actual processing to the action specific controller.

The following example shows the configuration of the RESTful interface in the default application:

1 [Routes]
2 /rest/{language}/{className} = action=restAction&collection=1
3 /rest/{language}/{className}/{id|[0-9]+} = action=restAction&collection=0
4 /rest/{language}/{className}/{sourceId|[0-9]+}/{relation} = action=restAction&collection=1
5 /rest/{language}/{className}/{sourceId|[0-9]+}/{relation}/{targetId|[0-9]+} = action=restAction&collection=0
7 [ActionMapping]
8 ??restAction = wcmf\application\controller\RESTController

The Routes configuration section defines the urls for the interface. They all call the action restAction internally, which is handled by RESTController as defined in the ActionMapping section. For example the english version of the Author instance with id 1 may be retrieved by making a GET request to the url /rest/en/Author/1.


wCMF uses the NuSOAP library for implementing the SOAP interface. It consists of the SoapServer and SOAPController classes. The controller class handles all requests and delegates the processing to the server class. The service description in the WSDL format is generated by the code generator into a file called soap-interface.php (see PHP Code).

The following example shows the configuration of the SOAP interface in the default application:

1 [Routes]
2 /soap = action=soapAction
4 [ActionMapping]
5 ??soapAction = wcmf\application\controller\SOAPController

The Routes configuration section defines that the url /soap redirects to the action soapAction internally. The ActionMapping section defines that this action is handled by SOAPController. The interface description is available at the url /soap?wsdl.


Caching is an effective method to improve application performance. Caches in wCMF are supposed to be divided into sections, which hold key-value pairs (see Cache interface). Cache instances may be defined in the application configuration and retrieved by using ObjectFactory, which makes it easy to exchange the underlying caching implementation.

The following example shows the configuration of a FileCache instance in the default application:

1 [Cache]
2 __class = wcmf\lib\io\impl\FileCache
3 cacheDir = app/cache/

The usage of this cache is illustrated in the code example:

$cache = ObjectFactory::getInstance('cache');
$cacheSection = 'calculations';
$cacheKey = 'resultA';
if (!$cache->exists($cacheSection, $cacheKey)) {
// calculate the result and store it in the cache
$result = complexCalculationA();
$cache->put($cacheSection, $cacheKey, $value);
else {
// retrieve the result from the cache
$resultA = $cache->get($cacheSection, $cacheKey);

Supposed that complexCalculationA in this example takes long to finish, it should only run once at the first time the result is needed. So we check if resultA is already cached and calculate it, if not. Since it is put it into the cache after calculation, it can be retrieved resultA directly from there the next time it is needed.


Events are a way to decouple parts of a software by introducing an indirect communication. They allow clients to react to certain application events without the event source knowing them. wCMF uses the publish-subscribe messaging pattern, in which EventManager acts as the message broker. Subscribers use this class to register for certain Event types and publishers to send the events.

The following events are defined in wCMF:

The event system may be extended by custom events by inheriting from the Event class.

The class below is a basic example for a listener that subscribes to persistence events:

class PersistenceEventListener {
private $_eventListener = null;
public function __construct(EventListener $eventListener) {
$this->_eventListener = $eventListener;
array($this, 'persisted'));
public function __destruct() {
array($this, 'persisted'));
Listen to PersistenceEvent
@param $event PersistenceEvent instance
public function persisted(PersistenceEvent $event) {
// do something on any create/update/delete
To prevent memory leaks the EventManager::removeListener method must be called, if the event listener is destroyed.

To send a persistence event, the following code is used:

$eventListener = ObjectFactory::getInstance('eventManager');
new PersistenceEvent($object, PersistenceAction::UPDATE));

Implicit listener installation

In some cases you may want to install event listeners without explicitely instantiating them, because there is no appropriate place for that. For these cases the Application class reads the listeners value of the Application configuration section and initializes all instances listed there.

The default application defines two listeners as shown in the following example:

1 [Application]
2 listeners = {Search, EventListener}

Each entry in the listeners array is supposed to refer to an instance configuration (see Dependency injection).


wCMF integrates the logging frameworks log4php and Monolog. To abstract from these libraries wCMF defines the Logger interface and implementations for each framework. The decision, which framework to use is made by instantiating the appropriate Logger instance and passing it to the LogManager::configure method as shown for Monolog in the following example:

$logger = new MonologFileLogger('main', WCMF_BASE.'app/config/log.ini');

Afterwards Logger instances can be retrieved using the following code:

$logger = LogManager::getLogger(__CLASS__);

The parameter used in the LogManager::getLogger method is the logger name. It's a good practice to use the __CLASS__ constant as logger name, since this allows to enable/disable loggers by class names in the configuration (see Logging configuration).

The following example shows how to log an error message with a stack trace appended (see ErrorHandler::getStackTrace):

$logger->error("An error occured.\n".ErrorHandler::getStackTrace());