Variables

Setting and displaying variables

By default, only a few helper variables are available to the template system (see below for built-in variables). All other variables must be explicitly passed to the template system before you can use them there.

In the MVC context variables are typically set in the controller and then displayed in the view. Here’s an example:

// default.ctl.php / main()
$this->zajlib->variable->red = "red";
$this->zajlib->variable->blue = "blue";
$this->zajlib->template->show('index.html');

<!-- index.html -->
<strong>Roses are {{red}}, violets are {{blue}}</strong>

Output: Roses are red, violets are blue

So as seen above $this->zajlib->variable->my_variable_name is the proper way of passing variables to the template view files. The scope of the variable object is global, so any template you show after setting a variable will have access to it during that request.

Built-in variables

There are a number of helpful variables which are made available to you automatically within the template system. These variables are the same as any other: you can use them as tag parameters, you can filter them, or you can just print them out. Here are a few examples:

{% if ofw.https %}Running in HTTPS mode{% endif %}
Here's the GET param for ?page: {{ofw.get.page}}
...though you should likely escape this to avoid malicious user input: {{ofw.get.page|escape:'html'}}

Here is a list of all variables available:

• baseurl: This is the root address of the project. Also available as {{baseurl}}.
• fullurl: The entire url, including baseurl + request.
• fullrequest: The entire request, including baseurl + request + query string.
• requestpath: This is the current request without baseurl or query string.
• debug or debug_mode: Set to true if the system is in debug mode.
• app: The currently running app (this is usually the active controller’s name).
• mode: The currently running mode (this is usually the active controller method’s name).
• get: An object with each GET request variable as a property. These need to be escaped when used to avoid XSS.
• post: An object with each POST request variable as a property. These need to be escaped when used to avoid XSS.
• cookie: An object with each COOKIE request variable as a property. These need to be escaped when used to avoid XSS.
• request: An object with each GET, POST, or COOKIE request variable as a property. These need to be escaped when used to avoid XSS.
• server: The PHP SERVER variables. Use as {{ofw.server.HTTP_HOST}} for example.
• protocol: The value will be http: or https:. The colon is added so you can use {{ofw.protocol}}{{ofw.baseurl}}
• host: The current HTTP_HOST, for example www.example.com.
• subdomain: The current subdomain, for example www.
• domain: The current subdomain, for example example.com.
• tld: The current top level domain, for example com.
• https: Returns true if in HTTPS mode.
• version: An object with Outlast Framework version information. Properties of ofw.version are: major (int), minor (int), beta (bool), installed (bool).
• variable: Returns a list of variables available.
• config: Returns config and lang variables. See more info on localization.
• mobile: Returns true if the current device was detected as a mobile (not entirely reliable).
• tablet: Returns true if the current device was detected as a tablet (not entirely reliable).
• device_mode: Returns the current device mode or false if no device mode was set yet.
• platform: Returns the name of the current platform.
• browser: Returns an object with all the properties describing current browser capabilities. See browser library for more info.
• referer: Returns the referer as in the SERVER variable.
• useragent: Returns the user agent as in the SERVER variable.
• now: Returns the current UNIX timestamp.
• locale: The currently selected locale.
• locale_all: All the locales available. Returned as an array.
• locale_default: The default locale.
• lang: The current language (two-letter code). DEPRECATED! You should use locale instead.
• plugin: A key/value pair object where each key is the name of the plugin and the value is a boolean on whether or not it is enabled. So {{ofw.plugin.user}} is true if the user plugin is enabled.
• js: The javascript init script required for the OFW framework js functionality.

Filtering variables

Filters provide a mechanism in which variable content can be modified slightly before display. Typical uses of filters would be to escape certain characters or to convert something to all lowercase. But many other uses exist.

Let’s quickly look at the syntax of filtering:

{{red|upper}}

Given the above example, the output would be:Roses are RED, violets are blue

You can also chain filters in which case they will be applied in order:

{{red|upper|substr:2}}

The above example’s output would change to: Roses are RE, violets are blue

Each filter can have a single input parameter, and those inputs can be numbers, strings, or variables themselves:

{{red|escape:'url'}}
{{red|substr:my_substr_number}}

These are less than useful examples, but Outlast Framework provides a number of built-in filters and also allows extending these with any number of custom filters so the possibilities are endless.

Configuration variables

Outlast Framework also supports config {{#variables#}}. Configuration variables work like any other variables: they can be filtered, used in tags, etc. The difference is that they stored in a separate, structured, easy to read ini file that can be loaded dynamically.

Check out the detailed documentation here.

Language variables

Among Outlast Framework’s many localization features, you can use language files to localize your app’s texts. Language variables work almost exactly like config variables, with just a few differences in how you load it up.

Check out the detailed documentation here.

Variable variables

Variable variables are available in PHP $var = 'asdf'; echo $$var;. This can also be used for variables in the OFW template system by using the keyvalue filter on {{ofw.variable}} which returns a list of all available template variables.

Here’s an example:

/** controller **/
$this->zajlib->variable->some_variable = 'Hello World!';
$this->zajlib->variable->my_lang_variable_name = 'some_variable';

<! template file >
{{ofw.variable|keyvalue:my_lang_variable_name}}

The template file above will result in the output “Hello world!”.

You can also use variable variables for language variables and config variables.

Automatic XSS protection

Template variable contents are automatically checked for cross site scripting (XSS) vulnerabilities. Variables are automatically purified to ensure HTML output is safe.

If you want to allow Javascript within particular template variables, you can use the |safe filter. This designates that the contents of the variable is to be trusted and can be displayed without XSS checks. See the filter documentation for more details. In addition you can also set the variable value to OfwSafeString class – simply set the variable to $this->ofw->variable->safe_variable = OfwSafeString($safe_html).

You can also purify the HTML content to make it safe using $safe_html = $this->zajlib->security->purify($html) (uses HTMLPurifier).

Important! Language and configuration variables are not checked. Using the safe filter on these will not have any effect.