home *** CD-ROM | disk | FTP | other *** search
/ PC Professionell 2004 December / PCpro_2004_12.ISO / files / webserver / tsw / TSW_3.4.0.exe / Apache2 / perl / Views.pod < prev    next >
Encoding:
Text File  |  2004-01-30  |  19.6 KB  |  643 lines
  1. #============================================================= -*-perl-*-
  2. #
  3. # Template::Manual::Views
  4. #
  5. # DESCRIPTION
  6. #   This section describes dynamic views: a powerful but experimental
  7. #   new feature in version 2.01 of the Template Toolkit.
  8. #
  9. # AUTHOR
  10. #   Andy Wardley  <abw@andywardley.com>
  11. #
  12. # COPYRIGHT
  13. #   Copyright (C) 1996-2001 Andy Wardley.  All Rights Reserved.
  14. #   Copyright (C) 1998-2001 Canon Research Centre Europe Ltd.
  15. #
  16. #   This module is free software; you can redistribute it and/or
  17. #   modify it under the same terms as Perl itself.
  18. #
  19. # REVISION
  20. #   
  21. #
  22. #========================================================================
  23.  
  24.  
  25. #------------------------------------------------------------------------
  26. # IMPORTANT NOTE
  27. #   This documentation is generated automatically from source
  28. #   templates.  Any changes you make here may be lost.
  29. # 
  30. #   The 'docsrc' documentation source bundle is available for download
  31. #   from http://www.template-toolkit.org/docs.html and contains all
  32. #   the source templates, XML files, scripts, etc., from which the
  33. #   documentation for the Template Toolkit is built.
  34. #------------------------------------------------------------------------
  35.  
  36. =head1 NAME
  37.  
  38. Template::Manual::Views - Template Toolkit views (experimental)
  39.  
  40. =head1 DESCRIPTION
  41.  
  42. This section describes dynamic views: a powerful but experimental new
  43. feature in version 2.01 of the Template Toolkit.
  44.  
  45. A view is effectively a collection of templates and/or variable
  46. definitions which can be passed around as a self-contained unit.  This
  47. then represents a particular interface or presentation style for other
  48. objects or items of data.
  49.  
  50. You can use views to implement custom "skins" for an application or
  51. content set.  You can use them to help simplify the presentation of
  52. common objects or data types.  You can even use then to automate the
  53. presentation of complex data structures such as that generated in an
  54. XML::DOM tree or similar.  You let an iterator do the walking, and the
  55. view does the talking (or in this case, the presenting).  Voila - you
  56. have view independant, structure shy traversal using templates.  
  57.  
  58. In general, views can be used in a number of different ways to achieve
  59. several different things.  They elegantly solve some problems which
  60. were otherwise difficult or complicated, and make easy some things
  61. that were previously hard.
  62.  
  63. At the moment, they're still very experimental.  The directive syntax
  64. and underlying API are likely to change quite considerably over the 
  65. next version or two.  Please be very wary about building your 
  66. multi-million dollar e-commerce solutions based around this feature.
  67.  
  68. =head2 Views as Template Collectors/Providers
  69.  
  70. The VIEW directive starts a view definition and includes a name by
  71. which the view can be referenced.  The view definition continues up to
  72. the matching END directive.
  73.  
  74.     [% VIEW myview %]
  75.        ...
  76.     [% END %]
  77.  
  78. The first role of a view is to act as a collector and provider of templates.
  79. The include() method can be called on a view to effectively do the same 
  80. thing as the INCLUDE directive.  The template name is passed as the first 
  81. argument, followed by any local variable definitions for the template.
  82.  
  83.     [% myview.include('header', title='The Title') %]
  84.  
  85.     # equivalent to
  86.     [% INCLUDE header  title='The Title' %] 
  87.  
  88. Views accept a number of configuration options which can be used to control
  89. different aspects of their behaviour.  The 'prefix' and 'suffix' options 
  90. can be specified to add a fixed prefix and/or suffix to the name of each template.
  91.  
  92.     [% VIEW myview 
  93.          prefix = 'my/'
  94.          suffix = '.tt2' ;
  95.        END
  96.     %]
  97.  
  98. Now the call 
  99.  
  100.     [% myview.include('header', title='The Title') %]
  101.  
  102. is equivalent to
  103.  
  104.     [% INCLUDE my/header.tt2  title='The Title' %]
  105.  
  106. Views provide an AUTOLOAD method which maps method names to the
  107. include() method.  Thus, the following are all equivalent:
  108.  
  109.     [% myview.include('header', title='Hello World') %]
  110.     [% myview.include_header(title='Hello World') %]
  111.     [% myview.header(title='Hello World') %]
  112.  
  113. =head2 Local BLOCK Definitions
  114.  
  115. A VIEW definition can include BLOCK definitions which remain local to
  116. the view.   A request for a particular template will return a BLOCK,
  117. if defined, in preference to any other template of the same name.
  118.  
  119.     [% BLOCK foo %]
  120.        public foo block
  121.     [% END %]
  122.  
  123.     [% VIEW plain %]
  124.        [% BLOCK foo %]
  125.        plain foo block
  126.        [% END %]
  127.     [% END %]
  128.  
  129.     [% VIEW fancy %]
  130.        [% BLOCK foo %]
  131.        fancy foo block
  132.        [% END %]
  133.     [% END %]
  134.  
  135.     [% INCLUDE foo %]        # public foo block
  136.     [% plain.foo %]        # plain foo block 
  137.     [% fancy.foo %]        # fancy foo block 
  138.  
  139. In addition to BLOCK definitions, a VIEW can contain any other
  140. template directives.  The entire VIEW definition block is processed to
  141. initialise the view but no output is generated (this may change RSN -
  142. and get stored as 'output' item, subsequently accessible as [%
  143. view.output %]).  However, directives that have side-effects, such as
  144. those that update a variable, will have noticable consequences.
  145.  
  146. =head2 Preserving Variable State within Views
  147.  
  148. Views can also be used to save the values of any existing variables,
  149. or to create new ones at the point at which the view is defined.
  150. Unlike simple template metadata (META) which can only contain static
  151. string values, the view initialisation block can contain any template
  152. directives and generate any kind of dynamic output and/or data items.
  153.  
  154.     [% VIEW my_web_site %]
  155.        [% view.title   = title or 'My Cool Web Site' %]
  156.        [% view.author  = "$abw.name, $abw.email" %]
  157.        [% view.sidebar = INCLUDE my/sidebar.tt2 %]
  158.     [% END %]
  159.  
  160. Note that additional data items can be specified as arguments to the VIEW
  161. directive.  Anything that doesn't look like a configuration parameter is 
  162. assumed to be a data item.  This can be a little hazardous, of course, because
  163. you never know when a new configuration item might get added which interferes 
  164. with your data.
  165.  
  166.     [% VIEW my_web_site
  167.         # config options
  168.         prefix = 'my/'
  169.         # misc data
  170.         title   = title or 'My Cool Web Site'
  171.         author  = "$abw.name, $abw.email"
  172.         sidebar = INCLUDE my/sidebar.tt2 
  173.     %]
  174.        ...
  175.     [% END %]
  176.  
  177. Outside of the view definition you can access the view variables as, for
  178. example:
  179.  
  180.     [% my_web_site.title %]
  181.  
  182. One important feature is the equivalence of simple variables and templates.
  183. You can implement the view item 'title' as a simple variable, a template
  184. defined in an external file, possibly with a prefix/suffix automatically
  185. appended, or as a local BLOCK definition within the [% VIEW %] ... [% END %]
  186. definition.  If you use the syntax above then the view will Do The Right
  187. Thing to return the appropriate output.
  188.  
  189. At the END of the VIEW definition the view is "sealed" to prevent you
  190. from accidentally updating any variable values.  If you attempt to change
  191. the value of a variable after the END of the VIEW definition block then
  192. an 'view' error will be thrown.
  193.  
  194.     [% TRY; 
  195.          my_web_site.title = 'New Title';
  196.        CATCH;
  197.          error;
  198.        END
  199.     %]
  200.  
  201. The error above will be reported as:
  202.  
  203.     view error - cannot update item in sealed view: title
  204.  
  205. The same is true if you pass a parameter to a view variable.  This is
  206. interpreted as an attempt to update the variable and will raise the same
  207. warning.
  208.  
  209.     [% my_web_site.title('New Title') %]    # view error!
  210.  
  211. You can set the 'silent' parameter to have the view ignore these
  212. parameters and simply return the variable value. 
  213.  
  214.     [% VIEW my_web_site
  215.             silent = 1
  216.         title  = title or 'My Cool Web Site'
  217.         # ... ;
  218.        END
  219.     %]
  220.  
  221.     [% my_web_site.title('Blah Blah') %]   # My Cool Web Site
  222.  
  223. Alternately, you can specify that a view is unsealed allowing existing
  224. variables to be updated and new variables defined.
  225.  
  226.     [% VIEW my_web_site
  227.             sealed = 0
  228.         title  = title or 'My Cool Web Site'
  229.         # ... ;
  230.        END
  231.     %]
  232.  
  233.     [% my_web_site.title('Blah Blah') %]   # Blah Blah
  234.     [% my_web_site.title %]                # Blah Blah
  235.  
  236. =head2 Inheritance, Delegation and Reuse
  237.  
  238. Views can be inherited from previously defined views by use of the 'base'
  239. parameter.  This example shows how a base class view is defined which 
  240. applies a 'view/default/' prefix to all template names.
  241.  
  242.     [% VIEW my.view.default
  243.             prefix = 'view/default/';
  244.        END
  245.     %]
  246.  
  247. Thus the directive:
  248.  
  249.     [% my.view.default.header(title='Hello World') %]
  250.  
  251. is now equivalent to:
  252.  
  253.     [% INCLUDE view/default/header title='Hello World' %]
  254.  
  255. A second view can be defined which specifies the default view as a 
  256. base.
  257.  
  258.     [% VIEW my.view.fancy
  259.             base   = my.view.default
  260.             prefix = 'view/fancy/';
  261.        END
  262.     %]
  263.  
  264. Now the directive:
  265.  
  266.     [% my.view.fancy.header(title='Hello World') %]
  267.  
  268. will resolve to:
  269.  
  270.     [% INCLUDE view/fancy/header title='Hello World' %]
  271.  
  272. or if that doesn't exist, it will be handled by the base view as:
  273.  
  274.     [% INCLUDE view/default/header title='Hello World' %]
  275.  
  276. When a parent view is specified via the 'base' parameter, the
  277. delegation of a view to its parent for fetching templates and accessing
  278. user defined variables is automatic.  You can also implement your own
  279. inheritance, delegation or other reuse patterns by explicitly
  280. delegating to other views.
  281.  
  282.     [% BLOCK foo %]
  283.        public foo block
  284.     [% END %]
  285.  
  286.     [% VIEW plain %]
  287.        [% BLOCK foo %]
  288.        <plain>[% PROCESS foo %]</plain>
  289.        [% END %]
  290.     [% END %]
  291.  
  292.     [% VIEW fancy %]
  293.        [% BLOCK foo %]
  294.        [% plain.foo | replace('plain', 'fancy') %]
  295.        [% END %]
  296.     [% END %]
  297.  
  298.     [% plain.foo %]    # <plain>public foo block</plain>
  299.     [% fancy.foo %]    # <fancy>public foo block</fancy>
  300.  
  301. Note that the regular INCLUDE/PROCESS/WRAPPER directives work entirely
  302. independantly of views and will always get the original, unaltered
  303. template name rather than any local per-view definition.
  304.  
  305. =head2 Self-Reference
  306.  
  307. A reference to the view object under definition is available with the
  308. VIEW ... END block by its specified name and also by the special name
  309. 'view' (similar to the C<my $self = shift;> in a Perl method or the
  310. 'this' pointer in C++, etc).  The view is initially unsealed allowing
  311. any data items to be defined and updated within the VIEW ... END
  312. block.  The view is automatically sealed at the end of the definition
  313. block, preventing any view data from being subsequently changed.
  314.  
  315. (NOTE: sealing should be optional.  As well as sealing a view to prevent
  316. updates (SEALED), it should be possible to set an option in the view to 
  317. allow external contexts to update existing variables (UPDATE) or even 
  318. create totally new view variables (CREATE)).
  319.  
  320.     [% VIEW fancy %]
  321.        [% fancy.title  = 'My Fancy Title' %]
  322.        [% fancy.author = 'Frank Open' %]
  323.        [% fancy.col    = { bg => '#ffffff', bar => '#a0a0ff' } %]
  324.     [% END %]
  325.  
  326. or
  327.  
  328.     [% VIEW fancy %]
  329.        [% view.title  = 'My Fancy Title' %]
  330.        [% view.author = 'Frank Open' %]
  331.        [% view.col    = { bg => '#ffffff', bar => '#a0a0ff' } %]
  332.     [% END %]
  333.  
  334. It makes no real difference in this case if you refer to the view by
  335. its name, 'fancy', or by the general name, 'view'.  Outside of the
  336. view block, however, you should always use the given name, 'fancy':
  337.  
  338.     [% fancy.title  %]
  339.     [% fancy.author %]
  340.     [% fancy.col.bg %]
  341.  
  342. The choice of given name or 'view' is much more important when it
  343. comes to BLOCK definitions within a VIEW.  It is generally recommended
  344. that you use 'view' inside a VIEW definition because this is guaranteed
  345. to be correctly defined at any point in the future when the block gets
  346. called.  The original name of the view might have long since been changed
  347. or reused but the self-reference via 'view' should always be intact and 
  348. valid.
  349.  
  350. Take the following VIEW as an example:
  351.  
  352.     [% VIEW foo %]
  353.        [% view.title = 'Hello World' %]
  354.        [% BLOCK header %]
  355.        Title: [% view.title %]
  356.        [% END %]
  357.     [% END %]
  358.  
  359. Even if we rename the view, or create a new 'foo' variable, the header
  360. block still correctly accesses the 'title' attribute of the view to
  361. which it belongs.  Whenever a view BLOCK is processed, the 'view'
  362. variable is always updated to contain the correct reference to the
  363. view object to which it belongs.
  364.  
  365.     [% bar = foo %]
  366.     [% foo = { title => "New Foo" } %]  # no problem
  367.     [% bar.header %]                    # => Title: Hello World
  368.  
  369. =head2 Saving References to External Views
  370.  
  371. When it comes to view inheritance, it's always a good idea to take a
  372. local copy of a parent or delegate view and store it as an attribute
  373. within the view for later use.  This ensures that the correct view
  374. reference is always available, even if the external name of a view
  375. has been changed.
  376.  
  377.     [% VIEW plain %]
  378.        ...
  379.     [% END %]
  380.  
  381.     [% VIEW fancy %]
  382.        [% view.plain = plain %]
  383.        [% BLOCK foo %]
  384.        [% view.plain.foo | replace('plain', 'fancy') %]
  385.        [% END %]
  386.     [% END %]
  387.  
  388.     [% plain.foo %]        # => <plain>public foo block</plain>
  389.     [% plain = 'blah' %]    # no problem
  390.     [% fancy.foo %]        # => <fancy>public foo block</fancy>
  391.  
  392.  
  393. =head2 Views as Data Presenters
  394.  
  395. Another key role of a view is to act as a dispatcher to automatically
  396. apply the correct template to present a particular object or data
  397. item.  This is handled via the print() method.
  398.  
  399. Here's an example:
  400.  
  401.     [% VIEW foo %]
  402.  
  403.        [% BLOCK text %]
  404.           Some text: [% item %]
  405.        [% END %]
  406.  
  407.        [% BLOCK hash %]
  408.           a hash:
  409.           [% FOREACH key = item.keys.sort -%]
  410.              [% key %] => [% item.$key %]
  411.           [% END -%]
  412.        [% END %]
  413.  
  414.        [% BLOCK list %]
  415.           a list: [% item.sort.join(', ') %]
  416.        [% END %]
  417.  
  418.     [% END %]
  419.  
  420. We can now use the view to print text, hashes or lists.  The print()
  421. method includes the right template depending on the typing of the
  422. argument (or arguments) passed.
  423.  
  424.     [% some_text = 'I read the news today, oh boy.' %]
  425.     [% a_hash    = { house => 'Lords', hall => 'Albert' } %]
  426.     [% a_list    = [ 'sure', 'Nobody', 'really' ] %]
  427.  
  428.     [% view.print(some_text) %]
  429.             # Some text: I read the news today, oh boy.
  430.  
  431.     [% view.print(a_hash) %]
  432.             # a hash:
  433.                              hall => Albert
  434.                              house => Lords
  435.     [% view.print(a_list) %]
  436.             # a list: Nobody, really, sure
  437.  
  438.  
  439. You can also provide templates to print objects of any other class.
  440. The class name is mapped to a template name with all non-word
  441. character sequences such as '::' converted to a single '_'.
  442.  
  443.     [% VIEW foo %]
  444.        [% BLOCK Foo_Bar %]
  445.           a Foo::Bar object: 
  446.               thingies: [% view.print(item.thingies) %]
  447.                doodahs: [% view.print(item.doodahs)  %]
  448.        [% END %]
  449.     [% END %]
  450.  
  451.     [% USE fubar = Foo::Bar(...) %]
  452.  
  453.     [% foo.print(fubar) %]
  454.  
  455. Note how we use the view object to display various items within the 
  456. objects ('thingies' and 'doodahs').  We don't need to worry what 
  457. kind of data these represent (text, list, hash, etc) because we can
  458. let the view worry about it, automatically mapping the data type to 
  459. the correct template.
  460.  
  461. Views may define their own type =E<gt> template map.
  462.  
  463.     [% VIEW foo 
  464.          map = { TEXT  => 'plain_text',
  465.          ARRAY => 'show_list', 
  466.          HASH  => 'show_hash',
  467.          My::Module => 'template_name'
  468.          default    => 'any_old_data'
  469.                }
  470.     %]
  471.     [% BLOCK plain_text %]
  472.            ...
  473.         [% END %]
  474.        
  475.         ...
  476.  
  477.     [% END %]
  478.  
  479. They can also provide a 'default' map entry, specified as part of the 'map'
  480. hash or as a parameter by itself.
  481.  
  482.  
  483.     [% VIEW foo 
  484.          map     = { ... },
  485.          default = 'whatever'
  486.     %]
  487.        ...
  488.     [% END %]
  489.  
  490. or
  491.  
  492.     [% VIEW foo %]
  493.        [% view.map     = { ... }
  494.           view.default = 'whatever'
  495.        %]
  496.        ...
  497.     [% END %]
  498.  
  499. The print() method provides one more piece of magic.  If you pass it a
  500. reference to an object which provides a present() method, then the 
  501. method will be called passing the view as an argument.  This then gives
  502. any object a chance to determine how it should be presented via the 
  503. view.
  504.  
  505.     package Foo::Bar;
  506.  
  507.     ...
  508.  
  509.     sub present {
  510.     my ($self, $view) = @_;
  511.     return "a Foo::Bar object:\n"
  512.          . "thingies: " . $view.print($self->{ _THINGIES }) . "\n"
  513.              . "doodahs: " . $view.print($self->{ _DOODAHS }) . "\n";
  514.     }
  515.  
  516. The object is free to delve deeply into its innards and mess around with
  517. its own private data, before presenting the relevant data via the view.
  518. In a more complex example, a present() method might walk part of a tree
  519. making calls back against the view to present different nodes within the 
  520. tree.  We may not want to expose the internal structure of the tree
  521. (because that would break encapsulation and make our presentation code
  522. dependant on it) but we want to have some way of walking the tree and 
  523. presenting items found in a particular manner.
  524.  
  525. This is known as Structure Shy Traversal.  Our view object doesn't require
  526. prior knowledge about the internal structure of any data set to be able
  527. to traverse it and present the data contained therein.  The data items
  528. themselves, via the present() method, can implement the internal iterators
  529. to guide the view along the right path to presentation happiness.
  530.  
  531. The upshot is that you can use views to greatly simplify the display
  532. of data structures like XML::DOM trees.  The documentation for the 
  533. Template::Plugins::XML::DOM module contains an example of this.  In 
  534. essence, it looks something like this:
  535.  
  536. XML source:
  537.  
  538.     <user name="Andy Wardley">
  539.     <project id="iCan" title="iCan, but theyCan't"/>
  540.     <project id="p45"  title="iDid, but theyDidn't"/>
  541.     </user>
  542.  
  543. TT View:
  544.  
  545.     [% VIEW fancy %]
  546.        [% BLOCK user %]
  547.           User: [% item.name %]
  548.                 [% item.content(myview) %]
  549.        [% END %]
  550.  
  551.        [% BLOCK project %]
  552.             Project: [% project.id %] - [% project.name %]
  553.        [% END %]
  554.     [% END %]
  555.  
  556. Generate view:
  557.  
  558.     [% USE dom = XML.DOM %]
  559.     [% fancy.print(dom.parse(xml_source)) %]
  560.  
  561. Output:
  562.  
  563.           User: Andy Wardley
  564.             Project: iCan - iCan, but theyCan't
  565.             Project: p45 - iDid, but theyDidn't
  566.  
  567. The same approach can be applied to many other areas.  Here's an example from 
  568. the File/Directory plugins.
  569.  
  570.     [% VIEW myview %]
  571.        [% BLOCK file %]
  572.           - [% item.name %]
  573.        [% END %]
  574.     
  575.        [% BLOCK directory %]
  576.           * [% item.name %]
  577.             [% item.content(myview) FILTER indent %]
  578.        [% END %]
  579.     [% END %]
  580.  
  581.     [% USE dir = Directory(dirpath) %]
  582.     [% myview.print(dir) %]
  583.  
  584. And here's the same approach use to convert Pod documentation to any 
  585. other format via template.
  586.  
  587.     [%    # load Pod plugin and parse source file into Pod Object Model
  588.     USE Pod;
  589.     pom = Pod.parse_file(my_pod_file);
  590.         
  591.     # define view to map all Pod elements to "pod/html/xxx" templates
  592.     VIEW pod2html
  593.         prefix='pod/html';
  594.     END;
  595.         
  596.     # now print document via view (i.e. as HTML)
  597.     pod2html.print(pom) 
  598.     %]
  599.  
  600. Here we simply define a template prefix for the view which causes the
  601. view to look for 'pod/html/head1', 'pod/html/head2', 'pod/html/over' 
  602. as templates to present the different sections of the parsed Pod document.
  603.  
  604. There are some examples in the Template Toolkit test suite: t/pod.t and 
  605. t/view.t which may shed some more light on this.  See the distribution
  606. sub-directory 'examples/pod/html' for examples of Pod -E<gt> HTML templates.
  607.  
  608. (This documentation is incomplete but I'm not going to get it 100% pefect
  609. until the syntax and API stabilise).
  610.  
  611. =head1 AUTHOR
  612.  
  613. Andy Wardley E<lt>abw@andywardley.comE<gt>
  614.  
  615. L<http://www.andywardley.com/|http://www.andywardley.com/>
  616.  
  617.  
  618.  
  619.  
  620. =head1 VERSION
  621.  
  622. Template Toolkit version 2.13, released on 30 January 2004.
  623.  
  624. =head1 COPYRIGHT
  625.  
  626.   Copyright (C) 1996-2004 Andy Wardley.  All Rights Reserved.
  627.   Copyright (C) 1998-2002 Canon Research Centre Europe Ltd.
  628.  
  629. This module is free software; you can redistribute it and/or
  630. modify it under the same terms as Perl itself.
  631.  
  632.  
  633.  
  634. =cut
  635.  
  636. # Local Variables:
  637. # mode: perl
  638. # perl-indent-level: 4
  639. # indent-tabs-mode: nil
  640. # End:
  641. #
  642. # vim: expandtab shiftwidth=4:
  643.