use Data::Dump qw( pp );
use MooseX::Types::Util qw( has_available_type_export );
use Moose::Util qw( add_method_modifier ensure_all_roles );
+ use Data::Pond qw(pond_write_datum);
use Class::Inspector;
use Class::MOP;
next if $attr eq 'Chained' and $value eq UNDER_VAR;
push @attributes,
- map { sprintf '%s%s', $attr, defined($_) ? sprintf('(%s)', $_) : '' }
- (ref($value) eq 'ARRAY')
- ? @$value
- : $value;
+ map {
+ my $value = ref $_ ? pond_write_datum($_) : $_;
+ sprintf '%s%s', $attr, defined($value) ? sprintf('(%s)', $value) : ''
+ } (
+ ref($value) eq 'ARRAY'
+ ) ? @$value : $value;
}
return \@attributes;
# merge runtime and compiletime attrs
my %full_attrs = (%attributes, %$attrs);
my $compiled_attrs = $compile_attrs->(\%full_attrs);
-
my $real_method = $method->reify(
actual_body => $body,
attributes => $compiled_attrs,
# NYI
if ($modifier) {
-
add_method_modifier $class, $modifier, [$name, $real_method];
}
else {
$real_meta->$prepare_meta;
}
else {
-
$class->meta->$prepare_meta;
}
}
my ($first, @rest) = eval $params;
my %params = ref $first eq 'HASH' ? %$first : ($first, @rest); # both (%opts) and {%opts}
for my $key (keys %params) {
- push @{$attrs->{$key}}, $params{$key};
+ my $value = ref $params{$key} eq 'ARRAY' ? $params{$key} : [$params{$key}];
+ push @{ $attrs->{$key} ||=[] }, @$value;
+ ##push @{ $attrs->{$key} ||=[] }, $params;
+
}
}
}
push @{ $attrs->{CatalystX_Declarative_ActionRoles} ||= [] }, @roles;
-
return;
}
$attrs->{Signature} = $proto;
$attrs->{Action} = [];
- push @{ $attrs->{CatalystX_Declarative_ActionRoles} ||= [] }, CatchValidationError;
+ push @{ $attrs->{CatalystX_Declarative_DefaultActionRoles} ||= [] }, CatchValidationError;
# default chained base to the global under var, to be resolved at runtime
$attrs->{Chained} ||= UNDER_VAR;
}
}
+You can consume multiple action roles similarly to the way you do with the
+class or role keyword:
+
+ action user
+ with LoggedIn
+ with isSuperUser {}
+
+Or
+
+ action User
+ with (LoggedIn, isSuperUser) {}
+
+Lastly, you can pass parameters to the underlying L<Catalyst::Action> using
+a syntax that is similar to method traits:
+
+ action myaction with hasRole(opt1=>'val1', opt2=>'val2')
+
+Where C<%opts> is a hash that is used to populate $action->attributes in the
+same way you might have done the following in classic L<Catalyst>
+
+ sub myaction :Action :Does(hasRole) :opt1(val1) :opt2(val2)
+
+Here's a more detailed example:
+
+ action User
+ with hasLogger(log_engine=>'STDOUT')
+ with hasPermissions(
+ role=>['Administrator', 'Member'],
+ ) {}
+
+Think of these are classic catalyst subroutine attributes on steriods. Unlike
+subroutine attributes, you can split and format your code across multiple lines
+and you can use deep and complex data structures such as HashRefs or ArrayRefs.
+Also, since the parameters are grouped syntactically within the C<with> keyword
+this should improve readability of your code, since it will be more clear which
+parameters belong to with roles. This should give L<CatalystX::Declare> greater
+compatibility with legacy L<Catalyst> code but offer us a way forward from
+needing subroutine attributes, which suffer from significant drawbacks.
+
+A few caveats and differences from method traits. First of all, unlike method
+traits, parameters are not passed to the L<Catalyst::Action> constructor, but
+instead used to populate the C<attributes> attribute, which is to preserve
+compatibility with how subroutine attributes work in classic L<Catalyst>.
+
+Additionally, since subroutines attributes supported a very limited syntax for
+supplying values, we follow the convention where parameter values are pushed
+onto an arrayref. In other words the following:
+
+ action User with hasLogger(engine=>'STDOUT')
+
+would create the following data structure:
+
+ $action->attributes->{engine} = ['STDOUT']
+
+The one exception is that if the value is an arrayref, those will be merged:
+
+ action User with Permissions(roles=>[qw/admin member/]) {}
+ ## Creates: $action->attributes->{roles} = ['admin','member']
+
+My feeling is that this gives better backward compatibility with classic sub
+attributes:
+
+ sub User :Action :Does(Permissions) :roles(admin) :roles(member)
+
+However, I realize this method could lead to namespace collisions within the
+C<$action->attributes> attribute. For now this is an avoidable issue. In the
+future we may add a C<$action->trait_attributes> or similar attribute to the
+L<Catalyst::Action> class in order to resolve this issue.
+
=head2 Action Classes
B<This option is even more experimental>
projects / catagits/CatalystX-Declare.git / blobdiff