-
Notifications
You must be signed in to change notification settings - Fork 94
/
Internals.html
379 lines (377 loc) · 15.5 KB
/
Internals.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
[%#
# IMPORTANT NOTE
# This documentation is generated automatically from source
# templates. Any changes you make here may be lost.
#
# The 'docsrc' documentation source bundle is available for download
# from http://www.template-toolkit.org/docs.html and contains all
# the source templates, XML files, scripts, etc., from which the
# documentation for the Template Toolkit is built.
-%]
[% META book = 'Manual'
page = 'Internals'
%]
[% WRAPPER toc;
INCLUDE tocitem title="DESCRIPTION"
subs=["Outside Looking In", "Inside Looking Out"];
INCLUDE tocitem title="AUTHOR";
INCLUDE tocitem title="VERSION";
INCLUDE tocitem title="COPYRIGHT";
END
%]
<!-- Pod to HTML conversion by the Template Toolkit version 2 -->
[% WRAPPER section
title="DESCRIPTION"
-%]<p>
This document provides an overview of the internal architecture of the
Template Toolkit. It is a work in progress and is far from complete,
currently providing little more than an overview of how the major
components fit together. Nevertheless, it's a good starting point for
anyone wishing to delve into the source code to find out how it all
works.
</p>
[% WRAPPER subsection
title = "Outside Looking In"
-%]<p>
The <b>Template</b> module is simply a front end module which creates and
uses a Template::Service and pipes the output wherever you want it to
go (STDOUT by default, or maybe a file, scalar, etc). The
Apache::Template module (available separately from CPAN) is another
front end. That creates a Template::Service::Apache object, calls on
it as required and sends the output back to the relevant
Apache::Request object.
</p>
<p>
These front-end modules are really only there to handle any specifics
of the environment in which they're being used. The Apache::Template
front end, for example, handles Apache::Request specifics and
configuration via the httpd.conf. The regular Template front-end
deals with STDOUT, variable refs, etc. Otherwise it is
Template::Service (or subclass) which does all the work.
</p>
<p>
The <b>Template::Service</b> module provides a high-quality template
delivery service, with bells, whistles, signed up service level
agreement and a 30-day no quibble money back guarantee. "Have
a good time, all the time", that's our motto.
</p>
<p>
Within the lower levels of the Template Toolkit, there are lots of
messy details that we generally don't want to have to worry about most
of the time. Things like templates not being found, or failing to
parse correctly, uncaught exceptions being thrown, missing plugin
modules or dependencies, and so on. Template::Service hides that all
away and makes everything look simple to the outsider. It provides
extra features, like PRE_PROCESS, PROCESS and POST_PROCESS, and also
provides the error recovery mechanism via ERROR. You ask it to
process a template and it takes care of everything for you. The
Template::Service::Apache module goes a little bit further, adding
some extra headers to the Apache::Request, setting a few extra template
variables, and so on.
</p>
<p>
For the most part, the job of a service is really just one of
scheduling and dispatching. It receives a request in the form of a
call to its process() method and schedules the named template
specified as an argument, and possibly several other templates
(PRE_PROCESS, etc) to be processed in order. It doesn't actually
process the templates itself, but instead makes a process() call
against a Template::Context object.
</p>
<p>
<b>Template::Context</b> is the runtime engine for the Template Toolkit -
the module that hangs everything together in the lower levels of the
Template Toolkit and that one that does most of the real work, albeit
by crafty delegation to various other friendly helper modules.
</p>
<p>
Given a template name (or perhaps a reference to a scalar or file
handle) the context process() method must load and compile, or fetch a
cached copy of a previously compiled template, corresponding to that
name. It does this by calling on a list of one or more
Template::Provider objects (the LOAD_TEMPLATES posse) who themselves
might get involved with a Template::Parser to help turn source
templates into executable Perl code (but more on that later). Thankfully,
all of this complexity is hidden away behind a simple template()
method. You call it passing a template name as an argument, and it
returns a compiled template in the form of a Template::Document
object, or otherwise raises an exeception.
</p>
<p>
A <b>Template::Document</b> is a thin object wrapper around a compiled
template subroutine. The object implements a process() method which
performs a little bit of housekeeping and then calls the template
subroutine. The object also defines template metadata (defined in
<code>'[% tt_start_tag %] META ... [% tt_end_tag %]'</code> directives) and has a block() method which returns
a hash of any additional <code>'[% tt_start_tag %] BLOCK xxxx [% tt_end_tag %]'</code> definitions found in the
template source.
</p>
<p>
So the context fetches a compiled document via its own template()
method and then gets ready to process it. It first updates the stash
(the place where template variables get defined - more on that
shortly) to set any template variable definitions specified as the
second argument by reference to hash array. Then, it calls the
document process() method, passing a reference to itself, the context
object, as an argument. In doing this, it provides itself as an
object against which template code can make callbacks to access
runtime resources and Template Toolkit functionality.
</p>
<p>
What we're trying to say here is this: not only does the Template::Context
object receive calls from the <i>outside</i>, i.e. those originating in user
code calling the process() method on a Template object, but it also
receives calls from the <i>inside</i>, i.e. those originating in template
directives of the form <code>'[% tt_start_tag %] PROCESS template [% tt_end_tag %]'</code>.
</p>
<p>
Before we move on to that, here's a simple structure diagram showing
the outer layers of the Template Toolkit heading inwards, with pseudo
code annotations showing a typical invocation sequence.
</p>
<pre> ,--------.
| Caller | use Template;
`--------' my $tt = Template->new( ... );
| $tt->process($template, \%vars);
| Outside
- - - - | - - - - - - - - - - - - - - - - - - - - - - - - - - - - T T
| package Template; Inside
V
+----------+ sub process($template, \%vars) {
| Template | $out = $self->SERVICE->process($template, $vars);
+----------+ print $out or send it to $self->OUTPUT;
| }
|
| package Template::Service;
|
| sub process($template, \%vars) {
| try {
+----------+ foreach $p in @self->PRE_PROCESS
| Service | $self->CONTEXT->process($p, $vars);
+----------+
| $self->CONTEXT->process($template, $vars);
|
| foreach $p @self->POST_PROCESS
| $self->CONTEXT->process($p, $vars);
| }
| catch {
| $self->CONTEXT->process($self->ERROR);
| }
| }
|
V package Template::Context;
+----------+
| Context | sub process($template, \%vars) {
+----------+ # fetch compiled template
| $template = $self->template($template)
| # update stash
| $self->STASH->update($vars);
| # process template
| $template->process($self)
| }
V
+----------+ package Template::Document;
| Document |
+----------+ sub process($context) {
$output = &{ $self->BLOCK }($context);
}
</pre>
[%- END %]
[% WRAPPER subsection
title = "Inside Looking Out"
-%]<p>
To understand more about what's going on in these lower levels, we
need to look at what a compiled template looks like. In fact, a
compiled template is just a regular Perl sub-routine. Here's a very
simple one.
</p>
<pre> sub my_compiled_template {
return "This is a compiled template.\n";
}</pre>
<p>
You're unlikely to see a compiled template this simple unless you
wrote it yourself but it is entirely valid. All a template subroutine
is obliged to do is return some output (which may be an empty of
course). If it can't for some reason, then it should raise an error
via die().
</p>
<pre> sub my_todo_template {
die "This template not yet implemented\n";
}</pre>
<p>
If it wants to get fancy, it can raise an error as a
Template::Exception object. An exception object is really just a
convenient wrapper for the 'type' and 'info' fields.
</p>
<pre> sub my_solilique_template {
die Template::Exception->new('yorrick', 'Fellow of infinite jest');
}</pre>
<p>
Templates generally need to do a lot more than just generate static
output or raise errors. They may want to inspect variable values,
process another template, load a plugin, run a filter, and so on.
Whenever a template subroutine is called, it gets passed a reference
to a Template::Context object. It is through this context object that
template code can access the features of the Template Toolkit.
</p>
<p>
We described earlier how the Template::Service object calls on
Template::Context to handle a process() request from the <i>outside</i>.
We can make a similar request on a context to process a template, but
from within the code of another template. This is a call from the
<i>inside</i>.
</p>
<pre> sub my_process_template {
my $context = shift;</pre>
<pre> my $output = $context->process('header', { title => 'Hello World' })
. "\nsome content\n"
. $context->process('footer');
}</pre>
<p>
This is then roughly equivalent to a source template something
like this:
</p>
<pre> [% tt_start_tag %] PROCESS header
title = 'Hello World'
[% tt_end_tag %]
some content
[% tt_start_tag %] PROCESS footer [% tt_end_tag %]</pre>
<p>
Template variables are stored in, and managed by a <b>Template::Stash</b>
object. This is a blessed hash array in which template variables are
defined. The object wrapper provides get() and set() method which
implement all the magical.variable.features of the Template Toolkit.
</p>
<p>
Each context object has its own stash, a reference to which can be
returned by the appropriately named stash() method. So to print the
value of some template variable, or for example, to represent the
following source template:
</p>
<pre> <title>[% tt_start_tag %] title [% tt_end_tag %]</title></pre>
<p>
we might have a subroutine definition something like this:
</p>
<pre> sub {
my $context = shift;
my $stash = $context->stash();
return '<title>' . $stash->get('title') . '</title>';
}</pre>
<p>
The stash get() method hides the details of the underlying variable
types, automatically calling code references, checking return values,
and performing other such tricks. If 'title' happens to be bound to a
subroutine then we can specify additional parameters as a list
reference passed as the second argument to get().
</p>
<pre> [% tt_start_tag %] title('The Cat Sat on the Mat') [% tt_end_tag %]</pre>
<p>
This translates to the stash get() call:
</p>
<pre> $stash->get('title', ['The Cat Sat on the Mat']);</pre>
<p>
Dotted compound variables can be requested by passing a single
list reference to the get() method in place of the variable
name. Each pair of elements in the list should correspond to the
variable name and reference to a list of arguments for each
dot-delimited element of the variable.
</p>
<pre> [% tt_start_tag %] foo(1, 2).bar(3, 4).baz(5) [% tt_end_tag %]</pre>
<p>
is thus equivalent to
</p>
<pre> $stash->get([ foo => [1,2], bar => [3,4], baz => [5] ]);</pre>
<p>
If there aren't any arguments for an element, you can specify an
empty, zero or null argument list.
</p>
<pre> [% tt_start_tag %] foo.bar [% tt_end_tag %]
$stash->get([ 'foo', 0, 'bar', 0 ]);</pre>
<p>
The set() method works in a similar way. It takes a variable
name and a variable value which should be assigned to it.
</p>
<pre> [% tt_start_tag %] x = 10 [% tt_end_tag %]
$stash->set('x', 10);</pre>
<pre> [% tt_start_tag %] x.y = 10 [% tt_end_tag %]
$stash->set([ 'x', 0, 'y', 0 ], 10);</pre>
<p>
So the stash gives us access to template variables and the context
provides the higher level functionality. Alongside the process()
method lies the include() method. Just as with the PROCESS / INCLUDE
directives, the key difference is in variable localisation. Before
processing a template, the process() method simply updates the stash
to set any new variable definitions, overwriting any existing values.
In contrast, the include() method creates a copy of the existing
stash, in a process known as <i>cloning</i> the stash, and then uses that
as a temporary variable store. Any previously existing variables are
still defined, but any changes made to variables, including setting
the new variable values passed aas arguments will affect only the
local copy of the stash (although note that it's only a shallow copy,
so it's not foolproof). When the template has been processed, the include()
method restores the previous variable state by <i>decloning</i> the stash.
</p>
<p>
The context also provides an insert() method to implement the INSERT
directive, but no wrapper() method. This functionality can be implemented
by rewriting the Perl code and calling include().
</p>
<pre> [% tt_start_tag %] WRAPPER foo -[% tt_end_tag %]
blah blah [% tt_start_tag %] x [% tt_end_tag %]
[% tt_start_tag %]- END [% tt_end_tag %]</pre>
<pre> $context->include('foo', {
content => 'blah blah ' . $stash->get('x'),
});</pre>
<p>
Other than the template processing methods process(), include() and insert(),
the context defines methods for fetching plugin objects, plugin(), and
filters, filter().
</p>
<pre> [% tt_start_tag %] USE foo = Bar(10) [% tt_end_tag %]</pre>
<pre> $stash->set('foo', $context->plugin('Bar', [10]));</pre>
<pre> [% tt_start_tag %] FILTER bar(20) [% tt_end_tag %]
blah blah blah
[% tt_start_tag %] END [% tt_end_tag %]</pre>
<pre> my $filter = $stash->filter('bar', [20]);
&$filter('blah blah blah');</pre>
<p>
Pretty much everything else you might want to do in a template can be done
in Perl code. Things like IF, UNLESS, FOREACH and so on all have direct
counterparts in Perl.
</p>
<pre> [% tt_start_tag %] IF msg [% tt_end_tag %]
Message: [% tt_start_tag %] msg [% tt_end_tag %]
[% tt_start_tag %] END [% tt_end_tag %];</pre>
<pre> if ($stash->get('msg')) {
$output .= 'Message: ';
$output .= $stash->get('msg');
}</pre>
<p>
<b>### WARNING: THIS IS THE ABRUPT END OF THE DOCUMENTATION ###</b>
</p>
[%- END %]
[%- END %]
[% WRAPPER section
title="AUTHOR"
-%]<p>
Andy Wardley <abw@kfs.org>
</p>
<p>
[% ttlink('http://www.andywardley.com/', 'http://www.andywardley.com/') -%]
</p>
[%- END %]
[% WRAPPER section
title="VERSION"
-%]<p>
Template Toolkit version 2.04, released on 27 June 2001.
</p>
[%- END %]
[% WRAPPER section
title="COPYRIGHT"
-%]<pre> Copyright (C) 1996-2001 Andy Wardley. All Rights Reserved.
Copyright (C) 1998-2001 Canon Research Centre Europe Ltd.</pre>
<p>
This module is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.
</p>
[%- END %]