HTML::...ompiler(3pm)

πŸ¦‹ NAME πŸ¦‹

okay bestie, welcome to HTML::Mason::Compiler β€” this is the page from User Contributed Perl Documentation (you'll see it filed under the slightly cursed-looking HTML::...ompiler(3pm) label, don't worry about it πŸ’…). What does it do? It compiles Mason component source. that's it, that's the job. ✨


✨ SYNOPSIS ✨

the classic move β€” you subclass it, no cap:

package My::Funky::Compiler;

use base qw(HTML::Mason::Compiler);

πŸ’– DESCRIPTION πŸ’–

so here's the tea πŸ«–: the compiler kicks off the whole compilation process by calling its lexer's lex method, and it passes itself in as the compiler parameter. then the lexer just keeps calling various methods back on the compiler as it parses the component source. it's giving teamwork. it's giving callback energy. 😌


πŸŽ€ PARAMETERS TO THE new() CONSTRUCTOR πŸŽ€

these are the things you can hand over when you build your compiler, bestie:

  • allow_globals β€” a list of variable names, prefix and all ($@%), that you're planning to use as globals in your components. normally strict is out here forbidding global variables like a bouncer 😀, but any variable you name in this list gets a reprieve via a use vars statement. like so:
allow_globals => [qw($DBH %session)]

and heads up: if you're in a mod_perl environment, $r (the request object) gets added to this list automatically. freebie 🎁

  • default_escape_flags β€” the escape flags you want applied to all <% %> expressions by default. the currently valid flags are:
h - escape for HTML ('<' => '&lt;', etc.)
u - escape for URL (':' => '%3A', etc.)

your dev can totally override the default escape flags on a per-expression basis β€” see the escaping expressions section of the developer's manual for that 🧚. and if you wanna set multiple flags as the default, pass this as a reference to an array of flags. slay.

  • enable_autoflush β€” true or false, defaults to true. tells you whether components get compiled with support for autoflush. if it doesn't have to check for autoflush mode, a component can be compiled into a more efficient form β€” so if you can, set this to 0. πŸ”₯
  • lexer β€” the Lexer object you wanna pair with this Compiler. by default, a new object of class lexer_class gets created for you.
  • lexer_class β€” the class to use when creating a lexer. defaults to HTML::Mason::Lexer.
  • preprocess β€” a sub reference that gets called to preprocess each component before the compiler does its magic ✨. the sub is called with a single parameter: a scalar reference to the script. the sub is expected to process the script in-place. this is one way to extend the HTML::Mason syntax with new tags and stuff β€” though honestly a much more flexible way is to subclass the Lexer or Compiler class. see also postprocess_text and postprocess_perl.
  • postprocess_text β€” a sub reference that gets called to postprocess the text portion of a compiled component, right before it's assembled into its final subroutine form. called with a single parameter: a scalar reference to the text portion of the component. the sub is expected to process the string in-place. see also preprocess and postprocess_perl.
  • postprocess_perl β€” a sub reference that gets called to postprocess the Perl portion of a compiled component, right before it's assembled into its final subroutine form. called with a single parameter: a scalar reference to the Perl portion of the component. the sub is expected to process the string in-place. see also preprocess and postprocess_text.
  • use_source_line_numbers β€” true or false, defaults to true. this one's about whether the component line numbers showing up in error messages, stack traces, etc. are in terms of the source file instead of the object file. Mason pulls this off by inserting #line directives into compiled components. source line numbers are more immediately helpful, sure β€” but object file line numbers might be more appropriate if you're doing in-depth debugging sessions. your call πŸ‘‘

πŸ‘‘ ACCESSOR METHODS πŸ‘‘

every single property up there has a read-only accessor method with the same name. yes, all of them. 🫢

and listen β€” you cannot change any property of a compiler after it's been created. like, at all. among other things, that would potentially invalidate any existing cached component objects or object files, and we do not want that chaos 😭. your best bet is to create different compiler objects and load them into different interpreters. periodt.


πŸ”₯ METHODS πŸ”₯

besides the compilation callbacks below, there are several methods a Compiler subclass needs to implement. let's get into it πŸ’…

compile(...)

this method has several parameters:

  • comp_source (required) β€” either a scalar or a reference to a scalar containing the component source.
  • name (required) β€” the name of the component. this should be the filename of the component if it's file-based, or some other clear identifier of the component source.
  • comp_path (required) β€” this should be the component's path.
  • fh (optional) β€” if this is given, the output of the compiler goes directly to this handle instead of being buffered in memory. it's an optimization to avoid memory usage. cute and efficient. ✨

object_id

this method should return a unique id for the given compiler object. the interpreter uses it when determining the object directory, for example.


Compilation Callbacks

these are the methods the Lexer calls while it's processing a component source. if you're implementing your own custom Compiler class, you might wanna override some of these πŸ‘€

  • start_component() β€” called by the Lexer when it starts processing a component.
  • end_component() β€” called by the Lexer when it finishes processing a component.
  • start_block(block_type => <string>) β€” called by the Lexer when it encounters an opening Mason block tag like <%perl> or <%args>. its main purpose is keeping track of how different kinds of blocks nest inside each other. the type of block ("init", "once", etc.) comes in through the block_type parameter.
  • end_block(block_type => <string>) β€” called by the Lexer when it encounters a closing Mason block tag like </%perl> or </%args>. like start_block(), its main purpose is helping maintain syntactic integrity.
  • *_block(block => <string>, [ block_type => <string> ]) β€” several compiler methods like doc_block(), text_block(), and raw_block() get called by the Lexer after start_block() when it encounters blocks of certain types. these methods actually do the work of putting the body of a block into the compiled data structure. the methods following this pattern are init_block(), perl_block(), doc_block(), text_block(), and raw_block(). that last one gets called for all <%once>, <%cleanup>, <%filter>, <%init>, <%perl>, and <%shared> blocks.
  • text(text => <string>) β€” inserts the text contained in a text parameter into the component for verbatim output. this gets called when the lexer finds plain text in a component.
  • variable_declaration( type => <string>, name => <string>, default => <string> ) β€” inserts a variable declaration from the <%args> section into the component. the type will be either "$", "@", or "%", indicating a scalar, array, or hash. the name is the variable name without the leading sigil. the default is everything found after the first => on an <%args> block line, and it may include a comment.
  • key_value_pair(block_type => <string>, key => <string>, value => <string>) β€” inserts a key-value pair from a <%flags> or <%attr> section into the component. the block_type parameter will be either "flags" or "attr".
  • start_named_block(block_type => <string>, name => <name>) β€” analogous to item_start_block, but it starts a "named" block (<%method> or <%def>).
  • end_named_block() β€” called by the Lexer to end a "named" block.
  • substitution(substitution => <string>, escape => <string>) β€” called by the Lexer when it encounters a substitution tag (<% ... %>). the value of the escape parameter will be everything found after the pipe (|) in the substitution tag, and it may be more than one character, such as "nh".
  • component_call(call => <string>) β€” called by the Lexer when it encounters a component call tag without embedded content (<& ... &>). the call parameter contains the entire contents of the tag.
  • component_content_call(call => <string>) β€” called by the Lexer when it encounters a component call tag with embedded content (<&| ... &>).
  • component_content_call_end() β€” called by the Lexer when it encounters an ending tag for a component call with content (</&>). note that there's no corresponding component_call_end() method for component calls without content, because those calls don't have ending tags. (iykyk πŸ’€)
  • perl_line(line => <string>) β€” called by the Lexer when it encounters a %-line.

🌈 SUBCLASSING 🌈

we recommend that any parameters you add to Compiler be read-only, because the compiler object_id is only computed once on creation and wouldn't reflect any changes to Lexer parameters. so like, don't try to be sneaky about it πŸ™ˆ


and that's the whole page, bestie! πŸŽ€ this was HTML::...ompiler(3pm) β€” from perl v5.38.2, dated 2024-03-05, brought to you by User Contributed Perl Documentation. go forth and compile something iconic πŸ’– ✨ πŸ¦‹

πŸ“¦ where this page comes from