On Nov 1, 2005, at 10:41 AM, Michael Watkins wrote:
'specialized application framework' ... seems you may be on track there
Mario. One makes few choices for you; the other makes many choices.
With
Quixote you know what the publisher will look like, but sessions, User
management, persistence are all unknowns.
With qp you know what the basic web publishing environment stack will
look
like for any developer, from http through authentication to sessions,
User
and persistence. We might envision more sharing of 'applets' with such
a
backdrop. I wonder if that was one of the desired outcomes.
.... ya just better like the principal system architecture choices of
*nix and
Durus! This is where I spend my time anyway, so these choices do not
feel
like limitations to me but no doubt they will to some.
Unicode out of eh box is a great thing, as is qpy playing well with
pydoc. Now the tempting thing is how best, while still retaining all
the simplicity, to add the most attractive features of a full stack web
framework. What comes to mind, taking also inspirations from cursory
looks at other frameworks currently en vogue, is:
- Automatic admin interface (as django does currently). Most of this
functionality may be had for very little, from using a durus layer that
provides for rich model definitions, such as Schevo (that does offer
this feature already for other UI contexts, and may be very easy to
have it available also for qp) or moellus (does not do that yet). What
would be really nice here is if this interface will actually capitalize
on the fact that the model is real OO as opposed to a relational
mapping (Patrick, any thoughts here?). This could be an important
advantage and distinguishing feature, compared to the other
frameworks... Also, the utility control scripts that come with qp
should be extended to also access control options offered by the durus
layer being used, such as to init, update, evolve, etc the db as per
model creations, extensions or modifications.
- 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.
- Rich and automatic form and widget validation, or any other values
needing it, using the really nice spec module.
- Pluggable apps, or what you call applet sharing (similar to what
django does currently)
This would be really exciting....
mario
_______________________________________________
Quixote-users mailing list
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/quixote-users
