Template Engine Latte

[d'Hinnisdaël]

Add support for the Latte templating language to the Template Engine Factory.

Available on the module directory and on GitHub. The latest version uses Latte v3.

 

Configuration

The module offers the usual the following configuration:

Template files suffix
The suffix of the Latte template files, defaults to latte.

Default layout file
Layout that all views will extend from unless overwritten.

Provide ProcessWire API variables in Latte templates
API variables ($pages, $input, $config...) are accessible in Latte, e.g. {$config} for the config API variable.

Simplified path resolution
Enable Blade-style dot syntax for directory traversal, e.g. 
partials.navigation instead of ../../partials/navigation.latte

Auto refresh templates (recompile)
Recompile templates whenever the source code changes.

[artfulrobot]

Hi @d'Hinnisdaël

This looks interesting, thanks for posting. By the way, both the Getting Started link (to an #anchor) and the Documentation link (404: https://raw.githubusercontent.com/wanze/TemplateEngineFactory/v1.1.3/DOCUMENTATION.md) are broken at https://processwire.com/modules/template-engine-factory/

 

[d'Hinnisdaël]

@artfulrobot Great catch. Could you repost this in the support thread of the main TemplateEngineFactory module? I have no control over either that module or its repository; I merely created an integration for it adding support for the Latte language.

[artfulrobot]

@d'Hinnisdaël done, sorry for barking up the wrong tree!

 

[maetmar]

Does someone have a working example of using LATTE to parse through a Repeater Matrix (pro fields)?

Similar like here: https://processwire.com/blog/posts/more-repeaters-repeater-matrix-and-new-field-rendering/ just using LATTE files instead of PHP

[d'Hinnisdaël]

@maetmar When rendering templates using Latte, I've found the built-in field rendering a bit cumbersome to set up since you'll need an intermediary PHP file to render the Latte view from.

The straight-forward version would be using a loop and including a file based on the matrix type. This will look for a view partial at site/templates/views/partials/blocks/image.latte, when rendering a matrix page of the type "image" in a matrix field named "blocks":

{foreach $page->blocks as $block}
    <div class="block" data-block="{$block->type}">
        {include 'partials.blocks.' . $block->type, block => $block}
    </div>
{/foreach}

 

[maetmar]

thanks, it works that way!

One more thing, I found to get this warning due to PHP 8.2:

Deprecated: Using ${var} in strings is deprecated, use {$var} instead in /usr/www/users/xxxxxxxxxx/site/modules/TemplateEngineLatte/src/TemplateEngineLatte.php on line 139

[d'Hinnisdaël]

Thanks for reporting the issue; I've pushed a fix as 1.0.6. Updating the composer package should fix it:

composer update daun/template-engine-latte

[d'Hinnisdaël]

I've upgraded the module to work with Latte v3. Note that this is a potential breaking change if you're defining custom macros and might require code changes on your end. Learn more about the migration to Latte 3 and upgrading macros to tags.

To upgrade:

composer require daun/template-engine-latte:^2.0

[cwsoft]

@d'HinnisdaëlThanks for keeping the module updated. Latte rocks.

[maetmar]

In my templates I normaly call a _init.php file as prepend to initialize / set some variables, etc.

However, as soon as I activate "Enalobe automatic page rendering" in the "Template Engine Factory" Module, this _init.php seems to be nor longer called and therefore my default setting values are undefined and can not be used.

Any Idea how to fix this behaviour?

If I disable this feature, the system still calls my "standard.php" file including the _init.php call upfront. So maybe I could just load the latte template from within standard.php ? But I donßt know how to call it properly. 

thanks for any help

[d'Hinnisdaël]

@maetmar It's probably best to ask this in the dedicated forum topic for the TemplateEngineFactory module. The Latte engine has no influence on this behavior, it merely renders the output.

For what it's worth, I have that option enabled and my _init.php is being called normally, so it might be something else.

[maetmar]

will do so.

but could you give me a working example of how to call and render standard.latte from within standard.php?

would be great

 

[d'Hinnisdaël]

@maetmar You don't need to call or render anything. That's basically what TemplateEngineFactory does for you behind the scenes. For every template.php, it will look for a corresponding view file, e.g. template.latte or template.twig. Looking at the module again, for that to happen, you need the mentioned option enabled: Enable automatic page rendering. Why this would interfer with your prepended _init.php, I don't know and is something to debug.

[kp52]

I've been using TemplateLatteReplace for quite a while, and have been experimenting a bit with TemplateEngineLatte as a way to move on to Latte 3. I've found it easy to get on with, and will be trying out transplantation of a complete site. I'm not very familiar with the more sophisticated aspects of current versions of PHP, so I find it quite challenging to track down the causes of errors that come up when I just plug in my existing Latte templates. I've fixed a couple of hiccups, though:

Since I prefer to have fewer templates and files, I often link various Processwire templates to the basic-page.php file, with a switch structure to select the required handling. TemplateLatteReplace allows me to link to the necessary Latte template via $view->viewFile, e.g.

	case $page->name == 'diary': 
		$view->viewFile = 'diary.latte';

More by guesswork than analysis, I found I can have the same functionality in TemplateEngineLatte with $view->template:

	case $page->name == 'diary': 
		$view->template = 'diary.latte';

Is that a safe thing to do?

I have a few custom filters defined in _init.php in TemplateLatteReplace via $view->addFilter(). I found the equivalent hook-based method in the TemplateEngineLatte docs, and tried it with one of my filters:

wire()->addHookAfter('TemplateEngineLatte::initLatte', function (HookEvent $event) {
    /** @var Latte\Engine */
    $latte = $event->arguments('latte');
    $compiler = $latte->getCompiler();

    // Add filter for compound dates & formats
	$latte->addFilter('e_dates', function($day, $last, $format) {
...

This causes an error: Call to undefined method Latte\Engine::getCompiler()

The filter definition works fine when I comment out the "$compiler = " line. Presumably it's there for a purpose. What would be the respectable way to avoid the error?

KP

[d'Hinnisdaël]

1 hour ago, kp52 said:

Since I prefer to have fewer templates and files, I often link various Processwire templates to the basic-page.php file, with a switch structure to select the required handling. TemplateLatteReplace allows me to link to the necessary Latte template via $view->viewFile, e.g.

	case $page->name == 'diary': 
		$view->viewFile = 'diary.latte';

More by guesswork than analysis, I found I can have the same functionality in TemplateEngineLatte with $view->template:

	case $page->name == 'diary': 
		$view->template = 'diary.latte';

Is that a safe thing to do?

I have a few custom filters defined in _init.php in TemplateLatteReplace via $view->addFilter(). I found the equivalent hook-based method in the TemplateEngineLatte docs, and tried it with one of my filters:

wire()->addHookAfter('TemplateEngineLatte::initLatte', function (HookEvent $event) {
    /** @var Latte\Engine */
    $latte = $event->arguments('latte');
    $compiler = $latte->getCompiler();

    // Add filter for compound dates & formats
	$latte->addFilter('e_dates', function($day, $last, $format) {
...

This causes an error: Call to undefined method Latte\Engine::getCompiler()

The filter definition works fine when I comment out the "$compiler = " line. Presumably it's there for a purpose. What would be the respectable way to avoid the error?

KP

Setting $view->template is perfectly safe, it's currently undocumented but that's how I'm using it in every project so it's not going anywhere.

Uncommenting the $compiler line is fine as well — required, actually. The line was left over from the previous version but only works with Latte 2. In Latte 3, that line will cause an error. I'll take a note to remove that line in the current version to avoid tripping people up.

[da²]

Hello,

Maybe I will consider using Latte in the future. I love Twig but I have 2 problems with it:

1. This two issues I'm reporting on this page, the second one is the worse because you can write a working code that will break in the future because a field value has became blank. I could use object.get('prop') everywhere but that's ugly and boring to type.
2. The fact that it tries to interpret your property/method calls (maybe it can be disabled, I never searched), for example if I write object.method() and it's not found, it will also try object.getMethod(), object.method, and so on... So you can let typo in your code without knowing it if Twig found something else. On my custom page classes I can have a property prop (the PW field) AND a method getProp() (my own function that does more than prop) and they are not interchangeable even if they return same type of value.

Could you tell me if Latte is doing the same 2 things?

In terms of performance I didn't find benchmarks with latest version of both engines but I suppose they are close.

I'm not sure yet what I'll use in my next project, I'm also interested exploring my own full-PHP method to get the best performances but that must be a clean solution, easy to read/update/reuse.

[d'Hinnisdaël]

@da² Latte doesn't have those issues since Latte code is compiled directly to PHP. There's no magic methods and no funky business with dynamic properties. Everything should work as you would expect it to work in a plain PHP file. There's a short but relevant section in their docs on using PHP in Latte files.

I've never seen a project where Latte was a performance bottleneck — it's compiled to PHP and cached, so it should be just as fast as a normal PHP file. Usually, it's the amount of database queries and lack of granular caching that slows a site down. If the template engine is the biggest contributor to load times, you probably have a pretty fast site already 🙂

[d'Hinnisdaël]

@da² There's an official Twig-2-Latte converter that's really useful if you aim to compare both engines side-by-side. You can try it out online as well.

[da²]

14 hours ago, d'Hinnisdaël said:

Latte doesn't have those issues since Latte code is compiled directly to PHP. There's no magic methods and no funky business with dynamic properties. Everything should work as you would expect it to work in a plain PHP file. There's a short but relevant section in their docs on using PHP in Latte files.

Twig also is compiled to PHP, it's PHP code that interprets your method/property calls and fails on some PW properties for an obscure reason.

Reading your link, the first talk is about this sh*t Twig interpretation. 😄

Quote

Twig uses dot syntax, where {{ a.b }} can mean $a->b, $a['b'] or $a->getB()

So at least this ugly behavior is not part of Latte. 👍

 

EDIT : Haha, and just now I'm searching something in my IDE and see an old Twig error log, showing how WIIIIIIIDE is this Twig interpretation:

Quote

Neither the property "renderer" nor one of the methods "renderer()", "getrenderer()"/"isrenderer()"/"hasrenderer()" or "__call()" exist...