Template toolkit perl block

Furthermore, you can easily extend the Template Toolkit through the use of its plugin mechanism and other developer APIs. Whatever context you use it in, the primary purpose of the Template Toolkit is to allow you to create a clear separation between the presentation elements of your web site and everything else.

If you're generating static web pages, then you can use it to separate the commonly repeated user interface elements on each page headers, menus, footers, etc. If you're generating dynamic web pages for the front end of a web application, then you'll also be using it to keep the back-end Perl code entirely separate from the front-end HTML templates. Either way, a clear separation of concerns is what allow you to concentrate on one thing at a time without the other things getting in your way.

And that's what the Template Toolkit is all about. The Template::Manual contains detailed information about using the Template Toolkit. It gives examples of its use and includes a full reference of the template language, configuration options, filters, plugins and other component parts. Names containing any other characters should be quoted. All files should be unquoted names or quoted strings. Any variables should be interpolated into double-quoted strings.

If a BLOCK of the specified name is defined in the same file, or in a file from which the current template has been called i. Any template directives embedded within the file will be processed accordingly. All variables currently defined will be visible and accessible from within the included template. Local variable definitions may be specified after the template name, temporarily masking any existing variables. Insignificant whitespace is ignored within directives so you can add variable definitions on the same line, the next line or split across several line with comments interspersed, if you prefer.

Any changes made within the included template will not affect variables in the including template. Technical Note: the localisation of the stash that is, the process by which variables are copied before an INCLUDE to prevent being overwritten is only skin deep.

The top-level variable namespace hash is copied, but no attempt is made to perform a deep-copy of other structures hashes, arrays, objects, etc. Therefore, a foo variable referencing a hash will be copied to create a new foo variable but which points to the same hash array.

Thus, if you update compound variables e. If you're not worried about preserving variable values, or you trust the templates you're including then you might prefer to use the PROCESS directive which is faster by virtue of not performing any localisation. However, be aware that because of the localisation issues explained above if you skipped the previous Technical Note above then you might want to go back and read it or skip this section too , the variables might not actually be "local".

If the first element of the variable name already references a hash array then the variable update will affect the original variable. This behaviour can be a little unpredictable and may well be improved upon in a future version. If you know what you're doing with it and you're sure that the variables in question are defined nor not as you expect them to be, then you can rely on this feature to implement some powerful "global" data sharing techniques.

Otherwise, you might prefer to steer well clear and always pass simple undotted variables as parameters to INCLUDE and other similar directives. The variable stash is localised once and then the templates specified are processed in order, all within that same variable context.

This makes it slightly faster than specifying several separate INCLUDE directives because you only clone the variable stash once instead of n times , but not quite as "safe" because any variable changes in the first file will be visible in the second, third and so on.

This might be what you want, of course, but then again, it might not. Any changes made to variables within the included template will be visible in the including template. It's not unusual to find yourself adding common headers and footers to pages or sub-sections within a page. Something like this:. The individual template components being included might look like these:. It encloses a block up to a matching END directive, which is first processed to generate some output.

The specification order indicates outermost to innermost wrapper templates. For example, given the following template block definitions:. A BLOCK definition can be used before it is defined, as long as the definition resides in the same file.

The block definition itself does not generate any output. Like a named block, it can contain any other template directives which are processed when the block is defined. The output generated by the block is then assigned to the variable julius. The enclosing block is processed each time the macro is called. Conditions may be arbitrarily complex and are evaluated with the same precedence as in Perl. Parenthesis may be used to explicitly determine evaluation order.

Each CASE directive should contain a single value or a list of values which should match. When the FOREACH directive is used without specifying a target variable, any iterated values which are hash references will be automatically imported. Note that this particular usage creates a localised variable context to prevent the imported hash keys from overwriting any existing variables. The imported definitions and any other variables defined in such a FOREACH loop will be lost at the end of the loop, when the previous context and variable values are restored.

However, under normal operation, the loop variable remains in scope after the FOREACH loop has ended caveat: overwriting any variable previously in scope. This is useful as the loop variable is secretly an iterator object see below and can be used to analyse the last entry processed by the loop.

Each entry in the hash is returned in sorted order based on the key as a hash array containing 'key' and 'value' items. The LAST directive can be used to prematurely exit the loop. The following methods can be called on the loop iterator. See Template::Iterator for further details. Nested loops will work as expected, with the loop variable correctly referencing the innermost loop and being restored to any previous value i.

The iterator plugin can also be used to explicitly create an iterator object. This can be useful within nested loops where you need to keep a reference to the outer iterator within the inner loop. The iterator plugin effectively allows you to create an iterator by a name other than loop. See Template::Plugin::Iterator for further details. The WHILE directive can be used to repeatedly process a template block while a conditional expression evaluates true. An assignment can be enclosed in parenthesis to evaluate the assigned value.

If the loop exceeds iterations then an undef exception will be thrown, reporting the error:. As of version 2. The newline character at the end of the line is discarded aka "chomped". Outline tags aren't enabled by default. There are a numbers of ways you can enable them.

The first is to use the TAGS directive to set the tag style to outline in any templates where you want to use them. This will enable outline tags from that point on. You can set the TAGS back to the default value at some point later in the template if you want to disable them:. Setting this option will automatically enable outline tags. You can also use the TAGS directive to define your own custom tags start, end and now optionally, outline for a template or part of a template.

If you only specify a start and end tag then outline tags will be disabled. This method is also overloaded onto the stringification operator allowing the object reference itself to be printed to return the formatted error string. The Template module delegates most of the effort of processing templates to an underlying Template::Service object. This method returns a reference to that object. The Template::Service module uses a core Template::Context object for runtime processing of templates.

This method is a simple wrapper around the Template::Context method of the same name. It returns a compiled template for the source provided as an argument. The following list gives a short summary of each Template Toolkit configuration option. See Template::Manual::Config for full details. Root of directory in which compiled template files should be written default: undef - don't compile.

Flag to indicate regular Perl modules should be loaded if a named plugin can't be found default: 0. Reference to a custom service object default: Template::Service. Reference to a custom context object default: Template::Context. Reference to a custom stash object default: Template::Stash. Reference to a custom parser object default: Template::Parser.