Badger

 view release on metacpan or  search on metacpan

lib/Badger/Factory.pm  view on Meta::CPAN

            if (defined ($item = ${ $pkg.PKG.ITEM })) {
                $items = ${ $pkg.PKG.ITEMS };
                last;
            }
        }
    }
    return $self->error_msg('no_item')
        unless $item;

    # use 'items' in config, or grokked from $ITEMS, or guess plural
    $items = $config->{ items } || $items || plural($item);

    my $ipath    = $item.PATH_SUFFIX;
    my $inames   = $item.NAMES_SUFFIX;
    my $idefault = $item.DEFAULT_SUFFIX;

    # Merge all XXXX_PATH package vars with any 'xxxx_path' or 'path' config
    # items.  Ditto for XXXX_NAME / 'xxxx_name' / 'aka' and  XXXXS/ 'xxxxs'

    my @path  = @$config{ path  => lc $ipath  };

lib/Badger/Factory.pm  view on Meta::CPAN

        url   => 'My::Widget::URL',       # non-standard capitalisation
        color => 'My::Widget::Colour',    # different spelling
        amp   => 'Nigels::Amplifier',     # different path
    };

    1;

The C<$ITEM> and C<$ITEMS> package variables are used to define the
singular and plural names of the items that the factory is responsible for.
In this particular case, the C<$ITEMS> declaration isn't strictly
necessary because the module would correctly "guess" the plural name
C<widgets> from the singular C<widget> defined in C<$ITEM>.  However,
this is only provided as a convenience for those English words that
pluralise regularly and shouldn't be relied upon to work all the time.
See the L<pluralise()|Badger::Utils/pluralise()> method in L<Badger::Utils>
for further information, and explicitly specify the plural in C<$ITEMS> if
you're in any doubt.

The C<$WIDGET_PATH> is used to define one or more base module names under
which your widgets are located.  The name of this variable is derived
from the upper case item name in C<$ITEM> with C<_PATH> appended.  In this

lib/Badger/Modules.pm  view on Meta::CPAN

            
            if (defined ($item = ${ $pkg.PKG.ITEM })) {
                $items = ${ $pkg.PKG.ITEMS };
                last;
            }
        }
    }
    return $self->error_msg('no_item')
        unless $item;

    # use 'items' in config, or grokked from $ITEMS, or guess plural
    $items = $config->{ items } || $items || plural($item);

    my $ipath    = $item.PATH_SUFFIX;
    my $inames   = $item.NAMES_SUFFIX;
    my $idefault = $item.DEFAULT_SUFFIX;
    
    # Merge all XXXX_PATH package vars with any 'xxxx_path' or 'path' config 
    # items.  Ditto for XXXX_NAME / 'xxxx_name' / 'aka' and  XXXXS/ 'xxxxs'
    
    my @path  = @$config{ path  => lc $ipath  };

pod/Badger/FAQ.pod  view on Meta::CPAN

On the other hand, Moose is all about metaprogramming. If you don't use the
metaprogramming wide of things then you're not really using Moose.

=item * 

Moose is "just" an OO programming framework. It's a very impressive OO
framework that contains some really great ideas (some of which I've borrowed).
The fact that it just concerns itself with the OO framework side of things
should be considered a featured, not a weakness. It does one thing (well,
several things, all under the guess of one meta-thing) and does it extremely
well.

Badger provides a smaller and simpler set of generic OO programming tools as
part of a collection of generally useful modules for application authors (me
in particular). It contains the things that I need for TT, and the kind of
things that I find myself writing over and over again in pretty much every
Perl project I work on. So the Moose-like (and Spiffy-like) parts of Badger
are a means to an end, rather than the raison d'etre in themselves.

=item *