Table of Contents | Foreword | Preface
Chapters: 1 2 3 4 5 6 7 8 9 10 11 12
Appendices: A B C D
Glossary | Colophon | Copyright

Chapter 4: APIs

Mason is more than just a templating system. It provides a framework for translating requests into output.1 This framework has a number of class/object APIs worth knowing about. You certainly won't need to use most of these methods very often, but you will probably want to use at least some of them in many of your Mason-based projects. This chapter documents those APIs. For a more concise reference to these methods, see Appendix B.

Request Class and Object API

The request object in Mason represents the context of the current request process. For example, it knows where in the component wrapping chain it is, what arguments have been passed to various component calls, if you've been bad or good, and so on. It also allows you to change that context in various ways, such as by calling another component or aborting the request.

The request API provides access to some of the most frequently used Mason features, particularly those relating to component calls, autohandlers, and aborting in the middle of a request.

Recall, as first mentioned in Chapter 2, that the Mason request object is available in all components as $m.

The request class has only two class methods. The first, HTML::Mason::Request->new() , is intended for use by other Mason objects and is not documented for external use. If you want to make a new request object, use the make_subrequest() method provided by the request object, which is covered as part of the discussion of Mason's subrequest mechanism in Chapter 5.

The second class method, HTML::Mason::Request->instance() , returns the current Mason request object. This is useful if you have code outside of a Mason component that needs to access the request object. Inside components, you can just use $m.

The request object's methods can be grouped together into several functional areas.

Constructor Parameters

A number of

parameters can be set when creating a new request object. You will most often set these by passing them to the ApacheHandler's constructor or by setting them in your httpd.conf file. You may occasionally want to set one of these parameters on the fly for the current request. Finally, you will create a new request object when you want to make a subrequest, and you may want to set these parameters then.

All of the following parameters are also available as get/set methods of the same name:

Calling Other Components

Besides the component call tag (<& &>) discussed in Chapter 2, there are several other ways for one component to call another:

Aborting the Flow of Execution

Mason provides a way to abort the flow of execution during a request. Several request object methods relate to doing so and examining what happened afterward.

If you are using eval blocks for exception handling in your components, it is important to propagate exceptions generated from a call to abort(). Here is one way do this:

  eval { $m->call_next(%ARGS) };
  if ($@) {
    if ($m->aborted) {
      # pass this up to a higher level
      die $@;
    } else {
      # something else that's bad happened
      $m->comp( 'exception_handler', exception => $@ );
    }
  }

The Wrapping Chain

These are methods related to the wrapping chain, which was discussed in Chapter 3.

Dhandler-Related Methods

Certain request object methods are specifically related to dhandlers:

Miscellaneous Methods

The request object also has some general-use methods:

Introspection

The Mason request object provides numerous methods allowing introspection of the details of the current request. Some of these methods return one or more component objects, while others return information about the arguments passed to components.

These methods are useful if you are using autohandlers (particularly more than one) and you want to get some information about the components in a request.

Using some of these methods requires an understanding of autohandlers and the wrapping chain, a topic that was covered in Chapter 3.

Buffer-Related Methods

The following methods all deal with Mason's

buffer objects. A typical request starts off with a single base buffer. For each component that is called in the component stack, another buffer will be added to the stack. In addition, filtering and other special Mason features will add and remove additional buffers.

The buffer objects have their own API, detailed later in this chapter, but you will rarely need to use this unless you have a need to implement a subclass of Mason's default buffer class, HTML::Mason::Buffer .

The request API offers several methods for dealing with the buffer stack as a whole:

Caching

One of the easiest ways to gain a quick performance boost for an application is to cache the results of operations that are slow, such as a complicated database query that cannot be optimized. Even when you can optimize some code, it might be simpler to just cache its result rather than optimize your code at the expense of increasing its complexity, thus making it less maintainable.

Caching can also be a big win in providing scalability when you have a bottleneck like an RDBMS. For example, if your web site traffic quadruples in one day, caching the results of some database queries can be the difference between serving pages and watching your database box grind to a bloody, overloaded death.

Because caching is so useful, Mason has a simple caching system that you can use from within your components. Mason's caching system is merely a thin wrapper over DeWitt Clinton's excellent Cache::Cache

modules. These modules provide a number of caching backends such as file or shared memory caches with a simple, feature-rich API. All caches can be limited to a certain size using an LRU algorithm. In addition, it is possible to specify expiration times for stored data using a very flexible syntax.

For more information on Cache::Cache, simply install it from CPAN and type perldocCache::Cache on the command line. Also check out http://perl-cache.sourceforge.net/ for more information online.

Subrequests

Subrequests are request objects that inherit all their settable properties from their parent. The main difference between calling a component with a subrequest versus using a regular component call is that subrequests will invoke the autohandler and dhandler mechanisms, whereas a regular component call will execute only the called component. Subrequests are covered in a more detail in Chapter 5.

Methods Available Only When Using ApacheHandler

When you are using Mason under mod_perl with the HTML::Mason::ApacheHandler class, which is covered in Chapter 7, the Request object will contain several additional methods.

Methods Available When Using ApacheHandler or CGIHandler

Two additional methods are available in the HTML::Mason::ApacheHandler or HTML::Mason::CGIHandler classes. The latter class is covered in Chapter 9.

Getting in Close with Buffers

Underneath the hood of the request object, output is handled via buffer objects, which by default are of the HTML::Mason::Buffer class.

The request object maintains a buffer stack. Output goes to the top buffer on the stack, which can then manipulate it and pass it on to the next buffer in the stack, which can in turn do the same, and so on.

Buffers are also used to implement features like the request's scomp() method.

So why would you want to play with buffers? Chances are you won't want to simply add more plain old HTML::Mason::Buffer objects to the stack. That wouldn't achieve much.

But if you were to create a custom buffer subclass, you might want to selectively stick one onto the stack. For example, if you made a buffer that traced the source of all output it received, you might want to put it on the stack only for certain parts of your site during debugging. Just be sure to remove any buffers you add, or Mason may get confused and your output may never get sent.

The other buffer-related methods are potentially useful for introspection and debugging:

Component Object API

Objects that you will deal with in this class actually fall into three categories. The majority will be objects of the HTML::Mason::Component::FileBased class, which is used for components generated from component source files. The next most common will be HTML::Mason::Component::Subcomponent objects, which represent subcomponents and methods. Finally, anonymous components created via the HTML::Mason::Interp->make_component() method (covered in Chapter 5 and Chapter 6) will simply be of the HTML::Mason::Component class.

For the most part, these objects all share the same interface.

Component objects are returned from a number of Request object methods as well as the interpreter object's make_component() method.

These first methods are the ones you most likely want to use:

Much of the component API is interesting only for introspection, though we're sure creative developers can think of ways to work strange magic with this API.

Methods for File-based Components

A few additional methods are available only for file-based components.

Buffers

Playing with buffers is not for the everyday user but may be useful to you during debugging. Buffer objects have only a few methods:

Footnotes

1. You may or may not choose to call this an application server. -- Return.