Glossary
-
In this book, generally used to refer to the arguments passed to a component, declared in an
<%args>block. -
A named property of a component that can be inherited via the inheritance hierarchy. Attributes are set using the
<%attr>tag and queried using the$component->attr()method. -
A component that "wraps" other components and serves as a default parent. See also inheritance hierarchy and wrapping chain.
-
The bottommost child of the current component as invoked in a component call. This may be the current component itself. Analogous to the "self" in object-oriented programming. The base component changes several times throughout a request as components call one another.
-
The opposite of a "parent" component. Each component may have zero or more children. Children are not specified explicitly; rather, a component becomes a child by virtue of having a parent.
-
A class responsible for turning a body of Mason source code into Perl code suitable for execution by the Interpreter. Available in Mason components as
$m->interp->compiler. -
The basic building block of a Mason site. A component is usually defined in a source file inside the component tree, though one file may define several components. Components can also be created on the fly by feeding component source text to the Interpreter's
make_component()method. -
Depending on context, may refer to a named, ordered list of directories in which Mason will search for components or to a single element of this list. This linguistic ambiguity arises because Mason uses the parameter
comp_rootto refer to the entire list, but many people also use the phrase "multiple component roots" to refer to a component root with more than one element. See also component tree. -
The runtime chain of components that have invoked one another. Analogous to the runtime stack of subroutines in a typical programming language. Components call one another via
$m->comp(),$m->scomp(),$m->call_next(),$component->call_method(), or<& &>tags. The current component is always at the bottom of the component stack, and the top-level autohandler is usually at the top. -
An ordered list of directories in which Mason will search for components. See also component root.
-
The component currently executing at any given point in a Mason request.
-
A directory in which Mason will store temporary files, including object files and cached data.
-
Stands for "default handler." A component invoked when no component matching the requested component path exists.
-
A named property of a component that controls how Mason treats it. Attributes are set using the
<%flags>tag and queried using the$component->flag()method. Flags do not inherit via the inheritance hierarchy. -
A tree of parent/child relationships among components. Each component may inherit by default from an autohandler, or it may specify its parent (or declare that it has no parent) by setting its "inherit" flag.
-
A class responsible for supervising a pool of components and creating Mason Request objects. Available in Mason components as
$m->interp. -
A class responsible for turning a body of Mason source code into meaningful chunks for the Compiler.
-
A special kind of subcomponent that can be inherited via the inheritance hierarchy and called externally. Methods are defined using the
<%method>tag and invoked via$component->call_method()or with the colon-containingcomponent:methodsyntax in$m->comp()calls and the like. -
A filesystem-cached version of the Compiler's output for a single component source file.
-
In this book, generally used to refer to a settable property of any of the pieces of the Mason framework. Parameters for several classes can be passed to a single class's constructor method, and the
Class::Containermodule will make certain that parameters get routed to their intended destination. -
A single component that another component inherits from. Each component may have zero or one parent. See also inheritance hierarchy.
-
Depending on context, may mean the Mason Request object
$m, the Apache request object$r, or the HTTP request initiated by the end user in a web context. The three usually exist simultaneously in a one-to-one correspondence, so the term "request" may sometimes even refer to all three of these. -
The component originally specified in the
exec()Interpreter method, or if no such component exists, the first dhandler that accepts responsibility for the request. In a web-deployed Mason application, the requested component usually matches the URL seen in a web browser. The value of the requested component remains constant throughout a request. -
A class responsible for all interaction between the Interpreter and the underlying storage mechanism for component source files.
-
In this book, used to refer to any deployed Mason application. This is most commonly a web site but may be any collection of Mason components together with an Interpreter to render them.
-
A file containing the Mason source code for a component. A single source file may contain several component definitions if it contains subcomponents or methods. See also object file.
-
A privately scoped component defined in another component. Subcomponents are defined using the
<%def>tag and invoked via the normal component-calling techniques. -
A list of components constructed at the beginning of the request by finding the parent, grandparent, and so on of the requested component. The requested component is always at the bottom of the wrapping chain, and the top-level autohandler is usually at the top.
These HTML pages were created by running this script against the pseudo-POD source.