durusmail: quixote-users: 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
Why class 'Session' has no method get_user() ?
Mike Orr
2005-03-18
Michele Simionato wrote:

>On Thu, 17 Mar 2005 19:48:39 -0800, Shalabh Chaturvedi
> wrote:
>
>
>> > Regarding persistence, are you talking about one of my earlier
>> > e-mails?  I
>> > would like to see Quixote come with "batteries included", yes.
>>
>>Note that a free set of Quixote batteries can be downloaded anytime from
>>qlime.org ;) And while I'm shoving in plugs - cafepy.com now runs
>>Quixote + QLime on the main site - (not that there's much content there).
>>
>>Seriously, though, I think newbies will be happier if a few more things
>>work out of the box (a simple session persistence to picked file, for
>>example). I'm -0 on including Dulcinea though. Some good utilities are
>>already there (StaticFile etc.) and more could be picked up from the
>>wiki or submissions. However do the core developers really have the
>>resources to maintain all these other things? Hmm.. or should outside
>>developers (that's us!) start a quixote-extras project on SF?
>>
>>
>
>This is a most interesting observation ;)
>Seriously, I was attracted by Quixote minimalism, so I agree with the
>small core concept. OTOH, as Mike says, nearly all real Web applications
>require persistence, user management, etc. so it would have sense
>to have a standard default library providing that.
>

I was attracted to Quixote because of its minimalist approach, much
smaller than other web application servers, yet every "essential" I
needed was there: cookies, sessions, form management, etc, along with
hooks for every extra you might need to add.  Moving _q_traverse out of
the Publisher was a brilliant idea because it makes the Publisher much
easier to understand, while at the same time providing a nice hook for
any kind of traversal manipulation you want: login traps, header/footer
wrappers, etc.

But as time goes on I find more essentials I wish Quixote had (things
that David doesn't necessarily agree are essential :).  In my mind,
Quixote or Quixote+batteries should come with everything one needs to
build a straightforward professional app.  Session persistence first
off, maybe a login scheme, permissions scheme, login/permissions
integrated with User object, etc.  The DirMapping in Quixote 1.2, for
instance.  It solves the persistence problem in a straightforward way,
doesn't require third-party software, and scales to at least
moderately-sized applications.  I copied it into my project and just
assumed it remained in the demo directory, only to discover recently
that it had been dropped several alphas ago.  I had to add flock calls
to deal with concurrence, but other than that it works admirably, much
better than shelve.  (Which blew up with corruption errors on one
computer, presumably because DBM files aren't concurrency-safe.)  I
would call it FileSessionManager or something rather than DirMapping,
but it would make an excellent battery.

Could we do the same thing for a login/permissions/User scheme?
Something minimal for smallish sites that could be subclassed for larger
sites?  Maybe provide a few implementations to choose from.  Maybe have
the DirMapping mechanism plus an optional DB-API thing.

To somebody new to Quixote, expecting them to install Durus or Dulcinea
or QLime for these features is not very attractive.  They may be good
products, but the user isn't convinced of that yet.  The user is still
trying to get his head around Quixote, and now he's told to trust yet
another large package, one that is newer/less polished/less widely
used/less documented than Quixote.  Perhaps parts of Dulcinea or QLime,
if made standalone, could fit into this "batteries" role, but right now
I think they're too big and integrated for that.

>
>Concerning the idea of the quixote-extras project: I like the idea, but
>we need to guarantee an overall consistency of the batteries. I mean,
>not every contribution can go into it, the core Quixote developers
>must coordinate the efforts. This mean they would have a lot of time
>to spend just in discussions with the contributors: are they willing to
>spend all that time?
>
>

Webware has a separate SourceForge project, the Webware Sandbox, where
any developer can create his/her own directory and upload projects,
whether finished or unfinished.  The more useful code gets advertised by
word of mouth, and when it's ready it can be pulled into an official
"batteries" package.

http://webware-sandbox.sourceforge.net/



reply