= 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 [wiki:Docs/Validators request], [wiki:Docs/Session 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 $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 [wiki:Docs/Validators#Cancellingtherequest 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 [wiki:Docs/MVC/ViewEngines/XSL XML/XSL driven websites] * {{{net::stubbles::service::jsonrpc::stubJsonRpcProcessor}}} to answer [wiki:Docs/JsonRpc 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 [wiki:Docs/MVC/WebsiteCache website caching] * {{{net::stubbles::websites::processors::auth::stubAuthProcessor}}} for including [wiki:Docs/MVC/Auth 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.