On 11/3/05, mario ruggier  wrote:
> - Rich client-side components and widgets, ajax, ... i'd say go with
> mochikit (as tg & subway have done).
>
> - Adopt a convention, a la mvc, to easily support returning response as
> data (json) or already rendered (similar to what tg does). I feel that
> this however should only be a recommended "convention", and not an
> imposition.

We should at least spec out what a TG-equivalent configuration of
Quixote would be, and make a HOWTO for it.  That would let people
compare the systems easier, and give the assurance that it's been done
before.  QPY is already going in that direction and I'd see the same
thing as valuable for it.  However, I don't think everybody will be
excited about Durus or some of QPY's unique design decisions, so I'd
rather not leave it as "let QPY worry about that; we don't need it for
Quixote".

Shalabh will point out that QLime has had an O-R mapper for some time,
and... I don't remember if it has an MVC.  But the most interesting
thing about TurboGears from my perspective is outputting a dictionary,
which the framework automatically attaches to a template or converts
to JSON.  And MochiKit, which I haven't looked at yet.  That would be
a good research project for Quixote.  I may get to it if nobody else
does first.

Agreed that this should be optional additions to Quixote, not built
into it.  QPY is a good model of how to experiment with alternate
implementations without wrecking the Quixote codebase for those who
don't want it to change.

--
Mike Orr  or