Re: Re: What is the point of QP?

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