[Catalyst] Subsessions?

Hello,

there are currently two Problems I could easily solve with subsessions.

After saving some data I want to redirect the user back to where he came.
So I'd like to keep track where the user came from. As I expect the User
to use several Browser windows, neither Cookie based Sessions (incl.
stash) work in all scenarios. Right now I'm using the HTTP Referer, which
I'm also considering a bit clumsy.

Furtermore there are users who have access to other users' data. I'd like
them to select them *once* which user's data they want to work on and keep
this for the current browser window. Again I expect the user to use
multiple browser windows (say for working with multiple users' data at the
same time).

So I'm searching for something functional similar to:
http://paneris.net/cgi-bin/cvsweb.cgi/SubSession/SubSessions.html?rev=1.3

I've had no luck finding something similar for Catalyst. Well,
Catalyst::Plugin::Session::State::URI gives me some Ideas on how I could
implement this, but if possible I'd prefer to avoid re-inventing the
wheel (especially as I expect this to be non-trivial).

Rainer

A somewhat naive idea:

sub session {
my $c = shift;

if ( my $sub = $self->subsession_id ) {
  return $self->NEXT::session->{$sub} ||= {};
} else {
  $self->NEXT::session(@_);
}
}

subsession_id can be some param I suppose like in State::URI. You
can probably subclass State::URI to make it so that it doesn't plug
into the session system, but instead goes to subsession_id, or just
keep track of it manually.

Cheers,

Interesting.  I usually use GET parameters for that - but I can
imagine where it would become not enough.

Yuval Kogman wrote:
> sub session {
[...]
> return $self->NEXT::session->{$sub} ||= {};


Zbigniew Lukasiak wrote:
> On 9/27/07, Rainer Clasen <bj@zuto.de> wrote:
> > So I'm searching for something functional similar to:
> > http://paneris.net/cgi-bin/cvsweb.cgi/SubSession/SubSessions.html?rev=1.3
> >
>
> Interesting. I usually use GET parameters for that - but I can
> imagine where it would become not enough.

Thanks to both of you. Your responses helped a lot to sort my Ideas and
hack up my initial "poor man" / proof of concept solution:

- subsession ids are generated with c->generate_session_id from the
  Session Plugin.
- subsession data is stored as $c->session->{SUBSESSION}{$ssid}
- ssid is picked from $c->param
- uri_for automagically sets ssid
- all internal links are constructed with uri_for()
- change of subsession data doesn't yet cause a new ssid to be assigned.
  This comes later. Up to then it has to be done manually with
  subsession_next.
- You cannot change subsession data after you've shown the subsession id
  to the client (i.e. you've used uri_for).

So far this seems to work fine, but it needs a bit more testing (and
documentation).


Rainer

You’re asking the wrong question. Sessions are a bad idea in
general; application state should live on the client, not the
server. All state on the server should be resource state, ie it
should have a URI of its own.

I don’t use sessions *at all*[1], so my apps have all of the
properties you describe above without any effort on my part.
Basically the way you are designing your app goes against HTTP’s
grain. Work with HTTP rather than against it and you will get
simpler designs that work more robustly.

A context-free explanation of the design principles would take us
too far afield here; for that, I can warmly recommend O’Reilly’s
_RESTful Web Services_.

> Furtermore there are users who have access to other users'
> data. I'd like them to select them *once* which user's data
> they want to work on and keep this for the current browser
> window. Again I expect the user to use multiple browser windows
> (say for working with multiple users' data at the same time).

Bake the selection into the URI. That solves the problem without
any weird machinery on the server.

If you explain how your form interactions look like and what sort
of data you want to put into these subsessions, I could make some
suggestions for how to structure your URIs and the actions on
them to achieve the same goals without sessions.

> I've had no luck finding something similar for Catalyst.

Sometimes, no code has been written to solve a problem because no
code is necessary. :-)


[1] And my only use for cookies is to store an auth token.
    I’d prefer to avoid them entirely, but the HTTP auth
    implementation in browsers is atrocious even today.

Regards,

For what it's worth, I agree.

Sessions are like a half assed model with automagical fetching of
the resource to save some time. The moment the app becomes dependant
on this from a design POV things get nasty quite fast.

Think long and hard if your heavy use of the session is not better
done as some proper model.

Cheers,

A. Pagaltzis wrote:
> You???re asking the wrong question. Sessions are a bad idea in
> general; application state should live on the client, not the
> server. All state on the server should be resource state, ie it
> should have a URI of its own.

I also consider "normal" sessions evil. My subsessions are still ugly, but
at least they keep the state control in the client.

The subsessions were my answer, when I failed to setup the Chained
Dispatcher according to my laziness. And once available, subsessions
became the quick answer to other questions. Woken up by your feedback I'll
give the Chain another try (and actually it seems a lot easier having won
some Catalyst insight during the Subsession efforts).

So the "select a user once" is kind of solved.

Is there an elegant way to keep track of where the user came from? I
consider my Referer-based redirect after edit/delete/add actions a bit
clumsy.

Well, I could add edit/delete/add actions to each context to where I'd
like to call them:

/diary/<diary_id>/edit
/calendar/2007/9/30/diary/<diary_id>/edit
/calendar/2007/9/30/diary/add

But what about the "diary/add" link in my navbar? Does this mean I have to
put a ".../diary/add" action into each context?

And how shall I deal with GET/POST parameters of the referring context?
Say I want to call "/diary/search/<diary_id>/edit" from
/diary/search?notes="regexp"&daybegin="2007-09-01"

Is there a "best practice" for this? Is this something answered by the the
mentioned oReily book?

Rainer