view release on metacpan or  search on metacpan

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

interface to a filesystem. Files and directories are represented as
L<Badger::Filesystem::File> and L<Badger::Filesystem::Directory> objects
respectively. As well as being useful for general filesystem manipulation (in
this respect, they are very much like the L<Path::Class> modules), the same
modules can also be used to represent virtual filesystems via the
L<Badger::Filesystem::Virtual> module. This allows you to "mount" a virtual
file system under a particular directory (useful when you're dealing with web
sites to map page URLs, e.g. F</example/page.html>, to the source files, e.g.
F</path/to/example/page.html>). You can also create a virtual file system that
is a composite of several root directories (if you're familiar with the
Template Toolkit then think of the way the C<INCLUDE_PATH> works).

=item Codec modules

Going hand-in-hand with many basic filesystem operations, the codec modules
provide a simple object interface for encoding and decoding data to and 
from any particular format.  The underlying functionality is provided by
existing Perl modules (e.g. L<MIME::Base64>, L<Storable>, L<YAML>, etc).
The codec modules are wrappers that provide a standard interface to these 
various different modules.  It provides both functional and object oriented
interfaces, regardless of how the underlying module works.  It also provides
the relevant hooks that allow codec objects to be composed into pipeline
sequences.

=item Free

Badger is Open Source and "free" in both "free beer" and "free speech" senses
of the word. It's 100% pure Perl and has no external dependencies on any
modules that aren't part of the Perl core. Badger is the base platform for
version 3 of the Template Toolkit (coming RSN) and has portability and ease of
installation as primary goals. Non-core Badger add-on modules can make as much
use of CPAN as they like (something that is usually to be encouraged) but the
Badger core will always be dependency-free to keep it upload-to-your-ISP
friendly.

=back

=head2 Background

This section goes into a little more detail into the whys and wherefores
of how the Badger came to be.  You can safely skip onto the next section
if you're in a hurry.

The Badger modules originated in the development of version 3 of the Template
Toolkit. Badger is all the generic bits that form the basis of TT3, not to
mention a few dozen other Perl-based applications (mainly of the web variety)
that I've written over the past few years. The code has evolved and stabilised
over that time and is finally approaching a fit state suitable for human
consumption.

The Badger is a I<toolkit>, not a I<framework>. What's the difference? Good
question. For the purpose of this discussion, a framework is something that
requires you to structure your code in a particular way so as to fit into the
framework. In contrast a toolkit doesn't concern itself too much with how you
write your code (other than some basic principles of structured programming).
Instead it provides a set of tools that you can add into your applications
as you see fit.  

You can use all, some or none of the Badger modules in a project and they'll
play together nicely (convivial play is a central theme of Badger, as is
foraging in the forest for nuts and berries). However, there's no rigid
framework that you have to adjust your mindset to, and very litte "buy-in"
required to start playing Badger games. Use the bits you want and ignore the
rest. Modularity is good. Monolithicity probably isn't even a real word, but
it would be a bad one if it was.

Of course nothing is ever black and white (henceforth known as the "even
badgers have grey fur" principle).  There's a good deal of overlap between 
the two approaches and benefits to be had from them both.  We embrace
a bit of frameworky-ness when it makes good sense, but generally try and
keep things as toolkit-like as possible.

The Badger is dependency free (mind alterating substances notwithstanding).
The basic Badger toolkit requires nothing more than the core modules
distributed with modern versions of Perl (5.8+, maybe 5.6 at a pinch). This is
important (for me at least) because the Badger will be the basis for TT3 and
other forthcoming modules that require minimal dependencies (e.g. for ease of
installation on an ISP or other restricted server). That's not because we
don't love CPAN. Far from it - we luurrrve CPAN. We've borrowed liberally
from CPAN and tried to make as many things inter-play-nicely-able with
existing CPAN modules as possible. But ultimately, one of the goals of Badger
is to provide a self-contained and self-consistent set of modules that all
work the same way, talk the same way, and don't require you to first descend
fifteen levels deep into CPAN dependency hell before you can write a line of
code.

=head1 MODULES

=head2 Badger

The C<Badger> module is a front-end to other C<Badger> modules.  You can use
it to import any of the exportable items from any other C<Badger> module.
Simply specify the module name, minus the C<Badger::> prefix as a load option.

For example:

    use Badger 
        Filesystem => 'Dir File',
        Utils      => 'numlike textlike',
        Constants  => 'ARRAY HASH',
        Codecs     => [codec => 'base64'];

This is equivalent to:

    use Badger;
    use Badger::Filesystem 'Dir File';
    use Badger::Utils      'numlike textlike',
    use Badger::Constants  'ARRAY HASH',
    use Badger::Codecs      codec => 'base64';

Note that multiple arguments for a module should be defined as a list 
reference.

    use Badger 
        ...etc...
        Codecs => [codec => 'base64'];

This is equivalent to:

    use Badger::Codecs [codec => 'base64'];