[Templates] Views

[Mark Fowler]

On Fri, 29 Mar 2002, Tony Bowden wrote:

> So, does the silence mean that _no-one_ gets VIEWs then? ;)

No, just that I was very busy ;-)

The main thing I use views for is

 a) Rendering Pod::POM  (Pod -> Templates)

 b) Rendering XML.

Hmm more detail.

VIEWs are a collection of templates that you can bundle up as one thing
and pass around.  Importantly, views are self aware, and thus a view can
call other blocks to render out part of the object it's been asked to
render.

For example, a Pod::POM view has blocks named "head1" "head2" "item" and
so forth.  Critically the template code that displays this doesn't have to
care about how to render child elements.  They just say "render children
with this view too" and they do so.  For example, a head1 element may just
say to recursively render it's children after the text.  It doesn't care
that they happen to be items or whatever...they're just rendered.

The same is true for XML.  For example, I'm working on systems that pull
out chunks of XML using XPath.  The way it works is this:

I have a plugin that knows how to get at sections of my XML.  It's built
ontop of the XML::Path plugin, so when I call "title" from the plugin it
uses some XPath expression to get a XML::XPath::Node::Element back that
represents the "tree" of XML at this point.  Now the important thing is
that the main template doesn't know or care that the object it's been
handed back is an XML node or not.  It just renders it with the view.

The XML::XPath plugin made the XML nodes "view aware".  This means that
they know if they're told to render with a view then they should pick the
element in the view with the same name as the node tag.  The <p> elements
are rendered with the 'p' blocks, the 'i' elements are rendered with the
'i' blocks and so on.  Since the title is just plain text it'll just be
rendered with the default 'text' block.

Where this gets funky is where you have things like your plugin returning
the the "middle_bit".  Now the main template doesn't know what XML this
contains.  It could contain a list of <p> with text in them, and probably
does, but it likewise could contain a <p> followed by <img> or whatever.
Or it could contain a <pony/> tag which maps to the 'pony' block.  It just
renders them out and things that can contain other things can quite happily
naively rendering the XML as a tree, with each block saying "er, I look
like this, followed by my children, whatever they look like with this
view, and followed by this bit more".

So we can turn "<p>This is some <funky>crazy</funky> text</p>" into
"<p>This is some <font color="red">crazy</font> text</p>" by having a
"funky" block in our view like so:

 [% BLOCK funky -%]
   <font color="red">[% item.content(view) %]</font>
 [%- END %]

See that funky doesn't know or care what it's children look like - they
can take care of themselves.

Of course this is a very brief explanation of a very powerful feature.
I'll have to write more.  And I will, or rather, I am.  Expect me to
complete the rendering XML with HTML documentation somewhen in the near
future.

Later.

Mark.

-- 
  Mark Fowler
  Technology Developer
  http://www.indicosoftware.com/