The WebHandler Object
In the previous weblog entry, I discussed how Charlie used static file handlers to serve existing files. For example, the CssHandler would pick up an existing .css file, maybe update its content, and then return the file.
The next step was to create dynamic file handlers. Whereas the static file handlers are used when there is an existing file to return, the dynamic file handlers are used when there is no existing file to return. Rather, the response needs to be entirely generated from scratch.
This was a relatively simple exercise, since I had a single existing dynamic handler; namely, the PageEngine that used Presenters. I took the existing PageEngine and Presenter objects, and reworked them so that they could present documents in more than just HTML. I will admit that I did a shit job with my earlier attempts to describe the process by which a page is built in Charlie. Let me try again, this time using the new WebHandler object that replaced the previous PageEngine object.
Let’s consider how Charlie handles the following two requests.
/about /about.rss.xml
The first thing to note is that the same document is being requested (the About page), but the first request is for the document to be in HTML format, while the second request is for the document to be in RSS format.
The first thing Charlie does is hand these requests off to its WebContextBuilder object. The WebContextBuilder looks at the details of the request, and figures out which Document business object is being requested. In both cases, it is the About Document. At this stage, Charlie is unconcerned with the format requested; it is only concerned with which Document is being requested. The requested Document is then loaded up (pulling information from the database or cache) and attached to the current WebContext object.
The second thing that Charlie does is figure out what format has been requested. In these examples, the first request is for HTML format, and the second request is for RSS format. So at this point, Charlie knows which Document business object to present, and in which format to present the document.
The next step is for Charlie to introduce a WebHandler object. The task of this WebHandler is to take the Document business object, and present that Document in the HTML or RSS or other format requested. The WebHandler starts with a blank page that derives from System.Web.UI.Page. In the illustration below, the hand represents the Handler. (That should be easy to remember.)
The first thing the WebHandler does is say to the Document business object, “What template do you want to use?” The Document business object will return the name of the template that the website’s developer has specified. The template will be a simple name such as ‘Silver’ or ‘Playful’. The WebHandler will then add an extension that represents the format in which the document is to be presented. So in the first case .html will be added, while in the second case .rss will be added. The WebHandler then adds the .ascx extension, since templates in Charlie are based on ASP.NET User Controls. The WebHandler loads up the template (such as silver.rss.ascx), and applies it to the blank page.
Within that template may be any number of Placeholder controls that will define where the content is to be placed. For example, a template for an HTML webpage might include Placeholders for the header, content, and footer regions.
At this point, the page is half-constructed, and has slots where the content can go (the Placeholders). The WebHandler then goes back to the Document business object and grabs its collection of Containers. Each Container holds a business object that needs to be presented. For example, one container may hold an Article business object. Another container may hold a Photo business object. But at this point, all the WebHandler does is grab the Containers from the Document business object.
What the WebHandler does next is go through each Container and “tell” it what document format is being presented. So the first Container, which is holding an Article to be presented, knows whether the article is to be presented as HTML or as RSS or as some other format. With that knowledge, the Container says to its Presenter, “Here’s the Article to present, and we need to present it in HTML format.”
The WebHandler then says to the Presenter, “Give me an ASP.NET server control.” If you refer back to the weblog entry on the Presenter object, you’ll see that Charlie calls these server controls Views. So in the example being discussed, the Presenter of the first Container will return an ArticleHtmlView, with the Article business object attached. The second Container is presenting a photo, so its Presenter will return a PhotoHtmlView, with the Photo business object attached.
What this means is that the WebHandler will pull out a single server control, called a View, from each Container.
The final step for the WebHandler is to drop these View server controls onto the templated page. Each Container tells the WebHandler which Placeholder to use, and the position (first, second, third, or later) within that Placeholder.
The WebHandler has now created an ASP.NET Page complete with a Template and a bunch of arranged View server controls. The normal processing of an ASP.NET Page then occurs, and each View server control renders out the appropriate markup. An ArticleHtmlView will render an Article as an HTML element, while an ArticleRssView will render the same Article as an RSS item.
Sigh. I think this weblog entry is just as shit as the earlier entry. Oh well, since I am not being paid to write this weblog, I cannot justify rewriting this entry.
The end of this little story is that by introducing a new WebHandler object, and making the existing Presenter objects accept requests for all manner of different document formats, Charlie is now able to present its documents in multiple formats. What is notable—if I may say so myself—is that this flexibility is now built into Charlie’s architecture. If a client wants his or her pages exposed as Atom feeds, there is no need to write “fudge” code. Rather, by introducing a new ArticleAtomView and a PhotoAtomView, the rest of Charlie remains unchanged (including all existing security and localization).
I have now updated the sample site to present its documents as RSS and Atom feeds. I don’t yet know whether the XML generated is valid, because this is just a proof of concept. But as a proof of concept, I feel that it illustrates Charlie’s flexibility.
by Alister Jones | Next up: The Valley of Data Access - Part 1 →
----
Post a Comment