Abilities

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

	[ BUGFIXES ]
	- Fixed all bugs introduced in versions 0.3 and 0.4 that made this
	  package unusable (see the UPGRADING FROM v0.2 sections in both
	  Abilities.pm and Abilities/Features.pm for more info)

0.4       2013-05-02 21:06:25 Asia/Jerusalem
	[ VARIOUS CHANGES ]
	- Moved from Any::Moose to Moo as per the former's deprecation

	[ BUGFIXES ]
	- fixed _build_abilities() to skip non-blessed roles (submitted by cafe01)
	- small documentation fixes

0.3       2012-12-28 17:15:01 Asia/Jerusalem
	[ BACKWARDS COMPATIBILITY BROKEN ]
	- Actions and features can now have constraints. When an action/features
	  doesn't have any, then it's really a yes/no (have/don't) option.
	  When an action/feature does have constraints, then it's no longer
	  a yes/no option. This allows more finer grained control over
	  abilities.
	- The can_perform() method now can only take one action, not a list.

README  view on Meta::CPAN

    (either by names or by references), just as long as you correctly
    provide "roles" and "actions".

    Unfortunately, in both versions 0.3 and 0.4, I made a bit of a mess that
    rendered both versions unusable. While I documented the "roles"
    attribute as requiring role names instead of role objects, the actual
    implementation still required role objects. This has now been fixed, but
    it also meant I had to add a new requirement: consuming classes now have
    to provide a method called "get_role()" that takes the name of a role
    and returns its object. This will probably means loading the role from a
    database and blessing it into your role class that also consumes this
    module.

    I apologize for any inconvenience this might have caused.

AUTHOR
    Ido Perlmuter, "<ido at ido50 dot net>"

BUGS
    Please report any bugs or feature requests to "bug-abilities at
    rt.cpan.org", or through the web interface at

lib/Abilities.pm  view on Meta::CPAN

any way you want in a database (either by names or by references), just
as long as you correctly provide C<roles> and C<actions>.

Unfortunately, in both versions 0.3 and 0.4, I made a bit of a mess
that rendered both versions unusable. While I documented the C<roles>
attribute as requiring role names instead of role objects, the actual
implementation still required role objects. This has now been fixed,
but it also meant I had to add a new requirement: consuming classes
now have to provide a method called C<get_role()> that takes the name
of a role and returns its object. This will probably means loading the
role from a database and blessing it into your role class that also consumes
this module.

I apologize for any inconvenience this might have caused.

=head1 AUTHOR

Ido Perlmuter, C<< <ido at ido50 dot net> >>

=head1 BUGS

lib/Abilities/Features.pm  view on Meta::CPAN

any way you want in a database (either by names or by references), just
as long as you correctly provide C<plans> and C<features>.

Unfortunately, in both versions 0.3 and 0.4, I made a bit of a mess
that rendered both versions unusable. While I documented the C<plans>
attribute as requiring plan names instead of plan objects, the actual
implementation still required plan objects. This has now been fixed,
but it also meant I had to add a new requirement: consuming classes
now have to provide a method called C<get_plan()> that takes the name
of a plan and returns its object. This will probably means loading the
plan from a database and blessing it into your plan class that also consumes
this module.

I apologize for any inconvenience this might have caused.

=head1 AUTHOR

Ido Perlmuter, C<< <ido at ido50 dot net> >>

=head1 BUGS

t/lib/TestManager.pm  view on Meta::CPAN

package TestManager;

use warnings;
use strict;

sub new { bless {}, shift }

sub add_objects {
	my $self = shift;

	foreach (@_) {
		$self->{$_->name} = $_;
	}

	return $self;
}