is the center of Mason’s universe. It is responsible
for coordinating the activities of the Compiler and Resolver, as well
as creating Request objects. Its main task involves receiving
requests for components and generating the resultant output of those
requests. It is also responsible for several tasks behind the scenes,
such as caching components in memory or on disk. It exposes only a
small part of its object API for public use; its primary interface is
via its constructor, the
method accepts lots of parameters. It
accepts any parameter that its Resolver or Compiler (and through the
Compiler, the Lexer) classes accept in their
new( ) methods; these parameters will be transparently passed
along to the correct constructor. It also accepts the following
parameters of its own:
This parameter specifies the name that Mason uses for autohandler files. The default name is “autohandler.”
sets the limit, in bytes, of the in-memory cache for component code.
The default is 10 megabytes (10 * 1024 * 1024). This is not the same
thing as the on-disk cache for component code, which will keep
growing without bound until all components are cached on disk. It is
also different from the data caches, the sizes of which you control
Normally, warnings issued during the loading of a component are
treated as fatal errors by Mason. Mason will ignore warnings that
match the regular expression specified in this
The default setting is
qr/Subroutine .* redefined/i. If you change this parameter, you will
probably want to make sure that this particular warning continues to
be ignored, as this allows you to declare named subroutines in the
<%once> section of components
and not cause an error when the component is reloaded and the
subroutine is redefined.
takes a list of components to be preloaded when the Interpreter is
created. In a
mod_perl setting this can lead to
substantial memory savings and better performance, since the
components will be compiled in the server’s parent
process and initially shared among the server children. It also
reduces the amount of processing needed during individual requests,
as preloaded components will be standing at the ready.
The list of components can either be specified by listing each
component path individually or by using
glob( )-style patterns to specify several component paths.
Passing a true value for this parameter causes Mason to execute in “static source” mode, which means that it will compile a source file only once, ignoring subsequent changes. In addition, it will resolve a given path only once, so adding or removing components will not be noticed by the interpreter.
If you do want to make changes to components when Mason is in this
mode, you will need to delete all of Mason’s object
files and, if you are running Mason under
mod_perl, restart the Apache server.
This mode is useful in order to gain a small performance boost on a heavily trafficked site when your components don’t change very often. If you don’t need the performance boost, then don’t bother turning this mode on, as it just makes for extra administrative work when you change components.
As we mentioned before, each Interpreter object creates a Compiler
and a Resolver object that it works with to serve requests. You can
substantially alter the compilation or resolution tasks by providing
your own Compiler or Resolver when creating the Interpreter, passing
them as the values for the
resolver parameters. Alternatively, you may pass
resolver_class parameters (and any arguments
required by those classes’
methods) and allow the Interpreter to construct the Compiler or
Resolver from the other parameters you specify:
my $interp = HTML::Mason::Interpreter->new ( resolver_class => 'MyApp::Resolver', compiler_class => 'MyApp::Compiler', comp_root => '/home/httpd/docs', # Goes to resolver default_escape_flags => 'h', # Goes to compiler );
By default, the Compiler will be an
HTML::Mason::Compiler::ToObject object, and the
Resolver will be an
Besides the Interpreter’s own parameters, you can pass the Interpreter any parameter that the Request object accepts. These parameters will be saved internally and used as defaults when making a new Request object.
Besides accepting these as constructor parameters, the Interpreter also provides get/set accessors for these attribute. Setting these attributes in the interpreter will change the attribute for all future Requests, though it will not change the current Request.