Skip to content
This repository has been archived by the owner on Jan 16, 2019. It is now read-only.

Docs MVC Processors

Jump to bottom
Frank Kleine edited this page Apr 7, 2012 · 1 revision

Table of Contents

Controller, Processors and Processor resolvers

Stubbles contains an unique front controller that does all necessary actions for processing a request by delegating the real work to processors. While the front controller does the general process handling (establishing request, session and response instances) a processor contains the logic how to process a specific request. The front controller itself uses processor resolvers to determine which processor is responsible for processing a request. The following article explains how these three components work together and can be used to build MVC applications on top of them.

The front controller

The net::stubbles::websites::stubFrontController is used to keep the index.php small and clean. However the front controller has several dependencies that need to get injected, so we don't instantiate the front controller directly in our index.php but rather use the dependency injection features: 

#php
<?php
// load Stubbles
require '../../../bootstrap.php';
$projectPath = realpath(dirname(<u>FILE</u>) . '/../');
stubBootstrap::init(array('project' => $projectPath));
// load classes used in this file
stubClassLoader::load('net::stubbles::ioc::stubApp',
                      'net::stubbles::ioc::module::stubModeBindingModule',
                      'net::stubbles::ioc::module::stubPropertiesBindingModule',
                      'net::stubbles::websites::ioc::stubWebsiteBindingModule'
);
// configure the bindings, get a front controller instance and call its process() method
stubApp::createFrontController(new stubModeBindingModule(),
                               new stubPropertiesBindingModule($projectPath),
                               'net::stubbles::ipo::ioc::stubIpoBindingModule',
                               'net::stubbles::util::log::ioc::stubLogBindingModule',
                               'net::stubbles::util::cache::ioc::stubCacheBindingModule',
                               stubWebsiteBindingModule::createWithXmlProcessorAsDefault('interceptors')
                                                       ->enableRss('interceptors')
                                                       ->enableJsonRpc('interceptors')
         )
       ->process();
?>

What we do here is very simple: include the bootstrap and do some initializations, configure the bindings required by the application, and instantiate the controller using dependency injection and run it.

In the process() method all preinterceptors are called, then the processor itself, and afterwards all postinterceptors. If in one of those steps the request is cancelled only the response will be send. This means, if a preinterceptor cancels the request, the response will be send immediately and neither the subsequent preinterceptors, the processor nor any postinterceptor will be called. If the processor itself cancels the request, no postinterceptor will be called, and if a postinterceptor cancels the request all subsequent postinterceptors will not be called.

Configuring the net::stubbles::websites::ioc::stubWebsiteBindingModule

The net::stubbles::websites::ioc::stubWebsiteBindingModule is responsible for setting up which processor should be run and to configure all bindings required by the processors.

Processor resolvers

A processor resolver is responsible for analysing the request and to create the processor that is able to process the request. Stubbles offers two implementations: a net::stubbles::websites::processors::stubSimpleProcessorResolver and a net::stubbles::websites::processors::stubDefaultProcessorResolver. While the net::stubbles::websites::processors::stubSimpleProcessorResolver will always return the same processor, the net::stubbles::websites::processors::stubDefaultProcessorResolver can be configured to create processors dependent on the processor variable of the request.

Of course you can implement you own processor resolver. It needs to implement the net::stubbles::websites::processors::stubProcessorResolver interface, but you can ease this with extending the net::stubbles::websites::processors::stubAbstractProcessorResolver.

Processors

Finally, the processor will do the real work in processing the request. With the processor the type of the view is chosen. On instantiation the processor will get the request, session, response and router instances (its the task of a processor resolver to create the processor and to supply these instances to it). The front controller will ask it for the interceptor descriptor. This descriptor decides which configuration the interceptor initializer should use to create the pre- and postinterceptors (see above). Finally, after calling all preinterceptors, the front controller retrieves the configured processor from the processor resolver and calls the process() method of the processor, where the processor can now do any work it needs to do to fulfill the request.

Default processors in Stubbles

Stubbles delivers several processors for different tasks:

  • net::stubbles::websites::xml::stubXMLProcessor to build XML/XSL driven websites
  • net::stubbles::service::jsonrpc::stubJsonRpcProcessor to answer JSON/RPC requests.
  • net::stubbles::xml::rss::stubRSSProcessor for delivering RSS feeds.

Additionally there are decorating processors which can be used with any of the processors above:

  • net::stubbles::websites::cache::stubCachingProcessor to enable website caching
  • net::stubbles::websites::processors::auth::stubAuthProcessor for including authorization

Create your own processor

If you are missing a processor that suits your needs you can create your own by implementing the net::stubbles::websites::processors::stubProcessor interface. The net::stubbles::websites::processors::stubAbstractProcessor] already delivers a default implementation that just needs to be extended.

Clone this wiki locally