CHP-6>

Now that you're familiar with Mason's basic syntax and some of its more advanced features, it's time to explore the details of how the various pieces of the Mason architecture work together to process components. By knowing the framework well, you can use its pieces to your advantage, processing components in ways that match your intentions.

In this chapter we'll discuss four of the persistent objects in the Mason;objects in> Mason framework: the Interpreter, Resolver, Lexer, and Compiler. These objects are created once (in a mod_perl setting, they're typically created when the server is starting up) and then serve many Mason requests, each of which may involve processing many Mason components.

Each of these four objects has a distinct purpose. The Resolver> Resolver is responsible for all interaction with the underlying component source storage mechanism, which is typically a set of directories on a filesystem. The main job of the Resolver is to accept a component path as input and return various properties of the component such as its source, time of last modification, unique identifier, and so on.

The Lexer> Lexer is responsible for actually processing the component source code and finding the Mason directives within it. It interacts quite closely with the Compiler> Compiler, which takes the Lexer's output and generates a Mason component object suitable for interpretation at runtime.

The Interpreter> Interpreter ties the other three objects together. It is responsible for taking a component path and arguments and generating the resultant output. This involves getting the component from the resolver, compiling it, then caching the compiled version so that next time the interpreter encounters the same component it can skip the resolving and compiling phases.

A<CHP-6-FIG-1>Figure 6-1 illustrates the relationship between these four objects. The Interpreter has a Compiler and a Resolver, and the Compiler has a Lexer.