On 3/6/06, Neil Schemenauer wrote:
> On Mon, Mar 06, 2006 at 02:11:31PM -0700, Orr, Steve wrote:
> > What is the current state of Quixote?
>
> I guess either people are happy or they left for other frameworks.
Reports of Quixote's death are exaggerated. It's a small package that
has reached stability, so there aren't many bug reports. Those that
are reported get fixed quickly, thanks to Neil and David. Quixote's
minimalist philosophy means it's slow to add features, so there's not
much reason to change.
> It seems to me that Quixote is losing a marketing war with other
> frameworks. That's a shame because I think Quixote does a lot of
> things well.
The newer frameworks use Quixote as a reference model. At least
that's true for TurboGears, which I've been involved with the past few
months. The form and widgets influenced TG's widgets, even though
they decided to go different directions to link into Kid's ElementTree
DOM. They are aware that ._q_traverse() would solve several of the
limitations they're bumping up against with CherryPy's built-in
traversal, especially (1) restful URLs, and (2) the ability for a
method to return a sub-Directory that would continue the traversal.
(Directories are called Controllers there, but same thing.)
> At this point the only major changes I would make would be to make
> it more modular and more library like. Ideally, QP could be built
> using components from Quixote. The restructuring would probably
> consist of backwards incompatible changes and I'm not sure the
> community is up for that.
>
> Oh yes, obviously the documentation could use a lot of work. We
> should have at least an up-to-date high-level tutorial and low-level
> documentation for all the components.
I have three Quixote applications which I'm not eager to rewrite. But
if it's just changing a few imports or renaming a few top-level
variables, that's fine. Otherwise let's either do it under a new
name, or call it Quixote 3 but continue to support Quixote 2.
I've got another site due in September and I made a TG demo for it,
but I'm undecided whether to pursue TG or Quixote for the final. I'm
trying to decide what's best for our organization long term and what
I'll teach the new developers I'll be training. We don't want to have
too many frameworks or have to rewrite a lot of stuff as the state of
the art evolves.
I like TG's AJAX integration, JSON output, MVC, unified config file,
out-of-the-box database browser, control panel, and the work they've
put into composite widgets, internationalization, XML DOM
manipulation, etc. Basically, they've got a lot of developers
constantly contributing and peer-reviewing stuff, and one never knows
which component might be useful someday. But I'd rather use something
that's been peer-reviewed and I didn't have to write, rather than
reinventing the wheel, as I had to do with persistent sessions, SQL
generator, etc. I like all these components in theory, but I'm not
always happy with TG's implementation of them. I've had specific
problems with Kid, CherryPy, and SQLObject, it's three biggest
components. Partly because the projects are in such flux and
undocumented, but also due to their limitations. TG has implemented
pluggable templates (TurboCheetah, TurboStan, etc), and is
experimenting with replacing CherryPy with a minimal traversal library
(RhubarbTart) linked to Paste, and with replacing SQLObject with
SQLAlchemy. My own project is having problems with SQLite
performance, and I may have to substitute Durus or put the 30 MB
database into memory.
I get frustrated at having to learn to do things the TG way and
digging through the source coz they're not documented (and looking all
through TG/CherryPy/Kid/SQLObject's source to see which one implements
it), and thinking, "But this was so easy in Quixote!" That's what
pulls me back. But I don't want to miss out on components I might
need, or have to reimplement them in Quixote myself.
Since we're discussing Quixote 3, here's my wishlist:
- Native WSGI, supported coupling to Paste, and use of middleware for
Publisher functionality as much as feasable. This means a WSGI entry
point in the Publisher, and adapting the other servers to use it. This
will position us best for whatever useful third-party packages might appear
in the future. The code is already written (QWIP and SWUP); it just needs
to be incorporated.
- Add a Directory class that supports Routes. (http://routes.groovie.org/)
This provides an algorithmic choice of callable and converts URL
components to named arguments, with optional regex checking of
components. This may be preferrable to elaborate ._q_traverse methods
and ._q_lookup-returning-subdirectories in some applications.
- Borrow Directory features from TG:
* @expose(template, allow_json=False) wrapper plugs callable return
value (a dictionary) into a
template, thus providing an MVC and common page header/footer.
Or if user requests, convert dict to JSON and send to browser (this is for
AJAX). @expose also obviates the need for ._q_exports.
* @validate(form) handles input validation, although we'd have to
see how compatible that is with Quixote's form object, and whether
losing the ability to parse the value at any time is significant.
* Copy input values into named callable args or **kw. This would have to
be compatible with @validate.
* Convert remaining URL components to positional args. (May be
obviated by Routes.)
- Delete PTL, use QPY instead.
- Perhaps spin off the Form library into a separate package, to encourage
other frameworks to use it.
- Add egg info for the dependencies (QPY and Forms). Eggs and
easy_install make users happy.
- Make all classes new-style and Replace .get_* and .set_* methods with
Python properties. (I realize some people are ideologically
opposed to this.)
- Compare the other features in the megaframeworks and have a FAQ
explaining how to do these in Quixote. When multiple alternatives exist
(SQLObject, SQLAlchemy, Durus), list the tradeoffs of each. Quixote 2 needs
this too.
- Persistent sessions! Either QP's implementation or session2 would be
acceptable, but session2 would give the user more flexibility.
I've started a comparision of Quixote, QP, and TG, which will answer
the latter part. But I have to learn more about TG before I can
finish it. If anybody wants to help on this or the other stuff above,
let me know.
Here's my article about PyCon. It doesn't mention Quixote but has
some stuff about frameworks and TG.
http://linuxgazette.net/124/orr.html
--
Mike Orr
(mso@oz.net address is semi-reliable)