view release on metacpan or  search on metacpan

lib/Path/Resolver.pm  view on Meta::CPAN

#pod =head1 WHAT'S THE POINT?
#pod
#pod Path::Resolver lets you use a simple, familiar notation for accessing all kinds
#pod of hierarchical data.  It's also distributed with resolvers that act as
#pod multiplexers for other resolvers.  Since all resolvers share one mechanism for
#pod addressing content, they can easily be mixed and matched.  Since resolvers know
#pod what kind of object they'll return, and can be fitted with translators, it's
#pod easy to ensure that all your multiplexed resolvers will resolve names to the
#pod same kind of object.
#pod
#pod For example, we could overlay two search paths like this:
#pod
#pod   my $resolver = Path::Resolver::Resolver::Mux::Ordered->new({
#pod     resolvers => [
#pod       Path::Resolver::Resolver::FileSystem->new({ root => './config' }),
#pod       Path::Resolver::Resolver::Archive::Tar->new({ archive => 'config.tgz' }),
#pod     ],
#pod   });
#pod
#pod   $resolver->entity_at('/foo/bar.txt');
#pod

lib/Path/Resolver.pm  view on Meta::CPAN

=head1 WHAT'S THE POINT?

Path::Resolver lets you use a simple, familiar notation for accessing all kinds
of hierarchical data.  It's also distributed with resolvers that act as
multiplexers for other resolvers.  Since all resolvers share one mechanism for
addressing content, they can easily be mixed and matched.  Since resolvers know
what kind of object they'll return, and can be fitted with translators, it's
easy to ensure that all your multiplexed resolvers will resolve names to the
same kind of object.

For example, we could overlay two search paths like this:

  my $resolver = Path::Resolver::Resolver::Mux::Ordered->new({
    resolvers => [
      Path::Resolver::Resolver::FileSystem->new({ root => './config' }),
      Path::Resolver::Resolver::Archive::Tar->new({ archive => 'config.tgz' }),
    ],
  });

  $resolver->entity_at('/foo/bar.txt');