FAQ
Spinning this off into a new thread.
So make it a controller base class.

People make everything a plugin by default because it seems like a good idea
at the time. This has resulted in massive compatibility issues due to
namespace collisions.

Don't Do It.
I've pondered the "controller vs. plugin" choice myself several times,
and I see I'm not alone. I see the namespace issue with plugins, but
does the potential for conflict make all plugins evil? This is
another area where a clear best practices would be quite helpful.
Matt, could you share your thoughts on when it's appropriate to choose
a plugin over a base controller and vice versa?

I'm guessing plugins become necessary when you need to get your hooks
into a specific piece of Catalyst framework logic in order to achieve
your goal -- like overriding and extending a method. Is a controller
preferable in all other cases?

Anybody else have thoughts on this?

Search Discussions

  • Matt S Trout at Aug 18, 2006 at 1:40 am

    Mark Blythe wrote:
    Spinning this off into a new thread.
    So make it a controller base class.

    People make everything a plugin by default because it seems like a good idea
    at the time. This has resulted in massive compatibility issues due to
    namespace collisions.

    Don't Do It.
    I've pondered the "controller vs. plugin" choice myself several times,
    and I see I'm not alone. I see the namespace issue with plugins, but
    does the potential for conflict make all plugins evil? This is
    another area where a clear best practices would be quite helpful.
    Matt, could you share your thoughts on when it's appropriate to choose
    a plugin over a base controller and vice versa?

    I'm guessing plugins become necessary when you need to get your hooks
    into a specific piece of Catalyst framework logic in order to achieve
    your goal -- like overriding and extending a method. Is a controller
    preferable in all other cases?
    That and the request cycle. Other than that, it probably doesn't need to be a
    plugin. The main reason things have been made plugins is because it's (a)
    convenient, (b) there are existing examples, (c) "everybody else seems to be
    doing it", (d) the name "Plugin" makes people happy. I'd really quite like a
    similar system for having model, view, controller, engine and dispatcher
    plugins, but we don't have enough of them to figure out the use cases yet :(

    If your only argument is "I need $c" you can usually do a controller, view or
    model with an ACCEPT_CONTEXT method. Often you only actually need the app
    instance (i.e. the "MyApp" class name in 5.70) not the full request context.

    If you want to pass stuff to the view, an object or a subref in the stash is
    usually best.

    Things like Session and Authentication make perfect sense as plugins; form
    validators don't. It makes common controller base classes for CRUD or whatever
    (and yes, scaffolding code :) much harder because the form validators all seem
    to be plugins and, wahey, you can only have one $c->form method.

    --
    Matt S Trout Offering custom development, consultancy and support
    Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact
    Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information

    + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +
  • John Napiorkowski at Aug 18, 2006 at 6:54 am
    I've been thinking that a plugin is something that usefully hooks into the catalyst process, like authentication and sessioning or extends the existing functions, like the dumper plugin extends the log object. There are a lot of plugins to add convenience methods to the context object, like the datetime plugin, which are mostly thin wrappers around existing CPAN modules. This really just makes it so you don't have to add 'use xxxxx' at the top of each controller that needs it, but I can see trouble with this in terms of the namespace collision you mentioned. Also a lot of these convenience plugins don't offer the full functionality of the CPAN module they are wrapping and then you end up using it the normal way instead.

    I try to think of controllers are encapsulating some bit of logic that I want to reuse. Like I have a feed controller that takes a list of uris pointing to some sort of feed (rss, atom, etc) and returns each feed in a common translated format. This is something I need in several places on my site, so I just do a subrequest to an action which is subclassing that base controller. This could have been a plugin I guess but is seems more like a controller to me.

    On a side note if anyone has a working useful example of ACCEPT_CONTEXT I'd be glad to see it. I can see the value of this but no matter how often I reread the doc on it I just don't get it.

    --john


    ----- Original Message ----
    From: Matt S Trout <dbix-class at trout.me.uk>
    To: The elegant MVC web framework <catalyst at lists.rawmode.org>
    Sent: Friday, August 18, 2006 9:40:46 AM
    Subject: Re: [Catalyst] Plugins vs. Base Controllers

    Mark Blythe wrote:
    Spinning this off into a new thread.
    So make it a controller base class.

    People make everything a plugin by default because it seems like a good idea
    at the time. This has resulted in massive compatibility issues due to
    namespace collisions.

    Don't Do It.
    I've pondered the "controller vs. plugin" choice myself several times,
    and I see I'm not alone. I see the namespace issue with plugins, but
    does the potential for conflict make all plugins evil? This is
    another area where a clear best practices would be quite helpful.
    Matt, could you share your thoughts on when it's appropriate to choose
    a plugin over a base controller and vice versa?

    I'm guessing plugins become necessary when you need to get your hooks
    into a specific piece of Catalyst framework logic in order to achieve
    your goal -- like overriding and extending a method. Is a controller
    preferable in all other cases?
    That and the request cycle. Other than that, it probably doesn't need to be a
    plugin. The main reason things have been made plugins is because it's (a)
    convenient, (b) there are existing examples, (c) "everybody else seems to be
    doing it", (d) the name "Plugin" makes people happy. I'd really quite like a
    similar system for having model, view, controller, engine and dispatcher
    plugins, but we don't have enough of them to figure out the use cases yet :(

    If your only argument is "I need $c" you can usually do a controller, view or
    model with an ACCEPT_CONTEXT method. Often you only actually need the app
    instance (i.e. the "MyApp" class name in 5.70) not the full request context.

    If you want to pass stuff to the view, an object or a subref in the stash is
    usually best.

    Things like Session and Authentication make perfect sense as plugins; form
    validators don't. It makes common controller base classes for CRUD or whatever
    (and yes, scaffolding code :) much harder because the form validators all seem
    to be plugins and, wahey, you can only have one $c->form method.

    --
    Matt S Trout Offering custom development, consultancy and support
    Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact
    Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information

    + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +

    _______________________________________________
    List: Catalyst at lists.rawmode.org
    Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst at lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/
  • Matt S Trout at Aug 18, 2006 at 2:08 pm

    John Napiorkowski wrote:
    I've been thinking that a plugin is something that usefully hooks into the catalyst process, like authentication and sessioning or extends the existing functions, like the dumper plugin extends the log object.
    Actually, the Dumper plugin is strongly disrecommended for the moment; the
    author and I discussed on IRC and he had an epiphany and is figuring out a
    saner way to rewrite it.
    I try to think of controllers are encapsulating some bit of logic that I want to reuse. Like I have a feed controller that takes a list of uris pointing to some sort of feed (rss, atom, etc) and returns each feed in a common translated format. This is something I need in several places on my site, so I just do a subrequest to an action which is subclassing that base controller. This could have been a plugin I guess but is seems more like a controller to me.
    That's how I'd do it.
    On a side note if anyone has a working useful example of ACCEPT_CONTEXT I'd be glad to see it. I can see the value of this but no matter how often I reread the doc on it I just don't get it.
    C::M::DBIC::Schema injects an ACCEPT_CONTEXT method into the composed model
    classes to get the resultset return - something like

    package MyApp::Model::DB::Foo;

    sub ACCEPT_CONTEXT { my ($self, $c) = @_; return
    $c->model('DB')->schema->resultset('Foo'); }

    --
    Matt S Trout Offering custom development, consultancy and support
    Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact
    Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information

    + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +
  • Leonard A Jaffe at Aug 18, 2006 at 2:42 pm

    Matt S Trout <dbix-class at trout.me.uk> :: 08/18/2006 10:08 AM :

    John Napiorkowski wrote:
    That's how I'd do it.
    On a side note if anyone has a working useful example of
    ACCEPT_CONTEXT I'd be
    glad to see it. I can see the value of this but no matter how often I
    reread
    the doc on it I just don't get it.
    C::M::DBIC::Schema injects an ACCEPT_CONTEXT method into the composed model
    classes to get the resultset return - something like

    package MyApp::Model::DB::Foo;

    sub ACCEPT_CONTEXT { my ($self, $c) = @_; return
    $c->model('DB')->schema->resultset('Foo'); }
    Thanks. I'm much clearer on the concept now :-)

    Len.


    -----------------------------------------
    This transmission may contain information that is privileged,
    confidential, legally privileged, and/or exempt from disclosure
    under applicable law. If you are not the intended recipient, you
    are hereby notified that any disclosure, copying, distribution, or
    use of the information contained herein (including any reliance
    thereon) is STRICTLY PROHIBITED. Although this transmission and
    any attachments are believed to be free of any virus or other
    defect that might affect any computer system into which it is
    received and opened, it is the responsibility of the recipient to
    ensure that it is virus free and no responsibility is accepted by
    JPMorgan Chase & Co., its subsidiaries and affiliates, as
    applicable, for any loss or damage arising in any way from its use.
    If you received this transmission in error, please immediately
    contact the sender and destroy the material in its entirety,
    whether in electronic or hard copy format. Thank you.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.rawmode.org/pipermail/catalyst/attachments/20060818/07a894ee/attachment.htm
  • Krzysztof Krzyżaniak at Aug 30, 2006 at 11:18 am
    Matt S Trout wrote:

    [..]
    If your only argument is "I need $c" you can usually do a controller, view or
    model with an ACCEPT_CONTEXT method. Often you only actually need the app
    instance (i.e. the "MyApp" class name in 5.70) not the full request context.
    Could someone point me example (some basic template, existing code) of this?


    eloy
    --
    -------e-l-o-y---------------------------e-l-o-y- at -k-o-f-e-i-n-a-.-n-e-t------

    jak to dobrze, ?e s? oceany - bez nich by?oby jeszcze smutniej
  • John Napiorkowski at Aug 30, 2006 at 12:09 pm
    Check out the thread summary for this thread at: http://www.gossamer-threads.com/lists/catalyst/users/9312?search_string=Plugins%20vs.%20Base%20Controllers;#9312

    and toward the bottom Matt gives and example and pointed me to a module that was using it.

    --john

    ----- Original Message ----
    From: Krzysztof Krzyzaniak <eloy at kofeina.net>
    To: The elegant MVC web framework <catalyst at lists.rawmode.org>
    Sent: Wednesday, August 30, 2006 7:18:33 AM
    Subject: Re: [Catalyst] Plugins vs. Base Controllers

    Matt S Trout wrote:

    [..]
    If your only argument is "I need $c" you can usually do a controller, view or
    model with an ACCEPT_CONTEXT method. Often you only actually need the app
    instance (i.e. the "MyApp" class name in 5.70) not the full request context.
    Could someone point me example (some basic template, existing code) of this?


    eloy
    --
    -------e-l-o-y---------------------------e-l-o-y- at -k-o-f-e-i-n-a-.-n-e-t------

    jak to dobrze, ?e s? oceany - bez nich by?oby jeszcze smutniej

    _______________________________________________
    List: Catalyst at lists.rawmode.org
    Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst at lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/
  • Krzysztof Krzyżaniak at Aug 30, 2006 at 1:26 pm

    John Napiorkowski wrote:
    Check out the thread summary for this thread at: http://www.gossamer-threads.com/lists/catalyst/users/9312?search_string=Plugins%20vs.%20Base%20Controllers;#9312

    and toward the bottom Matt gives and example and pointed me to a module that was using it.

    --john

    ----- Original Message ----
    From: Krzysztof Krzyzaniak <eloy at kofeina.net>
    To: The elegant MVC web framework <catalyst at lists.rawmode.org>
    Sent: Wednesday, August 30, 2006 7:18:33 AM
    Subject: Re: [Catalyst] Plugins vs. Base Controllers

    Matt S Trout wrote:

    [..]
    If your only argument is "I need $c" you can usually do a controller, view or
    model with an ACCEPT_CONTEXT method. Often you only actually need the app
    instance (i.e. the "MyApp" class name in 5.70) not the full request context.
    Could someone point me example (some basic template, existing code) of this?
    Thank you, works like a charm.

    eloy
    --
    -------e-l-o-y---------------------------e-l-o-y- at -k-o-f-e-i-n-a-.-n-e-t------

    jak to dobrze, ?e s? oceany - bez nich by?oby jeszcze smutniej

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedAug 18, '06 at 1:21a
activeAug 30, '06 at 1:26p
posts8
users5
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2021 Grokbase