[dancer-users] Sessions in D2 (was Before Hook hit multiple times).

David Golden xdg at xdg.me
Fri Jan 4 20:57:48 GMT 2013


On Fri, Jan 4, 2013 at 2:27 PM, Alexis Sukrieh <sukria at sukria.net> wrote:
> Because you can have many engines defined.

Can you have many engines of a *type* defined?

Looking at Core::Role::Config, it doesn't look like it.

E.g. "session: YAML" goes and looks in "engines: session: YAML: ... ".

Even if you defined multiple things under engines, nothing I can see
would instantiate them or give access to them.

Consider:

    session: YAML
    engines:
      session:
        YAML:
          session_config:
            cookie_name: 'session.yaml.dancer'
            expires: 86400
      session:
        Sereal:
          session_config:
            cookie_name: 'session.sereal.dancer'
            expires: 86400

The engine() sub in Dancer::Core::App is just a wrapper around the
config hash, so engine("session") is actually grabbing the top level
session key (which has been inflated from "YAML" into an object).  It
doesn't grab something under engines.

Which also means that engines("random_config_setting") works and has
nothing to do with engines, which seems poor as well.

It would seem to make more sense to me to inflate everything under
engines (perhaps lazily), and have engines() return those, and let the
top-level "session" key define the default engine used to set the
'session' in the request context object (and thus available via the
DSL).

Then you could do:

    hook 'begin' => sub {
        var alt_session => engine( session => "Sereal" )->retrieve;
    };

    get "/" => sub {
        session Foo => "Bar"; # stored in YAML session
        alt_session Foo => "Baz"; #stored in Sereal session
    };

Admittedly, it's a bit complicated for sessions, since you need to
flush and set cookies at the end of the request.  (It woudn't be
terribly hard to do some accounting of them.)

But what I describe above generalizes to other engine types as well.

On the other hand, if multiple engines aren't desired, then you could
could eliminate the top-level key and just define everything under
engines:

    # session: YAML # unnecessary

    # simple
    engines:
      session: YAML

    # with config
    engines:
      session: # with config
        class: YAML
        session_config:
          cookie_name: 'session.yaml.dancer'
          expires: 86400
        session_dir: /tmp/dancer-session

(If value is scalar, use with default config; if hash, get class key
and pass rest to constructor.)

Or, avoid the whole 'engines' config abstraction:

    # simple
    session: YAML

    # with config
    session:
        class: YAML
        session_config:
          cookie_name: 'session.yaml.dancer'
          expires: 86400
        session_dir: /tmp/dancer-session

You're inflating off the top-level key anyway, so all "engines" is
doing is giving you a (redundant) place to park config data.

David

-- 
David Golden <xdg at xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg


More information about the dancer-users mailing list