Perlblogs » moose

Loaded for Werewolf

chromatic — Thu, 08 Mar 2012 23:47:39 +0000

Legend has it that Jean Chastel fired two shots and killed the beast of Gévaudan.

The beast attacked livestock and people in south-central France in the middle of the 18th century. Some say the beast killed over a hundred people. The attacks ended after the deaths of two large wolves—one in 1765 and the other by Chastel in 1767.

By the 20th century the legend had grown to include the story that Chastel had melted down a medallion of the Virgin Mary to make two bullets of silver.

In 1986, Fred Brooks used this metaphor to propose that no single technology nor management technique could produce an order of magnitude improvement in productivity, reliability, or simplicity within the decade. (Most people get this quote very wrong. Most people haven't read the paper in detail or at all.)

Perl 1 entered the public world in 1987.

Today (while solving hard problems), I realized that Moose and its ecosystem—including projects it's inspired, such as other declarative mechanisms for describing classes and objects—may just represent an order of magnitude improvement in productivity, reliability, and simplicity.

I write a lot less code. I write less repetitive code. My code is easier to read and to maintain. My code is much more correct. My code is much more flexible and easier to test. (Compilation error messages are much worse. That doesn't bother me terribly, but keep it in mind.)

Keep your blessed hash references all you want and lament that kids these days don't have to walk uphill in the snow both ways to stuff things in package global variables like @INC and that we're lazy, fat slobs for using CPAN modules for what you have done by hand since 1994, just as Moses did and King James always intended...

... but I'm loaded for werewolf.

The Memoization of Lazy Attributes

chromatic — Mon, 27 Feb 2012 18:45:41 +0000

Great software changes the way you use computers. Great languages, libraries, and tools change the way you code. Moose qualifies as great.

Moose includes a feature known as attribute builders. When you declare the attributes of an object, you can specify default values:

use Moose;

has 'name', is => 'ro', default => 'Binky';

When someone builds a new object of this type, they can provide a name for the object, or get a default name of Binky.

For more dynamic behavior, provide a function reference as the default. For example, if an object needs to know its creation time (and not the time the system started):

use Moose;
use DateTime;

has 'birthtime', is => 'ro', default => sub { DateTime->now };

For even more flexibility, you can use the name of a method as the builder. This allows you to customize the behavior further with a subclass, role, or other mechanism:

use Moose;
use DateTime;

has 'birthtime', is => 'ro', builder => '_build_birthtime';

sub _build_birthtime { DateTime->now };

Overriding this builder is easy (far easier than intercepting all calls to the object's constructor.) As another benefit, you know that because Moose calls this builder during object construction, your object always gets constructed in a consistent, known-good state. You can rely on it being correct throughout the rest of its lifespan. (Obviously you have to avoid poking into it to do the wrong things, but that's up to you.)

This feature in and of itself would be good, but Moose went further to make it great. If you specify the attribute builder as lazy, Moose will only call the builder when someone uses the attribute's accessor:

use Moose;
use DateTime;

has 'first_access_time', is   => 'ro', builder => '_build_firstaccesstime',
                         lazy => 1;

sub _build_firstaccesstime { DateTime->now };

This makes the most sense when calculating an attribute is somehow expensive or the use of an attribute is rare. For example, I have an object which represents the calculation and projection of ten year free cash flow growth of a stock (like earnings, but measures liquid assets and less prone to manipulation via accrual accounting methods). This object is responsible for calculating the projected ten year average growth rate in free cash flow and produces a graph of ten year trailing free cash flow, the trendline for those ten years and ten years in the future, and projected growth curve ten years in the future.

That requires some math.

That math has a lot of interdependencies. Finding a good trendline for earnings which fluctuate means statistical analysis, such as with Statistics::Basic::LeastSquareFit. As it happens, the lazy lsf attribute nicely encapsulates that statistics object. Further, the growth rate is another lazy attribute, as are the sets of points of the trendline and the trend curve.

While the original proof of concept of this code performed all of the calculations in one large function of a couple of hundred lines, the current code is several methods of 10 - 50 lines apiece, with much better calculation accuracy, and better factoring. This is all thanks to Moose's lazy attributes.

The monolithic code was monolithic because I wanted to calculate everything once and only once: growth rate, number of points on the lines and curves, everything. Variables would stay in scope over tens and hundreds of lines because I'd need to use them later.

By factoring individual calculations into their own lazy builders, I can call the accessors when I need attribute data and everything snaps into place behind the scenes thanks to Moose. Oh, and if I've already calculated the data for the object, it's already there, and I don't have to recalculate it.

Lazy attributes give me memoization for free, and I don't even have to think about the data dependency graph of my calculations. It's an emergent property of the source code. That's one more step in expressing what I want to happen and not how to make it happen. Thanks, Moose!

You’re Already Using Dependency Injection

chromatic — Thu, 11 Aug 2011 17:07:18 +0000

Ben Hengst gave a talk at Portland Perl Mongers last night about dependency injection and inversion of control in Perl. He said something completely true. "You've probably already done this, even though you didn't know it was called this."

At its core, dependency injection is a formalization of the design principle "Don't hard-code your dependencies." Consider the code:

sub fetch
{
    my ($self, $uri) = @_;
    my $ua           = LWP::UserAgent->new;
    my $resp         = $ua->get( $uri );

    ...
}

That's not bad code by any means, but it's a little too specific and a little less generic due to the presence of the literal string LWP::UserAgent. That might be fine for your application, but that hard-coding introduces a coupling that can work against other uses of this code. Imagine testing this code, for example. While you could use Test::MockObject to intercept calls to LWP::UserAgent's constructor, that approach manipulates Perl symbol tables to work around a hard coded dependency.

An alternate approach uses a touch of indirection to allow for greater genericity:

use Moose;
has 'ua', is => 'ro', default => sub { LWP::UserAgent->new };

sub fetch
{
    my ($self, $uri) = @_;
    my $ua           = $self->ua;
    my $resp         = $ua->get( $uri );

    ...
}

Now the choice of user agent is up to the code which constructs this object. If it provides a ua to the constructor, fetch() will use that. Otherwise, the default behavior is to use LWP::UserAgent as before.

Adding one line of code and changing one line of code has provided much more flexibility.

An alternate approach is to allow setting ua through an accessor instead of a constructor, but as far as I can tell the only reason to do this is if you're stuck in The Land of the Java Bean Eaters.

While the existing literature on inversion of control and dependency injection tends to throw around big words which have the effect of obfuscating rather than enlightening, the basic concepts is simple. You've probably already done it. Now you know what it's called and why it's useful, and probably also can find ways to use it where it helps.

(See also: how you select a DBD with DBI.)

Making Catalyst Session Flash Methody

chromatic — Thu, 09 Jun 2011 22:08:32 +0000

I have a handful of modest Catalyst applications and will undoubtedly have more. One of the reasons I enjoy working with Perl 5 so much is that it's reasonably easy to solve a problem experienced in multiple places, extract that solution, and generalize and publish it for other people. The modern Perl world only makes that easier with Moose, CPAN, and even Github.

Sometimes that ease moves the problem around, which reinforces the notion that the only two hard problems in computer science are naming and caching. To abuse that truism, once I've found a workable solution, the hard part is figuring out what to call it and how to make it available to other people.

Take the flash feature of Catalyst's Catalyst::Plugin::Session. It resembles the stash, in that you can store and retrieve information in and from the flash, but that data is only available until the first request which uses it. This is incredibly handy for user notifications, such as "You missed a required entry field!" or "Your interaction succeeded!", especially when combined with the Humane JS library.

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

Yet every time I write that code, it feels slightly wrong, as if I'm violating encapsulation by updating the variable behind the flash directly. It's also prone to typos and has the whiff of violating the Law of Demeter.

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

... where my actions don't have to know about the internals of how the flash stores its data, where I don't have the possibility of stomping all over the array references accidentally, and where I can replace syntax (the grotty Perl 5 reference syntax!) with a method which describes my intent.

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

This approach has (at least) two problems. First, while I'm happy to make this code available to other developers, I don't want to add any difficulties to use other plugins which may themselves extend or modify Catalyst::Plugin::Session.

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

I have a hash. I want named methods to store application-specific data in that hash. I would like the ability to customize that set of methods methods without hard-coding them, so as to produce a component that multiple people can reuse in multiple applications.

You can see why a big bag of untyped stuff (a hash) is useful.

What I really need is a way to say "My application will use these and only these specific elements of the flash, so please produce methods for them." Fortunately, I have one in MooseX::Role::Parameterized. The consumer of this code looks like:

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

This code does have some naïve in it. In particular, it ought to use a smarter pluralization scheme. As well, the interface bothers me in two places. I'm not sure that the module's name is correct. I also don't particularly like that using this role means creating a new class of ~10 lines to make the code available as a Catalyst plugin (though how one might expand Catalyst's import() to understand how to reify a parametric role given the appropriate parameters is beyond my language design skills today).

Then again, my ~10 line plugin which consumes this role does work across my multiple Catalyst applications, at the cost of one more file and nine more lines of code altogether. The ratio of code per method decreases substantially with each new method I add, though.

I had originally intended to improve stash handling in this fashion, but but that's much more work. Neither Catalyst's core nor any other plugin I currently use rely on the presence of flash, so the scope of this work was much smaller. Even if they did, this approach does not prevent anything else from poking into the flash for good or ill.

Making Catalyst Session Flash Methody

chromatic — Thu, 09 Jun 2011 22:08:32 +0000

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

You can see why a big bag of untyped stuff (a hash) is useful.

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

Making Catalyst Session Flash Methody

chromatic — Thu, 09 Jun 2011 22:08:32 +0000

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

You can see why a big bag of untyped stuff (a hash) is useful.

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

Making Catalyst Session Flash Methody

chromatic — Thu, 09 Jun 2011 22:08:32 +0000

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

You can see why a big bag of untyped stuff (a hash) is useful.

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

Making Catalyst Session Flash Methody

chromatic — Thu, 09 Jun 2011 22:08:32 +0000

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

You can see why a big bag of untyped stuff (a hash) is useful.

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

Making Catalyst Session Flash Methody

chromatic — Thu, 09 Jun 2011 22:08:32 +0000

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

You can see why a big bag of untyped stuff (a hash) is useful.

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

Making Catalyst Session Flash Methody

chromatic — Thu, 09 Jun 2011 22:08:32 +0000

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

You can see why a big bag of untyped stuff (a hash) is useful.

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;