view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    The "id" column in this table is not really necessary for
    "Apache2::Translation". But if you want to deploy
    Apache2::Translation::Admin you need it.

    Well, here we have a frontend/backend configuration. The frontend
    records are labeled with the key "front", the backend records with
    "back".

    When a request comes in first the records with ":PRE:" in the
    "uri"-field are examined. Suppose, a request for
    "http://abc.com/static/img.png" comes in. Record 1 (id=1) checks the
    "Host" header. The expression after "Cond:" is evaluated as Perl code.
    It obviously returns true. "Cond" stands for *condition*. But how does
    it affect the further workflow? Here "blk" and "ord" come in. All
    records with the same "key", "uri" and "blk" form a block. "ord" gives
    an order within this block. Within a block all actions are executed up
    to the first condition that is false.

    Now, because our condition in record 1 is true the action in record 2
    (within the same block) is executed. It redirects the browser with a
    HTTP code of 301 (MOVED PERMANENTLY) to "http://xyz.com/static/img.png".

    When the redirected request comes back the condition in record 1 is
    false. Hence, the next block (key=front, uri=:PRE:, blk=1) is evaluated.
    First a "lang" member of a context hash is set to "en". A "Do" action is
    similar to a condition, only its value is ignored. Record 4 then checks
    if the "Host" header matches "/de$/". If so, then record 5 sets the
    *language* to "de".

    Now, the records labeled with ":PRE:" are finished. The handler starts
    looking for blocks labeled with the request uri. That is, it looks for a
    block with key=front, uri=/static/img.png. None is found.

    Then it cuts off the last part of the uri (/img.png), repeats the lookup
    and finds record 6. The "File" action sets "$r->filename" to
    "$DOCROOT/en/img.png". "Apache2::Translation" provides some convenience
    variables. They are tied to members of the request record.
    $MATCHED_PATH_INFO contains the uri part cut off ("/img.png"). More on
    them below.

    Now another round is started and the next uri part is cut off. Record 9
    matches. We see a "Config" action that sets "AuthName" and "AuthType".

    At the end the translation handler checks if "$r->filename" was set and
    returns "Apache2::Const::OK" or "Apache2::Const::DECLINED" respectively.

    I think that example gives a general idea, what "Apache2::Translation"
    does.

lib/Apache2/Translation.pod  view on Meta::CPAN

 13  back   /appl2   0   0   PerlHandler: 'My::Application2'

The C<id> column in this table is not really necessary for
C<Apache2::Translation>. But if you want to deploy
L<Apache2::Translation::Admin> you need it.

Well, here we have a frontend/backend configuration. The frontend records
are labeled with the key C<front>, the backend records with C<back>.

When a request comes in first the records with C<:PRE:> in the C<uri>-field are
examined. Suppose, a request for C<http://abc.com/static/img.png>
comes in. Record 1 (id=1) checks the C<Host> header. The expression
after C<Cond:> is evaluated as Perl code. It obviously returns true.
C<Cond> stands for I<condition>. But how does it affect the further
workflow? Here C<blk> and C<ord> come in. All records with the same
C<key>, C<uri> and C<blk> form a B<block>. C<ord> gives an order within
this block. Within a block all actions are executed up to the first
condition that is false.

Now, because our condition in record 1 is true the action in record 2
(within the same block) is executed. It redirects the browser with a
HTTP code of 301 (MOVED PERMANENTLY) to C<http://xyz.com/static/img.png>.

When the redirected request comes back the condition in record 1 is
false. Hence, the next block (key=front, uri=:PRE:, blk=1) is evaluated.
First a C<lang> member of a context hash is set to C<en>. A C<Do> action
is similar to a condition, only its value is ignored. Record 4 then
checks if the C<Host> header matches C</de$/>. If so, then record 5 sets
the I<language> to C<de>.

Now, the records labeled with C<:PRE:> are finished. The handler starts
looking for blocks labeled with the request uri. That is, it looks
for a block with key=front, uri=/static/img.png. None is found.

Then it cuts off the last part of the uri (/img.png), repeats the
lookup and finds record 6. The C<File> action sets C<$r-E<gt>filename> to
C<$DOCROOT/en/img.png>. C<Apache2::Translation> provides some convenience
variables. They are tied to members of the request record.
C<$MATCHED_PATH_INFO> contains the uri part cut off
(C</img.png>). More on them below.

Now another round is started and the next uri part is cut off. Record 9
matches. We see a C<Config> action that sets C<AuthName> and C<AuthType>.

At the end the translation handler checks if C<$r-E<gt>filename> was set and
returns C<Apache2::Const::OK> or C<Apache2::Const::DECLINED> respectively.

I think that example gives a general idea, what C<Apache2::Translation>
does.

lib/Apache2/Translation/Admin.pm  view on Meta::CPAN

our $DEFAULTPROVIDERHOST='http://localhost';

$STATIC=__PACKAGE__;
$STATIC=~s!::!/!g;
$STATIC=$INC{$STATIC.'.pm'};
$STATIC=~s/\.pm$//;

our %TYPES=
  (
   gif=>'image/gif',
   png=>'image/png',
   jpg=>'image/jpeg',
   jpeg=>'image/jpeg',
   ico=>'image/x-icon',
   html=>'text/html',
   shtml=>'text/html',
   css=>'text/css',
   js=>'application/x-javascript',
  );

sub _config_provider_SPEC {