- Components: Modular Design Elements
- Object-Style Component Inheritance
- Intelligent Caching Mechanisms
- Integration with Apache and mod_perl
Alternatives to Mason: Embperl
- Embperl may be the most similar one to Mason
- Embperl is one of the oldest heavyweight systems that is still in widespread use
- Has several “magical” HTML-manipulation features, this means that Embperl does some scanning of your HTML and your Perl code to decide when you mean to use its magical generation.
- If you are continually frustrated by your development tools and environment, you will almost certainly not be able to create a satisfactory product.
- Mason was created to help you with tasks when you need help and get out of your way when you don’t.
- Mason’s design choices were made to encourage a structural approach to site building rather than a procedural approach
Mason’s compilation process consists of turning Mason source code into Perl code
stores the compiled code in an LRU (least recently used) cache in memory.
A component is a combination of text and Mason-specific markup. However, a component always corresponds to a single file. Components are closely analogous to Perl subroutines.
The component root is a directory or list of directories on the filesystem under which Mason expects to find all of your components.
A URL is a unique identifier for a particular resource.
- <% … %> Substitution Perl that is evaluated and sent as output
- % … Perl line A single line of Perl code 2
- <%perl> … </%perl> Perl block Perl code
- <& … &> Component call A call to another component, possibly with arguments
- <%init> … </%init> init block Perl code that executes before the main body of the component
- <%args> … </%args> args block A component’s input argument declarations
- <textarea name=”foo”><% $foo_data | h %></textarea> (escape)
An alternative to the <& &> syntax for calling other components is the $m->comp() method. The $m variable contains the HTML::Mason::Request object for the current request.
They are equals:
<& menu, width => 640, admin => 1 &>
% $m->comp(‘menu’, width => 640, admin => 1);
So far, we know three ways to call c omponents: by using the inline component call tag (<& &>), by using the $m->comp() method, or via a URL.
By default, Mason components return undef. If you want to return something else, you can add an explicit return() statement inside that component
- $m: This variable is an HTML::Mason::Request object;
- $r: If Mason is running under mod_perl (as is the case in most Mason setups), all components also have access to the Apache request object via the global variable $r.
Dhandlers and Autohandlers
If any of these components exist, the search will terminate and Mason will serve the first dhandler it finds, making the remainder of the requested component path available to the dhandler via $m->dhandler_arg.
Dhandlers can be useful in many situations.
You may want to use Mason’s features to create or process these documents, but it wouldn’t be feasible to create a separate Mason component for each document on your server.
/docs/component.mas may decline the request by calling $m->decline, which passes control to /docs/dhandler
Mason borrows a page from object-oriented programming.
Several components may have the same parent, thereby sharing their common functionality.
<%flags> inherit => 'mommy.mas' </%flags>
If a component doesn’t specify a parent explicitly, Mason may assign a default parent.
This is (finally) how autohandlers come into: If no autohandler exists in the same directory, Mason will look for an autohandler one directory up.
Just like dhandlers, you can change the component name used for the autohandler mechanism from autohandler to something else, by setting the Mason interpreter’s autohandler_name parameter.
About call_next usage:
<html> <head><title>Example.com</title></head> <body> % $m->call_next; <br><a href="/">Home</a> </body> </html>
Mason is more than just a templating system. It provides a framework for translating requests into output.