[prev in list] [next in list] [prev in thread] [next in thread] 

List:       twig-devel
Subject:    RE: [twig-devel] Session changing
From:       "Greg Ross" <greg () darkphoton ! com>
Date:       2000-04-26 22:43:25
[Download RAW message or body]


	You should be able to use the extended version of TWIGLink() to accomplish
anything you need for the view settings that need to modify session and
context.  However since the mail view settings are more related to an
individual message instead of being in the scope of a feature or all of twig
it probably makes more sense to keep them seperate from session or context
so they get 'dropped' from the environment as a message is closed.

	The extensions to TWIGLink(), TWIGSession() and TWIGContext() should take
are of the majority of cases where session and context need to be changed.
However there will always be exceptions to the rule ;)

							Greg

> -----Original Message-----
> From: m. allan noah [mailto:anoah@pfeiffer.edu]
> Sent: Wednesday, April 26, 2000 5:10 PM
> To: twig-devel@screwdriver.net
> Subject: Re: [twig-devel] Session changing
>
>
> yes- i have been in need of this for handling the viewing of
> attachments and
> headers in mail. i had considered making the changes to the
> session directly,
> but that sucks for modularity.
>
> the way the apps i write for work are coded, we dont print anything to the
> screen till the entire page is rendered, and we run regex over
> the completed
> page to substitute in the session info, etc. i realize this is
> pretty far off
> from twig, but without someway to atleast modify the session, we
> end up with
> each module designer doing lots of silly stuff on his own.
>
> look at how the msgview code looks for a sep. view[] and $ns
> variables in the
> url....
>
> allan
>
> Craig Foster <craig@wiw.org> said:
>
> > As I have been looking at the group changing problems in
> schedule as well as
> how our various
> > listing codes work (newlist in contacts, list in todo and bookmarks,
> integrated listing routines
> > in schedule).  It has struck me again how clumsy our session
> changing code
> it.  Basicly there is
> > no real way (with the possible exception of the recent changes
> to TWIGlink)
> to change session
> > variables built into the overall TWIG framework.  As a result,
> each module
> has different ways of
> > working around this.  For changes in sorting methos or directions, TWIG
> sends a module specific
> > variable in the URL which the module then interprets and
> changes the session
> values from those
> > already contained in the session information to those contained in the
> special variables.
> > Likewise with changing groups...each module has a slightly
> different way of
> doing this, and then
> > the groups code has its own approach (i.e. looking to see if
> $data_thisGroup
> exists).
> >
> > How about a unified way of changing session values?  The
> simplest way I can
> think of is to put an
> > array of modified session variables into the URL (something like
> > newsession[sortby]=date&newsession[sortbyway]=1) and then right after
> retrieving the session
> > information ($session = TWIGGetSession();  I think this is line 61 of
> index.php3 in the CVS
> > version) we could modify the currect session using the newsession array:
> >
> > while(list($key,$val) = each ($newsession)) { $session[$key]=$val; }
> >
> >
> > Then we could clean all of the redundant code out of the
> various modules and
> groups code for
> > changing sorting, groups, and the like, and do it all with that
> simple bit
> of code in
> > index.php3.  This is basicly the same method we are alrady
> using, but it is
> centralized.  But
> > since this involved a change to the basic TWIG framework, I thought it
> deserved mention to the
> > group before actually making the change.
> >
> > --
> > Craig Foster
> > craig@wiw.org
> >
> >
> >
>
>
>
> --
>
>
>

[prev in list] [next in list] [prev in thread] [next in thread]