On 17 May 2002, Jonathan Corbet said:
> I currently have three application state objects:
>
> - User roles
> - Preferences/customization
> - "Where to go when you finish this general editing process"
>
> The first two can be (and are) stored in other places - keeping them in the
> session object just makes it easier to pull in everything quickly.  The
> third really is part of a session, and needs to be associated with it
> somehow.
>
> So, I guess I need a way to keep a small amount of stuff in the session
> object (or associated with it somehow).  It wouldn't be that hard to just
> add it directly to my derived version of that object.  The ApplicationState
> stuff does seem like a little bit more mechanism than I really need.

Right, just add instance attributes to your Session class:

  class LWNSession (Session):
      def __init__ (self, request, id):
          Session.__init__(self, request, id)
          self.user_roles = None
          self.user_prefs = None
          self.where_next = None

...and then your application code would update those three attributes as
the information becomes available.  If you're really anal, you'd write
modifier methods to make sure that you don't accidentally pass in the
wrong thing.

Now if you have a User class to hang off your Session class' 'user'
attribute, you could drop user_roles and user_prefs from your Session
class, and just write delegate accessor methods:

  class LWNSession (Session):
      def __init__ (self, request, id):
          Session.__init__(self, request, id)
          self.where_next = None

      def get_user_roles (self):
          if self.user:
              return self.user.roles
          else:
              return None

      def get_user_prefs (self):
          if self.user:
              return self.user.prefs
          else:
              return None

Depends on your preferred style, I guess.

By the way, this:

> - "Where to go when you finish this general editing process"

set off alarm bells.  We have tried to put context information in
session objects, and it always fails obscurely in the end.  Eg. on our
site, you don't have to login until you try to do something that
requires privilege.  So if you anonymously access (say) /private/ you're
redirected to /user/login, with the intention that once you have
successfully logged in, you'll be redirected back to /private/.  This is
surprisingly difficult to get right.  We originally put the "return URL"
in the session object, but for reasons that I cannot remember it didn't
work.  I'm pretty sure the !#^%@#^! "Back" button was involved.  We now
put it in the URL, so if you try to access /private/, you are redirected
to /user/login?/private/, which takes care of sending you to /private/
once you've logged in.  Ugly, but it seems to work most of the time.

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org