Questions and syntax LATTE (Template Engine by Nette)

[sebibu]

I really love LATTE (Template Engine by Nette) but here and there I still have problems with the syntax.

I'm using RockPageBuilder by @bernhard and try to output the html for this module:
https://processwire.com/modules/fieldtype-leaflet-map-marker/

In PHP this would be:

<?php echo $map->render($page, 'YOUR MARKER FIELD'); ?>

And in LATTE? 😆 I tried this variants and more:

{$map->render($page, 'map')}
{$map->render($page, 'block->map')}
{$map->render($page, $block->map)}

Getting: Call to a member function render() on null in block #1158 (rockpagebuilderblock-map)

Maybe this topic can be a collection point for smaller Latte syntax questions.

[bernhard]

This

<?php echo $map->render($page, 'YOUR MARKER FIELD'); ?>

would be this

{$map->render($page, 'YOUR MARKER FIELD')}

Your error message means, that $map is NULL. That means $map is not available in your latte file for whatever reason. That means you are not struggling with latte syntax, you are struggling with PHP 😉 😛 

You can easily debug this via TracyDebugger:

{bd($map)}
{bd($page)}

To help you with your specific problem I'd need more info in where you are trying to use this markup...

[MrSnoozles]

It looks like you need to make $map available in your Latte file first. Then, as Bernhad has said, you could write in your Latte file

{$map->render($page, 'YOUR MARKER FIELD')}

With https://processwire.com/modules/template-engine-latte/ you would write something like the following in your PHP template file (or ready.php):

$view->set('map', $map);

It might vary depending on which modules you use exactly in your project.

Edited Friday at 08:17 AM by MrSnoozles

[bernhard]

6 hours ago, MrSnoozles said:

$views->set('map', $map);

RockFrontend / Latte doesn't provide this syntax as far as I know. What are you referring to?

6 hours ago, sebibu said:

https://processwire.com/modules/fieldtype-leaflet-map-marker/

Ah sorry, now I see $map should be a map marker object. The docs there state this:

<?php $map = wire('modules')->get('MarkupLeafletMap'); ?>

Which you could do in latte like this:

{var $map = $modules->get('MarkupLeafletMap')}

 

[MrSnoozles]

1 minute ago, bernhard said:

What are you referring to?

Updated the post to be clear it's an example and varies depending on which modules are used.

[sebibu]

Thanks for your help!

Trying..

{var $map = wire('modules')->get('MarkupLeafletMap')}
{$map->render($page, 'map')}

..in RockPageBuilder block LATTE-file I get: Call to undefined function wire() in block

Trying..

{var $map = $this->$wire('modules')->get('MarkupLeafletMap')}
{$map->render($page, 'map')}

.. I get: Method name must be a string in block

Now I'm confused. 😆 What I'm doing wrong?

[bernhard]

Sorry, wire() is not available in a latte file, because wire() is actually \ProcessWire\wire with the namespace. In PHP files where you have "namespace ProcessWire" at the top just adding wire() will work.

In latte it is a different story, because the latte file has no namespace and it will be compiled. Therefore "wire()" is not available.

But all ProcessWire API variables are, so please just use $wire instead of wire().

Pro-Tip: From any API variable you can access the wire object via ->wire, so this would also work: $block->wire->... or $config->wire->... etc.; So in hooks you might see $event->wire->... and that's the reason for this.

PS: $block is not an API variable but is available in RockPageBuilder blocks! And as it is also extending "wire" it will also have its methods.

Edit: I've just updated the example above and realised that it was using wire('modules') syntax that I'm never using. In that case you need to use $wire->modules->... or simply use $modules->... as $modules is also an API variable and therefore directly available.

[FireWire]

I came back to the thread to share some experiences and they are very similar to what @sebibu is running into. Latte introduces a lot of challenges with scoping and augments how you interact with ProcessWire. This is most pronounced for me when working with different inheritance types provided by Latte.

When working with `include` there is no scope so anything that is added using {include 'file_name.latte'} will have access to the parent variables. This includes $page and $wire. Unfortunately the limitations with Latte is that you can't define blocks inside them, they only take parameters in the {include} statement. This is fine for most applications, but if you have a reusable component, such as a modal where the markup for the modal stays the same but complex contents should be contained in that markup, it would best be served by using {embed} because you can define something like {block content}{/block}.

So while variables are available in primary template files, using all available features in Latte starts to lock out ProcessWire.

Files included using {embed} are isolated in scope, so anything you want/need available in that file must be passed as parameters or added as rendered content within a {block}stuff here{/block}. This can get laborious for developers that are used to having ProcessWire's global variables and functions available anywhere. From my experience, there are two options.

{embed 'file_to_embed.latte',
  page: $page,
  wire: $wire,
  foo: 'foo',
  bar: 'bar
}
{block content}waddap{/block}
{/embed}

You can choose to add parameters to an {embed} file that provide ProcessWire's API. I'm not entirely a fan of this because it feels laborious and if we're just going to have to pass the ProcessWire API into Latte components to overcome the limited scope, then it's just an extra step that ends up adding additional parameters passed to components all over your templates very repetitiously. I'm also used to working around the concept of only providing objects the specific data they are supposed to work with like best practices for dependency injection containers.

The second option is to add custom functions to Latte using a hook at runtime. This method allows you to declare functions that will be available globally within all types of Latte reusability methods. Here's an example of a hook file on my current project. I have a dedicated latte_functions_extension.php file where I can declare these in an organized way.

<?php

declare(strict_types=1);

namespace ProcessWire;

use Latte\Extension;

final class CustomLatteFunctions extends Extension
{
    public function getFunctions(): array
    {
        return [
            // Latte templating paths
            'definitions' => fn (string $file) => $this->createComponentPath('definitions', $file),
            'embeds' => fn (string $file) => $this->createComponentPath('embeds', $file),
            'imports' => fn (string $file) => $this->createComponentPath('imports', $file),
            'layout' => fn (string $file) => $this->createPath('layouts', $file),
            'partial' => fn (string $file) => $this->createPath('partials', $file),
            // Expose ModernismWeekSite.module.php as site()
            'site' => fn () => wire('modules')->get('ModernismWeekSite'),
            // Ensure that wire() is available in all components
            'wire' => fn (?string $property = null) => wire($property),
        ];
    }

    /**
     * Creates a path for including a component
     * @param  string $file Dot notation subdir and filename,
     * @return string
     */
    private function createComponentPath(string $componentSubdir, string $file): string
    {
        return $this->createPath("components/{$componentSubdir}", $file);
    }

    /**
     * Creates a component file path for a given filename does not require .latte suffix
     * @param  string $templatesSubdir Name of directory in /site/templates
     * @param  string $file            Name of .latte file that exists in the directory
     */
    private function createPath(string $templatesSubdir, string $file): string
    {
        !str_ends_with($file, '.latte') && $file = "{$file}.latte";

        return wire('config')->paths->templates . "{$templatesSubdir}/{$file}";
    }
}

$wire->addHookAfter(
    "RockFrontend::loadLatte",
    fn (HookEvent $e) => $e->return->addExtension(new CustomLatteFunctions),
);

I've defined a 'wire' function that will be available in every component with a parameter that allows you to use it like you would expect to such as 'wire('modules')'. I have a custom site module so I've exposed that as 'site()'. If you wanted to make it easier to work with modules in your templates and included files you could define a more terse 'modules' function:

<?php

final class CustomLatteFunctions extends Extension
{
    public function getFunctions(): array
    {
        return [
            // ...
            'modules' => fn (string $moduleName) => wire('modules')->get($moduleName),
        ];
    }
}

I feel that there is a tradeoff when using Latte in ProcessWire. There are some great features in Latte, but it requires introducing abstractions and feature management to make Latte act like ProcessWire, like manually defining functions. This just means that you'll have to keep a balance of complexity/abstraction vs. using as minimal enough of a approach to keep it sane.

The other challenge here is that now there can be a deviation between where the native ProcessWire API is used in Latte and other places where it isn't. So some files will use $modules, and other files will use modules(), and it's not clear whether that's referencing the ProcessWire functions API, or whether it's leveraging Latte's custom functions extension feature. Something to keep in mind when determining how other files will be included/rendered in other files.

In my case I have two examples that brought this challenge out for me today. Here's one

// Native behavior provided by the module
// Does not work everywhere due to scoping in Latte. This caused an issue when trying to embed forms
// in a modal within a {block}
{$htmxForms->render($page->field_name)}

// With one level of abstraction using a custom function
// Because this replicates how ProcessWire provides the wire() function natively, the usage feels
// natural and predictable, especially for core behavior, but this introduces a lot of verbosity
// that starts to make files pretty messy
{wire('modules')->get('FormBuilderHtmx')->render($page->field_name)}

// With two levels of abstraction in Latte via a custom function
// This looks better and still adheres to the syntax of the ProcessWire functions API
// The issue is that every native ProcessWire function has to be manually replicated in our custom
// functions hook class. Managing this in the long term requires extra work and cognitive load
{modules('FormBuilderHtmx')->render($page->field_name)}

// With 3 levels of abstraction
// This has restored the feel of the variables provided by the module, but again we have to track
// And implement them on an as-needed basis to manage them within the context of usage in Latte
{htmxForms()->render($page->fieldName)}

The level of abstraction you choose depends on how much customization you want vs. how much extra work it will take to maintain simplicity by hiding complexity.

The other functions, 'embeds', 'definitions', 'imports', etc. are to overcome the relative paths all over the place in Latte.

// In my home.latte file
{layout './layouts/main.latte')}
{var $collapseNavOnScroll = true}
{import './components/definitions/headlines.latte'}
{import './components/definitions/event_activity_card.latte')}
{block subnav}
  {embed './components/embeds/event_subnav.latte', eventPage: $page->eventPage()}{/embed}
{/block}
// ...etc

// Becomes
{layout layout('main')}
{var $collapseNavOnScroll = true}
{import definitions('headlines')}
{import definitions('event_activity_card')}
{block subnav}
  {embed embeds('event_subnav'), eventPage: $page->eventPage()}{/embed}
{/block}
// etc.

// In RPB blocks
{embed '../../../components/embeds/example.latte', content: $block->body()}{/embed}

{embed embeds('example'), content: $block->body()}{/embed}

This really helps when working with Latte templates that embed components that have nested embeds and imports because the functions are generating absolute paths that Latte can handle. With these functions, I don't have to think about relative paths anywhere.

As for the directory structure that I chose that requires the different paths, here's what it looks like:

/templates
  ...etc
  /components
    /definitions
    /embeds
    /imports
    ...etc

I chose that method because Latte has many different ways of including, embedding, and importing code from other files. It made more sense to organize my code by how Latte treats it. It wasn't my first choice, but this overcomes confusion that I was experiencing when working with all of the files sharing the same components directory.

Without this type of organization it can be challenging to because of scoping and how {embed}, {include}, {define}, and {import} behave differently. Some accept parameters, export values, or use blocks, but not all of them do. So having a "modal.latte" component file that provides a {block content}{/block} next to 'button.latte' that doesn't render anything and only exports items created using {define}, next to a file that is only added to a template using {include} that doesn't take parameters or provide blocks had me jumping between files a lot and slows down development checking to see that the file is being used correctly.

Just sharing some of my experiences in case it helps anyone else out.

If anyone sees anything here that can be done better or if I'm missing out on features that Latte has that don't require some extra steps, let me know!

[FireWire]

Importing definitions are also not working for me. I have this defined:

When attempting to use it:

 

I've confirmed that the path is correct, so it's seeing the file, but attempting to create simple elements using {define} and then using them with {import} fails.

What am I doing wrong?

 

[bernhard]

Hey @FireWire sorry to hear that you are having troubles.

It seems that you are doing some quite complex stuff. I've never experienced any of these problems - maybe because I keep things very simple!

12 hours ago, FireWire said:

If anyone sees anything here that can be done better or if I'm missing out on features that Latte has that don't require some extra steps, let me know!

What is "better" is a very subjective thing, but there are two things I want to mention upfront:

12 hours ago, FireWire said:

{embed 'file_to_embed.latte',
  page: $page,
  wire: $wire,
  foo: 'foo',
  bar: 'bar
}

Instead of listing all API variables you can just pass the $wire variable and then access anything you need in your template from there:

// if you passed the wire variable you can do this:
{$wire->pages->find(...)}
{$wire->modules->get(...)}
{$wire->...}

// if you passed "page: $page" do this
{$page->wire->pages->find(...)}

// or this
{var $wire = $page->wire}
{$wire->pages->find(...)}

I guess I don't have these problems because I'm always working with custom page classes, so I most of the time add those things to the pageclass and then I can just use $page->myMethod(). That has the benefit that template files stay very simple and I have all the logic in PHP and not in Latte, which has a ton of benefits. For example you can do this for debugging:

// in site/ready.php
bd(wire()->pages->get(123)->myMethod());

Or you could access ->myMethod from anywhere else, like in a cronjob etc. If you have your business logic in latte then you have to refactor at some point or you are violating the DRY concept if you are lazy and just copy that part of your logic from the latte file to the cronjob.

10 hours ago, FireWire said:

I'm not sure I can follow... I put this in whatever.latte:

  {block foo}
    <h1>Hello World</h1>
  {/block}

  {define bar}
    <h1>Hello World</h1>
  {/define}

  {include foo}
  {include bar}

And I get 3 times "Hello World" as expected. {block} does immediately render while {define} waits for the final include

Also I don't know why you make things "complicated". When I need a reusable portion of code like for a button, I simply put that into /site/templates/partials/my-button.latte and then I use {include ../partials/my-button.latte} in my latte file.

I'm usually always either in /site/templates/sections or in /site/templates/partials. That's it.

Sections are full width elements, like hero, slider, breadcrumbs, main, footer, etc. and partials are things like buttons, cards, etc.

Having said that I see that there might be potential to improve the experience though. For example we might make the functions api available to all latte layout files or we might make API variables always available. But to make that happen I'd need some easy to follow real world examples and not complex code examples like your specific setup.

Also I'm hesitant as I didn't experience any of these "problems" for maybe two years or so. So we have to identify the real problem first. Maybe the problem is only lack of documentation for example.

[FireWire]

@bernhard I get that there are easier ways of doing things. My challenges arose when trying to use Latte according to the documentation because keeping things simple started causing problems.

I started going off what the Latte docs say about these tags:

{layout}
{include}
{import}
{define}
{embed}

The biggest part for me is identifying what role a component of the design performs so that the code maintainable similar to the Latte docs. My example of the button follows the example use case from Latte to output simple elements. In my case I currently have 3 different kinds of buttons, probably will be more, that line up with how {define} works. Using {define} lets me organize these in one buttons.latte file and then import that file so any one or more of them can be used.

{* buttons.latte *}

{define button-primary, label, color: 'cerulean'}
  <button class="very-long tailwing-classes to-style this-button {$color === 'cerulean' ? 'bg-cerulean text-white'}{$color === 'strikemaster' ? 'bg-strikemaster text-white'} many-more-classes">
    {label|noescape}
  </button>
{/define}

{define button-secondary, label, color: 'cerulean'}
  <button class="very-long tailwing-classes to-style this-button bg-white {$color === 'cerulean' ? 'text-cerulean'}{$color === 'strikemaster' ? 'text-strikemaster'} many-more-classes">
    {label|noescape}
  </button>
{/define}

{define button-secondary, label, theme: 'light'}
  <button class="very-long tailwing-classes to-style this-button {$theme === 'dark' ? 'child-svg:fill-neutral-600 child-svg:hover:fill-neutral-800}{$theme ==='light' ? 'child-svg:fill-white/90 child-svg:hover:fill-white'} many-many-more-classes">
    {site()->renderIcon(
      name: 'material-design:close',
      title: __('Close'),
      description: __('Close this modal'))
    }
  </button>
{/define}



{*
	view.latte (simplified for example)
	This is where importing from an external file fails.
*}
{import definitions('buttons.latte');

{include button-primary, __('View Tickets')}

Other definitions are input elements like toggles and selects, Field outputs (like reusable containers specific from TinyMCE), and Headlines that contains multiple reusable headline styles. I have been struggling to figure out why my code doesn't work like the Latte documentation states for including everything from a file using {import}.

Using {define} makes a lot of sense in this project because these are simple elements that just output markup and managing them in one file makes life a lot easier.

Then there are modals, lightbox galleries, product cards, etc. I already have 32 separate components for including and embedding, and that number is growing very quickly. Some components are quite complex since they're implemented using AlpineJS (lots of JS). So for me the complexity is coming from the project requirements rather than overengineering.

4 hours ago, bernhard said:

But to make that happen I'd need some easy to follow real world examples and not complex code examples like your specific setup.

I think the examples below are good examples that are real world.

For example, I have 3 different types of modals thus far and there will be more, these are all perfectly suited for the {embed} method that introduces the scoping considerations I mentioned. Here's an example of one of the modals that really need the usefulness that {embed} provides.

{parameters $formField, $content = null, $ariaTitle, $buttonLabel, $buttonStyle = 'primary'}
{import definitions('buttons.latte')}
<div x-data="{ open: false }"
     @keydown.escape.window="open = false"
     x-on:toggle-modal.window="open = !open"
     x-on:close-modal.window="open = false"
     x-id="['ariaTitle']"
  >
  {if $buttonStyle === 'primary'}
    {include button-primary, label: $buttonLabel, click: "open = true"}
  {/if}
  {if $buttonStyle === 'text'}
    <button @click="open = true">{$buttonLabel}</button>
  {/if}
  <template x-teleport="body">
      <div x-show="open"
           :aria-labelledby="$id('ariaTitle')"
           x-transition:enter="transition ease-out duration-300"
           x-transition:enter-start="opacity-0"
           x-transition:enter-end="opacity-1"
           x-transition:leave="transition ease-in duration-300"
           x-transition:leave-start="opacity-1"
           x-transition:leave-end="opacity-0"
           x-on:transitionend="event => {
             if (event.target !== $el) {
               return;
             }

             if (open) {
               $refs.formContainer.style.minHeight = `${ $refs.formContainer.offsetHeight }px`;

               {* Force focus on first field instead of close button by x-trap *}
               $refs.formContainer.querySelector('input').focus();
             }

             if (!open) {
               const container = $refs.formContainer;

               container.style.minHeight = 'auto';
               container.querySelector('form').reset();

               [...container.querySelectorAll('.FormBuilderErrors, .input-error')].forEach(el => el.remove());
             }
           }"
           class="flex fixed inset-0 z-[100] items-center justify-center w-screen h-screen bg-white/60 backdrop-blur-sm limit-max-width p-5 md:p-8"
      >
        <div class="relative w-full max-w-[40rem] bg-white shadow-xl flex flex-col overflow-y-scroll max-h-[95vh]"
            @click.outside="open = false"
            :aria-hidden="open ? 'false' : 'true'"
            x-trap.noscroll.inert.noautofocus="open"
            role="dialog"
            aria-modal="true"
        >
          {include button-modal-close}
          <div class="p-10 overflow-y-scroll after:block after:absolute after:z-10 after:bottom-0 after:left-0 after:h-10 after:w-full after:bg-gradient-to-t after:from-white after:to-transparen">
            {block content}
            	{* Headline, additional text, CTA message, etc. *}
            {/block}
            <div x-ref="formContainer" class="w-full [&>div]:w-full">
              {modules('FormBuilderHtmx')->render($formField, [], ".htmx-indicator-form-processing")|noescape}
            </div>
          </div>
          <div class="htmx-indicator htmx-indicator-form-processing absolute inset-0 h-full w-full bg-white/70 z-10 flex items-center justify-center">
            <div class="loader"></div>
          </div>
      </div>
    </div>
  </template>
</div>

There's not a better way to do this without {embed}.

The modal embed is where the scoping is introduced that blocks out the API, so I added site(), wire(), and modules() available, but that list will grow and manually managing each API function becomes cumbersome and doesn't really fit with how ProcessWire works. I know that my current project is more complicated than the usual site, but that's where templating systems really shine!

4 hours ago, bernhard said:

Instead of listing all API variables you can just pass the $wire variable and then access anything you need in your template from there:

In my examples, the parameter list can already get quite long and seeing $wire passed around a lot makes Latte feel detached rather than integrated. Having Latte files get only what they need makes code and purpose a lot easier to grok. It's also just a best practice similar to OOP. When using {include} Even if they're available, I also avoid using parent variables directly because I don't know where using them from one place to another may break something. The {embed} scope ends up acting as a "safety check" to make that component safe to use anywhere.

I think exposing the Functions API would be great. It makes a lot of sense to me when working with how scope is documented in Latte and also how it's documented as globally available in ProcessWire. Although my example above of modules()->get('FormBuilderHtmx')->render() is more verbose than $htmxForms->render(), the Functions API makes it clear that you are working with globally scoped modules(). I think this becomes even more useful if we consider how many non-standard global variables are made available via modules, $forms, $rockicons, $fluency, etc.

4 hours ago, bernhard said:

Also I don't know why you make things "complicated". When I need a reusable portion of code like for a button, I simply put that into /site/templates/partials/my-button.latte and then I use {include ../partials/my-button.latte} in my latte file.

I am definitely trying to keep things from getting complicated! The use cases are more complex than using {include}, but they're not overengineered. Using {include} for things like modals ended up making my code more complicated where I was able to come up with a solution, but it was very clear that I was using the wrong tool for the job.

This is where my project is at and I have a ways to go before it's done, so this is going to grow a lot more. Using {define} and {import} with shared elements like above would save 8 additional files alone just right now.

In my file structure above, the 'includes' are big standalone elements, 'embeds' are complex functional units of behavior independent of context, and 'definitions' are repetitious generic UI elements. My 'layouts' and 'partials' directories live in /site/templates.

I was using the method you mentioned with {include} but it just got to a point where the Latte features really started making more sense. I'm fully using Page Classes so my access to $page and $pages hasn't presented any problems and that's data perfectly suited for parameters passed to a component from a template.

[bernhard]

Hey @FireWire thx for the detailed response. Unfortunately it does not help me understand your problem or request.

9 minutes ago, FireWire said:

My challenges arose when trying to use Latte according to the documentation because keeping things simple started causing problems.

What problems? I can't help if I can't understand the problem.

10 minutes ago, FireWire said:

Using {define} makes a lot of sense in this project because these are simple elements that just output markup and managing them in one file makes life a lot easier.

Personally I don't agree here. But that might be a matter of preference. If files are growing you can also just put them in a folder, so instead of /site/partials/button-primary.latte you could simply have /site/templates/buttons/primary.latte, or am I missing something?

12 minutes ago, FireWire said:

The modal embed is where the scoping is introduced that blocks out the API, so I added site(), wire(), and modules() available, but that list will grow and manually managing each API function becomes cumbersome and doesn't really fit with how ProcessWire works.

I understand that. But to be precise this is only how ProcessWire works if the functions API is enabled, which might not always be the case. Personally I'm always using wire()->modules instead of modules() in my modules, because wire() is always available and wire('modules') does break intellisense in my IDE whereas wire()->modules does work.

I'd be interested to see simple examples (like 5 lines, not 50 like the one example you pasted) how you are using those function calls and what exactly causes problems if they are not available.

17 minutes ago, FireWire said:

There's not a better way to do this without {embed}.

I'm sorry, but this example is too complex for me to grasp.

17 minutes ago, FireWire said:

I think exposing the Functions API would be great.

I agree, but I need to fully understand the situation/scope/whatever first.

19 minutes ago, FireWire said:

Using {include} for things like modals ended up making my code more complicated where I was able to come up with a solution, but it was very clear that I was using the wrong tool for the job.

I'd still appreciate to get an example.

20 minutes ago, FireWire said:

Buttons were a good example since they're the perfect use for storing in an external file as {define} then using {import} to get everything in that file. Another good example are form elements like stylized Alpine/TW toggles and selects that when sharing a file become very easy to manage.

I'm sorry but I don't understand. Maybe some simple code examples would help.

22 minutes ago, FireWire said:

I was using the method you mentioned with {include} but it just got to a point where the Latte features really started making more sense.

Same as above.

[FireWire]

@bernhard I think it's difficult to explain with actual code examples from my project, other than to say that in this case it is more complex than other projects. I would be simplifying my code to match the examples in the documentation. Here's an example of my workaround to use {include} vs. using Latte's {embed} tag.

{* Using capture to assign to a variable *}
{capture $modalContents}
   <h2>{=__('Welcome to my humble modal')}</h2>
  {$page->body|noescape}
  <hr>
  {include 'button-primary.latte'}
{/capture}

{include 'modal.latte', butonLabel: __('Random Details'), buttonType: 'link', size: 'lg', height: 'fit', content: $modalConents}

{* Using embed *}
{embed 'modal.latte', butonLabel: __('Random Details'), buttonType: 'link', size: 'lg', height: 'fit'}
  {block content}
    <h2>{=__('Welcome to my humble modal')}</h2>
    {$page->body|noescape}
    <hr>
    {include 'button-primary.latte'}
  {/block}
{/embed}

There are pages with multiple modals and using {embed} just makes use of the Latte features as documented. For me, it's easier to read, provides indentation, and it's useful to see the {block} feature of {embed} would come in handy- especially when there are multiple blocks. So, true- the same thing can be achieved with using {include}, but more complexity starts to feel like it's compounding. Beyond that, I can't really make a case for why embed is better or not, it's just a feature of Latte that has been helpful.

4 hours ago, bernhard said:

I understand that. But to be precise this is only how ProcessWire works if the functions API is enabled, which might not always be the case. Personally I'm always using wire()->modules instead of modules() in my modules, because wire() is always available and wire('modules') does break intellisense in my IDE whereas wire()->modules does work.

Providing specific examples of where the Functions API would be used is less useful than to say that none of the ProcessWire variables or functions work in Latte files included using {embed}.

That is why I mentioned the custom hook I wrote to overcome that error in my earlier post. I don't really have a strong preference whether the Function or object API (or anything else) is made available, it only matters if it's going to be implemented. I just need to know if there's any way that this would be available in RFE or if I should just keep managing it using the RockFrontend::loadLatte hook.

3 hours ago, bernhard said:

Personally I don't agree here. But that might be a matter of preference. If files are growing you can also just put them in a folder, so instead of /site/partials/button-primary.latte you could simply have /site/templates/buttons/primary.latte, or am I missing something?

I guess you're right about it being a preference. When I first talked about the {define} {import} style and the errors I was getting, I didn't think that had something to do with RFE. I didn't know where to start and figured I did something wrong so that's where I was troubleshooting from. I can't really make a case for this other than to say it's just a feature in Latte that works very well for me.

So there's only to things I'm struggling with at the moment-

Can some form of the ProcessWire API be made available through RPB to files using {embed}?
Can it be possible to use {define} and {import} using files as shown in the Latte docs?

I think I was too specific in my other response and didn't mean for it to get in the way of what I was trying to say. I posted before coffee this morning. I didn't mean to be poorly communicative or aggressive.