GLOSS>

arguments;definition of>argument

In this book, generally used to refer to the arguments passed to a component, declared in an <%args> block.

attributes;definition of>attribute

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.

autohandlers;definition of>autohandler

A component that ``wraps'' other components and serves as a default parent. See also inheritance hierarchy and wrapping chain.

base components;definition of>components;base>base component

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.

child components>components;child>child component

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.

Compiler;definition of>Compiler

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.

components;definition of>component

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.

component roots;definition of>component root

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.

component stacks>component stack

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.

component tree>component tree

An ordered list of directories in which Mason will search for components. See also component root.

current components>components;current>current component

The component currently executing at any given point in a Mason request.

data directory>directories;data>data directory

A directory in which Mason will store temporary files, including object files and cached data.

dhandlers;definition of>dhandler

Stands for ``default handler.'' A component invoked when no component matching the requested component path exists.

flags>flag

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.

inheritance hierarchy>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.

Interpreter;definition of>Interpreter

A class responsible for supervising a pool of components and creating Mason Request objects. Available in Mason components as $m->interp.

Lexer>Lexer

A class responsible for turning a body of Mason source code into meaningful chunks for the Compiler.

methods;definition of>method

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.

object files>object file

A filesystem-cached version of the Compiler's output for a single component source file.

parameters>parameter

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.

parent components>components;parent>parent component

A single component that another component inherits from. Each component may have zero or one parent. See also inheritance hierarchy.

requests>request

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.

requested components>components;requested>requested component

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.

Resolver;definition of>Resolver

A class responsible for all interaction between the Interpreter and the underlying storage mechanism for component source files.

sites>site

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.

source files>source file

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.

subcomponents;definition of>components;subcomponents>subcomponent

A privately scoped component defined in another component. Subcomponents are defined using the <%def> tag and invoked via the normal component-calling techniques.

wrapping chain;definition of>wrapping chain

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.