HTML::...:Interp(3pm)
okay bestie, welcome to the HTML::Mason::Interp(3pm) page from User Contributed Perl Documentation π this is part 1 and we're decoding the Mason component interpreter together. no cap, it's giving backend main character energy.
β¨ NAME β¨
HTML::Mason::Interp β Mason Component Interpreter π
πΈ SYNOPSIS πΈ
my $i = HTML::Mason::Interp->new (data_dir=>'/usr/local/mason',
comp_root=>'/usr/local/www/htdocs/',
...other params...);
so you're making an interpreter object and passing params. the ...other params... is literally where the rest of this page goes, iykyk.
π« DESCRIPTION π«
okay so Interp is the Mason workhorse β it executes components and routes their output and errors to all the right places. In a mod_perl environment, Interp objects are handed off immediately to an ApacheHandler object which internally calls the Interp implementation methods. In that case the only user method is the new() constructor. periodt.
π οΈ PARAMETERS TO THE new() CONSTRUCTOR π οΈ
these are the knobs you can pass to new(). each one is a whole vibe, so let's go.
β¨ autohandler_name β¨
File name used for autohandlers. Default is "autohandler". If this is set to an empty string ("") then autohandlers are turned off entirely.
β¨ buffer_preallocate_size β¨
Number of bytes to preallocate in the output buffer for each request. Defaults to 0. Setting this to, say, your maximum page size (or close to it) can reduce the number of reallocations Perl performs as components add to the output buffer.
β¨ code_cache_max_size β¨
Specifies the maximum number of components that should be held in the in-memory code cache. The default is 'unlimited', meaning no components will ever be discarded; Mason can perform certain optimizations in this mode. Setting this to zero disables the code cache entirely. See the code cache section of the administrator's manual for further details.
β¨ comp_root β¨
The component root marks the top of your component hierarchy and defines how component paths are translated into real file paths. For example, if your component root is /usr/local/httpd/docs, a component path of /products/index.html translates to the file /usr/local/httpd/docs/products/index.html.
Under Apache and CGI, comp_root defaults to the server's document root. In standalone mode comp_root defaults to the current working directory.
This parameter may be either a scalar or an array reference. If it is a scalar, it should be a filesystem path indicating the component root. If it is an array reference, it should be of the following form:
[ [ foo => '/usr/local/foo' ],
[ bar => '/usr/local/bar' ] ]
This is an array of two-element array references, not a hash. The "keys" for each path must be unique and their "values" must be filesystem paths. These paths will be searched in the provided order whenever a component path is resolved. For example, given the above component roots and a component path of /products/index.html, Mason would search first for /usr/local/foo/products/index.html, then for /usr/local/bar/products/index.html.
The keys are used in several ways. They help to distinguish component caches and object files between different component roots, and they appear in the title() of a component.
When you specify a single path for a component root, this is actually translated into
[ [ MAIN => path ] ]
If you have turned on dynamic_comp_root, you may modify the component root(s) of an interpreter between requests by calling $interp->comp_root with a value. However, the path associated with any given key may not change between requests. For example, if the initial component root is
[ [ foo => '/usr/local/foo' ],
[ bar => '/usr/local/bar' ], ]
then it may not be changed to
[ [ foo => '/usr/local/bar' ],
[ bar => '/usr/local/baz' ],
but it may be changed to
[ [ foo => '/usr/local/foo' ],
[ blarg => '/usr/local/blarg' ] ]
In other words, you may add or remove key/path pairs but not modify an already-used key/path pair. The reason for this restriction is that the interpreter maintains a component cache per key that would become invalid if the associated paths were to change.
β¨ compiler β¨
The Compiler object to associate with this Interpreter. By default a new object of class compiler_class will be created.
β¨ compiler_class β¨
The class to use when creating a compiler. Defaults to HTML::Mason::Compiler.
β¨ data_dir β¨
The data directory is a writable directory that Mason uses for various features and optimizations: for example, component object files and data cache files. Mason will create the directory on startup, if necessary, and set its permissions according to the web server User/Group.
Under Apache, data_dir defaults to a directory called "mason" under the Apache server root. You will need to change this on certain systems that assign a high-level server root such as /usr!
In non-Apache environments, data_dir has no default. If it is left unspecified, Mason will not use object files, and the default data cache class will be "MemoryCache" instead of "FileCache".
β¨ dynamic_comp_root β¨
True or false, defaults to false. Indicates whether the comp_root can be modified on this interpreter between requests. Mason can perform a few optimizations with a fixed component root, so you should only set this to true if you actually need it.
β¨ escape_flags β¨
A hash reference of escape flags to set for this object. See the section on the set_escape method for more details.
β¨ ignore_warnings_expr β¨
Regular expression indicating which warnings to ignore when loading components. Any warning that is not ignored will prevent the component from being loaded and executed. For example:
ignore_warnings_expr =>
'Global symbol.*requires explicit package'
If set to undef, all warnings are heeded. If set to '.', warnings are turned off completely as a specially optimized case.
By default, this is set to 'Subroutine .* redefined'. This allows you to declare global subroutines inside <%once> sections and not receive an error when the component is reloaded.
β¨ object_file_extension β¨
Extension to add to the end of object files. Default is ".obj".
β¨ preloads β¨
A list of component paths, optionally with glob wildcards, to load when the interpreter initializes. e.g.
preloads => ['/foo/index.html','/bar/*.pl']
Default is the empty list. For maximum performance, this should only be used for components that are frequently viewed and rarely updated. See the preloading components section of the administrator's manual for further details.
As mentioned in the developer's manual, a component's <%once> section is executed when it is loaded. For preloaded components, this means that this section will be executed before a Mason or Apache request exist, so preloading a component that uses $m or $r in a <%once> section will fail.
β¨ request_class β¨
The class to use when creating requests. Defaults to HTML::Mason::Request.
β¨ resolver β¨
The Resolver object to associate with this Compiler. By default a new object of class resolver_class will be created.
β¨ resolver_class β¨
The class to use when creating a resolver. Defaults to HTML::Mason::Resolver::File.
β¨ static_source β¨
True or false, default is false. When false, Mason checks the timestamp of the component source file each time the component is used to see if it has changed. This provides the instant feedback for source changes that is expected for development. However it does entail a file stat for each component executed.
When true, Mason assumes that the component source tree is unchanging: it will not check component source files to determine if the memory cache or object file has expired. This can save many file stats per request. However, in order to get Mason to recognize a component source change, you must flush the memory cache and remove object files. See static_source_touch_file for one easy way to arrange this.
We recommend turning this mode on in your production sites if possible, if performance is of any concern.
β¨ static_source_touch_file β¨
Specifies a filename that Mason will check once at the beginning of of every request. When the file timestamp changes, Mason will (1) clear its in-memory component cache, and (2) remove object files if they have not already been deleted by another process.
This provides a convenient way to implement static_source mode. All you need to do is make sure that a single file gets touched whenever components change. For Mason's part, checking a single file at the beginning of a request is much cheaper than checking every component file when static_source=0.
β¨ use_object_files β¨
True or false, default is true. Specifies whether Mason creates object files to save the results of component parsing. You may want to turn off object files for disk space reasons, but otherwise this should be left alone.
π ACCESSOR METHODS π
All of the above properties have standard accessor methods of the same name. Only comp_root and ignore_warnings_expr can be modified in an existing interpreter; the rest are read-only. π
β¨ ESCAPE FLAG METHODS β¨
ok so these are the methods that let you β¨curateβ¨ which escapes your interpreter knows about. escapes are little text transformations you can apply by flag, and honestly? they're giving main character energy. let's go π
πΈ apply_escapes ($text, $flags, [more flags...])
bestie this one does exactly what it says on the tin: it takes a piece of text and applies one or more escapes to it. you specify which escapes you want by handing over their flags. each escape gets applied to the text in turn, one after the other, and then the now-modified text gets returned to you. π
πΈ remove_escape ($name)
give it an escape name and it yeets that escape out of the interpreter's known escapes. and if the name isn't recognized? no drama, it's just simply ignored. π
πΈ set_escape ($name => see below])
this is the one you call to add an escape flag to the interpreter's list of known escapes. the flag can only be made of characters matching \w plus the dash (-). and it absolutely must start with an alpha character or an underscore (_). no starting with a digit, queen, that's the rule. π
the right hand side can be several different things, so listen up:
- it can be a subroutine reference. classic.
- it can be a string matching
/^\w+$/, and in that case it's assumed to be the name of a subroutine inside theHTML::Mason::Escapesmodule. - and finally, if it's a string that does not match that regex above, then it's assumed to be
evalable code, which will return a subroutine reference. spicy. π₯
when you're setting these with PerlSetVar directives in an Apache configuration file, you do it like this:
PerlSetVar MasonEscapeFlags "h => \&HTML::Mason::Escapes::basic_html_escape"
PerlSetVar MasonEscapeFlags "flag => \&subroutine"
PerlSetVar MasonEscapeFlags "uc => sub { ${$_[0]} = uc ${$_[0]}; }"
PerlAddVar MasonEscapeFlags "thing => other_thing"
π OTHER METHODS π
the rest of the toolkit, bestie. grab a snack, we're going through all of them. π
π¦ comp_exists (path)
hand it an absolute component path and it returns a boolean telling you whether or not a component actually exists for that path. true/false, exists/doesn't, yep/nope. simple. π
π¦ exec (comp, args...)
this creates a brand new HTML::Mason::Request object for the given comp and args, and executes it. the return value is the return value of comp, if there even is one.
super useful for running Mason outside of a web environment β like, standalone script vibes. see "using Mason from a standalone script" in HTML::Mason::Admin for examples.
heads up: this method isn't generally useful in a mod_perl environment. for that, go look at subrequests instead. β¨
π¦ flush_code_cache
empties the component cache. and listen, this matters: when using Perl 5.00503 or earlier, you should call this when you're finished with an interpreter, so those circular references get removed β otherwise they'd prevent the interpreter from being destroyed. so like, clean up after yourself, periodt. π§Ή
π¦ load (path)
returns the component object that corresponds to an absolute component path, or undef if none exists. and if the component fails to load because of a syntax error? it dies with an error. no soft launch, it's over. π
π¦ make_component (comp_source => ... )
π¦ make_component (comp_file => ... )
this method compiles Mason component source code and hands you back a Component object. you can pass the source in as a string in comp_source, or as a filename in comp_file. and when you use comp_file, that filename is specified as a path on the file system β not as a path relative to Mason's component root (for that one, go see $m->fetch_comp).
if Mason hits an error during processing, an exception gets thrown. so wrap it, bestie.
example of usage, exactly as written:
# Make an anonymous component
my $anon_comp =
eval { $interp->make_component
( comp_source => '<%perl>my $name = "World";</%perl>Hello <% $name %>!' ) };
die $@ if $@;
$m->comp($anon_comp);
π¦ make_request (@request_params)
this one creates a Mason request object. the arguments you pass are the same as those for the HTML::Mason::Request->new constructor, or its relevant subclass. real talk, this method will likely only be of interest to those attempting to write new handlers or to subclass HTML::Mason::Interp. and if you want to create a subrequest instead? see subrequests. π
π¦ purge_code_cache ()
called during request execution to clear out the code cache. mainly useful to subclasses that may want to take some custom action upon clearing the cache. niche but iconic. β
π¦ set_global ($varname, [values...])
this sets a global to be used inside components. varname is a variable name, optionally preceded with a prefix ($, @, or %) β and if you leave the prefix off, then $ is assumed. varname is followed by a value in the case of a scalar, or by one or more values in the case of a list or hash. for example:
# Set a global variable $dbh containing the database handle
$interp->set_global(dbh => DBI->connect(...));
# Set a global hash %session from a local hash
$interp->set_global('%session', %s);
the global gets set in the package that components run in: usually HTML::Mason::Commands, although this can be overridden via the in_package parameter. so the lines above, for example, are equivalent to:
$HTML::Mason::Commands::dbh = DBI->connect(...);
%HTML::Mason::Commands::session = %s;
assuming in_package has not been changed. π
okay important one: any global you set should also be registered with theallow_globalsparameter, otherwise you'll get warnings fromstrict. don't skip this step, it's giving unfinished business andstrictwill absolutely call you out. π
and that's the whole page, bestie!! πΈ you made it all the way through, and honestly? iconic behavior. now go write some components. π
this fine piece of documentation is perl v5.38.2, dated 2024-03-05, from the user-contributed Perl documentation for HTML::...::Interp(3pm) β she's a little old, she's a little fancy, and she ate. π«Άπ
β¨
π¦ where this page comes from
- debian trixie: libhtml-mason-perl 1:1.60-2 Β· Artistic-1.0-Perl OR GPL-1.0-or-later
- ubuntu noble: libhtml-mason-perl 1:1.60-2 Β· Artistic-1.0-Perl OR GPL-1.0-or-later
- ubuntu resolute: libhtml-mason-perl 1:1.60-2 Β· Artistic-1.0-Perl OR GPL-1.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms