Parsing Pod

    use Pod::POM;

    my $parser = Pod::POM->new();
    my $pom = $parser->parse_file($filename)
        || die $parser->error();

The parse(), parse_text() and parse_file() methods return undef on error. The error() method can be called to retrieve the error message generated. Parsing a document may also generate non-fatal warnings. These can be retrieved via the warnings() method which returns a reference to a list when called in scalar context or a list of warnings when called in list context.

    foreach my $warn ($parser->warnings()) {
        warn $warn, "\n";
    }

Alternatively, the 'warn' configuration option can be set to have warnings automatically raised via "warn()" as they are encountered.

    my $parser = Pod::POM->new( warn => 1 );

Walking the Object Model

So to fetch the list of '=head1' sections within our parsed document, we would do the following:

    my $sections = $pom->head1();

Methods like this will return a list of further Pod::POM::Node::* objects when called in list context or a reference to a list when called in scalar context. In the latter case, the list is blessed into the Pod::POM::Node::Content class which gives it certain magical properties (more on that later).

Given the list of Pod::POM::Node::Head1 objects returned by the above, we can print the title attributes of each like this:

    foreach my $s (@$sections) {
        print $s->title();
    }

Let's look at the second section, DESCRIPTION.

    my $desc = $sections->[1];

We can print the title of each subsection within it:

    foreach my $ss ($desc->head2()) {
        print $ss->title();
    }

Hopefully you're getting the idea by now, so here's a more studly example to print the title for each item contained in the first list within the METHODS section:

    foreach my $item ($desc->head2->[0]->over->[0]->item) {
        print $item->title(), "\n";
    }

Element Content

    foreach my $item ($pom->content()) {
        my $type = $item->type();
        if ($type eq 'head1') {
            ...
        }
        elsif ($type eq 'head2') {
            ...
        }
        ...
    }

The content for an element is represented by a reference to a list, blessed into the Pod::POM::Node::Content class. This provides some magic in the form of an overloaded stringification operator which will automatically print the contents of the list if you print the object itself. In plain English, or rather, in plain Perl, this means you can do things like the following:

    foreach my $head1 ($pom->head1()) {
        print '<h1>', $head1->title(), "</h1>\n\n";
        print $head1->content();
    }

    # print all the root content
    foreach my $item ($pom->content()) {
        print $item;
    }

    # same as above
    print $pom->content();

In fact, all Pod::POM::Node::* objects provide this same magic, and will attempt to Do The Right Thing to present themselves in the appropriate manner when printed. Thus, the following are all valid.

    print $pom;                 # entire document
    print $pom->content;        # content of document
    print $pom->head1->[0];     # just first section
    print $pom->head1;          # print all sections
    foreach my $h1 ($pom->head1()) {
        print $h1->head2();     # print all subsections
    }

Output Views

A view is represented in this case by an object class which contains methods for displaying each of the different element types that could be encountered in any Pod document. There's a method for displaying "=head1" sections (view_head1()), another method for displaying "=head2" sections (view_head2()), one for "=over" (view_over()), another for "=item" (view_item()) and so on.

If we happen to have a reference to a $node and we know it's a 'head1' node, then we can directly call the right view method to have it displayed properly:

    $view = 'Pod::POM::View::HTML';
    $view->view_head1($node);

Thus our earlier example can be modified to be slightly less laborious and marginally more flexible.

    foreach my $node ($pom->content) {
        my $type = $node->type();
        if ($type eq 'head1') {
            print $view->view_head1($node);
        }
        elsif ($type eq 'head2') {
            print $view->view_head2($node);
        }
        ...
    }

However, this is still far from ideal. To make life easier, each Pod::POM::Node::* class inherits (or possibly redefines) a "present($view)" method from the Pod::POM::Node base class. This method expects a reference to a view object passed as an argument, and it simply calls the appropriate view_xxx() method on the view object, passing itself back as an argument. In object parlance, this is known as "double dispatch". The beauty of it is that you don't need to know what kind of node you have to be able to print it. You simply pass it a view object and leave it to work out the rest.

    foreach my $node ($pom->content) {
        print $node->present($view);
    }

If $node is a Pod::POM::Node::Head1 object, then the view_head1($node) method gets called against the $view object. Otherwise, if it's a Pod::POM::Node::Head2 object, then the view_head2($node) method is dispatched. And so on, and so on, with each node knowing what it is and where it's going as if determined by some genetically pre-programmed instinct. Fullfilling their destinies, so to speak.

Double dispatch allows us to do away with all the explicit type checking and other nonsense and have the node objects themselves worry about where they should be routed to. At the cost of an extra method call per node, we get programmer convenience, and that's usually a Good Thing.

Let's have a look at how the view and node classes might be implemented.

    package Pod::POM::View::HTML;

    sub view_pod {
        my ($self, $node) = @_;
        return $node->content->present($self);
    }

    sub view_head1 {
        my ($self, $node) = @_;
        return "<h1>", $node->title->present($self), "</h1>\n\n"
             . $node->content->present($self);
    }

    sub view_head2 {
        my ($self, $node) = @_;
        return "<h2>", $node->title->present($self), "</h2>\n\n"
             . $node->content->present($self);
    }

    ...

    package Pod::POM::Node::Pod;

    sub present {
        my ($self, $view) = @_;
        $view->view_pod($self);
    }

    package Pod::POM::Node::Head1;

    sub present {
        my ($self, $view) = @_;
        $view->view_head1($self);
    }

    package Pod::POM::Node::Head2;

    sub present {
        my ($self, $view) = @_;
        $view->view_head2($self);
    }

    ...

Some of the view_xxx methods make calls back against the node objects to display their attributes and/or content. This is shown in, for example, the view_head1() method above, where the method prints the section title in "<h1>"..."<h1>" tags, followed by the remaining section content.

Note that the title() attribute is printed by calling its present() method, passing on the reference to the current view. Similarly, the content present() method is called giving it a chance to Do The Right Thing to present itself correctly via the view object.

There's a good chance that the title attribute is going to be regular text, so we might be tempted to simply print the title rather than call its present method.

    sub view_head1 {
        my ($self, $node) = @_;
        # not recommended, prefer $node->title->present($self)
        return "<h1>", $node->title(), "</h1>\n\n", ...
    }

However, it is entirely valid for titles and other element attributes, as well as regular, formatted text blocks to contain code sequences, such like "B<this>" and "I<this>". These are used to indicate different markup styles, mark external references or index items, and so on. What's more, they can be "B<nested I<indefinitely>>". Pod::POM takes care of all this by parsing such text, along with any embedded sequences, into Yet Another Tree, the root node of which is a Pod::POM::Node::Text object, possibly containing other Pod::POM::Node::Sequence objects. When the text is presented, the tree is automatically walked and relevant callbacks made against the view for the different sequence types. The methods called against the view are all prefixed 'view_seq_', e.g. 'view_seq_bold', 'view_seq_italic'.

Now the real magic comes into effect. You can define one view to render bold/italic text in one style:

    package My::View::Text;
    use parent qw( Pod::POM::View::Text );

    sub view_seq_bold {
        my ($self, $text) = @_;
        return "*$text*";
    }

    sub view_seq_italic {
        my ($self, $text) = @_;
        return "_$text_";
    }

And another view to render it in a different style:

    package My::View::HTML;
    use parent qw( Pod::POM::View::HTML );

    sub view_seq_bold {
        my ($self, $text) = @_;
        return "<b>$text</b>";
    }

    sub view_seq_italic {
        my ($self, $text) = @_;
        return "<i>$text</i>";
    }

Then, you can easily view a Pod Object Model in either style:

    my $text = 'My::View::Text';
    my $html = 'My::View::HTML';

    print $pom->present($text);
    print $pom->present($html);

And you can apply this technique to any node within the object model.

    print $pom->head1->[0]->present($text);
    print $pom->head1->[0]->present($html);

In these examples, the view passed to the present() method has been a class name. Thus, the view_xxx methods get called as class methods, as if written:

    My::View::Text->view_head1(...);

If your view needs to maintain state then you can create a view object and pass that to the present() method.

    my $view = My::View->new();
    $node->present($view);

In this case the view_xxx methods get called as object methods.

    sub view_head1 {
        my ($self, $node) = @_;
        my $title = $node->title();
        if ($title eq 'NAME' && ref $self) {
            $self->{ title } = $title();
        }
        $self->SUPER::view_head1($node);
    }

Whenever you print a Pod::POM::Node::* object, or do anything to cause Perl to stringify it (such as including it another quoted string "like $this"), then its present() method is automatically called. When called without a view argument, the present() method uses the default view specified in $Pod::POM::DEFAULT_VIEW, which is, by default, 'Pod::POM::View::Pod'. This view regenerates the original Pod document, although it should be noted that the output generated may not be exactly the same as the input. The parser is smart enough to detect some common errors (e.g. not terminating an "=over" with a "=back") and correct them automatically. Thus you might find a "=back" correctly placed in the output, even if you forgot to add it to the input. Such corrections raise non-fatal warnings which can later be examined via the warnings() method.

You can update the $Pod::POM::DEFAULT_VIEW package variable to set the default view, or call the default_view() method. The default_view() method will automatically load any package you specify. If setting the package variable directly, you should ensure that any packages required have been pre-loaded.

    use My::View::HTML;
    $Pod::POM::DEFAULT_VIEW = 'My::View::HTML';

or

    Pod::POM->default_view('My::View::HTML');

Template Toolkit Views

The latest version of the Template Toolkit (2.06 at the time of writing) provides a Pod plugin to interface to this module. It also implements a new (but experimental) VIEW directive which can be used to build different presentation styles for converting Pod to other formats. The Template Toolkit is available from CPAN:

    http://www.cpan.org/modules/by-module/Template/

Template Toolkit views are similar to the Pod::POM::View objects described above, except that they allow the presentation style for each Pod component to be written as a template file or block rather than an object method. The precise syntax and structure of the VIEW directive is subject to change (given that it's still experimental), but at present it can be used to define a view something like this:

    [% VIEW myview %]

       [% BLOCK view_head1 %]
          <h1>[% item.title.present(view) %]</h1>
          [% item.content.present(view) %]
       [% END %]
 
       [% BLOCK view_head2 %]
          <h2>[% item.title.present(view) %]</h2>
          [% item.content.present(view) %]
       [% END %]

       ...

    [% END %]

A plugin is provided to interface to the Pod::POM module:

    [% USE pod %]
    [% pom = pod.parse('/path/to/podfile') %]

The returned Pod Object Model instance can then be navigated and presented via the view in almost any way imaginable:

    <h1>Table of Contents</h1>
    <ul>
    [% FOREACH section = pom.head1 %]
       <li>[% section.title.present(view) %]
    [% END %]
    </ul>

    <hr>

    [% FOREACH section = pom.head1 %]
       [% section.present(myview) %]
    [% END %]

You can either pass a reference to the VIEW (myview) to the present() method of a Pod::POM node:

    [% pom.present(myview) %]       # present entire document

Or alternately call the print() method on the VIEW, passing the Pod::POM node as an argument:

    [% myview.print(pom) %]

Internally, the view calls the present() method on the node, passing itself as an argument. Thus it is equivalent to the previous example.

The Pod::POM node and the view conspire to "Do The Right Thing" to process the right template block for the node. A reference to the node is available within the template as the 'item' variable.

   [% BLOCK view_head2 %]
      <h2>[% item.title.present(view) %]</h2>
      [% item.content.present(view) %]
   [% END %]

The Template Toolkit documentation contains further information on defining and using views. However, as noted above, this may be subject to change or incomplete pending further development of the VIEW directive.

new(\%config)

    use Pod::POM;

    my $parser = Pod::POM->new();

A reference to a hash array of configuration options may be passed as an argument.

    my $parser = Pod::POM->new( { warn => 1 } );

For convenience, configuration options can also be passed as a list of (key => value) pairs.

    my $parser = Pod::POM->new( warn => 1 );

The following configuration options are defined:

code

This option can be set to have all non-Pod parts of the input document stored within the object model as 'code' elements, represented by objects of the Pod::POM::Node::Code class. It is disabled by default and code sections are ignored.

    my $parser = Pod::POM->new( code => 1 );
    my $podpom = $parser->parse(\*DATA);

    foreach my $code ($podpom->code()) {
        print "<pre>$code</pre>\n";
    }

    __DATA__
    This is some program code.

    =head1 NAME

    ...
    

This will generate the output:

    <pre>This is some program code.</pre>
    

Note that code elements are stored within the POM element in which they are encountered. For example, the code element below embedded within between Pod sections is stored in the array which can be retrieved by calling "$podpom->head1->[0]->code()".

    =head1 NAME

    My::Module::Name;

    =cut

    Some program code embedded in Pod.

    =head1 SYNOPSIS

    ...
    

warn

Non-fatal warnings encountered while parsing a Pod document are stored internally and subsequently available via the warnings() method.

    my $parser = Pod::POM->new();
    my $podpom = $parser->parse_file($filename);

    foreach my $warning ($parser->warnings()) {
        warn $warning, "\n";
    }
    

The 'warn' option can be set to have warnings raised automatically via "warn()" as and when they are encountered.

    my $parser = Pod::POM->new( warn => 1 );
    my $podpom = $parser->parse_file($filename);
    

If the configuration value is specified as a subroutine reference then the code will be called each time a warning is raised, passing the warning message as an argument.

    sub my_warning {
        my $msg = shift;
        warn $msg, "\n";
    };

    my $parser = Pod::POM->new( warn => \&my_warning );
    my $podpom = $parser->parse_file($filename);
    

meta

The 'meta' option can be set to allow "=meta" tags within the Pod document.

    my $parser = Pod::POM->new( meta => 1 );
    my $podpom = $parser->parse_file($filename);
    

This is an experimental feature which is not part of standard POD. For example:

    =meta author Andy Wardley
    

These are made available as metadata items within the root node of the parsed POM.

    my $author = $podpom->metadata('author');
    

See the METADATA section below for further information.

parse_file($file)

    my $podpom = $parser->parse_file($filename)
        || die $parser->error();

    my $podpom = $parser->parse_file(\*STDIN)
        || die $parser->error();

Any warnings encountered can be examined by calling the warnings() method.

    foreach my $warn ($parser->warnings()) {
        warn $warn, "\n";
    }

parse_text($text)

parse($text_or_$file)

A hash reference can be passed as an argument that contains a 'text' or 'file' key and corresponding value.

    my $podpom = $parser->parse({ file => $filename })
        || die $parser->error();

Otherwise, the argument can be a reference to an input handle which is passed off to parse_file().

    my $podpom = $parser->parse(\*DATA)
        || die $parser->error();

If the argument is a text string that looks like Pod text (i.e. it contains '=' at the start of any line) then it is passed to parse_text().

    my $podpom = $parser->parse($podtext)
        || die $parser->error();

Otherwise it is assumed to be a filename and is passed to parse_file().

    my $podpom = $parser->parse($podfile)
        || die $parser->error();