Embedding Perl in HTML with Mason Chapter 6: The Lexer, Compiler, Resolver, and Interpreter Objects

Tham khảo tài liệu embedding perl in html with mason chapter 6: the lexer, compiler, resolver, and interpreter objects, công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả
Nội dung trích xuất từ tài liệu:
Embedding Perl in HTML with Mason Chapter 6: The Lexer, Compiler, Resolver, and Interpreter Objects Chapter 6: The Lexer, Compiler, Resolver, and Interpreter ObjectsNow that youre familiar with Masons basic syntax and some of its moreadvanced features, its time to explore the details of how the various piecesof the Mason architecture work together to process components. By knowingthe framework well, you can use its pieces to your advantage, processingcomponents in ways that match your intentions.In this chapter well discuss four of the persistent objects in the Masonframework: the Interpreter, Resolver, Lexer, and Compiler. These objectsare created once (in a mod_perl setting, theyre typically created when theserver is starting up) and then serve many Mason requests, each of whichmay involve processing many Mason components.Each of these four objects has a distinct purpose. The Resolver is responsiblefor all interaction with the underlying component source storage mechanism,which is typically a set of directories on a filesystem. The main job of theResolver is to accept a component path as input and return various propertiesof the component such as its source, time of last modification, uniqueidentifier, and so on.The Lexer is responsible for actually processing the component source codeand finding the Mason directives within it. It interacts quite closely with theCompiler, which takes the Lexers output and generates a Mason componentobject suitable for interpretation at runtime.The Interpreter ties the other three objects together. It is responsible fortaking a component path and arguments and generating the resultant output.This involves getting the component from the resolver, compiling it, thencaching the compiled version so that next time the interpreter encounters thesame component it can skip the resolving and compiling phases.Figure 6-1 illustrates the relationship between these four objects. TheInterpreter has a Compiler and a Resolver, and the Compiler has a Lexer.Figure 6-1. The Interpreter and its croniesPassing Parameters to Mason ClassesAn interesting feature of the Mason code is that, if a particular objectcontains another object, the containing object will accept constructorparameters intended for the contained object. For example, the Interpreterobject will accept parameters intended for the Compiler or Resolver and dothe right thing with them. This means that you often dont need to knowexactly where a parameter goes. You just pass it to the object at the top ofthe chain.Even better, if you decide to create your own Resolver for use with Mason,the Interpreter will take any parameters that your Resolver accepts -- not theparameters defined by Masons default Resolver class.Also, if an object creates multiple delayed instances of another class, as theInterpreter does with Request objects, it will accept the created classsparameters in the same way, passing them to the created class at theappropriate time. So if you pass the autoflush parameter to theInterpreters constructor, it will store this value and pass it to any Requestobjects it creates later.This system was motivated in part by the fact that many users want to beable to configure Mason from an Apache config file. Under this system, theuser just sets a certain configuration directive (such as MasonAutoflush1to set the autoflush parameter) in her httpd.conf file, and it gets directedautomatically to the Request objects when they are created.The details of how this system works are fairly magical and the codeinvolved is so funky its creators dont know whether to rejoice or weep, butit works, and you can take advantage of this if you ever need to create yourown custom Mason classes. Chapter 12 covers this in its discussion of theClass::Container class, where all the funkiness is located.The LexerMasons built-in Lexer class is, appropriately enough,HTML::Mason::Lexer . All it does is parse the text of Masoncomponents and pass off the sections it finds to the Compiler. As of Version1.10, the Lexer doesnt actually accept any parameters that alter its behavior,so theres not much for us to say in this section.Future versions of Mason may include other Lexer classes to handlealternate source formats. Some people -- crazy people, we assure you -- haveexpressed a desire to write Mason components in XML, and it would befairly simple to plug in a new Lexer class to handle this. If youre one ofthese crazy people, you may be interested in Chapter 12 to see how to useobjects of your own design as pieces of the Mason framework.By the way, you may be wondering why the Lexer isnt called a Parser, sinceits main job seems to be to parse the source of a component. The answer isthat previous implementations of Mason had a Parser class with a differentinterface and role, and a differe ...