http://www.google.com/buzz/pjkeane/CWyFG8ydaoT/URL-Dispatching-made-easy-Ive-not-yet-found-a-URL

I have no objection to there being an object which encapsulates an HTTP request or response nor extensive use of libraries, what is the problem is the WSGI stack being obscured. Establish the request object further up the stack and hork it into environ and let me pull it out later if I want, but don’t change my application signatures. Those signatures help to ensure that I’m creating what amounts to a stackable series of independent tiny little web apps (even if to the outside world they look like just one). Creating using that model helps to ensure that my codebase is deliciously extensible and scalable.

I know the other solutions and their shortcomings, so you might find that Autodispatch finally gets it right.

I’d be curious what people think: if you were making an application, what’s the next thing you’d look to a library for? Templates are a no-brainer. I’d add an optional constraint: barring things that abstract out logic and conditionals (e.g.,, what Application does), what library (or kind of library) would you want to use?

1- removing repetition for example in this case you will get tired of creating Response objects on every return so you will either create a default response you clone and return a string (this is what pylons did) or make up some marker to determine how to create it (this is what TurboGears did with the @expose decorator + returning a dict)

2- Raw WSGI is hard to maintain not to mention very unfriendly to object oriented programming, reading from the environ and checking if the key is valid gets old quick which is why webob was born.

In other words as others have pointed out the framework grows out of the necessity of eliminating repetition which pulls in constraints on design and style. IMO that is the trade off and I’ll salute everyone that will be able to abstract repetition without adding constraints.

That said this leads us down the route of having to reinvent everything as it is not possible to reuse anything for this “framework” as there is nothing written in it except for what you wrote and IMO that is very bad, mainly because there is always someone out there that could and in fact already wrote a better solution to this particular problem.

That brings me to another plus point which is code reuse, in this no-framework environment reusing code is actually the best part of it as it is all wsgi and since you are using the least amount of code it means you will be compatible with others and (at least in theory) you should be able to plug in code written in other frameworks into your own system.

Last but not least thank you for putting words to what I have been playing around with. I have been doing something like this for two small apps playing around with this idea, and so far I like what I have. I have been slowly getting converted into the philosophy of libraries > frameworks and the ability to plug-n-play with component to create that dream of a “Best of” framework.

As for the argument regarding “developers that don’t know better” I think we have to be pragmatic here, you should (at different points in time) both be the super wise guy that dives into the HTTP headers while at others you just want to have a method be called and return a string.

Anyway sorry for the long comment and keep up the good work recently your post have been enlightening filling peaces of the puzzle