local-lib5/man/man3/Template::Manual::Views.3pm

   1 .\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.3
   2 .\"
   3 .\" Standard preamble:
   4 .\" ========================================================================
   5 .de Sh \" Subsection heading
   6 .br
   7 .if t .Sp
   8 .ne 5
   9 .PP
  10 \fB\\$1\fR
  11 .PP
  12 ..
  13 .de Sp \" Vertical space (when we can't use .PP)
  14 .if t .sp .5v
  15 .if n .sp
  16 ..
  17 .de Vb \" Begin verbatim text
  18 .ft CW
  19 .nf
  20 .ne \\$1
  21 ..
  22 .de Ve \" End verbatim text
  23 .ft R
  24 .fi
  25 ..
  26 .\" Set up some character translations and predefined strings.  \*(-- will
  27 .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
  28 .\" double quote, and \*(R" will give a right double quote.  | will give a
  29 .\" real vertical bar.  \*(C+ will give a nicer C++.  Capital omega is used to
  30 .\" do unbreakable dashes and therefore won't be available.  \*(C` and \*(C'
  31 .\" expand to `' in nroff, nothing in troff, for use with C<>.
  32 .tr \(*W-|\(bv\*(Tr
  33 .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  34 .ie n \{\
  35 .    ds -- \(*W-
  36 .    ds PI pi
  37 .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
  38 .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
  39 .    ds L" ""
  40 .    ds R" ""
  41 .    ds C` ""
  42 .    ds C' ""
  43 'br\}
  44 .el\{\
  45 .    ds -- \|\(em\|
  46 .    ds PI \(*p
  47 .    ds L" ``
  48 .    ds R" ''
  49 'br\}
  50 .\"
  51 .\" If the F register is turned on, we'll generate index entries on stderr for
  52 .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
  53 .\" entries marked with X<> in POD.  Of course, you'll have to process the
  54 .\" output yourself in some meaningful fashion.
  55 .if \nF \{\
  56 .    de IX
  57 .    tm Index:\\$1\t\\n%\t"\\$2"
  58 ..
  59 .    nr % 0
  60 .    rr F
  61 .\}
  62 .\"
  63 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  64 .\" way too many mistakes in technical documents.
  65 .hy 0
  66 .if n .na
  67 .\"
  68 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
  69 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
  70 .    \" fudge factors for nroff and troff
  71 .if n \{\
  72 .    ds #H 0
  73 .    ds #V .8m
  74 .    ds #F .3m
  75 .    ds #[ \f1
  76 .    ds #] \fP
  77 .\}
  78 .if t \{\
  79 .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
  80 .    ds #V .6m
  81 .    ds #F 0
  82 .    ds #[ \&
  83 .    ds #] \&
  84 .\}
  85 .    \" simple accents for nroff and troff
  86 .if n \{\
  87 .    ds ' \&
  88 .    ds ` \&
  89 .    ds ^ \&
  90 .    ds , \&
  91 .    ds ~ ~
  92 .    ds /
  93 .\}
  94 .if t \{\
  95 .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
  96 .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
  97 .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
  98 .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
  99 .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
 100 .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
 101 .\}
 102 .    \" troff and (daisy-wheel) nroff accents
 103 .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
 104 .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
 105 .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
 106 .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
 107 .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
 108 .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
 109 .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
 110 .ds ae a\h'-(\w'a'u*4/10)'e
 111 .ds Ae A\h'-(\w'A'u*4/10)'E
 112 .    \" corrections for vroff
 113 .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
 114 .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
 115 .    \" for low resolution devices (crt and lpr)
 116 .if \n(.H>23 .if \n(.V>19 \
 117 \{\
 118 .    ds : e
 119 .    ds 8 ss
 120 .    ds o a
 121 .    ds d- d\h'-1'\(ga
 122 .    ds D- D\h'-1'\(hy
 123 .    ds th \o'bp'
 124 .    ds Th \o'LP'
 125 .    ds ae ae
 126 .    ds Ae AE
 127 .\}
 128 .rm #[ #] #H #V #F C
 129 .\" ========================================================================
 130 .\"
 131 .IX Title "Template::Manual::Views 3"
 132 .TH Template::Manual::Views 3 "2008-11-13" "perl v5.8.7" "User Contributed Perl Documentation"
 133 .SH "NAME"
 134 Template::Manual::Views \- Template Toolkit views (experimental)
 135 .SH "Overview"
 136 .IX Header "Overview"
 137 A view is effectively a collection of templates and/or variable
 138 definitions which can be passed around as a self-contained unit.  This
 139 then represents a particular interface or presentation style for other
 140 objects or items of data.
 141 .PP
 142 You can use views to implement custom \*(L"skins\*(R" for an application or
 143 content set.  You can use them to help simplify the presentation of
 144 common objects or data types.  You can even use then to automate the
 145 presentation of complex data structures such as that generated in an
 146 \&\f(CW\*(C`XML::DOM\*(C'\fR tree or similar.  You let an iterator do the walking, and the
 147 view does the talking (or in this case, the presenting).  Voila \- you
 148 have view independant, structure shy traversal using templates.
 149 .PP
 150 In general, views can be used in a number of different ways to achieve
 151 several different things.  They elegantly solve some problems which
 152 were otherwise difficult or complicated, and make easy some things
 153 that were previously hard.
 154 .PP
 155 At the moment, they're still very experimental.  The directive syntax
 156 and underlying \s-1API\s0 are likely to change quite considerably over the
 157 next version or two.  Please be very wary about building your
 158 multi-million dollar e\-commerce solutions based around this feature.
 159 .SH "Views as Template Collectors/Providers"
 160 .IX Header "Views as Template Collectors/Providers"
 161 The \f(CW\*(C`VIEW\*(C'\fR directive starts a view definition and includes a name by
 162 which the view can be referenced.  The view definition continues up to
 163 the matching \f(CW\*(C`END\*(C'\fR directive.
 164 .PP
 165 .Vb 3
 166 \&    [% VIEW myview %]
 167 \&       ...
 168 \&    [% END %]
 169 .Ve
 170 .PP
 171 The first role of a view is to act as a collector and provider of templates.
 172 The \f(CW\*(C`include()\*(C'\fR method can be called on a view to effectively do the same
 173 thing as the \f(CW\*(C`INCLUDE\*(C'\fR directive.  The template name is passed as the first
 174 argument, followed by any local variable definitions for the template.
 175 .PP
 176 .Vb 1
 177 \&    [% myview.include('header', title='The Title') %]
 178 .Ve
 179 .PP
 180 .Vb 2
 181 \&    # equivalent to
 182 \&    [% INCLUDE header  title='The Title' %]
 183 .Ve
 184 .PP
 185 Views accept a number of configuration options which can be used to control
 186 different aspects of their behaviour.  The '\f(CW\*(C`prefix\*(C'\fR' and '\f(CW\*(C`suffix\*(C'\fR' options
 187 can be specified to add a fixed prefix and/or suffix to the name of each template.
 188 .PP
 189 .Vb 5
 190 \&    [% VIEW myview
 191 \&         prefix = 'my/'
 192 \&         suffix = '.tt2' ;
 193 \&       END
 194 \&    %]
 195 .Ve
 196 .PP
 197 Now the call
 198 .PP
 199 .Vb 1
 200 \&    [% myview.include('header', title='The Title') %]
 201 .Ve
 202 .PP
 203 is equivalent to
 204 .PP
 205 .Vb 1
 206 \&    [% INCLUDE my/header.tt2  title='The Title' %]
 207 .Ve
 208 .PP
 209 Views provide an \f(CW\*(C`AUTOLOAD\*(C'\fR method which maps method names to the
 210 \&\f(CW\*(C`include()\*(C'\fR method.  Thus, the following are all equivalent:
 211 .PP
 212 .Vb 3
 213 \&    [% myview.include('header', title='Hello World') %]
 214 \&    [% myview.include_header(title='Hello World') %]
 215 \&    [% myview.header(title='Hello World') %]
 216 .Ve
 217 .SH "Local BLOCK Definitions"
 218 .IX Header "Local BLOCK Definitions"
 219 A \f(CW\*(C`VIEW\*(C'\fR definition can include \f(CW\*(C`BLOCK\*(C'\fR definitions which remain local to
 220 the view.   A request for a particular template will return a \f(CW\*(C`BLOCK\*(C'\fR,
 221 if defined, in preference to any other template of the same name.
 222 .PP
 223 .Vb 3
 224 \&    [% BLOCK foo %]
 225 \&       public foo block
 226 \&    [% END %]
 227 .Ve
 228 .PP
 229 .Vb 5
 230 \&    [% VIEW plain %]
 231 \&       [% BLOCK foo %]
 232 \&       plain foo block
 233 \&       [% END %]
 234 \&    [% END %]
 235 .Ve
 236 .PP
 237 .Vb 5
 238 \&    [% VIEW fancy %]
 239 \&       [% BLOCK foo %]
 240 \&       fancy foo block
 241 \&       [% END %]
 242 \&    [% END %]
 243 .Ve
 244 .PP
 245 .Vb 3
 246 \&    [% INCLUDE foo %]       # public foo block
 247 \&    [% plain.foo %]         # plain foo block
 248 \&    [% fancy.foo %]         # fancy foo block
 249 .Ve
 250 .PP
 251 In addition to \f(CW\*(C`BLOCK\*(C'\fR definitions, a \f(CW\*(C`VIEW\*(C'\fR can contain any other
 252 template directives.  The entire \f(CW\*(C`VIEW\*(C'\fR definition block is processed to
 253 initialise the view but no output is generated (this may change \s-1RSN\s0 \-
 254 and get stored as '\f(CW\*(C`output\*(C'\fR' item, subsequently accessible as \f(CW\*(C`[%
 255 view.output %]\*(C'\fR).  However, directives that have side\-effects, such as
 256 those that update a variable, will have noticable consequences.
 257 .SH "Preserving Variable State within Views"
 258 .IX Header "Preserving Variable State within Views"
 259 Views can also be used to save the values of any existing variables,
 260 or to create new ones at the point at which the view is defined.
 261 Unlike simple template metadata (\f(CW\*(C`META\*(C'\fR) which can only contain static
 262 string values, the view initialisation block can contain any template
 263 directives and generate any kind of dynamic output and/or data items.
 264 .PP
 265 .Vb 5
 266 \&    [% VIEW my_web_site %]
 267 \&       [% view.title   = title or 'My Cool Web Site' %]
 268 \&       [% view.author  = "$abw.name, $abw.email" %]
 269 \&       [% view.sidebar = INCLUDE my/sidebar.tt2 %]
 270 \&    [% END %]
 271 .Ve
 272 .PP
 273 Note that additional data items can be specified as arguments to the \f(CW\*(C`VIEW\*(C'\fR
 274 directive.  Anything that doesn't look like a configuration parameter is
 275 assumed to be a data item.  This can be a little hazardous, of course, because
 276 you never know when a new configuration item might get added which interferes
 277 with your data.
 278 .PP
 279 .Vb 10
 280 \&    [% VIEW my_web_site
 281 \&            # config options
 282 \&            prefix = 'my/'
 283 \&            # misc data
 284 \&            title   = title or 'My Cool Web Site'
 285 \&            author  = "$abw.name, $abw.email"
 286 \&            sidebar = INCLUDE my/sidebar.tt2
 287 \&    %]
 288 \&       ...
 289 \&    [% END %]
 290 .Ve
 291 .PP
 292 Outside of the view definition you can access the view variables as, for
 293 example:
 294 .PP
 295 .Vb 1
 296 \&    [% my_web_site.title %]
 297 .Ve
 298 .PP
 299 One important feature is the equivalence of simple variables and templates.
 300 You can implement the view item '\f(CW\*(C`title\*(C'\fR' as a simple variable, a template
 301 defined in an external file, possibly with a prefix/suffix automatically
 302 appended, or as a local \f(CW\*(C`BLOCK\*(C'\fR definition within the \f(CW\*(C`[% VIEW %] ... [% END %]\*(C'\fR
 303 definition.  If you use the syntax above then the view will Do The Right
 304 Thing to return the appropriate output.
 305 .PP
 306 At the \f(CW\*(C`END\*(C'\fR of the \f(CW\*(C`VIEW\*(C'\fR definition the view is \*(L"sealed\*(R" to prevent you
 307 from accidentally updating any variable values.  If you attempt to change
 308 the value of a variable after the \f(CW\*(C`END\*(C'\fR of the \f(CW\*(C`VIEW\*(C'\fR definition block then
 309 a \f(CW\*(C`view\*(C'\fR error will be thrown.
 310 .PP
 311 .Vb 6
 312 \&    [% TRY;
 313 \&         my_web_site.title = 'New Title';
 314 \&       CATCH;
 315 \&         error;
 316 \&       END
 317 \&    %]
 318 .Ve
 319 .PP
 320 The error above will be reported as:
 321 .PP
 322 .Vb 1
 323 \&    view error \- cannot update item in sealed view: title
 324 .Ve
 325 .PP
 326 The same is true if you pass a parameter to a view variable.  This is
 327 interpreted as an attempt to update the variable and will raise the same
 328 warning.
 329 .PP
 330 .Vb 1
 331 \&    [% my_web_site.title('New Title') %]    # view error!
 332 .Ve
 333 .PP
 334 You can set the \f(CW\*(C`silent\*(C'\fR parameter to have the view ignore these
 335 parameters and simply return the variable value.
 336 .PP
 337 .Vb 6
 338 \&    [% VIEW my_web_site
 339 \&            silent = 1
 340 \&            title  = title or 'My Cool Web Site'
 341 \&            # ... ;
 342 \&       END
 343 \&    %]
 344 .Ve
 345 .PP
 346 .Vb 1
 347 \&    [% my_web_site.title('Blah Blah') %]   # My Cool Web Site
 348 .Ve
 349 .PP
 350 Alternately, you can specify that a view is unsealed allowing existing
 351 variables to be updated and new variables defined.
 352 .PP
 353 .Vb 6
 354 \&    [% VIEW my_web_site
 355 \&            sealed = 0
 356 \&            title  = title or 'My Cool Web Site'
 357 \&            # ... ;
 358 \&       END
 359 \&    %]
 360 .Ve
 361 .PP
 362 .Vb 2
 363 \&    [% my_web_site.title('Blah Blah') %]   # Blah Blah
 364 \&    [% my_web_site.title %]                # Blah Blah
 365 .Ve
 366 .Sh "Inheritance, Delegation and Reuse"
 367 .IX Subsection "Inheritance, Delegation and Reuse"
 368 Views can be inherited from previously defined views by use of the \f(CW\*(C`base\*(C'\fR
 369 parameter.  This example shows how a base class view is defined which
 370 applies a \f(CW\*(C`view/default/\*(C'\fR prefix to all template names.
 371 .PP
 372 .Vb 4
 373 \&    [% VIEW my.view.default
 374 \&            prefix = 'view/default/';
 375 \&       END
 376 \&    %]
 377 .Ve
 378 .PP
 379 Thus the directive:
 380 .PP
 381 .Vb 1
 382 \&    [% my.view.default.header(title='Hello World') %]
 383 .Ve
 384 .PP
 385 is now equivalent to:
 386 .PP
 387 .Vb 1
 388 \&    [% INCLUDE view/default/header title='Hello World' %]
 389 .Ve
 390 .PP
 391 A second view can be defined which specifies the default view as a
 392 base.
 393 .PP
 394 .Vb 5
 395 \&    [% VIEW my.view.fancy
 396 \&            base   = my.view.default
 397 \&            prefix = 'view/fancy/';
 398 \&       END
 399 \&    %]
 400 .Ve
 401 .PP
 402 Now the directive:
 403 .PP
 404 .Vb 1
 405 \&    [% my.view.fancy.header(title='Hello World') %]
 406 .Ve
 407 .PP
 408 will resolve to:
 409 .PP
 410 .Vb 1
 411 \&    [% INCLUDE view/fancy/header title='Hello World' %]
 412 .Ve
 413 .PP
 414 or if that doesn't exist, it will be handled by the base view as:
 415 .PP
 416 .Vb 1
 417 \&    [% INCLUDE view/default/header title='Hello World' %]
 418 .Ve
 419 .PP
 420 When a parent view is specified via the \f(CW\*(C`base\*(C'\fR parameter, the
 421 delegation of a view to its parent for fetching templates and accessing
 422 user defined variables is automatic.  You can also implement your own
 423 inheritance, delegation or other reuse patterns by explicitly
 424 delegating to other views.
 425 .PP
 426 .Vb 3
 427 \&    [% BLOCK foo %]
 428 \&       public foo block
 429 \&    [% END %]
 430 .Ve
 431 .PP
 432 .Vb 5
 433 \&    [% VIEW plain %]
 434 \&       [% BLOCK foo %]
 435 \&       <plain>[% PROCESS foo %]</plain>
 436 \&       [% END %]
 437 \&    [% END %]
 438 .Ve
 439 .PP
 440 .Vb 5
 441 \&    [% VIEW fancy %]
 442 \&       [% BLOCK foo %]
 443 \&       [% plain.foo | replace('plain', 'fancy') %]
 444 \&       [% END %]
 445 \&    [% END %]
 446 .Ve
 447 .PP
 448 .Vb 2
 449 \&    [% plain.foo %]     # <plain>public foo block</plain>
 450 \&    [% fancy.foo %]     # <fancy>public foo block</fancy>
 451 .Ve
 452 .PP
 453 Note that the regular \f(CW\*(C`INCLUDE/PROCESS/WRAPPER\*(C'\fR directives work entirely
 454 independantly of views and will always get the original, unaltered
 455 template name rather than any local per-view definition.
 456 .Sh "Self-Reference"
 457 .IX Subsection "Self-Reference"
 458 A reference to the view object under definition is available with the
 459 \&\f(CW\*(C`VIEW ... END\*(C'\fR block by its specified name and also by the special name
 460 \&'\f(CW\*(C`view\*(C'\fR' (similar to the \f(CW\*(C`my $self = shift;\*(C'\fR in a Perl method or the
 461 \&'\f(CW\*(C`this\*(C'\fR' pointer in \*(C+, etc).  The view is initially unsealed allowing
 462 any data items to be defined and updated within the \f(CW\*(C`VIEW ... END\*(C'\fR
 463 block.  The view is automatically sealed at the end of the definition
 464 block, preventing any view data from being subsequently changed.
 465 .PP
 466 (\s-1NOTE:\s0 sealing should be optional.  As well as sealing a view to prevent
 467 updates (\f(CW\*(C`SEALED\*(C'\fR), it should be possible to set an option in the view to
 468 allow external contexts to update existing variables (\f(CW\*(C`UPDATE\*(C'\fR) or even
 469 create totally new view variables (\f(CW\*(C`CREATE\*(C'\fR)).
 470 .PP
 471 .Vb 5
 472 \&    [% VIEW fancy %]
 473 \&       [% fancy.title  = 'My Fancy Title' %]
 474 \&       [% fancy.author = 'Frank Open' %]
 475 \&       [% fancy.col    = { bg => '#ffffff', bar => '#a0a0ff' } %]
 476 \&    [% END %]
 477 .Ve
 478 .PP
 479 or
 480 .PP
 481 .Vb 5
 482 \&    [% VIEW fancy %]
 483 \&       [% view.title  = 'My Fancy Title' %]
 484 \&       [% view.author = 'Frank Open' %]
 485 \&       [% view.col    = { bg => '#ffffff', bar => '#a0a0ff' } %]
 486 \&    [% END %]
 487 .Ve
 488 .PP
 489 It makes no real difference in this case if you refer to the view by
 490 its name, '\f(CW\*(C`fancy\*(C'\fR', or by the general name, '\f(CW\*(C`view\*(C'\fR'.  Outside of the
 491 view block, however, you should always use the given name, '\f(CW\*(C`fancy\*(C'\fR':
 492 .PP
 493 .Vb 3
 494 \&    [% fancy.title  %]
 495 \&    [% fancy.author %]
 496 \&    [% fancy.col.bg %]
 497 .Ve
 498 .PP
 499 The choice of given name or '\f(CW\*(C`view\*(C'\fR' is much more important when it
 500 comes to \f(CW\*(C`BLOCK\*(C'\fR definitions within a \f(CW\*(C`VIEW\*(C'\fR.  It is generally recommended
 501 that you use '\f(CW\*(C`view\*(C'\fR' inside a \f(CW\*(C`VIEW\*(C'\fR definition because this is guaranteed
 502 to be correctly defined at any point in the future when the block gets
 503 called.  The original name of the view might have long since been changed
 504 or reused but the self-reference via '\f(CW\*(C`view\*(C'\fR' should always be intact and
 505 valid.
 506 .PP
 507 Take the following \s-1VIEW\s0 as an example:
 508 .PP
 509 .Vb 6
 510 \&    [% VIEW foo %]
 511 \&       [% view.title = 'Hello World' %]
 512 \&       [% BLOCK header %]
 513 \&       Title: [% view.title %]
 514 \&       [% END %]
 515 \&    [% END %]
 516 .Ve
 517 .PP
 518 Even if we rename the view, or create a new \f(CW\*(C`foo\*(C'\fR variable, the header
 519 block still correctly accesses the \f(CW\*(C`title\*(C'\fR attribute of the view to
 520 which it belongs.  Whenever a view \f(CW\*(C`BLOCK\*(C'\fR is processed, the \f(CW\*(C`view\*(C'\fR
 521 variable is always updated to contain the correct reference to the
 522 view object to which it belongs.
 523 .PP
 524 .Vb 3
 525 \&    [% bar = foo %]
 526 \&    [% foo = { title => "New Foo" } %]  # no problem
 527 \&    [% bar.header %]                    # => Title: Hello World
 528 .Ve
 529 .Sh "Saving References to External Views"
 530 .IX Subsection "Saving References to External Views"
 531 When it comes to view inheritance, it's always a good idea to take a
 532 local copy of a parent or delegate view and store it as an attribute
 533 within the view for later use.  This ensures that the correct view
 534 reference is always available, even if the external name of a view
 535 has been changed.
 536 .PP
 537 .Vb 3
 538 \&    [% VIEW plain %]
 539 \&       ...
 540 \&    [% END %]
 541 .Ve
 542 .PP
 543 .Vb 6
 544 \&    [% VIEW fancy %]
 545 \&       [% view.plain = plain %]
 546 \&       [% BLOCK foo %]
 547 \&       [% view.plain.foo | replace('plain', 'fancy') %]
 548 \&       [% END %]
 549 \&    [% END %]
 550 .Ve
 551 .PP
 552 .Vb 3
 553 \&    [% plain.foo %]         # => <plain>public foo block</plain>
 554 \&    [% plain = 'blah' %]    # no problem
 555 \&    [% fancy.foo %]         # => <fancy>public foo block</fancy>
 556 .Ve
 557 .Sh "Views as Data Presenters"
 558 .IX Subsection "Views as Data Presenters"
 559 Another key role of a view is to act as a dispatcher to automatically
 560 apply the correct template to present a particular object or data
 561 item.  This is handled via the \f(CW\*(C`print()\*(C'\fR method.
 562 .PP
 563 Here's an example:
 564 .PP
 565 .Vb 1
 566 \&    [% VIEW foo %]
 567 .Ve
 568 .PP
 569 .Vb 3
 570 \&       [% BLOCK text %]
 571 \&          Some text: [% item %]
 572 \&       [% END %]
 573 .Ve
 574 .PP
 575 .Vb 6
 576 \&       [% BLOCK hash %]
 577 \&          a hash:
 578 \&          [% FOREACH key = item.keys.sort \-%]
 579 \&             [% key %] => [% item.$key %]
 580 \&          [% END \-%]
 581 \&       [% END %]
 582 .Ve
 583 .PP
 584 .Vb 3
 585 \&       [% BLOCK list %]
 586 \&          a list: [% item.sort.join(', ') %]
 587 \&       [% END %]
 588 .Ve
 589 .PP
 590 .Vb 1
 591 \&    [% END %]
 592 .Ve
 593 .PP
 594 We can now use the view to print text, hashes or lists.  The \f(CW\*(C`print()\*(C'\fR
 595 method includes the right template depending on the typing of the
 596 argument (or arguments) passed.
 597 .PP
 598 .Vb 3
 599 \&    [% some_text = 'I read the news today, oh boy.' %]
 600 \&    [% a_hash    = { house => 'Lords', hall => 'Albert' } %]
 601 \&    [% a_list    = [ 'sure', 'Nobody', 'really' ] %]
 602 .Ve
 603 .PP
 604 .Vb 2
 605 \&    [% view.print(some_text) %]
 606 \&                        # Some text: I read the news today, oh boy.
 607 .Ve
 608 .PP
 609 .Vb 6
 610 \&    [% view.print(a_hash) %]
 611 \&                        # a hash:
 612 \&                             hall => Albert
 613 \&                             house => Lords
 614 \&    [% view.print(a_list) %]
 615 \&                        # a list: Nobody, really, sure
 616 .Ve
 617 .PP
 618 You can also provide templates to print objects of any other class.
 619 The class name is mapped to a template name with all non-word
 620 character sequences such as '\f(CW\*(C`::\*(C'\fR' converted to a single '\f(CW\*(C`_\*(C'\fR'.
 621 .PP
 622 .Vb 7
 623 \&    [% VIEW foo %]
 624 \&       [% BLOCK Foo_Bar %]
 625 \&          a Foo::Bar object:
 626 \&              thingies: [% view.print(item.thingies) %]
 627 \&               doodahs: [% view.print(item.doodahs)  %]
 628 \&       [% END %]
 629 \&    [% END %]
 630 .Ve
 631 .PP
 632 .Vb 1
 633 \&    [% USE fubar = Foo::Bar(...) %]
 634 .Ve
 635 .PP
 636 .Vb 1
 637 \&    [% foo.print(fubar) %]
 638 .Ve
 639 .PP
 640 Note how we use the view object to display various items within the
 641 objects ('\f(CW\*(C`thingies\*(C'\fR' and '\f(CW\*(C`doodahs\*(C'\fR').  We don't need to worry what
 642 kind of data these represent (text, list, hash, etc) because we can
 643 let the view worry about it, automatically mapping the data type to
 644 the correct template.
 645 .PP
 646 Views may define their own type => template map.
 647 .PP
 648 .Vb 11
 649 \&    [% VIEW foo
 650 \&         map = { TEXT  => 'plain_text',
 651 \&                 ARRAY => 'show_list',
 652 \&                 HASH  => 'show_hash',
 653 \&                 My::Module => 'template_name'
 654 \&                 default    => 'any_old_data'
 655 \&               }
 656 \&    %]
 657 \&        [% BLOCK plain_text %]
 658 \&           ...
 659 \&        [% END %]
 660 .Ve
 661 .PP
 662 .Vb 2
 663 \&        ...
 664 \&    [% END %]
 665 .Ve
 666 .PP
 667 They can also provide a \f(CW\*(C`default\*(C'\fR map entry, specified as part of the \f(CW\*(C`map\*(C'\fR
 668 hash or as a parameter by itself.
 669 .PP
 670 .Vb 6
 671 \&    [% VIEW foo
 672 \&         map     = { ... },
 673 \&         default = 'whatever'
 674 \&    %]
 675 \&       ...
 676 \&    [% END %]
 677 .Ve
 678 .PP
 679 or
 680 .PP
 681 .Vb 6
 682 \&    [% VIEW foo %]
 683 \&       [% view.map     = { ... }
 684 \&          view.default = 'whatever'
 685 \&       %]
 686 \&       ...
 687 \&    [% END %]
 688 .Ve
 689 .PP
 690 The \f(CW\*(C`print()\*(C'\fR method provides one more piece of magic. If you pass it a
 691 reference to an object which provides a \f(CW\*(C`present()\*(C'\fR method, then the method
 692 will be called passing the view as an argument. This then gives any object a
 693 chance to determine how it should be presented via the view.
 694 .PP
 695 .Vb 8
 696 \&    package Foo::Bar;
 697 \&    ...
 698 \&    sub present {
 699 \&        my ($self, $view) = @_;
 700 \&        return "a Foo::Bar object:\en"
 701 \&             . "thingies: " . $view\->print($self\->{ _THINGIES }) . "\en"
 702 \&             . "doodahs: " . $view\->print($self\->{ _DOODAHS }) . "\en";
 703 \&    }
 704 .Ve
 705 .PP
 706 The object is free to delve deeply into its innards and mess around with
 707 its own private data, before presenting the relevant data via the view.
 708 In a more complex example, a \f(CW\*(C`present()\*(C'\fR method might walk part of a tree
 709 making calls back against the view to present different nodes within the
 710 tree.  We may not want to expose the internal structure of the tree
 711 (because that would break encapsulation and make our presentation code
 712 dependant on it) but we want to have some way of walking the tree and
 713 presenting items found in a particular manner.
 714 .PP
 715 This is known as \fIStructure Shy Traversal\fR.  Our view object doesn't require
 716 prior knowledge about the internal structure of any data set to be able
 717 to traverse it and present the data contained therein.  The data items
 718 themselves, via the \f(CW\*(C`present()\*(C'\fR method, can implement the internal iterators
 719 to guide the view along the right path to presentation happiness.
 720 .PP
 721 The upshot is that you can use views to greatly simplify the display
 722 of data structures like \f(CW\*(C`XML::DOM\*(C'\fR trees.  The documentation for the
 723 \&\f(CW\*(C`Template::Plugin::XML::DOM\*(C'\fR module contains an example of this.  In
 724 essence, it looks something like this:
 725 .PP
 726 \&\s-1XML\s0 source:
 727 .PP
 728 .Vb 4
 729 \&    <user name="Andy Wardley">
 730 \&        <project id="iCan" title="iCan, but theyCan't"/>
 731 \&        <project id="p45"  title="iDid, but theyDidn't"/>
 732 \&    </user>
 733 .Ve
 734 .PP
 735 \&\s-1TT\s0 View:
 736 .PP
 737 .Vb 5
 738 \&    [% VIEW fancy %]
 739 \&       [% BLOCK user %]
 740 \&          User: [% item.name %]
 741 \&                [% item.content(myview) %]
 742 \&       [% END %]
 743 .Ve
 744 .PP
 745 .Vb 4
 746 \&       [% BLOCK project %]
 747 \&            Project: [% project.id %] \- [% project.name %]
 748 \&       [% END %]
 749 \&    [% END %]
 750 .Ve
 751 .PP
 752 Generate view:
 753 .PP
 754 .Vb 2
 755 \&    [% USE dom = XML.DOM %]
 756 \&    [% fancy.print(dom.parse(xml_source)) %]
 757 .Ve
 758 .PP
 759 Output:
 760 .PP
 761 .Vb 3
 762 \&          User: Andy Wardley
 763 \&            Project: iCan \- iCan, but theyCan't
 764 \&            Project: p45 \- iDid, but theyDidn't
 765 .Ve
 766 .PP
 767 The same approach can be applied to many other areas.  Here's an example from
 768 the \f(CW\*(C`File\*(C'\fR/\f(CW\*(C`Directory\*(C'\fR plugins.
 769 .PP
 770 .Vb 4
 771 \&    [% VIEW myview %]
 772 \&       [% BLOCK file %]
 773 \&          \- [% item.name %]
 774 \&       [% END %]
 775 .Ve
 776 .PP
 777 .Vb 5
 778 \&       [% BLOCK directory %]
 779 \&          * [% item.name %]
 780 \&            [% item.content(myview) FILTER indent %]
 781 \&       [% END %]
 782 \&    [% END %]
 783 .Ve
 784 .PP
 785 .Vb 2
 786 \&    [% USE dir = Directory(dirpath) %]
 787 \&    [% myview.print(dir) %]
 788 .Ve
 789 .PP
 790 And here's the same approach use to convert \s-1POD\s0 documentation to any
 791 other format via template.
 792 .PP
 793 .Vb 3
 794 \&    [%  # load Pod plugin and parse source file into Pod Object Model
 795 \&        USE Pod;
 796 \&        pom = Pod.parse_file(my_pod_file);
 797 .Ve
 798 .PP
 799 .Vb 4
 800 \&        # define view to map all Pod elements to "pod/html/xxx" templates
 801 \&        VIEW pod2html
 802 \&            prefix='pod/html';
 803 \&        END;
 804 .Ve
 805 .PP
 806 .Vb 3
 807 \&        # now print document via view (i.e. as HTML)
 808 \&        pod2html.print(pom)
 809 \&    %]
 810 .Ve
 811 .PP
 812 Here we simply define a template prefix for the view which causes the
 813 view to look for \f(CW\*(C`pod/html/head1\*(C'\fR, \f(CW\*(C`pod/html/head2\*(C'\fR, \f(CW\*(C`pod/html/over\*(C'\fR
 814 as templates to present the different sections of the parsed Pod document.
 815 .PP
 816 There are some examples in the Template Toolkit test suite: \fIt/pod.t\fR and
 817 \&\fIt/view.t\fR which may shed some more light on this.  See the distribution
 818 sub-directory \fIexamples/pod/html\fR for examples of Pod \-> \s-1HTML\s0 templates.