This API is the PHP compiler for ViewLanguage, a markup language that acts like an extension of HTML standard, designed to completely eliminate the need for scripting in views. Latter performs its templating goals by:
The entire logic of this API is "bootstrapped" by ViewLanguageParser class. As far as developers are concerned, this is likely the only relevant section since everything else are classes it depends on. It performs its job in two steps:
All classes inside API belong to namespace Lucinda\Templating.
Compilation involves following steps:
The output of compilation is a PHP file that represents your whole aggregate view ready to be displayed. From that point on it is client's task to decide what to do next (typically require compilation file to complete output).
Because compilation is somewhat performance hungry, results are cached on disk and returned directly on next requests unless one of its components (template or tag) has changed. This makes View Language 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!
Thanks to its flexibility, ViewLanguageAPI can be used for obtain something similar to template inheritance while at the same time obeying its inception paradigm of working like an extension of HTML. Unlike other templating engines you cannot "extend" views, but you can dynamically load them via a recipe-ingredients principle. This works in a way similar to dependency injection: instead of EXTENSION (which brings up rigidity to the structure) you opt for INJECTION (which makes constituent structures light and maintainable). This way, an item can "inherit" many behaviors, which is actually a fundamental requirement in HTML templating.
Let's say for example you have an HTML application where every page shares a common header and footer while at the same time holding a body component that is page-specific. In that case, every view of that page should just present the recipe via a tag that glues constituents then add attributes that identify custom components. Homepage, for example, will only present a recipe:
<site:page body="site:homepage" ... />
whose tag body is:
<site:header .../> <$[body] .../> <site:footer .../>
where $[body] on compilation will be replaced with site:homepage, whose tag body contains templating part specific to homepage.
Since compilation is recursive, the same "inheritance" principles can apply at infinite levels. You can have pages that contain MULTIPLE recipe tags, themselves composed of fixed (like site:header tag above) and mobile(like site:homepage tag above) tags, themselves pointing to recipes or implementations.
To learn how to install and use this API, follow this step-by-step guide!