Modern Perl

Catalyst Advent Wrap Up And Thoughts

There was a few later additions to the Catalyst Advent for 2012, which happened due to trouble I had with my Internet connection.  If you didn't look lately you should glance at:

http://www.catalystframework.org/calendar

And in particular please check out Day 26 which is a great retrospective on choosing Catalyst from a technology platforms perspective.

There was a conversation over on the Catalyst mailing list regarding the depth of articles for Catalyst Advent over the years.  One thought I suggested was we could do worse than to identify some of the better articles over the years, modernize them if necessary and do a bit of Peer review to make them even better, and then wrap them up into a ebook or similar.

Octavian, that superhero that did NINE advent articles, jumped right on it and suggested the following:

(2005) Catalyst Advent - Day 11 - Caching
http://www.catalystframework.org/calendar/2005/11

(2007) Making your Catalyst App Cache-friendly
http://www.catalystframework.org/calendar/2007/11

(2010) Painless Memcached Configuration With Catalyst & DBIx::Class
http://www.catalystframework.org/calendar/2010/3

(2005) Catalyst Advent - Day 15 - Sessions
http://www.catalystframework.org/calendar/2005/15

(2005) Catalyst Advent - Day 16 - Adding RSS feeds
http://www.catalystframework.org/calendar/2005/16

If there are better ways to add an RSS feed, it should be modernized.

(2005) Catalyst Advent - Day 18 - Catalyst::View::TT
http://www.catalystframework.org/calendar/2005/18

(2005) Catalyst Advent - Day 19 - Testing
http://www.catalystframework.org/calendar/2005/19

(2006) Day 7 - Testing with an External Web Server
http://www.catalystframework.org/calendar/2006/7

(2006) Day 17 - Testing Catalyst Controllers
http://www.catalystframework.org/calendar/2006/17

Eventually create a single big article or a serie of articles regarding testing.

(2005) Catalyst Advent - Day 22 - Action Types
http://www.catalystframework.org/calendar/2005/22

(2005) Catalyst Advent - Day 23 - Static::Simple
http://www.catalystframework.org/calendar/2005/23

(2009) Delivering Static Media with Catalyst
http://www.catalystframework.org/calendar/2009/16


(2006) Day 1 - Getting started with Catalyst and Subversion
http://www.catalystframework.org/calendar/2006/1

Maybe it can be modernized to use distributed source control systems like git and mercurial.

(2006) Day 2 - Handel
http://www.catalystframework.org/calendar/2006/2

(2007) A Future Look at Mango
http://www.catalystframework.org/calendar/2007/12

(2006) Day 3 - The Layout of a Catalyst Application
http://www.catalystframework.org/calendar/2006/3

(2006) Day 9 - Web Services with Catalyst::Action::REST
http://www.catalystframework.org/calendar/2006/9

(2009) Writing REST web services with Catalyst::Controller::REST
http://www.catalystframework.org/calendar/2009/19

(2006) Day 10 - The Chained Dispatch Type
http://www.catalystframework.org/calendar/2006/10

(2006) Day 13 - Adding Custom Headers
http://www.catalystframework.org/calendar/2006/13

(2006) Day 18 - I18N
http://www.catalystframework.org/calendar/2006/18

(2010) Internationalising Catalyst, Part 1
http://www.catalystframework.org/calendar/2010/9

(2010) Internationalising Catalyst, Part 2
http://www.catalystframework.org/calendar/2010/20

(2006) Day 24 - The Catalyst Community
http://www.catalystframework.org/calendar/2006/24

:-)

(2007) Application Design Techniques
http://www.catalystframework.org/calendar/2007/3

(2007) Catalyst + Open Flash Chart: Fancy graphs with minimal fuss
http://www.catalystframework.org/calendar/2007/4

(2008) Making sparklines with Chart::Clicker
http://www.catalystframework.org/calendar/2008/3

(2012) DRAWING GRAPH CHARTS
http://www.catalystframework.org/calendar/2012/19

(2007) Adding Authentication to your Catalyst App
http://www.catalystframework.org/calendar/2007/5

(2007) Inline Authentication Without Redirection
http://www.catalystframework.org/calendar/2007/6

(2008) Progressive Authentication with Catalyst (Using OpenID)
http://www.catalystframework.org/calendar/2008/19

(2011) Login, Authorization and User Administration
http://www.catalystframework.org/calendar/2011/15

(2007) local::lib and Catalyst
http://www.catalystframework.org/calendar/2007/8

(2007) Day 13 - $c->uri_for fun and profit
http://www.catalystframework.org/calendar/2007/13

(2007) Catalyst Configuration: A to Z
http://www.catalystframework.org/calendar/2007/15

(2008) Day 10. Dealing with Config::General's inability to provide single item arrays.
http://www.catalystframework.org/calendar/2008/10

(2009) Configuration layouts
http://www.catalystframework.org/calendar/2009/11

(2007) Advanced Search in web DBIx::Class based applications (with tags, full text search and searching by location)
http://www.catalystframework.org/calendar/2007/16

(2007) HTML::FormFu - Handles forms, so you don't have to
http://www.catalystframework.org/calendar/2007/20

(2007) DBIx::Class::Tutorial::Part1
http://www.catalystframework.org/calendar/2007/22

(2007) Using plain classes as Catalyst models
http://www.catalystframework.org/calendar/2007/24

(2008) Catalyst and nginx
http://www.catalystframework.org/calendar/2008/2

(2008) Making Catalyst Sites Shine with Varnish
http://www.catalystframework.org/calendar/2008/14

(2008) Day 8. Some notes on ACCEPT_CONTEXT, with and without antlers.
http://www.catalystframework.org/calendar/2008/8

(2008) Custom URL styles with CatalystX::CRUD
http://www.catalystframework.org/calendar/2008/12

(2011) Easy CRUD for your Catalyst App
http://www.catalystframework.org/calendar/2011/11

(2008) Day 16. Catalyst 5.80
http://www.catalystframework.org/calendar/2008/16

(2008) WrapCGI: CGI.pm in your Catalyst app.
http://www.catalystframework.org/calendar/2008/18

(2009) Running CGI Scripts Under Catalyst
http://www.catalystframework.org/calendar/2009/6

(2009) Loadable Traits for Catalyst Components
http://www.catalystframework.org/calendar/2009/10

(2009) How DBIx::Class::ResultSet::WithMetaData can help keep your controllers clean
http://www.catalystframework.org/calendar/2009/12

(2009) Keeping Your Model Reusable
http://www.catalystframework.org/calendar/2009/18

(2011) Get fat this Christmas
http://www.catalystframework.org/calendar/2011/3

(2009) A Tour of DBIx::Class::Helpers
http://www.catalystframework.org/calendar/2009/20

(2009) An HTTP API in 5 minutes
http://www.catalystframework.org/calendar/2009/21

(2009) An AJAX CRUD Interface with Catalyst and jQuery
http://www.catalystframework.org/calendar/2009/22

(2010) Getting Started with Catalyst and jQuery (and jQuery UI)
http://www.catalystframework.org/calendar/2010/13

(2009) Plack - A Fantastic Layer To Make Your App Deployment Easier
http://www.catalystframework.org/calendar/2009/23

(2010) Creating an Easy to Manage Search Engine with Catalyst and ElasticSearch
http://www.catalystframework.org/calendar/2010/2

(2010) Adding Simple Excel Support
http://www.catalystframework.org/calendar/2010/6

(2010) Input Verification with Data::Manager
http://www.catalystframework.org/calendar/2010/10

(2010) Creating reusable actions with Moose::Role - an example
http://www.catalystframework.org/calendar/2010/22

(2010) Moose::Role, Moose::Util and DBIx::Class based Models (multiaction revisited)
http://www.catalystframework.org/calendar/2010/23

(2011) The ControllerRole ChainAction Massacre (Part 1)
http://www.catalystframework.org/calendar/2011/10

(2011) The ControllerRole ChainAction Massacre (Part 2)
http://www.catalystframework.org/calendar/2011/17

(2012) Action Roles for cleaner, less stashy Catalyst Actions
http://www.catalystframework.org/calendar/2012/16

(2010) Access the Twitter API through Catalyst
http://www.catalystframework.org/calendar/2010/15

(2010) Integrating Facebook into your Catalyst application
http://www.catalystframework.org/calendar/2010/24

(2011) 2011 Reflections - 5.90 and beyond.
http://www.catalystframework.org/calendar/2011/1

The modules discussed in that article can be helpful to be presented...

(2011) Checking for leaks in MyApp.
http://www.catalystframework.org/calendar/2011/2

(2011) Keep your libraries organized
http://www.catalystframework.org/calendar/2011/4

(2011) Deploy Catalyst Applications with Starman and Apache
http://www.catalystframework.org/calendar/2011/16

(2011) A Git Tutorial
http://www.catalystframework.org/calendar/2011/22

(2012) Catalyst in 9 steps
http://www.catalystframework.org/calendar/2012/7

...and the other 8 articles of this serie.

(2012) Dynamic forms with HTML::FormFu
http://www.catalystframework.org/calendar/2012/17

(2012) SCALING IMAGES ON DEMAND
http://www.catalystframework.org/calendar/2012/20

(2012) HTML::FormHandler & jQuery Validator
http://www.catalystframework.org/calendar/2012/23

(2012) Combining assets
http://www.catalystframework.org/calendar/2012/25

What do the rest of you think?  Comments, additions to the list, etc?  My thinking is to organize them on github as the first step.

 

Catalyst Advent 2012 is Live!

Perl Catalyst Advent is on for 2012!  Check it out!

Thanks to those of you that stepped up already or who are in the process of preparing something!

Update on the Status of Catalyst Advent 2012

Hey All,

So here's a quick update on what is happening with Catalyst Advent 2012.  I want to thank deptrov++ and others for jumping in last week to help on this!

Although the Advent Article publishing system is canonically over on the old SVN repository (see here) we are also this year allowing people to contribute via the Perl Catalyst github organization.  Either approach is fine (the subversion repository is going to be less effort on our part, for what that is worth, but we are guessing openning this up via Github is going to make it easier).

So start forking away and write pretty much anything, and feel free to share on IRC or via pull requests for comments and suggestions.

As previously stated, we'd love to see articles beyond technology cookbooks.  If you are in management and want to write about your experiences with your team using Catalyt or if you are a technology recruiter and have some useful comments to the Catalyt community, for example, that would be great!

Technically Advent already started, but lets not get ourselves down about it, and get writing!

 

Perl Moose and ->BUILDARGS

Perl Moose and BUILDARGS

Moose::Object supports a method called BUILDARGS which is used to pre process incoming initialization arguments. By default you get one that allows you to initialize an object with either HASH or HASHREF arguments. However, you can wrap that method and do additional custom pre-processing. For example:

    use Test::Most;

    {
      package Foo;

      use Moose;

      has foo => (is=>'ro');

      around 'BUILDARGS', sub {
        my ($orig, $class, %args) = @_;
        if(my $bar = delete $args{bar}) {
          $args{foo} ||= $bar;
        }

        $class->$orig(%args);
      };
    }

    ok my $foo_thinks_is_bar = Foo->new(bar=>100);
    is $foo_thinks_is_bar->foo, '100';

    done_testing;

In this case we allow the Foo class to accept an initialization argument of 'bar' and map that to 'foo'. Ok this is a trivial example but it illustrated the point. It does the job.

However I have found ->BUILDARGS can be a code smell or lead to complex, hard to understand code. For example, when you have lots of attributes that need mapping or changing and lots of conditional logic in the BUILDARGS modifier, that can be hard to understand and hard to test. For people that don't know Moose it can be confusing. It also takes a lot of control away from the caller, and hides it in potentially twisty logic. Lastly, I think it tends to be a feature that gets overused rather than to properly model your logic.

For the most part I think that BUILDARGS should be limited to helping your Moose classes be compatible with non Moose code that might be expecting an initialization style that is different from the standard Moose ->new(%args) style. For example, you might have a class called Kettle that uses a Color object and you decide you want to rewrite Color in Moose. However Kettle initialized Colors with ->new($color_name). You can this:

    use Test::Most;

    {
      package Color;

      use Moose;

      has 'name' => (is=>'ro', required=>1);

      around 'BUILDARGS', sub {
        my ($orig, $class, $name) = @_;
        return $class->$orig(name=>$name);
      };

      package Kettle;

      sub new {
        my ($class, @args) = @_;
        return bless {
          color => Color->new('black'),
          @args };
      }

      sub color_name { shift->{color}->name }

    }

    ok my $kettle = Kettle->new;
    is $kettle->color_name, 'black';

    done_testing;

I think this is a reasonable use case for BUILDARGS since its basically making Moose play nice with your existing non Moose stuff, and doesn't force anyone to understand what Moose is doing here nor are you getting back something other than what you expect.

So if BUILDARGS isn't always the right choices, what is? Well, there's actually a few programming design patterns that are generic across most OO programming languages and don't require a lot back story to understand. First, you can have a factory method on your class that does what you want. For example:

    use Test::Most;

    {
      package Foo;

      use Moose;

      has foo => (is=>'ro');

      sub new_with_bar {
        my ($class, %args) = @_;
        return $class->new(foo=>$args{bar});
      }

    }

    ok my $foo_thinks_is_bar2 = Foo->new_with_bar(bar=>100);
    is $foo_thinks_is_bar2->foo, '100';

  done_testing;

Not only is this less lines of code then the BUILDARGS approach, but there's already some decent built in argument checking (at it would be trivial to add a bit more) and it lets the caller get something expected, rather than unexpected. And the approach scales pretty well:

    use Test::Most;

    {
      package Foo3;

      use Moose;

      has foo => (is=>'ro');

      sub new_with_bar {
        my ($class, %args) = @_;
        return $class->new(foo=>$args{bar});
      }

      sub new_with_bat {
        my ($class, %args) = @_;
        return $class->new(foo=>$args{bat});
      }

    }

    ok my $foo_thinks_is_bar3 = Foo3->new_with_bat(bat=>100);
    is $foo_thinks_is_bar3->foo, '100';

    done_testing;

But what if you want a bit of magic, and not require your caller to choose the correct builder method? You can if you want create a builder dispatcher, which at least makes the logic reasonable separate:

    {
      package Foo4;

      use Moose;

      has foo => (is=>'ro');

      sub construct {
        my ($class, %args) = @_;
        if($args{bar}) { return $class->new(foo=>$args{bar}) }
        if($args{bat}) { return $class->new(foo=>$args{bat}) }
      }

      sub new_with_bar {
        my ($class, %args) = @_;
        return $class->new(foo=>$args{bar});
      }

      sub new_with_bat {
        my ($class, %args) = @_;
        return $class->new(foo=>$args{bat});
      }

    }

    is((Foo4->construct(bar=>200)->foo), 200);
    is((Foo4->construct(bat=>300)->foo), 300);

    done_testing;

You can probably think of more elegant ways to write that dispatcher (I'd probably make it a separate class rather than inlined with the construct method since that would be more reusable and testingable) but at least this version has the big upside of being clear.

So this option I think is better for most cases when you are thinking of reaching for BUILDARGS. There is another approach that I tend to now favor, however. One issue with 'Foo4' is that you are mixing a lot of instantiation logic with actual 'Foo'ness which I think can become distracting to the person reading the class. Ideally I think a class should do one thing.

We could create a separate class to handle any complex instantiation work. There's a classic design pattern called the 'builder pattern (read up on it here "http://en.wikipedia.org/wiki/Builder_pattern") and if you take a look at that article here's my Moosey interpretation:

    use Test::More;

    {
      package Pizza;

      use Moose;

      has [qw/dough sauce topping/] => (is=>'rw');

      package PizzaBuilder;

      use Moose::Role;

      requires qw/build_dough build_sauce build_topping/;

      has pizza => (is=>'ro', isa=>'Pizza',
        builder=>'_build_pizza', required=>1);

      sub _build_pizza { Pizza->new }

      package HawaiianPizzaBuilder;

      use Moose;
      with 'PizzaBuilder';

      sub build_dough { shift->pizza->dough('cross') }
      sub build_sauce { shift->pizza->sauce('mild') }
      sub build_topping { shift->pizza->topping('ham+pineapple') }

      package SpicyPizzaBuilder;

      use Moose;
      with 'PizzaBuilder';

      sub build_dough { shift->pizza->dough('pan baked') }
      sub build_sauce { shift->pizza->sauce('hot') }
      sub build_topping { shift->pizza->topping('pepperoni+salami') }

      package Waiter;

      use Moose;

      has 'pizza_builder' => (is=>'rw', does=>'PizzaBuilder');

      sub pizza { shift->pizza_builder->pizza }

      sub construct_pizza {
        my ($self) = @_;
        $self->pizza_builder->$_ for (qw/
          build_dough build_sauce build_topping/);
      }

    }

    ok my $waiter = Waiter->new;
    ok my $hawaiian_pizza_builder = HawaiianPizzaBuilder->new;
    ok my $spicy_pizza_builder = SpicyPizzaBuilder->new;

    for($waiter) {
      $_->pizza_builder($hawaiian_pizza_builder);
      $_->construct_pizza;
    }

    is $waiter->pizza->sauce, 'mild';

    for($waiter) {
      $_->pizza_builder($spicy_pizza_builder);
      $_->construct_pizza;
    }

    is $waiter->pizza->sauce, 'hot';

    done_testing;

Ok, that's a lot of classes, and I'd probably alter it a bit since after all Perl is a dynamic language and some of the hoops the classic builder pattern requires are based on the fact that Java and others are static, but I think you get the idea. Your more Perly interpretations are very welcomed!

So overall there's a lot of options you have when there's complex initialization requirements, most of which are patterns that are cross language, which has a nice upside that you have code more likely to be understood by people new or Moose and you can draw upon the large thought ecosystem regarding these types of patterns.

Here's a gist of all the example code in a single test case you should be able to run directly.