1 package Moose::Cookbook::Meta::Recipe2;
3 # ABSTRACT: A meta-attribute, attributes with labels
12 package MyApp::Meta::Attribute::Labeled;
14 extends 'Moose::Meta::Attribute';
19 predicate => 'has_label',
22 package Moose::Meta::Attribute::Custom::Labeled;
23 sub register_implementation {'MyApp::Meta::Attribute::Labeled'}
25 package MyApp::Website;
29 metaclass => 'Labeled',
32 label => "The site's URL",
43 my $meta = $self->meta;
47 for my $attribute ( map { $meta->get_attribute($_) }
48 sort $meta->get_attribute_list ) {
50 if ( $attribute->isa('MyApp::Meta::Attribute::Labeled')
51 && $attribute->has_label ) {
52 $dump .= $attribute->label;
55 $dump .= $attribute->name;
58 my $reader = $attribute->get_read_method;
59 $dump .= ": " . $self->$reader . "\n";
67 my $app = MyApp::Website->new( url => "http://google.com", name => "Google" );
71 In this recipe, we begin to delve into the wonder of meta-programming.
72 Some readers may scoff and claim that this is the arena of only the
73 most twisted Moose developers. Absolutely not! Any sufficiently
74 twisted developer can benefit greatly from going more meta.
76 Our goal is to allow each attribute to have a human-readable "label"
77 attached to it. Such labels would be used when showing data to an end
78 user. In this recipe we label the C<url> attribute with "The site's
79 URL" and create a simple method showing how to use that label.
81 The proper, modern way to extend attributes (using a role instead of a
82 subclass) is described in L<Moose::Cookbook::Meta::Recipe3>, but that recipe
83 assumes you've read and at least tried to understand this one.
85 =head1 META-ATTRIBUTE OBJECTS
87 All the attributes of a Moose-based object are actually objects
88 themselves. These objects have methods and attributes. Let's look at
91 has 'x' => ( isa => 'Int', is => 'ro' );
92 has 'y' => ( isa => 'Int', is => 'rw' );
94 Internally, the metaclass for C<Point> has two
95 L<Moose::Meta::Attribute>. There are several methods for getting
96 meta-attributes out of a metaclass, one of which is
97 C<get_attribute_list>. This method is called on the metaclass object.
99 The C<get_attribute_list> method returns a list of attribute names. You can
100 then use C<get_attribute> to get the L<Moose::Meta::Attribute> object itself.
102 Once you have this meta-attribute object, you can call methods on it like this:
104 print $point->meta->get_attribute('x')->type_constraint;
107 To add a label to our attributes there are two steps. First, we need a
108 new attribute metaclass that can store a label for an
109 attribute. Second, we need to create attributes that use that
114 We start by creating a new attribute metaclass.
116 package MyApp::Meta::Attribute::Labeled;
118 extends 'Moose::Meta::Attribute';
120 We can subclass a Moose metaclass in the same way that we subclass
126 predicate => 'has_label',
129 Again, this is standard Moose code.
131 Then we need to register our metaclass with Moose:
133 package Moose::Meta::Attribute::Custom::Labeled;
134 sub register_implementation { 'MyApp::Meta::Attribute::Labeled' }
136 This is a bit of magic that lets us use a short name, "Labeled", when
137 referring to our new metaclass.
139 That was the whole attribute metaclass.
141 Now we start using it.
143 package MyApp::Website;
145 use MyApp::Meta::Attribute::Labeled;
147 We have to load the metaclass to use it, just like any Perl class.
149 Finally, we use it for an attribute:
152 metaclass => 'Labeled',
155 label => "The site's URL",
158 This looks like a normal attribute declaration, except for two things,
159 the C<metaclass> and C<label> parameters. The C<metaclass> parameter
160 tells Moose we want to use a custom metaclass for this (one)
161 attribute. The C<label> parameter will be stored in the meta-attribute
164 The reason that we can pass the name C<Labeled>, instead of
165 C<MyApp::Meta::Attribute::Labeled>, is because of the
166 C<register_implementation> code we touched on previously.
168 When you pass a metaclass to C<has>, it will take the name you provide
169 and prefix it with C<Moose::Meta::Attribute::Custom::>. Then it calls
170 C<register_implementation> in the package. In this case, that means
171 Moose ends up calling
172 C<Moose::Meta::Attribute::Custom::Labeled::register_implementation>.
174 If this function exists, it should return the I<real> metaclass
175 package name. This is exactly what our code does, returning
176 C<MyApp::Meta::Attribute::Labeled>. This is a little convoluted, and
177 if you don't like it, you can always use the fully-qualified name.
179 We can access this meta-attribute and its label like this:
181 $website->meta->get_attribute('url')->label()
183 MyApp::Website->meta->get_attribute('url')->label()
185 We also have a regular attribute, C<name>:
192 This is a regular Moose attribute, because we have not specified a new
195 Finally, we have a C<dump> method, which creates a human-readable
196 representation of a C<MyApp::Website> object. It will use an
197 attribute's label if it has one.
202 my $meta = $self->meta;
206 for my $attribute ( map { $meta->get_attribute($_) }
207 sort $meta->get_attribute_list ) {
209 if ( $attribute->isa('MyApp::Meta::Attribute::Labeled')
210 && $attribute->has_label ) {
211 $dump .= $attribute->label;
214 This is a bit of defensive code. We cannot depend on every
215 meta-attribute having a label. Even if we define one for every
216 attribute in our class, a subclass may neglect to do so. Or a
217 superclass could add an attribute without a label.
219 We also check that the attribute has a label using the predicate we
220 defined. We could instead make the label C<required>. If we have a
221 label, we use it, otherwise we use the attribute name:
224 $dump .= $attribute->name;
227 my $reader = $attribute->get_read_method;
228 $dump .= ": " . $self->$reader . "\n";
234 The C<get_read_method> is part of the L<Moose::Meta::Attribute>
235 API. It returns the name of a method that can read the attribute's
236 value, I<when called on the real object> (don't call this on the
241 You might wonder why you'd bother with all this. You could just
242 hardcode "The Site's URL" in the C<dump> method. But we want to avoid
243 repetition. If you need the label once, you may need it elsewhere,
244 maybe in the C<as_form> method you write next.
246 Associating a label with an attribute just makes sense! The label is a
247 piece of information I<about> the attribute.
249 It's also important to realize that this was a trivial example. You
250 can make much more powerful metaclasses that I<do> things, as opposed
251 to just storing some more information. For example, you could
252 implement a metaclass that expires attributes after a certain amount
256 metaclass => 'TimedExpiry',
257 expires_after => { hours => 1 },
258 refresh_with => sub { get( $_[0]->url ) },
267 my $app = MyApp::Website->new( url => "http://google.com", name => "Google" );
269 $app->dump, q{name: Google
270 The site's URL: http://google.com
271 }, '... got the expected dump value'