Fundamentals of Themelia - Processor Factories
Tuesday, August 26, 2008
This documentation has been updated for Themelia Framework 2.0 Beta 5.
One of the most basics concepts in Themelia is the handler factory. If you recall, this allows simplified access to any HTTP handler. In stead of registering a handler as "Sample.Web.AuthenticateHandler, Sample.Web", you could simply use "Authenticate" or "Auth" depending on how your handler factory was setup. This factory also created the HTTP handler thereby giving a small boost in performance over dynamically creating an instance of "Sample.Web.AuthenticateHandler, Sample.Web".
Analogous to this is a processor factory, it's identical every every way to an handler factory, except that it generated any and all types of processors. You can alias pre processors, mid processors, fall through processors, error processors, post processors, and post state processors. Thus, instead of registering the long name of "Themelia.Web.Routing.ForbiddenFallThroughProcessor, Themelia.Web" you may simply register "ForbiddenFallThroughProcessor" and instead of "ABCCorp.Web.Routing.SalesPreProcessor, ABCCorp.Web", you just register "SalesPreProcessor" or "Sales" or whatever you want (however it's a good idea to leave the processor type suffix).
In fact, for our example, let's look at Themelia's internal processor factory:
internal class CommonProcessorFactory : Themelia.Web.Routing.ProcessorFactoryBase { //- @CreateProcessor -// public override IProcessor CreateProcessor(String text) { switch (text) { case "passthrough": return new PassThroughPreProcessor(); case "emailsendingerrorprocessor": return new EmailSendingErrorProcessor(); case "forbiddenfallthroughprocessor": return new ForbiddenFallThroughProcessor(); case "passthroughfallthroughprocessor": return new PassThroughFallThroughProcessor(); case "pagealiasfallthroughprocessor": return new PageAliasFallThroughProcessor(); case "redirectfallthroughprocessor": return new RedirectFallThroughProcessor(); } //+ return null; } }
As you can see, every common reusable processor type is registered so that you don't need to write out the entire type each time. Also, once again, we have a small performance boost since dynamic creation is now out of the question.
As a side note to this, where as handlers are created on each request (lest they share stale state), Themelia pools processors so they are only created once. Actually, pools processors regardless if you are using a processor factory or not. So, the performance boost in a processor factory isn't nearly that much as the boost in a handler factory. However, it sure does help you remember the name of the types.
It's important to remember that you can use a processor factory for any type of processor. You do not need to have a separate processor factory for each type of processor. A single processor factory may create anything form error processors to mid processors to post state processors and everything in between.
A processor factory is made by creating a class that inherits from Themelia.Web.Routing.ProcessorFactoryBase. This is an abstract class that requires you to implement the following signature:
IProcessor CreateProcessor(String text)
Processor factories like all Themelia factories are registered in web.config in the <factories> collection. Below is an example:
<themelia.web> <webDomains> <add> <factories> <add type="Sample.Web.Routing.ProcessorFactory, Sample.Web" /> </factories> </add> </webDomains> </themelia.web>
Lastly, processor factories are also installed using web components, thus showing once again that web components are the end all for the Themelia pipeline. You register one Themelia web component and all your Themelia functionality is registered and running.




