Howdy!
I've read your announcement and think it looks interesting, but the default class dispatching mechanism of web.py is much more convenient for me. The regexp matching of the url which simultaneously generates the handler method parameters (like GET(self, id)) saves me a lot of work in parsing and validating complex urls myself.
Which is why I kept the original dispatching mechanism in place. With some of my larger projects I may use three forms of dispatch at once: Component Management System / DB deferred dispatch, object instance / method dispatch, and GET/POST split class dispatch. Each has distinct advantages for certain kinds of projects, or sections of a single project.
For the most part I use the add_processor extension method to add pre/post request hooks to my code. As an example, from the Web.py cookbook article on adding SQLAlchemy ORM support, I've used the following in my code to automatically handle database sessions:I've looked into the preprocessors, and while they are a great idea forsome stuff, I can't get hold of the handler class instance from there. The handler parameter is either the next preprocessor in the chain or the handle() method of the web.py application that does the actualinstantiation of the handler class and calls the appropriate method. SoI haven't found a method to inject dependencies from there.
I see. I'll be adding a __before__ and __after__ method to the base Controller class, to be overridden in subclasses, allowing for the addition of standard processor hooks with the ability to access the instance and whole class tree. In fact, I think I'll commit that right now. :)
— Alice.
smime.p7s
Description: S/MIME cryptographic signature
