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() ?
mso@oz.net
2005-03-17
Ioan Coman wrote:
> But quixote.get_user()    should move to    Session.get_user()
> quixote.get_session()      should move to    RootDirectory.session
quixote.get_request()      should move to   RootDirectory.request
>
> with RootDirectory derived from Directory
>
> I am a beginner in using Quixote; I started apps with Quixote a few days
ago.
> And I found unusual to import and call:
>     from quixote import
> get_request,get_session,get_session_manager,get_field,get_user,get_publisher
when all are in quixote.publish and imported by __init__ ...
> but should belong to Directory.
>
> All RootDirectory or other kind of Directory should be inherited from
Directory

I can't speak authoritatively for Quixote (Neil and David can), but my
impression is these are part of the Quixote philosophy.  Other frameworks
like Webware and Zope require a directory or servlet to subclass a certain
class.  Quixote tries to be more flexible.  In Quixote 1, any object with
attributes (instance, class, module...) could represent a directory.  This
was one of the things that attracted me to Quixote in the first place.

It required code in the Publisher to do the traversal.  But there was a
desire to do this in userspace instead, so Quixote 2.0a2 streamlined the
Publisher and moved the traversal to the Directory.  This meant
directories suddenly had to be Directory instances.  I'm sure that
requirement was imposed reluctantly.  For 2.0a5 it they realized this rule
could be relaxed as long as the directory object has a compatible
.._q_traverse method/function.

So, allowing directories to be the widest possible variety of object is
incompatible with requiring it to support several methods/attributes that
are already available in other ways.

I did not like the Directory subclass requirement when it first appeared,
but after using Directories I began to like them.  I certainly like having
Directory classes better than servlet classes.  (In other frameworks like
Webware and PHP, the directory is a filesystem directory, and every URL
needs its own module file.)  With everything for one directory in the same
module, it makes it easier to see how each URL relates to the others.

Quixote has been moving in the direction of more quixote.get_*() functions
rather than fewer.  quixote.get_request(), quixote.get_session(),
quixote.get_user(), etc.  Again that was not my preference, but it has a
sound basis.  Quixote likes to decouple things, to not require that
functions be methods of certain classes.  This means that many things that
are standalone functions in Quixote (quixote.util.*, quixote.redirect())
would have to be methods of certain classes in Java/Webware-like
frameworks.    Also, even if they were methods, you can't always predict
which method will need which context object (context object meaning
anything accessible via quixote.get_*()).  And even if you could,
oftentimes you'd have to pass the object as an argument to one method just
so it can pass it through to another method.  It's easier to have
methods/functions just get the context objects they need directly from a
central registry, and that's one uniform way that works at any point in
the application.


reply