durusmail: quixote-users: "Template" components. Was: Why class 'Session' has no method get_user()?
Why class 'Session' has no method get_user() ?
2005-03-17
2005-03-17
2005-03-17
2005-03-17
2005-03-17
Why class 'Session' has no method get_user() ?
2005-03-17
Why class 'Session' has no method get_user() ?
2005-03-17
2005-03-17
2005-03-17
2005-03-17
2005-03-17
2005-03-17
Why class 'Session' has no method get_user() ?
Why class 'Session' has no method get_user() ?
Why class 'Session' has no method get_user() ?
2005-03-18
Why class 'Session' has no method get_user() ?
2005-03-18
Why class 'Session' has no method get_user() ?
2005-03-18
Why class 'Session' has no method get_user() ?
2005-03-18
Why class 'Session' has no method get_user() ?
"Template" components. Was: Why class 'Session' has no method get_user()?
2005-03-19
"Template" components. Was: Why class 'Session' has no method get_user()?
2005-03-19
Why class 'Session' has no method get_user() ?
2005-03-17
2005-03-17
2005-03-17
2005-03-17
2005-03-17
2005-03-17
"Template" components. Was: Why class 'Session' has no method get_user()?
Michael Watkins
2005-03-19
> way to do object publishing. However I expect much greater disagreements
> as to what a simple, minimal, Pythonic persistence or permission
> mechanism might be.

Agree completely.

> might lead to a stricter definition of what a Quixote
> application is, stripping us of some of the our current freedom in
> designing applications.

That would be my fear. I didn't choose *other* frameworks because I didn't
like whatever design choices or technology constraints they had made.

Perhaps the approach Quixote has made to session persistence could be used
as a model for an "extras" package - some basic and not so basic
implementations of persistance are available out of the box or with the
Dulcinea package as well as contributions from users.

We could take this a step further and create other basic building blocks -
as simple as possible to do the bare minimum, agree on a basic set of
functionality, and implement in as similar a manner as possible while
using different back ends in as Quixotic a manner as possible.

Just throwing an idea out there, the basics of the Dulcinea user
management system could be implemented with a SQLObject back end rather
than Durus fairly simply I think, although in Dulcinea there is quite a
lot of other, simpler, functionality in Dulcinea that could be used as a
base for other efforts.

And if not using Dulcinea as a base, taking the PyWebOff (
http://pyre.third-bit.com/pyweb/index.html ) approach - reimplement an
idea multiple ways (different persistence mechanisms / SQL DBs, Durus and
or ZODB, etc), but in similar, Quixotic, ways - still seems like a good
idea to me. If nothing else it would help new Quixote users to quickly get
functional prototypes up and running.

A skeleton application - how to structure an app - I also view as very
important, particularly for those new to python and especially those new
to python web development especially.

Perhaps this will be helpful to some readers - I've put up a sample of
Quixote + Dulcinea + Durus - the "toboso" example application from
http://www.mems-exchange.org/software/

Demo at:

http://demo.mikewatkins.net/

Create an id, logon as an admin, have at it. Maybe download Dulcinea and
Toboso code so you can see what's going on behind the scenes.

This is running using the "simple server" from Quixote and I'll leave it
up and running for a bit. I added the "news" and "feedback" and "links"
stock components from Dulcinea to give something else to play with other
than user management. Adding each to a site takes but a couple minutes.

(PS Dulcinea/Toboso folks: note Toboso is missing FeedbackDirectory and a
StaticDirectory for /images)

Cheers
Mike


reply