HTML-MasonX-Free

 view release on metacpan or  search on metacpan

lib/HTML/MasonX/Free/Resolver.pm  view on Meta::CPAN

package HTML::MasonX::Free::Resolver 0.007;

# ABSTRACT: a resolver that lets you specialize components with dir overlays
use Moose;

#pod =head1 OVERVIEW
#pod
#pod This class is a replacement for L<HTML::Mason::Resolver::File>.  If you don't
#pod know anything about what the resolver does or what comp roots are, this whole
#pod thing might make no sense.  If you really like L<Mason|HTML::Mason>, though, it
#pod might be worth reading about it.  Right now.
#pod
#pod Okay, are you caught up?

lib/HTML/MasonX/Free/Resolver.pm  view on Meta::CPAN

#pod
#pod So, let's say you had this set of C<comp_roots>:
#pod
#pod   my_app  =>  /usr/myapp/mason
#pod   shared  =>  /usr/share/mason
#pod
#pod The idea is that you can have stuff in the C<my_app> root that specializes
#pod generalized stuff in the C<shared> root.  Unfortunately, it's not really very
#pod useful.  You can't have F<foo> in the first comp root inherit from F<foo> in
#pod the second.  You can't easily take an existing set of templates and specialize
#pod them with an overlay.
#pod
#pod I<That> is the problem that this resolver is meant to solve.  Instead of having
#pod the resolver try to find each path in each comp root independenly, the
#pod C<comp_roots> are instead stored in the resolver's C<resolver_roots>.  When
#pod looking for a path, it looks in each root in turn.  When it finds one, it
#pod returns that.  If there's another one in one of the later paths, the one that
#pod was found will automatically be made to inherit from it and (by default) to
#pod call it by default.
#pod
#pod Because you don't want the interp object to confuse things with comp roots, you

lib/HTML/MasonX/Free/Resolver.pm  view on Meta::CPAN

1;

__END__

=pod

=encoding UTF-8

=head1 NAME

HTML::MasonX::Free::Resolver - a resolver that lets you specialize components with dir overlays

=head1 VERSION

version 0.007

=head1 OVERVIEW

This class is a replacement for L<HTML::Mason::Resolver::File>.  If you don't
know anything about what the resolver does or what comp roots are, this whole
thing might make no sense.  If you really like L<Mason|HTML::Mason>, though, it

lib/HTML/MasonX/Free/Resolver.pm  view on Meta::CPAN

So, let's say you had this set of C<comp_roots>:

  my_app  =>  /usr/myapp/mason
  shared  =>  /usr/share/mason

The idea is that you can have stuff in the C<my_app> root that specializes
generalized stuff in the C<shared> root.  Unfortunately, it's not really very
useful.  You can't have F<foo> in the first comp root inherit from F<foo> in
the second.  You can't easily take an existing set of templates and specialize
them with an overlay.

I<That> is the problem that this resolver is meant to solve.  Instead of having
the resolver try to find each path in each comp root independenly, the
C<comp_roots> are instead stored in the resolver's C<resolver_roots>.  When
looking for a path, it looks in each root in turn.  When it finds one, it
returns that.  If there's another one in one of the later paths, the one that
was found will automatically be made to inherit from it and (by default) to
call it by default.

Because you don't want the interp object to confuse things with comp roots, you