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_root
to 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-containing component:method
syntax 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::Container
module 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.