The Hand of FuManChu - Latest comments on Customization vs handler dispatch in web application servers

In response to: Customization vs handler dispatch in web application servers

Ben Bangert [Visitor] — Tue, 25 Oct 2005 19:27:21 +0000

I'm looking forward to better methods to plug-in dispatch schemes for CherryPy. One person already coded up an integration with Routes for CherryPy though I'm sure it has some bugs since he couldn't fully integrate it into CherryPy's back-end. I believe as it currently is, this should be implemented as some sort of filter?

In Routes, I added two functions intended to be used by the developer in whatever framework they use, that passes the configuration data using a thread-local singleton class. Kind of non-Pythonic (implicit instead of explicit), but it seemed like the best choice.

There are some interesting abilities gained and lost by having the C in MVC taken care of independently of the V. Of course, it will be more modular and a framework developer will be able to pick and choose more parts when they can plug-in a Controller (middle-section) type thing like CherryPy, then a template language, a Model class, etc. On the other hand, more advanced functionality that requires access to the Controller or sub-requests to Controller data might not work at all or as well when they are bound more closely.

This is one of the reasons I'm using Myghty as the VC in MVC for my own little mega-framework. In the case I cite at the end, the functionality desired is to pull the content of what is essentially a sub-request, and insert its content into the template being rendered. It's possible this is do-able in CherryPy, but I can't seem to find it in the docs.

Regarding creating frameworks in general, I'm hoping more people choose mega-framework type things, so I don't have to keep learning tons of new stuff anytime I want a new framework (ie, build on CherryPy, Myghty, or other extensible frameworks). Transferrable skill-sets are nice to have, as TurboGears emphasizes.

In response to: Customization vs handler dispatch in web application servers

fumanchu [Member] — Tue, 25 Oct 2005 17:23:28 +0000

Hi, Ben!

The post is descriptive. I'm trying to point out some of the issues that a developer will run into when making a framework.

"If you're looking for better systems for deployers, I'd suggest looking at Paste."

I'm not, really. I'm much more interested in the content of such a file than the management of it. [However, if the management tools, like Paste, are widely considered to be hard to understand, then framework and server authors are naturally going to prefer other ways to allow customization of their code.]

"The other thing I'm not sure you're accounting for is all of the frameworks you mention will fail in a deployment scenario where the entire web application is deployed under another URL namespace."

I disagree, but I think it may be semantics. There are two issues involved in supporting arbitrary mount points. First, dispatch needs to still work (input), and second, URL's need to be written appropriately (output). The latter can be addressed either via relative URL's or via rewriting (interpolation of the correct absolute root). At least three of the four servers I covered have facilities for correct dispatch:

One of Django's design goals is to promote fluid roots.
Mod_python can depend on its deployers using mod_rewrite in almost every case.
It's easy enough to find or write a filter for CherryPy which does the dispatch-rewriting for you.

I can't speak for Quixote on this issue.

Regarding the output (URL generation), I'm only really familiar with CherryPy, which, since it is templating-language agnostic, leaves the relativity of URI's to the application developer (I know all of my URI's are both correct and re-routable). One nice thing about CherryPy is that it doesn't own any URI's itself, and therefore does not have to address this issue in the core.

Regardless of existing support, I think Routes is a great step in providing this functionality to lots of existing frameworks.

"I've read your post a few times now, and I'm still having difficulty deciphering the terms you're using for various contexts. Perhaps thats because I'm not primarily a web framework creator?"

Perhaps, but it's more likely just my intuitive munging of terms. I'll re-read it (now that I've had some sleep) and see if I can't touch it up and be more consistent.

Thanks for the info re: Myghty and Routes. I've actually got another post in draft right now regarding CherryPy, and how I'd like to turn it inside-out in order to support various dispatch schemes. [I don't think it'll start doing response composition anytime soon, though. That is, I don't see CP resolvers handling "sub-requests"; perhaps that's an advantage that Myghty provides, that CP can't count on (not having a blessed template solution).]

In response to: Customization vs handler dispatch in web application servers

Ben Bangert [Visitor] — Tue, 25 Oct 2005 16:47:53 +0000

I'm not entirely sure what the point of this post is, is it comparing methods or trying to find strengths in one or the other?

If you're looking for better systems for deployers, I'd suggest looking at Paste. The config file format is rather minimal given the ability it wraps up, though CherryPy will need the ticket resolved that prevents it from functioning properly with multiple webapps in a single process.

The other thing I'm not sure you're accounting for is all of the frameworks you mention will fail in a deployment scenario where the entire web application is deployed under another URL namespace. If you wrote your web application with the presumption it'd "own" the root path, and have hard-coded /archives/2004 in templates and such, the webapp will fail when a user tries to deploy it under /joes/blog URI.

For a web application to survive under this type of deployment, all URL's it generates to its own parts will need to be generated. This was one of my primary goals in porting the Rails system of Routes to Python (and I liked their flexible mapping system that didn't use huge regexps). Zope already has this under control as well since they use URL generation to call webapp resources.

I've read your post a few times now, and I'm still having difficulty deciphering the terms you're using for various contexts. Perhaps thats because I'm not primarily a web framework creator?

I should mention however, that Myghty allows for significant customization of dispatch far beyond what I believe CherryPy or Django offer. As I'm building a mega-framework of sorts on top of Myghty, the customization has allowed me to easily build MVC frameworks and experiment using:

A stateless controller class (one controller is instantiated and used persistently)
A stateful controller class (controller is instantiated and used for each request)
Stateless controller thats automatically instantiated outside the users code
Pipe-lined request dispatch (ala the Axkit XML/XSLT approach)
Routes-based dispatching

Myghty's advanced resolver mechanism allows the entire resolver dispatch scheme to be fully customized by the web application developer (should they choose to). Entire custom resolvers can be written and added in, or pipe-lined. The resolvers can even be fine-tuned per the context of the request, for example one rule-set of resolvers could be used during the initial request, and a different set of resolvers could be called during a sub-request.

This entire approach makes for a very very powerful and customizable base for building custom mega-frameworks on top of it (as I'm doing). Of course, in Myghty's case this means the templating it provides is available though there's no reason one couldn't build their own mega-framework using Myghty for this feature and using another template language.

Hopefully that helps some with the comparison of URL dispatching/configuration and the customizability it provides a developer.