O'Reilly logo

Embedding Perl in HTML with Mason by Ken Williams, Dave Rolsky

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

The Interpreter

The Interpreter 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 new( ) method.

The new( ) 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:

autohandler_name

This parameter specifies the name that Mason uses for autohandler files. The default name is “autohandler.”

code_cache_max_size

This parameter 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 through the $m->cache and $m->cache_self methods.

data_dir

This parameter specifies the directory under which Mason stores its various data, such as compiled components, cached data, and so on. This cannot be changed after the Interpreter is created.

ignore_warnings_expr

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 parameter. 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.

preloads

This parameter 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.

static_source

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.

compiler
compiler_class
resolver
resolver_class

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 compiler or resolver parameters. Alternatively, you may pass compiler_class or resolver_class parameters (and any arguments required by those classes’ new( ) 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 HTML::Mason::Resolver::File object.

Request Parameters Passed to the Interpreter

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.

The parameters that can be set are: autoflush , data_cache_defaults , dhandler , error_mode , error_format , and out_method .

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.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required