eZ components - Template component ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. contents:: Table of Contents Introduction ============ The template component provides a manageable way to separate application logic from presentation data. The application logic is the PHP code of your application, including the call to the Template component. Presentation data are the template files. The separation of application logic and presentation data is easier to maintain and allows different people to work on separate parts. Another advantage is that the Template language is more suitable for non programmers and web designers. The language is designed to be easier to use and contains more expressive constructs for repetitive tasks in the presentation data. Class overview ============== The following list sums up the most important API classes: ezcTemplate This class provides the main API for processing templates. This class compiles the template to PHP code, executes it, and returns the result. ezcTemplateConfiguration This class configures the Template engine. Settings like: where to find the source templates, where to store the compiled templates, the type of context to use, are stored in this class. ezcTemplateVariableCollection The variables that should be send to the template or retrieved from the template are stored in the object from this class. More information about these classes can be found in the documentation of the class itself. Template component ================== This section describes how to use the template component in your PHP application. How to write the templates itself is described in the next section. Getting started --------------- The simplest example we can come up with is writing "Hello world" to your standard output. Basically it consists of two steps: The first step is to create a text file "hello_world.ezt" that contains only one line:: Hello world and store it in the directory where your application sources reside. The next step is to copy the following PHP script, and check if the application works. .. include:: tutorial_simple.php :literal: If you run your application, it should print "Hello world". Otherwise check that: - The base class can be found. Check your 'include\_path' in the PHP.ini settings, and see if the components are included. - The template "hello\_world.ezt" can be found. Write the absolute path to your hello\_world template in the 'process' method. - The Template engine can write to the current directory. By default it tries to create the directory compiled_templates with the permissions of the running PHP process. The next section explains how another output directory can be specified. Configuring the Template engine ------------------------------- Templates are not always stored in your local directory and neither do you want to store the compiled templates among your source files. Therefore we have to change the configuration: .. include:: tutorial_configuration.php :literal: If you try to copy/paste and run this example, you'll probably get the following output:: Fatal error: Uncaught exception 'ezcTemplateFileNotFoundException' with message 'The requested template file does not exist.' This error shows that the Template engine looks in the "/usr/share/templates" directory for the templates. If the *hello_world.ezt* template was present at */usr/share/templates/* then the Template engine tries to write to the */tmp/compiled_templates/* directory. Make sure that this directory is writable by the current running PHP process. Under Linux the following code makes the directory accessible for anyone:: mkdir /tmp/compiled_templates chmod a+rwx /tmp/compiled_templates The ezcTemplate class calls the getInstance() method from the ezcTemplateConfiguration class and retrieves the "default" configuration. It is possible to set multiple configurations, which is demonstrated in the next example: .. include:: tutorial_multi_configuration.php :literal: Running this example will produce the following output:: The requested template file does not exist. The requested template file does not exist. The requested template file does not exist. As demonstrated, the Template configuration can be set in the 'configuration' property, given as second parameter in the process method, or use the 'default' getInstance configuration. Lazy initialization ------------------- Lazy initialization is a mechanism to load and configure a component, only when it is really used in your application. This mechanism saves time for parsing the classes and configuration, when the component is not used at all during one request. You can find a description how you can use it for your own components and how it works in the `ezcBase tutorial`__. The keyword for the template component is *ezcInitTemplateConfiguration*. __ introduction_Base.html#lazy-initialization .. include:: tutorial_lazy_initialization.php :literal: This examples shows how to configure the template component like shown in the first example. The main difference is, that we roll out the configuration to an own class, and define a callback using ezcBaseInit::setCallback to this class, which will be called with a template configuration object as first parameter on the first instantiation of the template component. ezcBaseInit::setCallback accepts as a first parameter a component specific key, which lets the component later request the right configuration callback. The second parameter is the name of the class to perform the static callback on. This class must implement the ezcBaseConfigurationInitializer class. Each component's lazy initialization calls the static method configureObject() on the referenced class. When the template component is finally instantiated in line 19 of the example, the configureObject() method will be called with an ezcTemplateConfiguration instance used by the Template engine, which can be modified by the method. Send and receive template variables ----------------------------------- More often than not a PHP application sends variables to the Template engine. Commonly those variables are displayed. It is also possible to retrieve variables from a template. The next example sends two variables to a template. The values are added and placed in a new variable that is returned. The code below is the PHP code needed to send the variables to the template. .. include:: tutorial_variable_send_receive.php :literal: The template code is as follows: .. include:: tutorial_variable_send_receive.ezt :literal: As you can expect the result is:: Answer: 5 Template locations ------------------ Since version 1.2 it is possible to send a location object instead of a *location* parameter of the *process* method. A location object is an object that implements the ezcTemplateLocation interface. The interface is as follows:: interface ezcTemplateLocation { public function getPath(); } The Template engine calls the *getPath* method on the object implementing this interface when needed. The *getPath* method returns a string specifying the template to execute. If the return value is a relative path, if it does not start with a slash, then the *templatePath* from the configuration is prepended. The next example executes the *hello\_world.ezt* template via a location object:: class MyLocation implements ezcTemplateLocation { public function getPath() { return "hello_world.ezt"; } } $t = new ezcTemplate(); $t->process( new MyLocation() ); It is also possible to provide a callback for every time a template's location is requested. Instead of supplying an object to the process() method of the ezcTemplate object like we do above we configure the callback with the template system's configuration:: $c = ezcTemplateConfiguration::getInstance( 'templates' ); $c->locator = new PathResolver(); The PathResolver class implements the ezcTemplateLocator interface and is responsible for translating the paths that processed by the template engine. In the example below it simply prepends "overridden/" to the path. The *templatePath* from the configuration is prepended. The implementation:: class PathResolver implements ezcTemplateLocator { public function translatePath( $path ) { return 'overridden/'. $path; } } For every path that now passes through the template engine, "overridden/" is prepended. Which means that the following code actually processes "overridden/test1.ezt":: $template = new ezcTemplate(); $out = $template->process( 'test1.ezt', $c ); Template syntax =============== This section explains the syntax that can be used in the template itself. Basic syntax ------------ The Template engine considers statements embedded in curly braces '{ .. }' as code. Everything outside a block is parsed as text. The following example shows a template that does a simple calculation:: 5 times 3 equals: { 5*3 } This example consists of two parts. The first part is the text up to the opening curly brace. The second part is the code between the braces. Text outside braces will always be printed. The code inside braces will be executed. If the code does not modify a variable then the output of the executed code will also be printed. The example will of course print:: 5 times 3 equals: 15 Curly braces separate text from template code. Therefore these braces cannot be used in the text directly. To use curly braces there are several possibilities. The most common are to use escape characters or use the literal tag. Escape characters ````````````````` A character can be escaped with a backslash (\\). In the text, there are three groups of sequences that can be escaped. Those are: - Open and close curly braces: '\\{' turns into '{' and '\\}' turns into '}'. - The escape character, backslash: '\\\\' turns into '\\'. - All newline character combinations: '\\[LF]', '\\[CR]' and '\\[CR][LF]' all turn into '' (nothing). The next example shows how to escape those characters:: Draw line: \{ (4, 10), (3, 5) \} Game path: C:\\Program files\\games\\ Multiple \ lines \ becomes one The output of the template is without the backslash and the characters appear normally:: Draw line: { (4, 10), (3, 5) } Game path: C:\Program files\games\ Multiple lines becomes one All other uses of the escape character '\\' result in the escape character being printed. This includes '\\' *just* before an EOF. Literal tags ```````````` Literal tags are used when the text needs to be processed as it is (literally). The curly braces don't need to be escaped and escape characters can be used. Usually javascript is surrounded by literal tags in the templates. The curly braces don't need to be escaped. The next example demonstrates how the escaped characters from the previous example can be omitted with literal tags: :: {literal} Draw line: { (4, 10), (3, 5) } Game path: C:\Program files\games\ {/literal} Comments -------- Comments are text blocks which are stripped away from the output when the template is compiled and executed. The Template engine supports three types of comments: - Code comments start and end with, respectively, '{\*' and '\*}' tags. - Multi-line in-line comment, starts with '/\*' and ends with '\*/'. - Single-line in-line comment that starts with '//' and reads until the end of the line or until a closing curly brace '}'. Code comments ````````````` Code comments start and end with:'{\*' and '\*}' tags, respectively. Everything inside those tags is considered as comment:: {* Variable $i alternates the value 0 and 1 *} {$i = 1 - $i} {* {if $i == 0} {$i = 1} {else} {$i = 0} {/if} *} Writing only *{$i = 1 - $i}* would have had the same output. Multi-line in-line comment `````````````````````````` Multi-line in-line comments are created using \/\* and \*\/. Use this comment to comment a part of a line or comment multiple lines:: {var $a = 1, /*$b = 2, */ $c = 3 } {$a = 2, /* $b = 3, $c = 4 */} If the result after removing the in-line comments is an empty block then the block will be ignored. The next example has an empty block that won't be visible in the output:: { /* var $a = 1 */ } And is of course the same as writing: *{ }*. The empty block will be ignored. Single-line in-line comment ``````````````````````````` Single-line in-line comments are created using two slashes: \/\/ . Use this to start a comment which continues to the end of the line or until the closing curly brace '}':: {var $a = 1, // $b = 2, $c = 3} {$a = 4 //, $b = 5, $c = 6} This example declares the variables *$a* and *$c* and assigns in the second statement the value 4 to variable *$a*. Primitive types --------------- The Template language supports several primitive types: :Boolean: Expresses the truth value, which is either 'true' or 'false'. :Integer: Is a number of the set: { .., -1, 0, 1, .. } :Float: Is a real (floating point) number. :String: A series of characters which are enclosed between single or double quotes. :Array: Contains a set of primitive types. :Object: A PHP object (imported via the user application). Boolean ``````` The boolean type contains either the value: *true* or the value *false*. The next example set the *$isValid* variable to *true*. :: {var $isValid = true} Some of the operators return boolean values. An example is the '==' operator. The Expressions_ section discusses the operators in more detail. The next example uses the '==' operator:: {var $isValid = ($number == 6) } It checks first whether the variable *$number* is equal to the value 6. The result is either *true* or *false*. The result is assigned to the variable *$isValid*. Integer ``````` Integers are specified in a decimal notation only. To use octals or hexadimals the number needs to be converted with the appropriate function. Examples are:: {2} {4} {math_hex_to_dec("1F")} See the methods: math_bin_to_dec, math_hex_to_dec, math_oct_to_dec, math_dec_to_bin, ath_dec_to_hex, and math_dec_to_oct for more information about those conversions. Float ````` Floating point numbers are values that contain a real value. Some examples:: {1.0} {-100.234214} {3.14} It is also possible to express an exponent in the float. The exponent is marked with the character 'e' or 'E' followed by one or more digits:: {1.0e3 // 1000 } {2e4 // 20000 } {1e-2 // 0.01 } {0.1e-2 // 0.001 } {-3.1e2 // -310 } String `````` The string consist of a series of characters enclosed between single or double quotes:: {'a string' // Using single quotes } {"hello world" // Using double quotes } In the string we use the backslash (\\) as escape character. For the single quoted string the escape characters are: +-------------+-------------+ | **String** | **Output** | +-------------+-------------+ | \' | ' | +-------------+-------------+ | \\ \\ | \\ | +-------------+-------------+ | \\ | \\ | +-------------+-------------+ Examples of the single quoted strings are:: {'This string contains a \'quotes\' and backslashes (\\).'} {'A single \ works also.'} {'Characters like \n, \t, ", {, }, $, etc can be used without problems'} The double quoted string allows more special characters than the single quoted string. Most useful escape characters are probably the variables and newlines that can be included in the string. The escape characters for the double quoted strings are: +-------------+-------------------+ | **String** | **Output** | +-------------+-------------------+ | \" | " | +-------------+-------------------+ | \\ \\ | \\ | +-------------+-------------------+ | \\ | \\ | +-------------+-------------------+ | \\n | | +-------------+-------------------+ | \\t | | +-------------+-------------------+ | $ | $ | +-------------+-------------------+ | \\r | | +-------------+-------------------+ The next example inserts newlines in the string:: {"Hello\nHello"} The output of the template above is:: Hello Hello Some other examples of using single and double quoted strings:: {" a \"quoted\" string "} {'Newlines are added with the \\n command.'} {'\tThis string starts with a tab (\\t).'} Array ````` The array is just like in PHP an ordered map. It can be used as an array or as a table that maps values to keys. There are two ways to create an array. The first method has the following syntax:: array( [ key => ] value, [ key2 => ] value2, ... ) The parts between brackets are optional. So the *key* can be omitted. In that case, it would simply create an array. First value has the index 0, the next value has index 1, and so on. The next example creates an array which consists of 3 elements:: {var $names = array( "Bernard", "Manny", "Fran" )} The array values, and in this case the names, can be accessed:: {$names[0] // Outputs "Bernard"} {$names[2] // Outputs "Fran"} {$names[3] // Is not allowed } The array with *keys* maps the key to a value:: {var $personInfo = array( "first_name" => "Bernard", "last_name" => "Black" ) } To access the information:: {$personInfo["first_name"] // Outputs "Bernard"} {$personInfo["last_name"] // Outputs "Black"} The second method to create an array is to use the *..* (dot-dot) operator :: .. The operator creates an array that contains the numbers from *number1* to *number2*. The next example creates an array that contains the numbers: 3, 4, 5, 6, and 7. {var $nrs = 3..7 } {$nrs[0] // Outputs 3} This method is especially useful to use in a foreach loop. The following example loops 10 times, and prints the number from 1 until 10:: {foreach 1..10 as $i} Number: {$i} {/foreach} The Foreach_ section describes this loop in more detail. Object `````` Objects are only available when they are sent from the user application. It is not possible to create an object inside the Template language. The template language restricts the accessibilities from the object only to its properties; thus function calls are not permitted. The next example is a part of an user application that sends an object to a template:: send->obj = new MyClass; // Create an object and assign it to "obj" $t->process("my_template.ezt"); ?> The class in the example above has two 'magic' PHP functions. Fetching any property is allowed, whereas setting a property value throws an Exception. The template code that belongs to the user application:: {use $obj // Import the "obj" } {$obj->Bernard // Calls the __get method on the object which returns "Hello Bernard"} {$obj->Bernard = "Fran" // Calls the __set method that throws an exception} More information about importing objects is described in the `External variable declaration (use)`_ section. Variables --------- A variable can only be used after it has been declared. A declaration defines a unique variable name that will be available from now until the end of the template. The next example declares a local variable:: {* Declare the variable *} {var $the_answer_to_life_the_universe_and_everything} {* Assign it to 42 *} {$the_answer_to_life_the_universe_and_everything = 42} Switching the assignment with the declaration results in a compiler error. Variables in the syntax languages are represented by a dollar sign followed by the name of the variable. The variable name is case-sensitive. A valid variable name starts with a letter or underscore, followed by any number of letters, numbers, or underscores:: {* valid declarations *} {var $abcdEFG} {var $_hello_} {var $hello12} {* invalid declarations *} {var $12monkeys} {var $dumb&dumber *} The Template language has three types of variable declaration: *var*, *use* and *cycle*. *Var* declares a local variable as used in the previous example, *use* imports an external variable, and *cycle* declares a cycle variable. Local variable declaration (var) ```````````````````````````````` The declaration of a local variable creates a variable that has only a value inside the current template. The syntax to declare a local variable is:: {var $ [ = ] [ , $ [ = ] ] } One or multiple variables can be declared with one *var* statement. A value can be assigned to the variable name, directly. If no value is given to the variable, then it will get the default value *null*. The next example declares four variables at the same time:: {var $a = 2, $b = "Hello World", $c = true, $d} All variables are initialized to a value. (The last variable is initialized to *null*.) External variable declaration (use) ``````````````````````````````````` The declaration of an external variable creates a variable that usually has a value from outside the current template. Outside the current template is, for example, the application that compiles and executes the template. The syntax for this type of variable is as follows:: {use $ [ = ] [ , $ [ = ] ] } Besides the *use* tag it is the same syntax as a local variable declartion. The variable will be imported from the user application or another template and is now available in the current template. If the declared *use* variable is not sent to the current template an exception will be raised **unless** the declared variable is initialized to a value. :: {use $a, $b = 2} Variable *$b* will be assigned to the value *2* if the variable is not sent to the template. Variable *$a* will raise an Exception when the variable is not sent. The next example shows a part of the user application:: $t = new ezcTemplate(); // Send some information to the Template $t->send->item1 = "Toaster"; $t->send->item2 = "Manny"; // Process the template and print it. echo $t->process(); The variables $item1 and $item2 are now available in the template if they are declared with *use*:: {use $item1 = "unknown", $item2 = "unknown"} Use {$item1} on {$item2} Cycles `````` A cycle is a special type of variable that contains a set of values. The cycle variable must be assigned to an array. Values are retrieved one array element at the time. Specific control structures are available to cycle through the set of values. The syntax for the cycle is:: {cycle $ [ = ] [ , $ [ = ] ] } An array must be assigned to the cycle variable. Otherwise the template compiler *may* give a compiler error. (Sometimes it is not possible to know at compile time whether the assignment is an array or not.) The next example declares a cycle, assigns a value, and retrieves the first and second value:: {cycle $rgb = array( "red", "green", "blue" ) } {$rgb // Print "red"} {$rgb // Print "red"} {increment $rgb // Go to the next element} {$rgb // Print "green"} See the Increment_, Decrement_ and Reset_ section for more information. Scopes `````` Variable declarations must be done at the highest scope of the template. Declaring a variable in a lower scope will result in a compiler error. Scopes are usually opened and closed with a start and end template block. Template blocks that open a new scope are: {if .. }{/if}, {while ..} {/while}, {foreach ..} {/foreach}, {switch .. } {/switch}, etc. The next example demonstrates this scoping:: {var $a = 2 // Correct } {if 2 == 3} {* This opens a new scope *} {var $b // ERROR! } {/if} Returning variables ``````````````````` Templates itself can also return variables to the user application or other templates. The return statement defines the variables that need to be returned:: {return ( as | ) [, ( as | ), ... ] } The return statement returns one or multiple variables. The caller of the template can retrieve the return values. Consider the following template:: {* Return 6! and "Hello world" *} {var $fac6 = 6 * 5 * 4 * 3 * 2 } {return $fac6, "Hello world" as $helloWorld} The user application can retrieve these values via the receive property of the template. See the next example for a demonstration:: $t = new ezcTemplate(); // Process the template. $t->process(); // Retrieve the values from the return. $fac6 = $t->receive->fac6; $hw = $t->receive->helloWorld; // Output Hello world: echo $hw; More information about returning variables is described in the Include_ section. Capturing content into variables ```````````````````````````````` Sometimes it's useful to capture a specific part of a template in a variable for reuse. This you can do with the capture statement:: {var $var} {capture $var} Add some content. {/capture} Output it a few more times: {$var} {$var} Be aware that you still have to declare the variable with the {var} block. Expressions ----------- An expression is anything you write in a template block that doesn't start with a special tag. But expressions are also used in template blocks with a tag and gives merely a value. PHP quotes the expression as "Anything that gives a value", that is also true for the template syntax. Expressions can be a single *operand* that returns a value. It is also possible to combine multiple operands with *operators*. The value returned depends on the used operands and operators. The operands are: - Boolean_ - Integer_ - Float_ - String_ - Array_ - Variables_ - Functions_ The operands Boolean, Integer, Float, String, and Array are described in the `Primitive types`_ section. Variables are described in the Variables_ section. Functions will be described in the Functions_ section. Variables and functions are considered as operands since they return one value. The type of this return value is also a: Boolean, Integer, Float, String, or Array. An operand returns a single value. Some examples are:: {5} {"Hello"} {str_len("Hello")} The values returned are, respectively: 5, Hello, and 5. Operators are things that you feed with one or multiple values and will result another value. Examples of operators are adding two numbers together with the plus (+) operator. This operator expects two integers or floats (in any combination) and returns either a integer of float. Another example is the equal operator (==). It expects two types operands of the same type and returns a Boolean. Arithmetic operators ```````````````````` The arithmetic operators can be used on all expressions which return a numerical value. The operator itself returns also a numeric value. The table below describes the available arithmetic operators: ============== =========== Negation -$o Ignored +$o Addition $ol + $or Subtraction $ol - $or Multiplication $ol * $or Division $ol / $or Modulus $ol % $or ============== =========== Note: The negation in this table is the arithmetic negation. Don't confuse this with the logic negation. The unary plus operator can also be used, but it doesn't affect the value. It's usually used to clarify that it's not a negative value. Examples:: { 2 + 5 // Returns value 7} { 2 - 5 } { 4 + 3 * 2 // Due to the operator precedence, first the * // will be evaluated and thereafter the +. } {var $a = 2} {var $b = -$a} Comparison operators ```````````````````` All comparison operators return a boolean value. The left-hand side and right-hand side should be of the same type. The available comparison operators are: ===================== ============ Equal $ol == $or Identical $ol === $or Not equal $ol != $or Not identical $ol !== $or Less than $ol < $or Greater than $ol > $or Less than or equal $ol <= $or Greater than or equal $ol >= $or ===================== ============ Examples:: { 4 == 5 } { 2 <= 5 } { true != false } { 4 == 5 == 6 } The last example compares 4 with 5. This returns the boolean *false*. After the first step the comparison is:: { false == 6 } The number 6 will be changed into a boolean. Every number except zero will get the boolean value *true*. Basically the last step of the comparison is:: { false == true } And this return the boolean value *false*. Logical operators ````````````````` The logical operators are used on all expressions which return a boolean value. The operator returns also a boolean: === ========== Not ! $o And $ol && $or Or $ol || $or === ========== Some usage examples:: { true || false } { $a == 5 && $a != 7 } { $a || $b } Assignments ----------- Assignments set a value to a variable. If the variable does already contain a value, it will be overwritten. As explained in the Variables_ section the variable must be declared first. Notice that an assignment can be used in the declaration itself. The syntax language has two types of assignments. The former type assigns a new value to the variable:: { = } The expression is evaluated and assigned to the variable. The next example assigns the value 4 to the variable *$myVar*:: {var $myVar} { $myVar = 3 + 5 / 5 } The latter assignment type updates the existing value with a modifier. There are multiple operators available: ============== =========== Addition $var += $or Subtraction $var -= $or Multiplication $var \*= $or Division $var /= $or Modulus $var %= $or Pre increment ++$var Pre decrement --$var Post increment $var++ Post decrement $var-- ============== =========== The Addition, Subtraction, Multiplication, Division, and Modulus assignment operators do an arithmetic calculation between the left (variable) and the right operand (expression) and assigns the value in the left operand (variable) again. Notice that the variable must already contain a value. The increment operators increment the number of the current variable by one. The decrement operators do the opposite and decrement the value of the current variable by one. There is no difference between the pre and post operators, and both are present for convenience purposes. Examples:: {var $myVar = 5 } {$myVar += 5 // $myVar has the value 10 } {$myVar++ // is the same as $myVar += 1 } {$myVar *= 10 // Multiply with 10} {--$myVar // Same as: $myVar -= 1 } Functions --------- The Template language has lots of built-in functions. These functions are categorized in a few groups: String, Array, Regular expression, Type information, and Arithmetic (math) functions. The functions are explained in the appendix. A function call has the following syntax:: ( [ Parameter1 [, Parameter2, ... ] ] ) An example:: {var $res = str_compare( "Hello", "world" ) } {$res // prints the result} All template functions follow these rules: - Function output is always returned. No variables are changed via references. - If the function contains a "haystack" and a "needle" then the first parameter will be the "haystack". The "needle parameter is a parameter that operates on another parameter, the "haystack". Contexts -------- The purpose of the context is to simplify the development of the templates and make the templates more secure. The context defines the purpose of the template output. For example the XHTML context should be set for the templates that generate (X)HTML output. When a template is processed and executed, it runs in a specific context. The context is set to XHTML by default. The next example shows a part of a user application that specifies the XHTML context:: $config = ezcTemplateConfiguration::getInstance(); $config->context = new ezcTemplateXhtmlContext(); $t = new ezcTemplate(); $t->process( "hello_world.ezt" ); Configuring the Template engine is discussed in the tutorial in more detail. The available context are described in the next subsections. XHTML Context ````````````` The XHTML Context escapes the HTML characters from the output from the expression blocks. Output outside the blocks are not escaped. See the next example:: {var $lt = "3 < 5"} {$lt} This template contains the HTML character '<' in an expression block. This character will be escaped. The output of the template is:: 3 < 5 The escape characters of the XHTML context are: ========= =========== Character Translation ========= =========== & & " " < < > > ========= =========== If the HTML characters in the expression block should not be escaped then the "raw" block should be used. The next example demonstrates a "raw" block:: {var $myBoldText = "Hello world"} {raw $myBoldText} This template outputs:: Hello world See the Raw_ section for more information. Additional required escaping ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Even inside XHTML there are still different output contexts, which might require different escaping. For example when using variables inside JavaScript the default escaping is *not sufficient*, but additional characters are required to be escaped, like shown in the following example. If the following template is called with the ``$input = '\' ); alert( \' XSS Alert ';``, it will show an JavaScript alert box, even with XHTML context escaping:: {use $input} ... To work around this issue you can either write a custom template function which wraps around the PHP function ``addslashes()`` or do the following in your template:: {use $input} ... This should be safe afterwards. Remember that there might be other contexts in your XHTML files, like other client side scripting languages, which again require different additional output escaping. No Context `````````` The No Context does not escape any characters. Usefull for text output and testing purposes. Control structures ------------------ Control structures are elements which help you control the flow of the code, either by doing conditional statements or by repeating certain actions. Increment ````````` The increment construct sets the cycle variable to the next value in the cycle array:: {cycle $rgb = array("red", "green", "blue" )} {$rgb // Print "red" } {increment $rgb} {$rgb // Print "green" } If the end of the cycle array is reached, it will jump again to the first value of the array. Decrement ````````` The decrement construct sets the cycle variable to the previous value in the cycle array:: {cycle $rgb = array("red", "green", "blue" )} {$rgb // Print "red" } {decrement $rgb} {$rgb // Print "blue" } If the begin of the cycle array is reached, it will jump again to the last value of the array. Reset ````` The reset construct sets the cycle variable to the first value in the cycle array:: {cycle $rgb = array("red", "green", "blue" )} {$rgb // Print "red" } {increment $rgb} {$rgb // Print "blue" } {reset $rgb} {$rgb // Print "red" } If, else, elseif ```````````````` The *if* construct allows conditional execution of code fragments. The structure is:: {if } {/if} If the evaluates to true, the fragment will be executed. For instance the following code will show "$a is less than $b" if $a is less than $b:: {if $a < $b } $a is less than $b. {/if} The *else* construct can be used in an *if* statement. It contains a code fragment that will be executed if the *expression* evaluates to false:: {if expression } code1 {else} code2 {/if} The *code2* is executed when the expression is false. Otherwise *code1* is executed. The *elseif* construct can be used in an *if* statement. It adds an extra expression and code block that will be evaluated and executed when the (previous) expression from the *if* statement does not evaluate to true:: {if $weekday == 0} Monday {elseif $weekday == 1} Tuesday {elseif $weekday == 2} Wednesday {else} Thursday, Friday, Saturday, or Sunday. {/if} Writing an *elseif* statement is actually the same as writing them with separate *if* and *else* statements. The previous example could be written as:: {if $weekday == 0} Monday {else} {if $weekday == 1} Tuesday {else} {if $weekday == 2} Wednesday {else} Thursday, Friday, Saturday, or Sunday. {/if} {/if} {/if} As you can see, this makes the code harder to read. Switch, Case, Default ````````````````````` The switch construct is quite similar to multiple *if* and *elseif* statements. The syntax is as follows:: {switch } [ case2 [ case3, .. ] ] [ default ] {/switch} A *case* block has the following syntax:: {case [, , ..]} {/case} And the *default* is as follows:: {default} {/default} The switch statement expects an expression. This expression will then be compared with the literal values from the *case* statements. The comparison starts and goes to the next literal as the values from the and are not equal. The from the first match will be executed and the rest of the cases are skipped. If none of the cases match, then the default block will be executed. See the example switch statement below:: {switch $weekDay} {case 0} Monday {/case} {case 1} Tuesday {/case} {case 2} Wednesday {/case} {case 3, 4, 5, 6} Thursday, Friday, Saturday, or Sunday {/case} {default} The $weekDay should be a number between 0 and 6. {/default} {/switch} This switch converts the weekday number to a name. Foreach ``````` A very important construct in the Template language is the *foreach*. The foreach is a loop structure that iterates over an array. Since this loop is used so often in the templates, it has several convenience tags build in. First we'll show the basic syntax:: {foreach as } {/foreach} {foreach as => } {/foreach} Two foreach structures are shown. The first structure takes each element from the *array*> and assigns it to the variable *. The second structure does the same, except that the key of the array is assigned to the variable *key*. An example for each structure:: {var $rgb = array( "red", "green", "blue" ) } {foreach $rgb as $color} The color is: {$color} {/foreach} {foreach $rgb as $key => $color} Array key {$key} contains the color: {$color} {/foreach} The output for this example will be:: The color is: red The color is: green The color is: blue Array key 0 contains the color: red Array key 1 contains the color: green Array key 2 contains the color: blue With this syntax we can easily loop any number, and is more convenient than using the while_ structure. This is demonstrated next:: {foreach 1..10 as $i} Iteration {$i} {/foreach} This works because the *1..10* statement creates an array with the values from 1 until 10. Often a foreach is used to create some kind of table or list. Several extensions are made available to ease the development: :Cycles: Increments or decrements a cycle variable. :Offset: Start the loop at a given offset. :Limit: Limits the number of iterations. The foreach loop can have an increment and decrement tag. These tags increment and/or decrement an cycle value, and work exactly the same as the Increment_ and Decrement_ control structures. The syntax is almost the same in the foreach:: [increment [, variable2, ... ] ] [decrement [, variable2, ... ] ] These tags are the same as the Increment_ and Decrement_ control structures. This tag is added at the end of the foreach construct. The next example increments the cycle value in every iteration of the loop:: {cycle $blackAndWhite = array( '#00000', '#FFFFFF' )} {foreach 1..5 as $value increment $blackAndWhite} Number: {$value} {/foreach} This loop outputs the following code:: Number: 1 Number: 2 Number: 3 Number: 4 Number: 5 The offset and limit code constructs are specified after the cycle increment or decrement tag. The offset and limit constructs are extremely useful for splitting a long table or list over multiple page views. The next example demonstrates this:: {use $hugeArray = array(), $offset = 0} {foreach $hugeArray as $tableEntry offset $offset limit 100} {* Show the information from the $tableEntry *} {foreach} See the `External variable declaration (use)`_ section for more information. The loop will start at the $offset and won't show the previous elements. The maximum iterations of the loop is 100. Another example shows the numbers from 50 until 100:: {var $hugeArray = 1..1000} {foreach $hugeArray as $value offset 50 limit 50} {$value} {/foreach} While ````` The while loop loops over a code fragment as long as the expression in the while evaluates to true. The syntax of the while loop is as follows:: {while } {/while} Usually the expression evaluates whether a counter reaches a certain number. In the *code* the counter is increased or decreased:: {var $i = 0} {while $i < 10} The number is: {$i}. {$i++} {/while} This example prints the numbers from 0 until 9. If you write a while loop, make sure that the loop eventually ends. The next example demonstrates another while loop. This loop increments a value from a Cycle. Compare how the same example can be done with a Foreach_:: {cycle $blackAndWhite = array( '#00000', '#FFFFFF' )} {var $i = 1} {while $i <= 5 } Number: {$i} {$i++} {increment $blackAndWhite} {/while} Delimiter ````````` The delimiter can be used (only) inside a loop to do every given iteration a specific action. The syntax is as follows:: {delimiter [modulo [is ]]} {/delimiter} The "module..." part can be omitted and by default the delimiter will be inserted between every iteration of the loop. If a modulo is used, the "is " part of the delimiter can be omitted and will be interpreted as "is 0". The delimiter will always be executed between two iterations of the loop. In the next example between every name a comma is inserted:: {var $names = array( 'Bernard', 'Fran', 'Manny' )} {foreach $names as $name} {$name} {delimiter}, {/delimiter} {/foreach} The next example demonstrates creates a matrix with 4 rows and 4 columns. The delimiter closes the current row and opens a new one every forth column as the delimiter is only added when "internal counter modulo 4" equals 0. The "internal counter" simply counts the number of executed iterations:: {var $columns = 4} {foreach 1..16 as $nr} {delimiter modulo $columns} {/delimiter} {/foreach} Continue ```````` The continue statement is used within the looping structures to skip the rest of the current loop iteration and continue execution at the condition evaluation and then the beginning of the next iteration. If a delimiter is available in the looping structure then this delimiter will be added. Use the Skip_ statement to skip also the delimiter. The next example show the numbers 1 to 5 separated with a comma. After the numbers 1, 2, and 3 is the token # appended. As the example shows, the numbers higher than 3 will not execute the rest of the foreach anymore. The delimiter is added anyway:: {foreach 1..5 as $i} {delimiter} , {/delimiter} {$i} {if $i > 3} {continue} {/if} # {/foreach} The output of the template is:: 1 #, 2 #, 3 #, 4 , 5 Skip ```` The skip is the same as a continue, except that the delimiter in the loop will be skipped also. The next example show the numbers 1 to 5. The number 1, 2, and 3 have the token # appended and are separated with a comma. As the example shows, the numbers higher than 3 will not execute the rest of the foreach anymore and the delimiter is not appended:: {foreach 1..5 as $i} {delimiter} , {/delimiter} {$i} {if $i > 3} {skip} {/if} # {/foreach} And outputs:: 1 #, 2 #, 3 #, 4 5 Break ````` The break ends execution of the current foreach or while structure. The example below prints the numbers 1 and 2. Due to the break, the rest of the loop is skipped:: {foreach 1..10 as $i} {$i} {if $i == 2} {break} {/if} {/foreach} Include ``````` The include calls other templates which will be executed within the current template. Variables can be passed on and retrieved from the included template. The generic template could then be used at multiple places and is configurable via the given variables. The syntax of the include is as follows:: {include [ send ] [ receive ] The file that needs to be included is either specified with a string (template\_name) or with a location object. The location object is explained in the section `Template locations`_. The has this syntax:: as | And the has almost the same syntax as the :: as | A next example will clarify the syntax a bit more:: {include "calc_a_plus_b.ezt" send 2 as $a, 5 as $b receive $c as $sum } The included template calculates the sum of the given variables $a and $b, and returns the answer in variable $c. The expressions "2" and "5" are assigned to the variables $a and $b of the included template. The value of the (returned) variable $c is directly assigned to the variable $sum. The variable $sum does not need to be declared first. The template "calc\_a\_plus\_b.ezt" is:: {use $a = false, $b = false} {if $a === false || $b === false} Variable $a or $b has an incorrect value. {/if} {return $a + $b as $c} The next templates includes the "calc\_a\_plus\_b.ezt" but does not use the expression part of the include:: {var $a = 2, $b = 5} {include "calc_a_plus_b.ezt" send $a, $b receive $c } {var $sum = $c} Raw ``` The raw construct outputs raw information and is not affected by the Contexts_. For example, the XHTML context is set and an expression contains HTML characters (which should be sent to the output) then use the "raw" block:: {var $myBoldText = "Hello world"} {raw $myBoldText} This template outputs:: Hello world Translation Constructs ---------------------- Translation constructs allow you to embed translatable strings in your templates. Every construct requires at least a string and a context, the context can however be set by default to be valid for subsequent translatable string entries. tr_context `````````` Is used to set a default translation context. All tr_ entries below this construct will then use this translation context if none is specified explicitly. Information on contexts can be found in the `Qt Linguist format specification`__. This construct is used like:: {tr_context "admin/forget_password"} Each template can have multiple tr_context statements. The default context that is set with this construct is valid until the next one is encountered. __ Translation_linguist-format.html#contexts tr `` The tr construct defines a translatable string, the simplest form of this construct is:: {tr "String to translate"} This will only work however, if there is a default context set with `tr_context`_. In case there is none set, you have to specify it yourself with the "context" parameter. The following two templates are equivalent:: {tr_context "admin/forget_password"} {tr "String to translate"} and:: {tr "String to translate" context "admin/forget_password"} When a translator translates a text, it is sometimes useful to have slightly more information than just the context and the string itself. The tr construct therefore allows to add a comment to the translatable string with the "comment" parameter. This has no effect on how the tr construct is interpreted however. An example:: {tr "Login" context "user/login" comment "Text before login input box"} In many occasions, the translatable strings allow positional or named parameters to allow for changing the order of arguments. For example the English string "Search for 'appelmoes' returned 3 matches" can be translated in Dutch as: "Er zijn 3 items gevonden bij het zoeken naar 'appelmoes'". A simple concatenation mechanism of multiple translatable strings would no longer work. The tr construct supports parameterized strings in two different ways: with numerical replacement identifiers (such as %1 and %2) and with associative identifiers (such as %search_string and %matches). The following example illustrates how this is done in the simplest possible way:: {tr "Search for '%1' returned '%2' matches" vars 'appelmoes', 3} If no key is specified for variables, like in the above example, they are automatically given numbers, starting by 1. It is also possible to add specific positions to variables, like:: {tr "Search for '%1' returned '%2' matches" vars 2 => 'appelmoes', 1 => 3} This is perhaps not so useful for positional parameters like here, but it is necessary for named parameters as illustrated in the example here:: {tr "Search for '%what' returned '%matchcount' matches" vars 'what' => 'appelmoes', 'matchcount' => 3} It is of course also possible to mix those two cases:: {tr "Search for '%1' returned '%matchcount' matches" vars 'matchcount' => 3, 'appelmoes'} or:: {tr "Search for '%1' returned '%matchcount' matches" vars 'appelmoes', 'matchcount' => 3} Variables without any key, are always given positional identifiers in sequential order. When doing so, variables with a named key are ignored, while variables with a numerical key reset the next number in the auto-numbering sequence to the number of the key. The following example shows that:: {tr "%1 %2 %3 %4 context "test" vars 3 => 'three', 'four', 1 => 'one', 'two'} For information on how to setup translations for your templates, please refer to the section `Translations`_. Extensions ========== This section explains how you can extend your Template language. Extending the Template language gives you the opportunity to add more application specific functionality. Some examples of Template language extensions are: - Adding a method to fetch information from a data structure. This data structure could be a single or a group of objects, a database, an array, etc. - Creating an HTML table using your own customized template blocks. - Doing an application specific calculation. Currently, there are two ways of adding custom functionality to the template. The methods are named: **custom blocks** and **custom functions**. Together we call them **custom extensions**. First, we'll explain how to create a custom block. With the knowledge of these custom blocks, we explain - much shorter - the custom functions. Custom blocks ------------- Custom blocks are extra functionality that could be used inside the template language. These blocks are implemented in PHP. The next section explains how an custom block can be used. The sections thereafter discuss how to add a new custom block. Custom blocks in the Template language `````````````````````````````````````` Custom blocks add specific behavior to the Template language. The most basic structure of a custom block - without any parameters - is:: '{' '}' The block starts and ends with curly braces. The ** identifies the custom block. Optionally, a custom block has also a closing block:: '{' '/' '}' The name must be the same as the start block, but starts with a forward slash ('/'). The text between the open and close tag is considered as input data. Whether a custom block should have a close tag is up to the developer. The next example demonstrates a custom block with an open and close tag that capitalizes the text in between:: {capitalize} Guybrush Threepwood. {/capitalize} Another example that uses a custom block without a close tag:: {capitalize "Guybrush Threepwood."} Whether or not a custom block has a close tag, it handles the parameters the same. The structure of a custom block is as follows:: '{' block_name [start_expression] [ ['='] ... ] '}' Basically, it describes that a custom block can have: - One optional expression which is not bound to a parameter name. - Zero or more named parameters with a value. Between the parameter name and value is an optional equal sign. Some example blocks that use parameters:: {link "eZ systems" to "http://ez.no"} {table border=true bgcolor="red"} {debug} {calculate 5 plus 5} {join array( 'Hello', "world" ) with "_"} {header style="bold"} Hello world {/header} Note that the values used in the examples are just ordinary expressions. Therefore it is possible to write:: {link "eZ" . " systems" to 'http'. "://" . "ez.no"} {calculate 2 + 3 plus 1 * 2 + 3} Again, the optional and required parameters are up to the developer. Adding a custom block ````````````````````` New custom blocks are added to the Template engine with the ezcTemplateConfiguration::addExtension() method. This method expects the class name which implements the new custom block. The next example adds a custom block to the Template engine which is implemented in MyClass:: $config = ezcTemplateConfiguration::getInstance(); $config->addExtension( "MyClass" ); The custom block class should implement the ezcTemplateCustomBlock interface. This interface has only one method getCustomBlockDefinition(). The class implementing this method should return an ezcTemplateCustomBlockDefinition object from a given block name, if possible. Custom block definition ``````````````````````` The custom block definition describes how the Template engine should interpret the custom block. The information is provided by returning an instance of the ezcTemplateCustomBlockDefinition:: class ezcTemplateCustomBlockDefinition extends ezcTemplateCustomExtension { public $class; public $method; public $hasCloseTag; public $startExpressionName; public $optionalParameters = array(); public $requiredParameters = array(); public $isStatic; } The member variables that should be set in this class are: :class: String value that specifies the (static) class that implements the function to be executed. :method: String value that specifies the (static) method that should be run. :hasCloseTag: Boolean value that specifies whether the class has an open and close tag or only a open tag. :startExpressionName: The first parameter of a custom block without a name is called the start expression. If the custom block should have a start expression then this variable specifies a name for it. The name should reappear in either the optionalParameters or the requiredParameters. :optionalParameters: Optional named parameters for this custom block. :requiredParameters: Required named parameters for this custom block. :excessParameters: When this is set to true, additional parameters are also available in the implementation of the custom block as elements of the $parameters array. :isStatic: The custom block is only called during compilation. At run time the static output from the custom block at compile time is displayed. The following custom block creates a hyper-link from a name and an URL:: {link "name" to "url" [title "title"]} This custom block has a: - Required unnamed parameter that contains the name. - Required named parameter "to" that contains the URL. - Optional named parameter "title" that contains the title. Except for the class and the method name the CustomBlockDefinition should look like:: $def = new ezcTemplateCustomBlockDefinition; $def->class = "MyLink"; $def->method = "linkMethod"; $def->hasCloseTag = false; $def->startExpressionName = "from"; $def->optionalParameters = array( "title" ); $def->requiredParameters = array( "from", "to" ); The CB definition should be made available to the Template engine via a class implementing the ezcTemplateCustomBlock interface:: interface ezcTemplateCustomBlock { public static function getCustomBlockDefinition( $name ); } The class implementing the getCustomBlockDefinition() method should return an ezcTemplateCustomBlockDefinition for the given block name $name. The next code demonstrates a class that implements the interface:: class MyLink implements ezcTemplateCustomBlock { public static function getCustomBlockDefinition( $name ) { switch ($name ) { case "link": $def = new ezcTemplateCustomBlockDefinition; $def->class = "MyLink"; // // Create definition // return $def; } return false; } } Implementing the custom block ````````````````````````````` In the CB definition is specified which class and what method should produce the custom block output. A typical implementation to create a hyper-link would be:: public static function link( $parameters ) { $title = ""; if( isset( $parameters["title"] ) ) { $title = "title='". $parameters["title"] ."'"; } return "".$parameters["from"]."" } The method implementing the custom block returns a string that will be inserted in the template output. The custom block parameters are provided in the first parameter as an array. The method itself must check whether the optional parameters are sent or not. Required parameters are always available as the template compiler throws a compiler exception if these parameters are absent. The custom blocks that do have a close tag need a method that accepts two parameters. For example the following custom block has a close tag:: {capitalize} Guybrush Threepwood {/capitalize} The method that implements the custom block:: public static function capitalize( $parameters, $text ) { return strtoupper( $text ); } The $parameters parameter is never used. The text between the open and close tag of the custom block is always passed in the second parameter. Example ``````` The 'calc' custom block calculates the sum of the given values. The sum is calculated from the initial value plus or minus the values added to the "plus" and or "minus" parameter. Some usage examples are:: {calc 5 plus 3} {calc 5 plus array(2,5,2) minus 2} {calc 2 minus 5} The custom block could be implemented like:: class CalcCustomBlock implements ezcTemplateCustomBlock { public static function getCustomBlockDefinition( $name ) { switch ($name ) { case "calc": $def = new ezcTemplateCustomBlockDefinition; $def->class = __CLASS__; $def->method = "calculate"; $def->hasCloseTag = false; $def->startExpressionName = "init"; $def->requiredParameters = array("init"); $def->optionalParameters = array("plus", "minus"); return $def; } return false; } public static function calculate( $params ) { $result = $params["init"]; if ( isset( $params["plus"] ) ) { if( is_array( $params["plus"] ) ) { foreach( $params["plus"] as $value ) { $result += $value; } } else { $result += $params["plus"]; } } if ( isset( $params["minus"] ) ) { if( is_array( $params["minus"] ) ) { foreach( $params["minus"] as $value ) { $result -= $value; } } else { $result -= $params["minus"]; } } return $result; } } This new custom block needs to be assigned to the Template configuration:: $config = ezcTemplateConfiguration::getInstance(); $config->addExtension( "CalcCustomBlock" ); And of course the template can be run like:: $t = new ezcTemplate(); $t->process( "my_template.ezt" ); Custom functions ---------------- This section explains how the custom function can be implemented. Custom blocks and custom functions are very similar. Custom functions in the Template language ````````````````````````````````````````` Custom functions are extra functions that can be used in the Template expressions. Some examples are:: Greatest common divisor: {gcd(8, 12)} {sin( $angle ) * 2} {matrix_multiply( $m1, $m2)} {fetch_from_database("items", 2)} Basically, the second line in the example runs a custom function and multiplies the result with two. This demonstrates that the difference between a custom block and a custom function. Custom functions can be used within an expression. Custom blocks are directly generating an output result. Adding a new custom function ```````````````````````````` As with the custom block, custom functions are added to the Template engine by the ezcTemplateConfiguration::addExtension() method. The class name given to this method should implement the ezcTemplateCustomFunction interface. Notice that this is the same as adding a custom block. :: $config = ezcTemplateConfiguration::getInstance(); $config->addExtension( "MyClass" ); The example above adds *MyClass* to the ezcTemplateConfiguration. MyClass implements the getCustomFunctionDefinition() from the ezcTemplateCustomFunction interface. This function returns an ezcTemplateCustomFunctionDefinition object:: class ezcTemplateCustomFunctionDefinition extends ezcTemplateCustomExtension { public $class; public $method; public $sendTemplateObject = false; // Deprecated: // public $parameters = array(); } The $class and $method parameter are the same as for custom blocks. The $parameters variable is obsolete with version 1.2. It used to specify the required and optional parameters for the custom function. - Required parameters are named strings. - Optional parameters are named strings enclosed with square brackets. These parameters should be specified after the required parameters. In version 1.2 and up it uses reflection to find the required and optional parameters. Due some bugs in the reflection classes it works properly in PHP version 5.2 and up. It is also possible to accept a variable number of (extra) arguments. For this you need to set the *variableArgumentList* property of the ezcTemplateCustomFunctionDefinition. The variable *$sendTemplateObject* adds the possibility to send the current template object to the custom function. As with functions in PHP the order of the unnamed parameters matter. The next example demonstrates a complete custom function implementation:: class MyClass implements ezcTemplateCustomFunction { public static function getCustomFunctionDefinition( $name ) { switch ($name ) { case "func": $def = new ezcTemplateCustomFunctionDefinition(); $def->class = "MyClass"; $def->method = "customFunction"; // Deprecated: // $def->parameters = array( "firstParam", "secondParam", "[thirdParam]"); return $def; } return false; } public static function customFunction( $firstParam, $secondParam, $thirdParam = "isOptional" ) { // Implementation. return "string"; } } The custom parameters specified in the definition block should also be present in the *customFunction* implementation. Three parameters are specified, so the customFunction implementation should have three parameters. The last parameter in the parameter definition is specified as optional, so should the last parameter in customFunction be optional. The interface of the ezcTemplateCustomFunction requires to implement the getCustomFunctionDefinition() method:: interface ezcTemplateCustomFunction { public static function getCustomFunctionDefinition( $name ); } Named parameters ```````````````` New in version 1.2 of the Template engine are named parameters. The advantage of named parameters is that the order of the parameters are no longer important and that parameters can be omitted that otherwise was not possible. The next example shows a common custom function retrieving items from the database:: // fetch_item ( select = "*", start = 0, limit = false, orderBy = "id", reverseOrder = false ) { fetch_item("*", 0, false, "name") } // Fetch everything but order by 'name' This example fetches everything from the items table and sorts it on "name". Without named parameters the problem is that only the second last parameter needs to be changed and therefore all the previous parameters need to be given. Named parameters are written in the form *"keyword = value"*. The keyword is the name of the parameter. The equal sign is used as separator because it is not possible to do any assignments within expressions. Using named parameters the code from the previous example is reduced to:: // fetch_item ( select = "*", start = 0, limit = false, orderBy = "id", reverseOrder = false ) { fetch_item( orderBy = "name") } // Fetch everything but order by 'name' Besides that the code is shorter, it is also more descriptive. Sending template objects ```````````````````````` In a few cases the template object is needed in the custom function implementation. With access to the template object, the configuration and other template settings could be retrieved and used. If the variable *sendTemplateObject* is set to *true*, the first parameter in the function contains the template object. The following The next example adds the custom function *templatePath*:: class MyClass implements ezcTemplateCustomFunction { public static function getCustomFunctionDefinition( $name ) { switch ($name ) { case "templatePath": $def = new ezcTemplateCustomFunctionDefinition; $def->class = "MyClass"; $def->method = "templatePath"; $def->sendTemplateObject = true; return $def; } return false; } public static function templatePath( $templateObj ) { return $templateObj->configuration->templatePath; } } Caching ======= The purpose of the template cache is to speed up the processing time of a template by storing its output to a file. This file is known as the *cache file*. When the same template is requested later on, the cached contents are displayed without processing the template first. The time consuming instructions, like computations and requests to a database, can then be reduced or omitted. Caching can truly reduce the processing time of the templates, but caching needs to be handled with care. The developer needs to: - Add caching at the correct, time consuming, spots in the template. - Make sure that the cache is expired and renewed in time. - Clean up the unused cache files. Each cached template has a bit of overhead in comparison with an uncached template. The extra work is to check if the cache file exists and if it's valid, optionally regenerate the cache, and execute the cache. If the cache file needs to be regenerated too often, the template is probably processed quicker without caching at all. The same applies for small, non-time consuming templates. Another issue the developer should keep in mind is that the cache needs to be expired and renewed in time. Usually a template cache is valid for a limited time. This can be a timeout (e.g. after 2 hours) or a trigger (an object changes) that expires the cache. The triggers and timeouts need to be available in the template. The last issue is that unused cache files need to be discarded. Without a proper cache clean up mechanism the system will eventually flood with unused cache files. It is the developer's responsibility to remove those files. Configuration ------------- The template cache is enabled by default and activated when cache blocks are present in the templates. The template configuration, *ezcTemplateConfiguration* controls the locations where the cache files are stored and the mechanism that cleans up the unused cache files. The configuration has the following properties relevant to caching: - *cachedTemplatesPath*: The location where the cached templates should be stored. The *compiledPath* and the *cachedTemplatePath* properties together form the complete cache path. - *cacheManager*: This property is assigned to a cache manager object that keeps track of the generated cache files and is responsible for its clean up. - *disableCache*: Disables all caching, useful during development. The next code demonstrates an example configuration: :: $config = ezcTemplateConfiguration::getInstance(); $config->templatePath = '/mydir/templates/'; $config->compilePath = '/mydir/templates_bin/'; $config->cachedTemplatesPath = "CACHE"; $config->disableCache = false; $config->cacheManager = new DatabaseCacheManager(); $template = new ezcTemplate(); $template->process( "hello_world.ezt" ); The engine will process the following template: :: "/mydir/templates/hello_world.ezt" The compiled template and the cached template will then be stored in: :: "/mydir/templates_bin/compiled_templates/" "/mydir/templates_bin/CACHE/" The 'compiled_templates' is a default setting. The cache manager that will be used is the *DatabaseCacheManager*. Details about the cache manager are explained later. Cache tags ---------- There are two methods to enable caching: *cache_block* and *cache_template*. The *cache_block* enables caching between the open and close tag:: {"dynamic"} {cache_block} {foreach 1..10 as $i} {$i} {/foreach} {/cache_block} {"dynamic"} This example caches the *foreach*-loop. The strings that contains *"dynamic"* are outside the cache block; thus not cached. The *cache_template* starts caching after this tag until the end of the template. In the next example everything is cached except the string that contains *"dynamic"*:: {"dynamic"} {cache_template} {foreach 1..10 as $i} {$i} {/foreach} {"cached"} Sometimes a large block needs to be cached with the exception of a small block of template code. Take for instance a relatively static page with the current time in one corner. The *dynamic* block is a block that can only be used inside a *cache_block* or after the *cache_template*. The code inside the *dynamic* block is not cached and will always be executed. The next example uses the *dynamic* block to display the current time: :: {cache_template} The current time is: {dynamic} {date_format_timestamp("H:i:s")} {/dynamic} Note that the example above is only for demonstration purposes. The template is so simple that it is probably quicker to use no caching at all. Cache renewal ------------- Usually cached templates are valid for a limited time. A certain page is known to be valid for some hours or until a value changes in the database. The Template engine supports three mechanisms to expire the cache: *cache-keys*, *time-to-live* (TTL), and a *cache manager*. The cache-keys and TTL are both parameters of the cache syntax. These parameters check whether the cache is still valid and if needed create a new version. The cache manager needs to be programmed manually. It gives a better control over the cache and can also remove old cache files. Cache keys `````````` Both *cache_block* and *cache_template* have a *keys* parameter. This parameter can be used to define the uniqueness of a cache block. For every combination of different values of the parameter, a separate file is stored on the disk, containing the output of the cache block. The *keys* parameter can be an expression but is usually limited to a variable or function call. The next example creates new cache files when the user ID changes: :: {use $user_id} {cache_block keys $user_id} Show user information. {/cache_block} {cache_block keys getUserId()} Show user information, again. {/cache_block} The first cache_block relies on the imported *$user_id*. The second *cache_block* uses a custom function that returns the ID. The given cache key can be of any type. If the type is a scalar (boolean, integer, float, or string) then the value is compared as a string. For arrays, it's compared with the checksum of the dumped structure. For objects, the comparison consists of two steps. First will be checked if the object has the *cacheKey* method. If this method exists on the object then this value will be used. Otherwise the checksum of the object dump will be used. The example below uses an user object as cache key. The name property of this object will be shown: :: {use $userObj} {cache_template keys $userObj} {$userObj->name} The user object can be implemented like: :: class User { public $firstName; public $lastName; public $name; public $id; public function cacheKey() { return $this->id; } public function __construct( $firstName, $lastName, $id = 1 ) { $this->firstName = $firstName; $this->lastName = $lastName; $this->name = $firstName . " " . $lastName; $this->id = $id; } } And the application calling the template is done like this: :: $t = new ezcTemplate(); $t->send->userObj = new User( "Bernard", "Black" ); echo $t->process( "my_template.ezt" ); Time-to-live ```````````` The *ttl* parameter makes it possible to specify how long a cache block should live in number of seconds. The cache is removed after the timeout. Note that this behavior is slightly different than the *cache-key*. The *cache-key* creates a new version of the cache but does not remove any cache files. The next example creates a cache block that is valid for two hours:: {cache_block ttl 2*60*60} News that changes not too often. {/cache_block} Via a custom function the TTL can be used to renew the cache at certain predefined timestamps: :: {cache_block ttl getRemainingTime(minute=0, hour=6)} Updated each morning at 6 o'clock {/cache_block} The custom function *getRemainingTime* calculates the remaining seconds until it is 6 o'clock in the morning. Cache manager ------------- In the previous sections it's already hinted about the cache manager. The cache manager is a slightly complex but powerful mechanism to control the cached pages. The cache manager is an interface that needs to be implemented and assigned to the Template engine. The implementation gives the application the possibilities to: - Mark expired cache files based on application criteria. - Remove old cache files. - Keep track of the cache dependencies. The solutions above need to be implemented from the cache manager interface. This implementation allows the developer to make an application-dependent solution. The cache manager interface ``````````````````````````` The user application and the Template engine communicate via method calls on the cache manager implementation. The cache manager interface has the following methods: :: interface ezcTemplateCacheManager { public function startCaching( $template, $templatePath, $cachePath, $cacheKeys ); public function stopCaching(); public function isValid( $template, $templateName, $cacheName ); public function register( $name, $value ); public function update( $name, $value ); public function includeTemplate( $template, $templatePath ); public function cleanExpired(); } The Template engine calls the following methods on the interface. Usually those methods are not called from the user application. - *startCaching*: When a cache file is going to be created. - *stopCaching*: After the cache file is created. - *isValid*: To check whether the given cache file is still valid. - *includeTemplate*: Notify the cache manager that a sub template is included. The remaining methods from the interface are called from the user application: - *register*: Register a value that is related to the cache file currently created. - *update*: A registered value is updated. This **may** indicate that a cache file is outdated. - *cleanExpired*: Removes the expired cache files. Typically the cache creation procedure is as follows. This procedure gives insight how the cache manager can be used: 1. The user application calls the method: *$t->process("my_template.ezt")*. 2. The template *"my_template.ezt"* caches parts of the page. 3. If a cache file exists for the requested template, the Template component calls *CacheManager::isValid()* to see whether the cache file is still correct. If it is then the cache contents can be returned. Otherwise a new cache file will be created and returned. 4. When a cache file is going to be created, the *CacheManager::startCaching()* method is called. The Cache Manager is now informed that all following function calls in the application are used inside the cache. 5. Application code returning data which may be modified in the future should be registered to the cache manager. This is done via the *CacheManager::register()* method. 6. The *CacheManager::includeTemplate()* is called when another template is included. 7. The *CacheManager::stopCaching()* is called when the cache file is created. 8. The user application should call the *CacheManager::update()* method when a change in the database or application may affect any of the caches. Keeping track of the values used in the caches is probably best stored in a database. Using the file system is also possible but makes things more complicated. Database storage ```````````````` The database is a good medium to keep track of all the generated caches. It can quickly mark lots of cache files as expired. The real removal of the cache files from the file system can then be done when the server load is low. In which database tables the cache information is stored depends on the implementation of the cache manager. In our example we will use two tables: *cache_files* and *cache_values*. The table *cache_files* has at least the following fields: +---------------+------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +===============+==================+======+=====+=========+================+ | id | int(10) unsigned | NO | PRI | NULL | auto_increment | +---------------+------------------+------+-----+---------+----------------+ | cache | varchar(255) | NO | MUL | | | +---------------+------------------+------+-----+---------+----------------+ | expired | tinyint(4) | NO | | 0 | | +---------------+------------------+------+-----+---------+----------------+ The fields store: :id: Is the unique cache identifier. :cache: The relative path to the cache file. :expired: Has the value 0 if the cache is valid, otherwise 1. The table *cache_values* has the following fields: +-------------+------------------+------+-----+---------+-------+ | **Field** | Type | Null | Key | Default | Extra | +=============+==================+======+=====+=========+=======+ | cache_id | int(10) unsigned | NO | PRI | | | +-------------+------------------+------+-----+---------+-------+ | name | varchar(50) | NO | PRI | | | +-------------+------------------+------+-----+---------+-------+ | value | varchar(255) | NO | PRI | | | +-------------+------------------+------+-----+---------+-------+ The fields store: :cache_id: The relation to *cache_files.id*. :name: Name of the value that is stored. :value: The value that belongs to the name. Another table can also store the cache keys that belong to the cache. The structure of this table is similar to the table *cache_values*. Database fetch `````````````` Often a database result needs to be shown in a template. Two techniques are commonly used: - Do the database queries inside the application. Send the result to the template. - Implement a custom function or block that can retrieve database information inside the template. The first solution has arguably a better separation between application and layout code. The second solution has the main advantage that it is easier to optimize. In this section we will continue with the second form. The following template code shows the user information of a single user. The template uses a custom function *db_fetch* that retrieves the user information as an object: :: {use $userID} {cache_template keys $userID} {var $userObj = db_fetch(object="user", id=$userID)} Name: {$userObj->name}
Name: {$userObj->address}
Email:{$userObj->email}
The caching system creates a separate cache file for each *userID*. This cache file is valid, until information changes. If *userID* 1 changes its e-mail address, the Template engine will still use the old cache file. The solution for this problem is that the application informs the Template engine via the Cache Manager about this information update. When the template is run for the first time, it calls the following methods in order: 1. *startCaching( $template, $templatePath, $cachePath, $cacheKeys )*. The current template will be cached. The $cachePath should be stored in the *cache_files* database. The following code could be an implementation of the *startCaching* method: :: public function startCaching( $template, $templatePath, $cachePath, $cacheKeys ) { // Get the current database handler. $db = ezcDbInstance::get(); // Get the current cache ID, if it does exist. $q = $db->prepare( "SELECT id FROM cache_files WHERE cache = :cache" ); $q->bindValue( ":cache", $cachePath ); $q->execute(); // One result and make sure the query is terminated. $r = $q->fetchAll(); if ( sizeof( $r ) > 0 ) // Do we have any results? { $id = $r[0]["id"]; // Renew the cache_file. $s = $db->prepare( "UPDATE cache_files SET expired=0 WHERE id = :id" ); $s->bindValue( ":id", $id ); $s->execute(); } else { // Insert the new cache file $q = $db->prepare( "INSERT INTO cache_files VALUES( '', :cache, '', 0)" ); $q->bindValue( ":cache", $cachePath ); $q->execute(); $id = $db->lastInsertId(); } // Mark that the template is currently creating a cache. $this->isCaching = true; $this->template_id = $id; } The code checks whether the cache file is already registered. If the cache file is available then it sets the *expired* status to 0. Otherwise it adds the cache to the table, with a new id and *expired* set to 0. The *cache_files* table contains something like: == ================================== ======= id cache expired == ================================== ======= 01 compiles/cache/user.ezt-9dsafa0 0 02 compiles/cache/user.ezt-84fdvj2 0 == ================================== ======= 2. *register( $name, $value )*. This function is called by the user application **during** cache creation. In our example the fetch function which returns the user object should call the *register* function. :: public static function fetch( $object, $id ) { $db = ezcDbInstance::get(); $s = $db->createSelectQuery(); $s->select( "*" )->from( $object )->where( $s->expr->eq( "id", $id ) ); $statement = $s->prepare(); $statement->execute(); $result = $statement->fetchAll(); // Inform the cache manager ezcTemplateConfiguration::getInstance()->cacheManager->register( $object, $result[0]["id"] ); } An example implementation of the *register* method is as follows: :: public function register( $name, $value ) { if ( $this->isCaching ) { $db = ezcDbInstance::get(); $s = $db->prepare( "REPLACE INTO cache_values VALUES ( :id, :name, :value )" ); $s->bindValue( ":id", $this->template_id ); $s->bindValue( ":name", $name ); $s->bindValue( ":value", $value ); $s->execute(); } } After registration the *cache_values* table contains something like: == ============= ======= id name value == ============= ======= 01 user 1 02 user 2 == ============= ======= Via the *cache_files* table, we know that the user ID 1 is bound to the cache file 'compiles/cache/user.ezt-9dsafa0' and it is not expired. 3. *stopCaching()*. The method is called when the caching is done. The only thing that needs to be done, is to set *isCaching* to *false*. :: public function stopCaching() { $this->isCaching = false; } Right now, the cache file is created. The database contains the user IDs requested during the cache creation. Since the cache file is available, the Template engine will also call the *isValid()* method on the next request. If this method returns *true* then the values used in the cache are unaltered. Let's continue with the example and assume that the user application does change the data of one user. 4. *update( $name, $value )*. The user application calls this method when a value changes that is possibly used inside the templates. The snippet below modifies the user name. :: public static function updateUser( $id ) { $db = ezcDbInstance::get(); $q = $db->createUpdateQuery(); $q->update( "user" )->set( "email", $q->bindValue( "bernard@example.com" ) )->where( $q->expr->eq( 'id', $id ) ); $st = $q->prepare(); $st->execute(); // Update the users. ezcTemplateConfiguration::getInstance()->cacheManager->update( "user", $id ); } Most important is the last line which updates the user with the ID $id. The *CacheManager::update* method can be implemented like: :: public function update( $name, $value ) { $db = ezcDbInstance::get(); $qry = "UPDATE cache_files, cache_values SET cache_files.expired=1 ". "WHERE cache_files.id = cache_values.cache_id AND cache_values.name = :name AND cache_values.value = :value"; $s = $db->prepare( $qry ); $s->bindValue( ":name", $name ); $s->bindValue( ":value", $value ); $s->execute(); } This method expires all the cache files that have the matching cache values: $name and $value. If we assume that user with ID 1 changes the e-mail address, the *cache_files* table is: == ================================== ======= id cache expired == ================================== ======= 01 compiles/cache/user.ezt-9dsafa0 1 02 compiles/cache/user.ezt-84fdvj2 0 == ================================== ======= And the *cache_values* table remains the same: == ============= ======= id name value == ============= ======= 01 user 1 02 user 2 == ============= ======= 5. *isValid( $template, $templateName, $cacheName )*. The Template engine calls this method to check whether the cache is still valid. See an example implementation below:: public function isValid( $template, $templateName, $cacheName ) { $db = ezcDbInstance::get(); // Check whether the cache is registered and if it's expired. $q = $db->prepare( "SELECT id, expired FROM cache_files WHERE cache = :cache" ); $q->bindValue( ":cache", $cacheName ); $q->execute(); $r = $q->fetchAll(); // Expect 0 or 1 result if ( count( $r ) == 0 || $r[0]["expired"] == 1 ) { return false; } return true; } When the cache file does not exist or when the cache file is marked as *expired* the function returns *false*, otherwise *true*. The Template engine regenerates the cache if this method returns *false*. Otherwise the cache is displayed. In this section we have discussed how to expire the cache when values in the database change. The implementation of the cache manager is limited to this problem for now. The following sections explain other problems that can be solved using the cache manager. Loose coupling `````````````` In the previous section we explained that the cache manager should be informed when data used in the templates is requested or altered. This requirement enforces strong dependencies, everywhere in the application code are function calls to the cache manager. The previous section uses the following two example functions inside the user application to update the cache manager:: public static function fetch( $object, $id ) { $db = ezcDbInstance::get(); $s = $db->createSelectQuery(); $s->select( "*" )->from( $object )->where( $s->expr->eq( "id", $id ) ); $statement = $s->prepare(); $statement->execute(); $result = $statement->fetchAll(); // Inform the cache manager ezcTemplateConfiguration::getInstance()->cacheManager->register( $object, $result[0]["id"] ); } public static function updateUser( $id ) { $db = ezcDbInstance::get(); $q = $db->createUpdateQuery(); $q->update( "user" )->set( "email", $q->bindValue( "bernard@example.com" ) )->where( $q->expr->eq( 'id', $id ) ); $st = $q->prepare(); $st->execute(); // Update the users. ezcTemplateConfiguration::getInstance()->cacheManager->update( "user", $id ); } The call to the *register* and *update* methods are making dependencies with the cache manager. These method calls can be replaced with a signal from the SignalSlot component. See the following example code:: public static function fetch( $object, $id ) { $db = ezcDbInstance::get(); // ... $result = $statement->fetchAll(); if( $object == "user") { User::signals()->emit( "fetched", "user", $results[0]["id"] ); } } public static function updateUser( $id ) { $db = ezcDbInstance::get(); // ... $st->execute(); User::signals()->emit( "updated", "user", $id ); } The emitted signal describes what just has happened. E.g. There is a user updated with ID number $id. This signal can be used not only for the cache manager but also for e.g. logging. The *User::signals()* method returns an ezcSignalCollection that belongs to the User objects. A signal is sent everytime a user is read or changed. The *signals* method can be implemented as follows:: public static function signals() { if( self::$signals == null ) { self::$signals = new ezcSignalCollection( __CLASS__ ); } return self::$signals; } The next step is to connect the signals to the cache manager. The connection should be done at a place before the Template is processed. For example in the *index.php* file. Creating the connections can be done like:: $tc = ezcTemplateConfiguration::getInstance(); User::signals()->connect( "fetched", array( $tc->cacheManager, "register" ) ); User::signals()->connect( "updated", array( $tc->cacheManager, "update" ) ); The signal *fetched* from the *User* object is connected to the *register* method from the cache manager. And the *update* signal is connected to the *update* method from the cache manager. Including templates ``````````````````` Assume there are two templates: A and B. Template A is cached and includes template B. Below is the code of template A: :: {cache_template} {include "B"} Template B prints only: :: Hello world After template A is executed a cache file is created. This cache file contains the same data as template B. Everything will work fine, until the developer changes template B. Template B is altered to: :: Goodbye world Template A uses the cache and therefore the modification of template B is not checked. Template A will still print "Hello world". The cache manager can solve the issue described above with the cost of some overhead. The cache manager implemented in the section `Database fetch`_ should be modified at three points: 1. The method *includeTemplate* should be implemented. The *includeTemplate* is called everytime a cached template includes another template. The following code stores the include template in the *cache_values* table. :: public function includeTemplate( $template, $templatePath ) { if ( $this->depth >= 0 ) { $db = ezcDbInstance::get(); $id = $this->keys[$this->depth]["cache_id"]; $q = $db->prepare( "REPLACE INTO cache_values VALUES(:id, :name, :value)" ); $q->bindValue( ":id", $id ); $q->bindValue( ":name", "include" ); $q->bindValue( ":value", $templatePath ); $q->execute(); } } 2. The *startCaching* method should also store the template currently processed. The following code should be added in the body of the 'else' statement: :: $q = $db->prepare( "REPLACE INTO cache_values VALUES(:id, :name, :value)" ); $q->bindValue( ":id", $id ); $q->bindValue( ":name", "include" ); $q->bindValue( ":value", $templatePath ); $q->execute(); The current template includes 'itself'. This makes it easier to expire the cache. 3. The *isValid* method should be extended that it also checks all the modification times of the included cache files: :: $q = $db->prepare( "SELECT * FROM cache_values WHERE name = 'include' AND cache_id = :id" ); $q->bindValue( ":id", $r[0]["id"] ); $q->execute(); $r = $q->fetchAll(); foreach ( $r as $a ) { if ( filemtime( $a["value"] ) > filemtime( $cacheName ) ) { return false; } } return true; The code retrieves all the included cache files and checks if an included cache file is newer than the requested cache file. The complete code of the include mechanism is documented in the cache manager interface. Translations ============ With the `tr_context`_ and tr_ template constructs you can add translatable strings to you application. For them to work you have to take a few steps. First of all, you need to make sure that you have the TemplateTranslationTiein and Translation_ components installed as well. The TranslationTemplate component provides the glue between the Template component and the Translation component. Then you have to configure the template system with the correct configuration for translations:: translation = ezcTemplateTranslationConfiguration::getInstance(); // Create a translation manager, and assign it to the template translation // configuration $backend = new ezcTranslationTsBackend( dirname( __FILE__ ). '/translations' ); $backend->setOptions( array( 'format' => '[LOCALE].xml' ) ); $manager = new ezcTranslationManager( $backend ); $tc->translation->manager = $manager; // Set the locale to use $tc->translation->locale = $locale; ?> .. _Translation: introduction_Translation.html More information on how to configure the ezcTranslationManager can be found in the documentation of the Translation_ component. Of course, the template configuration can also be made through `Lazy initialization`_. After the template system knows about the translations, it will use the Translation component's mechanism to fetch translations. More information ================ For more information, see the: * `Template functions`_ * `EBNF`_ * `API documentation`_ .. _`Template functions`: ../Template/functions.html .. _`EBNF`: ../Template/EBNF.html .. _`API documentation`: ../Template/phpdoc/classtrees.html .. Local Variables: mode: rst fill-column: 79 End: vim: et syn=rst tw=79
{$nr}