The thing I most like about Quixote is the long-term thinking by the
maintainers.  While keeping a minimalist philosophy, they add flexible
features that meet tomorrow's needs as well as today's, while still
being elegant and unobtrusive.

On 10/25/05, Matt Patterson  wrote:
> For me, the lack of scope of Quixote was one of the big wins. It
> didn't try to do everything, and I could ignore the bits I didn't
> like or didn't need. So here at work (BBC Radio & Music
> Interactive),  I'm building internal apps using Quixote as a URL-
> dispatch layer, with Cheetah as a templating layer, all held together
> by my own glue layers. I'm not using PTL or the forms module. If I
> wanted to use TurboGears or Django or Rails I'd have to follow their
> proscriptions.
>
> This isn't a fundamentally bad thing: the frameworks are really great
> if you're developing apps which fit snugly within their creator's
> philosophy of app development (the Rails guys are very open about
> this, and it makes a lot of sense). But, once you step out of that
> then you have to face dealing with code which is actively hiding the
> stuff you want or need because its job is to shield that from you and
> steer you in the direction the framework thinks is correct.

Interestingly, that's is the same thing we said about Zope five years
ago.  It's great if your project fits naturally into its paradigm, but
it's a pain if it doesn't.  However, since TurboGears and Subway are
mainly glue between third-party components, it's easier to replace
undesired components.  If I use TurboGears (which I'm considering),
I'd want Cheetah rather than Kid.  I'm not sure if that's possible
while still keeping all TG's features (auto template selection,
JSON-friendly, auto reload?), but it seems straightforward enough to
verify.  If I found TG too constraining, I could fall back to CherryPy
with minimal changes to my code.  CherryPy is only slightly more
constraining than Quixote.  So, essentially I'd be doing the same
thing you are, and the same thing I'm already doing in Quixote.
Whether my application could strictly be called "a TG application" or
"a TG/Cheetah application" or "a mix-n-match application" is academic.

If we consider devolving Quixote components, we get into "What makes
Quixote Quixote?"  I'd say the Publisher and its dependencies
(Directory, HTTPRequest, HTTPResponse).  The servers exist because
there was no WSGI equivalent at the time.  The session code can be
substituted with some changes to the API or a compatibility layer.
The form, PTL, and htmltext components are conveniences -- although
valuable because no equivalent modules exist elsewhere.

> I suspect that there'll be an increasing number of people who find
> themselves developing systems which share the same philosophical
> space as the current crop of frameworks, except that they'll be more
> and more specialised, allowing their creators to make slew of highly
> specialised apps on top of them. For example, our internal
> authentication infrastructure is complex and every app needs to use
> it, as is our publishing situation, so my almost-framework will make
> those available simply and transparently to every app I create.

The reason everybody and his dog are lining up for TG, Rails, etc, is
that most sites are simple enough that they can be expressed in this
kind of framework.  Quixote 1 was more flexible than Q2: any namespace
could represent a directory.  We found this wasn't necessary; a
Directory covers every conceivable use case.

In my department, a single framework is more important than the most
flexible framework.  It was hard enough to get Python accepted (over
existing PHP work) and then Quixote (over existing Webware), but now
it's become the standard.  Still, I'd like to not cut myself off from
innovations in Paste and TG I may want to use now or later.  Quixote
unfortunately requires more adaptions to interoperate with these
CherryPy does.  Yet most of our up-and-coming developers/maintainers
are new to Python, so we'd rather have them learn one framework rather
than two different ones.  (Remembering that every framework his its
idiosyncracies and workarounds.)  Quixote's uniqueness is a
disadvantage in this regard.

> That could well mean trying to shed the need
> to directly provide app server code, maybe WSGI all the way.

That would be nice long-term.  Currently I use scgi_server because
there's no compelling advantage of the WSGI servers, but this will
eventually change.  One thing I dislike about both Quixote and
CherryPy is the built-in servers and session code and configuraition
method that you just have to bypass if you're plugging into something
larger, but currently the alternative "standard implementations"
aren't quite there yet.  Nevertheless, one should note that CherryPy
reorganized its publisher and server to be WSGI-compliant by default,
which is a good forward-looking move.

> It could
> also mean making it easy to mess where messing is needed (for
> example, my desire to mess with HTTPRequest without messing around
> beyond the Publisher)

I have found that initializing extra request attributes in the
top-level ._q_traverse meets my needs: stuff that needs to persist
during the transaction but not beyond, accessible from any generic
function.   I used to inject methods into HTTPRequest (to avoid
subclassing it) but have since moved those to functions.  I will have
to modify the publisher soon because the usability experts want more
friendly and site-specific error messages.

--
Mike Orr  or