1. Create an XML template, populate the stash with data, let your template view render it, then override the Content-Type: header of your view with Catalyst::Response.
2. Use an XML::* feed module to render the XML, manually set the Catalyst::Response body, then set the Content-Type: header.

The former almost makes me angry, and the latter, although saner, puts view-specific responsibilities on the shoulders of the Controller.

Catalyst::View::XML::Feed

Catalyst::View::XML::Feed is an attempt at something cleaner, and more in the spirit of MVC, which makes the nitty-gritty details of presentation entirely the responsibility of the view. Using it is pretty much what you would expect from any view:

• Put your data in $c->stash->{feed}
• Forward to your View::Feed (or whatever you called your Catalyst::View::XML::Feed subclass)

It attempts to be as intelligent as possible, allowing you to supply data in a wide range of formats to the feed value in the stash. These can be XML::* Atom or RSS objects, custom objects, plain hashrefs of values, etc.

As always, any recommendations or other feedback are warmly welcomed.

Sometimes that method might not meet your needs, and you might really want to make a Moose subclass of a non-Moose class. This tutorial will get you started with a couple modules that will help you do just that: MooseX::NonMoose and MooseX::NonMoose::InsideOut.

The nitty-gritty

If you're looking to get your hands dirty and find out how this really works, your first stop should be Recipe 11 in the Moose Cookbook. It is optional reading for our purposes, though. It does a great job explaining how to subclass a common, blessed hash, non-Moose class "by hand," and points us to MooseX::NonMoose which handles those details for us.

We will take advantage of this handy module, and push forward to examine some trickier situations that can arise when subclassing non-Moose classes.

1) The simplest case

(Follow along with the example 1 gist)

In most circumstances using MooseX::NonMoose couldn't be easier. Let's imagine we have this: Animal1.pm. It is a trivial example of an animal class, which takes a hash reference of attributes in the constructor like this
Animal1->new({ name => 'Lassie' })
and provides an accessor to name that allows us to set and get that attribute.

In order to subclass this, all we need to do is add
use MooseX::NonMoose; extends 'Animal1';
Let's do this to create a subclass called Camel with an additional attribute called humps to specify the number of humps on its back. Our new class looks like this:

Camel example 1:
package Camel;
use Moose;
use MooseX::NonMoose;
extends 'Animal1';

has 'humps' => ( is  => 'ro', isa => 'Num' );

no Moose;
__PACKAGE__->meta->make_immutable;

We can now create a Camel object the same way we did with Animal1, but with the additional humps attribute. Here is our example script:

Example script 1:
#!/usr/bin/perl
use Modern::Perl;
use Camel;

my $c = Camel->new({ name => "Samuel Camel", humps => 2 });
say $c->name, " has ", $c->humps, " humps";

This produces

Samuel Camel has 2 humps

Most of the time subclassing a non-Moose class is as simple as this. MooseX::NonMoose does all the work for us.

2) Incompatible constructors

Sometimes, however, it isn't so easy.

What if our legacy class looked like this instead: Animal2.pm. It's largely the same as Animal1, except has a different constructor. Instead of providing it with a hash reference of attributes, we simply pass it the animal's name:
Animal2->new("Lassie");

We'll use the exact same Camel subclass as in Camel example 1, just change "extends 'Animal1'" to "extends 'Animal2'". Now let's try the Example script from above again.

Oh dear. This is not what we wanted...

HASH(0x100803ee8) has 2 humps

Moose expects hash or hashref arguments passed to the constructor, but Animal2 wants a string. Moose saw the first (and only) argument was a hashref, { name => "Samuel Camel", humps => 2 }, as it expected, and stored the name attribute. Animal2, on the other hand, does not accept hash references and simply tried to treat it as the animal's name (producing that "HASH(0x100...)").

Let's look at two ways we can modify Camel to resolve this problem:

1. accept a hash of attribute values in the constructor, breaking compatibility with Animal2
2. accept a single argument in the constructor like Animal2

2.1) Resolving incompatible constructors - Using hashes

(Follow along with the example 2.1 gist)

Even though Animal2 doesn't support hashes passed into its constructor, we can modify Camel to allow it, enabling our example script from before to do what we wanted.

We looked at BUILDARGS in our last tutorial, which allows us to modify the arguments sent to the Moose constructor. In this example, however, we need to modify the arguments sent to the Animal2 constructor.

MooseX::NonMoose provides a similar method, FOREIGNBUILDARGS, that allows us to determine what gets sent to the non-Moose parent constructor. It works like this:

# FOREIGNBUILDARGS is not declared anywhere in our parent classes,
# so we can just override it, rather than wrap it in 'around'
sub FOREIGNBUILDARGS {
    my $class = shift;
    # The remaining arguments were sent to the constructor.
    # e.g. if you called YourClass->new({ foo => 'bar' }), then 
    # @args contains one element, that hashref.
    my @args = @_;

    # ... Make any modifications to @args here.

    # Whatever we return will be sent to new() in the non-Moose parent
    return @args;
}

Now take those principles and apply them to our problem in order to provide the Animal2 constructor with a single string argument.

Camel example 2.1:
package Camel;
use Moose;
use MooseX::NonMoose;
extends 'Animal2';

has 'humps' => ( is  => 'ro', isa => 'Num' );

sub FOREIGNBUILDARGS {
    my $class = shift;
    # We expect a hashref with 'name' and 'humps'.
    my $args = shift;

    # Give Animal2 what it wants: just the name, and nothing else.
    return $args->{name};
}

no Moose;
__PACKAGE__->meta->make_immutable;

2.2) Resolving incompatible constructors - Maintaining compatibility with parent class

(Follow along with the example 2.2 gist)

NOTE: I do not recommend using this solution unless you must. Passing hashes to the constructor as we did in solution in 2.1 results in more readable and maintainable code. That being said...

If we want our Camel class to be a drop-in replacement for Animal2, we need the ability to pass our constructor just the name, rather than a hash. But what about the number of humps? We could change the humps attribute to be read-write (is => 'rw' instead of 'ro') and create our object like this: my $c = Camel->new("Samuel Camel"); $c->humps(2);

But this can be painful, especially when we're dealing with more complicated non-trivial classes. We probably prefer to leave humps readonly and instead pass the humps in the constructor like this: Camel->new("Samuel Camel", 2);

Let's start back with the bare-bones Camel example 1, which does not mess with BUILDARGS or FOREIGNBUILDARGS. If we try to use this with a constructor like this, Camel->new("Samuel Camel"); we get the following error:

Single parameters to new() must be a HASH ref at...

If you try to call Camel->new("Samuel Camel", 2) it won't throw an error, but it also will not store "2" for the number of humps. The Moose parent will interpret that as a hash "Samuel Camel" => 2 with its "Samuel Camel" name being the key with the number of humps as the value.

In order to do this, Camel->new("Samuel Camel", 2) we need to intercept those arguments with BUILDARGS and give { humps => 2 } to the Moose parent, and use FOREIGNBUILDARGS to pass only the name "Samuel Camel" to the non-Moose parent.

Camel example 2.2;
package Camel;
use Moose;
use MooseX::NonMoose;
extends 'Animal2';

has 'humps' => ( is  => 'ro', isa => 'Num' );

# Make sure Moose::Object parent gets a hashref with 'humps' in it
around BUILDARGS => sub {
    my $orig  = shift;
    my $class = shift;
    # We expect this to be called with: Camel->new($name, $optional_humps)
    # so @_ contains a name, and possibly a number of humps.
    my $camel_name  = shift;
    my $camel_humps = shift;

    my $moose_args = {};
    $moose_args->{humps} = $camel_humps if defined $camel_humps;

    # Give Moose constructor what it wants
    return $class->$orig($moose_args);
};

# Make sure Animal2 parent only gets a name
sub FOREIGNBUILDARGS {
    my $class = shift;
    my $name = shift;
    my $humps = shift; # We are going to ignore this.

    # Whatever we return will be sent to Animal2->new()
    return $name;
}

no Moose;
__PACKAGE__->meta->make_immutable;

Example script 2.2:
#!/usr/bin/perl
use Modern::Perl;
use Camel;

my $c = Camel->new("Samuel Camel", 2);
say $c->name, " has ", $c->humps, " humps";

3) Non-hash objects

(Follow along with the example 3 gist)

For our final example, consider Animal3.pm which is used exactly like Animal2, with a single string argument to its constructor: Animal3->new("Lassie");. Take either of the Camel class examples we created for Animal2 (either the one whose constructor takes hash-based arguments, or ordered arguments). Be sure to change its extends to the new Animal3 class.

If you try to use your new Camel class, you will get an error similar to this:

Not a HASH reference at generated method (unknown origin)...

Most Perl classes use a blessed hash behind the scenes, and that is what MooseX::NonMoose expects.

Even though Animal3 is used exactly like Animal2, this final example is implemented differenly inside. It uses a blessed array instead of a hash. If this doesn't mean much to you yet, don't worry about it! We have a simple solution:

In your Camel class, change the line that says use MooseX::NonMoose; to use MooseX::NonMoose::InsideOut.

When you encounter the "Not a HASH..." error while using MooseX::NonMoose, simply use MooseX::NonMoose:InsideOut instead. That's it! Everything else we've learned about BUILDARGS and FOREIGNBUILDARGS still applies.

Extra credit: Going the extra mile

In Camel example 1 and Camel example 2.1, we didn't utilize BUILDARGS for anything. This means our Moose::Object constructor was getting exactly the arguments we were passing into Camel. This includes the name attribute, which it has no knowledge of since it only exists in the non-Moose class.

To be a good citizen, we should probably strip out this name argument to keep it out of sight from our Moose parent.

Your mission, should you choose to accept it, is to add an around BUILDARGS => sub { ... }; to clean up the arguments so they only include those newly-added, Moosified attributes (i.e. just humps).

Don't subclass

There are probably some good arguments against subclassing non-Moose classes with a Moose class that center on principles of good design, and applying the most suitable design patterns. From a practical standpoint, though, there's a very simple reason to avoid it: using Moose to subclass a non-Moose class is fraught with "gotchas." We'll see some of these problems in an upcoming post, but for now let's look at an alternative to subclassing.

Perhaps a better option is to simply create your a new class and use delegation to call methods on an accessor containing your non-Moose object.

Let's say we initially wanted to subclass Date::Handler, but we decided to try delegation instead. After reading through Moose::Manual::Delegation we come up with the following:

package MyDate;
use Moose;
use namespace::autoclean;
use Date::Handler;

has 'date_handler' => (
    is => 'ro',
    isa => 'Date::Handler',
    handles => qr/.*/,
);

The "handles" option allows us to specify regular expressions, so rather than writing each of the countless methods Date::Handler provides, we simply specify that the date_handler attribute handles => qr/.*/ . Now our MyDate object will catch any method call and delegate it to the Date::Handler object in date_handler. In other words, instead of needing to write $my_date->date_handler->date_handler_method() we can write $my_date->date_handler_method().

There is still a major problem though. We initially wanted a subclass which, presumably, would act as a drop-in replacement. Our new class fails at this because we need to set the date_handler attribute:

MyDate->new(date_handler => Date::Handler->new(\%date_handler_args));

This is fairly inconvenient, and moreover, does not behave like a subclass would.

A drop-in replacement

We need to tell our MyDate->new(...) method to take the same arguments as Date::Handler does. Fortunately Moose::Object provides a method called BUILDARGS that lets us modify the arguments sent to the constructor. Overriding this can be problematic if we're not careful, so we'll use the around method modifier to modify the arguments being sent to BUILDARGS.

around BUILDARGS => sub {
    my $orig = shift;
    my $class = shift;
    return $class->$orig(date_handler => Date::Handler->new(@_));
};

When calling $orig() (i.e. BUILDARGS), we pass in the date_handler value automatically so the calling code no longer needs to worry about it. Notice that we also DO NOT pass the value from @_ to the constructor of our new MyDate class, but instead give it to the Date::Handler constructor.

We now have the ability to call MyDate->new(\%date_handler_args), and otherwise treat this new class and its objects just as we would a Date::Handler.

Let's go ahead and add a leading underscore to the _date_handler attribute. This isn't necessary, but it indicates that it is private and that the end-user should not worry about it.

Decorating a non-Moose class

Putting it all together, we get the following (gist).

package MyDate;
use Moose;
use namespace::autoclean;
use Date::Handler;

has '_date_handler' => (
    is => 'ro',
    isa => 'Date::Handler',
    handles => qr/.*/,
);
around BUILDARGS => sub {
    my $orig = shift;
    my $class = shift;
    return $class->$orig(_date_handler => Date::Handler->new(@_));
};

no Moose;
__PACKAGE__->meta->make_immutable;

But I REALLY want a subclass

If you really want to make a Moose subclass of a non-Moose class, check out the following post where we cover some examples of subclassing.

Credits

Thanks to doy, perigrin, and mst (and his mallet). I started writing some tutorials on subclassing tricky non-Moose classes, but they made the case that even if that's what you want to do, it's probably not what you should do.