mpitts at a3its
Feb 4, 2009, 10:21 AM
Post #3 of 3
(671 views)
Permalink
|
> -----Original Message-----
> From: Tomas Doran [mailto:bobtfish[at]bobtfish.net]
> Sent: Wednesday, February 04, 2009 12:28 PM
> To: Development of the elegant MVC web framework
> Subject: Re: [Catalyst-dev] Another Session discussion
>
>
> On 4 Feb 2009, at 16:55, Matt Pitts wrote:
>
> > I started hacking on a Moose-based Session plugin that uses Roles
and
> > delegation to a specified $c->model for storage. My main
> justification
> > for this work is to just get my own gears turning, so these are just
> > ideas, and I'd be happy to scrap it there's already something
> started.
>
> There isn't anything started other than the vague ideas discussed the
> other day on irc.
>
> If you have _any_ code at all, please grab a commit bit and get a
> branch of Plugin::Session (even if you throw away all the code in it
> and start again) so that the code is public - as quite a lot of
> people prefer to read code than to read text, and it'll also be nice
> to capture the entire development from beginning to end in revision
> history.
Agreed. What do I need to provide - htpasswd line?
> > A Roles distribution:
>
> Are you thinking of this as actually a different dist, or as part of
> the session plugin? As Session::Store::XXXX will require
> Plugin::Session, so I don't see an issue bundling it in the main
> session dist.
Yes, that way anybody that wants to implement the Roles can do so
without having the whole P::Session dist.
> >
> > Catalyst::Role::Session
>
> <snip>
>
> > Catalyst::Role::Session::Flash
> > - the basic methods necessary for flash functionality
> > - interface
> > requires 'flash';
> > requires 'clear_flash';
> > requires 'keep_flash';
>
> Flash is a _bad idea_ as its not tab safe, so I'd only be supporting
> flash for backwards compatibility - I don't think there is any value
> to providing a new interface on ways to fail ;)
But Flash *could* be tab safe if the storage backend is tab safe, i.e.
HTML 5 "Structured client-side storage". Although, I don't claim to be
an expert so maybe I'm just talking out my ass. I really like the flash
functionality, though.
> > Catalyst::Role::Session::Store
> > - the basic methods necessary to implement a storage backend
>
> <snip>
>
> > The Main P::Session distribution:
> >
> > Catalyst::Plugin::Session
> > - consumes Catalyst::Role::Session
> > - gets $self->_session_model from
> > $c->model($self->_session_model_class)
> > - ensures that
> > $self->_session_model->has_role('Catalyst::Role::Session::Store')
> > - delegates many functions to $self->_session_model
>
> It would be nice to be able to use _any model_ at all for session
> storage, even one which hadn't been specifically 'sessionified' (I'm
> thinking specifically Catalyst::Model::Adaptor type models etc).
>
> However there is nothing to stop you having a way to apply the role
> (which is just checking requirements really) to an arbitrary model...
> Worth thinking about anyway..
Yeah, I was actually wondering about that myself. I think it could be a
combination of both, but because of the Roles and the fact that
P::Session would already delegate much of the functionality to the
model, I would think it easier to write a C::M::Session::SomeCustomStore
that consumes C::R::Session::Store rather than a C::Model::Adapter based
model. As always, though, I'm sure someone would have a situation where
they'd want to.
> > Catalyst::Model::Session::Cookie
> > - consumes Catalyst::Role::Session::Store
> >
> > Catalyst::Model::Session::DBIC
> > - consumes Catalyst::Role::Session::Store
> >
> > Catalyst::Model::Session::ImaginarySomething
> > - consumes Catalyst::Role::Session::Store
>
> How do things which don't have a store (such as, for example,
> something like Catalyst::Plugin::CookiedSession) fit into this scheme?
I'm not really thinking of an all-in-one case, but for C::P::CP I see
one of two ways:
1. Catalyt::Model::Session::Cookie would deprecate it because it would
provide the same functionality under the new P::Session system
2. CookiedSession could be refactored to consume
'Catalyst::Role::Session'; thereby providing a lightweight session
implementer that skips all the unnecessary model(ing). This goes back to
having C::Roles::Session as a separate distribution. One big issue here,
of course, is that existing plugins (Authentication is the big one) that
$c->isa('C::P::Session') will still not work with CookiedSession.
> > And that's about as far as I got, I thought I'd get opinions before
> > more
> > model starts coming about of my head. BTW, none of this actually
> works
> > yet, it's just conceptualize code.
>
> Good call.
>
> Maybe worth taking a round of feedback and then writing 'the plan' up
> in some text format in subversion so that anyone interested can check
> back on (and again, we have versioned history with comments as the
> plan evolves in the face of trying to actually implement it).
Agreed.
> > Oh, and I'm not even thinking about
> > compat right now.
>
> Totally fair. Plan the new thing, get a prototype up to prove the
> 'plan' works, _then_ start thinking about how compat fits into the
> picture before everything is finalised..
>
> Good stuff, and well volunteered - its nice to see session getting
> the redesign it needs / deserves.
Thanks!
v/r
-matt pitts
_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
|
