lucinda/view-language

High performance templating API using tags & expressions inspired by Java JSTL and C Compiler

View Language API

Table of contents:, _(*1)

• About
  • Expressions
  • Tags
• Configuration
• Compilation
• Installation
• Unit Tests
• Examples
• Reference Guide

About

This API is the PHP compiler for ViewLanguage templating engine, a markup language inspired by JSP&JSTL @ Java that acts like an extension of HTML standard, designed to completely eliminate the need for scripting in views by:, _(*2)

• interfacing variables through expressions.
• interfacing logics (control structures, repeating html segments) through tags

, _(*3)

In order to achieve its goals, following steps need to be observed:, _(*4)

• configuration: setting up an XML file where templating is configured
• compilation: using Lucinda\Templating\Wrapper to read above XML and compile a template

API is fully PSR-4 compliant, only requiring PHP8.1+ interpreter and SimpleXML extension. To quickly see how it works, check:, _(*5)

• installation: describes how to install API on your computer, in light of steps above
• unit tests: API has 100% Unit Test coverage, using UnitTest API instead of PHPUnit for greater flexibility
• examples: shows an example how to template with ViewLanguage, including explanations for each step
• reference guide: shows list of tags that come with API

Expressions

An expression is a ViewLanguage representation of a scripting variable. Syntax for an expression is:, _(*6)

${variableName}

where variableName can be:, _(*7)

A very powerful feature is the ability to nest expressions: writing expressions whose key(s) are expressions themselves. This can go at any depth and it is very useful when iterating through more than one list and linking a one to another's key/value association:, _(*8)

Tags

A tag is a ViewLanguage representation of a scripting logic. All tags act like an extension of HTML standard and as such they have names and optionally attributes and bodies. There are two types of tags known by ViewLanguage:, _(*9)

• macro tags: api-defined tags to be processed before content is compiled.
• library tags: api/user-defined tags subject to compilation that belong to a library and have an unique name within that library.

A very powerful feature is the ability of tags to be recursive: it is allowed to put View Language tags inside View Language tags. Whenever that happens, compiler goes progressively deeper until no tags are left!, _(*10)

Macro Tags

Macro tags work in a way similar to C macros: before code is compiled, they are read and "expanded" so that compilation will run on a full source. Syntax is identical to that of normal HTML tags:, _(*11)

<NAME ATTRIBUTE="value" .../>

Where:, _(*12)

• NAME: name of tag that performs a single logical operation.
• ATTRIBUTE: configures tag behavior

API defines following macro tags:, _(*13)

• escape: tag whose body will be ignored by compiler. This is necessary to mark content inside as not subject to parsing.
• import: tag whose declaration will be replaced by compiler with the body of file pointed by its "file" attribute. This is crucial for layouting/templating.
• namespace: tag whose declaration will inform compiler where to look for tag libraries not found in default folder.

At the moment, it is not possible for users to define their own macro tags!, _(*14)

Library Tags

Library tags are compilable api/user-defined HTML snippets expected to implement scripting logic in a View Language application. They are non-static repeating snippets of template (html) code that depend on variables and thus can't be loaded using ., _(*15)

Their syntax extends HTML standard:, _(*16)

<LIBRARY:TAG ATTRIBUTE="value" ...>...</LIBRARY:TAG>

or, if they have no body:, _(*17)

<LIBRARY:TAG ATTRIBUTE="value" .../>

Where: - LIBRARY: namespace that contains related logical operations to perform on a template. Rules: - Value must be lowercase and alphanumeric. - "-" sign is allowed as well to replace spaces in multi-word values - TAG: name of tag that performs a single logical operation.Rules: - Value must be lowercase and alphanumeric. - sign is allowed as well to replace spaces in multi-word values - ATTRIBUTE: configures tag behavior (can be zero or more). Rules: - Name must be lowercase and alphanumeric. - "_" sign is allowed as well to replace spaces in multi-word names - Value can only be primitive (string or number) or ViewLanguage expressions. - Unlike standard HTML, attributes cannot be multilined currently., _(*18)

Standard Tags

API includes a standard library containing tags for programming language instructions where LIBRARY is empty:, _(*19)

• :for: iterates numerically through a list
• :foreach: iterates through a dictionary by key and value
• :if: evaluates body fitting condition
• :elseif: evaluates body fitting condition that did not met previous if/elseif.
• :else: evaluates body that did not met previous if/else if
• :set: creates a variable and/or sets a value for it.
• :unset: unsets a variable.
• :while: performs a loop on condition.
• :break: ends loop.
• :continue: skips evaluating the rest of current loop and moves to next iteration.

Standard tags work with ATTRIBUTE values of following types: - scalars: strings or integers - EXPRESSION: ViewLanguage expressions. If helper functions are used as attribute values, they must be left undecorated: count(${asd}) instead of ${count(${asd})}. - CONDITION: syntax is expected to be C-like, but ultimately matches that of language code is compiled into (in our case, PHP). Example: ${x}==true means in PHP $x==true., _(*20)

User Defined Tags

In order to break up HTML response into discrete units, developers must create their own libraries & tags. User defined tags are found on disk according to these rules:, _(*21)

• library name must be a folder inside tags folder supplied on compilation
• tag code muse be a HTML file inside library folder whose name equals name

Configuration

To configure this API you must have a XML with a templating tag inside:, _(*22)

<templating compilations_path="..." tags_path="..." templates_path="..." templates_extension="..." />

Where:, _(*23)

• compilations_path: (mandatory) path into which PHP compilations of ViewLanguage templates are saved
• tags_path: (optional) path into which ViewLanguage tag libraries are located
• templates_path: (optional) path into which templates are located
• templates_extension: (optional) template files extension. If not set, "html" is assumed!

Example:, _(*24)

<templating compilations_path="compilations" tags_path="application/taglib" templates_path="application/views" templates_extension="html"/>

Compilation

Once you have completed step above, you need to instantiate Lucinda\Templating\Wrapper in order to be able to compile templates later on:, _(*25)

$wrapper = new Lucinda\SQL\Wrapper(simplexml_load_file(XML_FILE_NAME));

Object has following method that can be used to compile one or more templates:, _(*26)

How are templates compiled?

As in any other templating language, compilation first traverses the tree of dependencies ever deeper and assembles result into a PHP file then produces an HTML by binding it to data received by user. It thus involves following steps:, _(*27)

• if a PHP compilation for $template argument exists, checks if elements referenced inside have changed since it was last updated. If it doesn't exist or it changed:
  • parses tags recursively (backing-up tag bodies in compilation file to be excluded from parsing) and appends results to compilation file
  • parses tags defined in templates, to know where to locate user-defined tag libraries not defined in default taglib folder
  • parses library tags recursively (backing-up tag bodies in compilation file to be excluded from parsing) and replaces them with relevant PHP/HTML code in compilation file.
  • parses expressions and replaces them with relevant PHP code in compilation file.
  • restores backed up tags bodies (if any) in compilation file
  • caches new compilation on disk along with a checksum of its parts (templates, tags) for future validations
• in output buffer, loads compilation file, binds it to $data supplied by user and produces a final HTML out of it

Since the whole process is somewhat performance hungry, PHP compilation files will be cached on disk and returned directly on next requests unless one of its components (template or tag) has changed. This makes API able to compile in around 0.001 sec amortised time, thus bringing no performance taxation whatsoever but all the advantages of an elegant view!, _(*28)

Installation

First choose a folder where API will be installed then write this command there using console:, _(*29)

composer require lucinda/view-language

Then create a configuration.xml file holding configuration settings (see configuration above) and a index.php file in project root with following code:, _(*30)

require(__DIR__."/vendor/autoload.php");
$wrapper = new Lucinda\SQL\Wrapper(simplexml_load_file("configuration.xml"));

To compile a template:, _(*31)

$html = $wrapper->compile(TEMPLATE_NAME, USER_DATA);

Where:, _(*32)

• TEMPLATE_NAME is the base template that must obey following rules:
  • must be a path to a file located in templates_path (see configuration)
  • file it points to must have templates_extension (see configuration)
  • because of above, must not include extension
• USER_DATA is a list of values from back-end to be accessed in template, obeying following rules:
  • must be an array
  • entry keys must be strings or integers (the usual PHP requirements)
  • entry values must be scalars or arrays
  • if array is multidimensional, keys and values in siblings must obey same rules as above

To display results:, _(*33)

header("Content-Type: text/html; charset=UTF-8");
echo $html;

Unit Tests

For tests and examples, check following files/folders in API sources:, _(*34)

• unit-tests.sql: SQL commands you need to run ONCE on server (assuming MySQL) before unit tests execution
• test.php: runs unit tests in console
• unit-tests.xml: sets up unit tests and mocks "sql" tag
• tests: unit tests for classes from src folder

Examples

Assuming configuration.xml (see configuration and installation) is:, _(*35)

```xml , <sub>(*36)</sub>

Let's create a *application/views/index.html* template with following body:

```html
<import file="header"/>
Hello, dear ${data.author}! Author of:
<ul>
    <:foreach var="${data.apis}" key="name" val="url">
    <my:api id="${name}" link="${url}"/>
    </:foreach>
</ul>
<import file="footer"/>

What above does is:, <sub>(*37)</sub>

• loads body of a application/views/header.html template
• echoes value of author array key of $data via expressions
• loops through value of apis array key of $data via <:foreach>
• on every iteration, loads body of application/taglib/my/api.html template (user tag), binding attributes to values
• loads body of a application/views/footer.html template

Contents of application/views/header.html file:, <sub>(*38)</sub>

<html>
    <head>
        <title>View Language API Tutorial</title>
    </head>
    <body>

Contents of application/taglib/my/api.html file:, <sub>(*39)</sub>

<li><a href="$[id]">$[link]</a></li>

Contents of application/views/footer.html:, <sub>(*40)</sub>

    </body>
</html/>

As one can see above, templates depend on variables to be received from back-end (author & apis), both keys of $data array. Assuming value of latter is:, <sub>(*41)</sub>

$data = [
    "author" => "Lucian Popescu", 
    "apis" => ["View Language API" => "https://www.lucinda-framework.com/view-language", "STDOUT MVC API" => "https://www.lucinda-framework.com/stdout-mvc"]
];

Now let's compile application/views/index.html template (see compilation) and bind it to $data:, <sub>(*42)</sub>

require(__DIR__."/vendor/autoload.php");
$wrapper = new Lucinda\SQL\Wrapper(simplexml_load_file("configuration.xml"));
$html = $wrapper->compile("index", $data);

First, ViewLanguage base template is compiled into PHP, results saved in a compilations/index.php file (in case it doesn't exist already) with following body:, <sub>(*43)</sub>

<html>
    <head>
        <title>View Language API Tutorial</title>
    </head>
    <body>
        Hello, <?php echo $data["author"]; ?>, author of:
        <ul>
            <?php foreach($data["apis"] as $name=>$url) { ?>
            <li><a href="<?php echo $url; ?>"><?php echo $name; ?></a></li>
            <?php } ?>
        </ul>
    </body>
</html/>

Then above file is loaded in output buffer and bound with $data, so the final HTML returned will be:, <sub>(*44)</sub>

<html>
    <head>
        <title>View Language API Tutorial</title>
    </head>
    <body>
        Hello, Lucian Popescu, author of:
        <ul>
            <li><a href="https://www.lucinda-framework.com/view-language">View Language API</a></li>
            <li><a href="https://www.lucinda-framework.com/stdout-mvc">STDOUT MVC API</a></li>
        </ul>
    </body>
</html/>

Reference Guide

tag escape

Marks tag body to be ignored by ViewLanguage compiler.Syntax:, <sub>(*45)</sub>

<escape>
...
</escape>

Examples how this tag is compiled into PHP:, <sub>(*46)</sub>

tag import

Includes another view language template into current one. Syntax:, <sub>(*47)</sub>

<import file="..."/>

Attributes:, <sub>(*48)</sub>

Examples how this tag is compiled into PHP:, <sub>(*49)</sub>

tag namespace

Marks custom location of user defined tag library (must be placed BEFORE latter declaration). Syntax:, <sub>(*50)</sub>

<namespace taglib="..." folder="..."/>

Attributes:, <sub>(*51)</sub>

Examples how this tag is compiled into PHP:, <sub>(*52)</sub>

tag :for

Creates a FOR loop. Syntax:, <sub>(*53)</sub>

<:for var="..." start="..." end="..." (step="...")>
    ...
</:for>

Attributes:, <sub>(*54)</sub>

Examples how this tag is compiled into PHP:, <sub>(*55)</sub>

tag :foreach

Creates a FOR EACH loop. Syntax:, <sub>(*56)</sub>

<:foreach var="..." (key="...") val="...">
    ...
</:foreach>

Attributes:, <sub>(*57)</sub>

Examples how this tag is compiled into PHP:, <sub>(*58)</sub>

tag :if

Creates an IF condition. Syntax:, <sub>(*59)</sub>

<:if test="...">
    ...
</:if>

Tag must not be closed if folowed by a :else or :elseif!, <sub>(*60)</sub>

Attributes:, <sub>(*61)</sub>

Examples how this tag is compiled into PHP:, <sub>(*62)</sub>

You can also run simple IF/ELSE statements from expressions using ternary operators!, <sub>(*63)</sub>

tag :elseif

Creates an ELSE IF condition. Syntax:, <sub>(*64)</sub>

<:elseif test="...">
    ...
</:if>

Tag must not be closed if folowed by a :else or :elseif!, <sub>(*65)</sub>

Attributes:, <sub>(*66)</sub>

Examples how this tag is compiled into PHP:, <sub>(*67)</sub>

tag :else

Creates an ELSE condition. Syntax:, <sub>(*68)</sub>

<:else>
    ...
</:if>

Examples how this tag is compiled into PHP:, <sub>(*69)</sub>

tag :set

Sets a value to a variable.Syntax:, <sub>(*70)</sub>

<:set var="..." val="..."/>

Attributes:, <sub>(*71)</sub>

Examples how this tag is compiled into PHP:, <sub>(*72)</sub>

tag :unset

Removes variable from memory. Syntax:, <sub>(*73)</sub>

<:unset var="..."/>

Attributes:, <sub>(*74)</sub>

Examples how this tag is compiled into PHP:, <sub>(*75)</sub>

tag :while

Creates a WHILE loop. Syntax:, <sub>(*76)</sub>

<:while test="...">
    ...
</:while>

Attributes:, <sub>(*77)</sub>

Examples how this tag is compiled into PHP:, <sub>(*78)</sub>

tag :break

Breaks a FOR/FOR EACH/WHILE statement loop. Syntax:, <sub>(*79)</sub>

<:break/>

Examples how this tag is compiled into PHP:, <sub>(*80)</sub>

tag :continue

Continues to next step within a FOR/FOR EACH/WHILE statement loop. Syntax:, <sub>(*81)</sub>

<:continue/>

Examples how this tag is compiled into PHP:, <sub>(*82)</sub>