[Catalyst] "Catalyst::Plugin::Authentication uses NEXT, which is deprecated."

will at serensoft.com will at serensoft.com
Mon May 31 16:36:08 GMT 2010

Thanks for your patience, Tom Sahib. :)

We've been getting up to speed via the (Packt Publishing) book "Catalyst:
Accelerating Perl Web Application Development" by Jonathan Rockway, using
the paradigm introduced on p74. That's where we went astray:

use Catalyst qw/ConfigLoader Static::Simple
    Session Session::State::Cookie Session::Store::DBIC

We'd lost track of the config portion:

    default_realm =3D members
                class =3D DBIx::Class

Feeling much better now. Thanks!

On Mon, May 31, 2010 at 10:53 AM, Tomas Doran <bobtfish at bobtfish.net> wrote:

> On 31 May 2010, at 16:25, will at serensoft.com wrote:
>  Thanks Tom. I can see now that I was a bit fuzzy on my question, whoops =
>> On Mon, May 31, 2010 at 9:34 AM, Tomas Doran <bobtfish at bobtfish.net>
>> wrote:
>> On 31 May 2010, at 05:16, will at serensoft.com wrote:
>> Okay, we should uninstall the deprecated modules just to be sure our
>> dependencies are all clean, and we should use Catalyst::Authentication
>> instead of Catalyst::Plugin::Authentication...
>> We still use Catalyst::Plugin::Authentication to do the heavy lifting --
>> but it's not supposed to rely on
>> Catalyst::Plugin::Authentication::Store::DBIC, but rather
>> Catalyst::Authentication::Store::DBIx::Class instead, right?
>> The syntax for "use Catalyst qw//" is that it prepends "Catalyst::Plugin"
>> to the beginning of any module you ask for unless you prefix it with a "=
>> use Catalyst qw/
>>    Authentication
>>    +Catalyst::Authentication::Store::DBIx::Class
>> /;
>> Is that the recommended syntax?
> NO. You don't add the extra authentication stores / credentials to the
> plugin list, as they're not plugins.
> Plugins are overlaid onto the app (i.e. your MyApp class @ISA each of your
> plugins).
> The authentication credentials/stores/realms are delegate objects used to
> provide those things - your app doesn't inherit them.
> You set the new Plugin::Authentication up to work like this with the new
> modules in the way that is documented, which doesn't suggest anywhere doi=
> anything like that ^^^.
>  Would like to have a clean library with no deprecated stuff available to
>> fall back on. Disk space is cheap but that seems like saying I'll drive
>> around the countryside just for fun because gas is cheap. Trying "make
>> uninstall" didn't get me very far. Maybe there's a way to use ExtUtils to
>> create a packlist file...
> Erm, you're going to configure different stuff in your configuration, and
> so there is no chance that the old stuff will be 'fallen back on'.
> The old classes won't be loaded (as you're no longer putting them in your
> plugin config) and won't be used (as if the authentication plugin does the
> loading, it won't load the old-style ::Plugin:: auth modules)..
>  B) How do we make sure we're using the recommended Store/Credential
>> modules? This isn't something we specify via "use Catalyst qw/blah/" I t=
>> it.
>> Correct, you specify it by the authentication config (as documented in t=
>> Authentication plugin)
>> Documentation? You mean... read? :)
> Yes, I mean read, try, yell when it isn't clear, patch to make it more
> clear :)
> Cheers
> t0m
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/

-- =

will trillich
"It's only by saying 'no' that you can concentrate on the things that are
really important." -- Steve Jobs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100531/46b5e=

More information about the Catalyst mailing list