GLOSS>
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 <&
&E<gt>
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.