Hi @alexander-schranz

I've tried to refactor some of Bootloaders for Spiral Framework. I tried to show you how it could be if I did it.

First of all, I don't understand the reason of using string nameslike 'schranz_templating.renderer.smarty' for container aliases. Why don't you use class names or interfaces?

$container->bindSingleton('schranz_templating.renderer.smarty', function (Container $container) {
      return new SmartyRenderer($container->get('smarty'));
});

When you bind closures into container you can request dependencies as function arguments. You don't need request container and then get dependencies from them.

$binder->bindSingleton(
    ViewFinderInterface::class,
    static function (BladeConfig $config, Filesystem $filesystem): ViewFinderInterface {
        return new FileViewFinder(
            $filesystem,
            $config->getPaths()
        );
    }
);

Spiral framework Bootloader can automatically load depended bootloaders before loading current.

final class SpiralViewBootloader extends Bootloader
{
    protected const DEPENDENCIES = [
        \Spiral\Views\Bootloader\ViewsBootloader::class
    ];

Currently the SpiralView Adapter requires a EngineInterface, this we are currently getting directly from the ViewManager here:

https://github.com/schranz-templating/templating/blob/5e8d60d8267f8f89c128e17f5aaecb0294a7853d/src/Integration/Spiral/SpiralView/Bootloader/SpiralViewBootloader.php#L17-L34

This way we are only supporting the NativeEngine, which maybe is not the expected Engine, as StemplerEngine is I think the default one used by Spiral but that sadly did throw an error:

dependency "locale" not found.

Maybe instead it would be better directly call from the ViewManager, we need debug the exists $this->views->renderer call to revalidate this.

I'm not yet sure if my Module.php are using best practices.

Also not sure what the best way of addExtension in Latte and Twig is:

• https://github.com/schranz-templating/templating/pull/5#discussion_r950609994

Would be nice if somebody of Laminas Core Team could have a look at the existing Module.php definition of Latte: https://github.com/schranz-templating/templating/blob/0.1/src/Integration/Laminas/Latte/Module.php

Was also linked to delegators: https://docs.laminas.dev/laminas-servicemanager/delegators/ but not sure if that can solve extension registry problem as it is more like service registration.

Update: After some discussions the extensions config is fine. For modules there could be two other ways which I got following response:

• Define a plugin manager for the component. These use SM configuration, and the component then pulls from the plugin manager when it needs an extension.
• Compose an event manager and trigger an event. In the MVC, modules then attach listeners to that event (or, in Mezzio, you use a PSR-14 dispatcher, and wire in listeners in your listener provider).

This will refractoring the SpiralViewRenderer using the ViewManager this way the ViewManager decides which templates to be rendered. Which will automatically add supports for Stempler template engine which is the default one for Spiral.

fixes #55

Fixes get the TwigEngine and NativeEngine from the Container initialized. The current implementation via directly get the TwigEngine service throws an error:

[Spiral\Views\Exception\EngineException] No associated environment found. in /Users/alexanderschranz/Documents/Projects/templating/examples/usages/spiral/vendor/spiral/twig-bridge/src/TwigEngine.php:74

The spiral twig integration was forgot to register correctly. This is done in this PR and creates a new subtree splited repo: https://github.com/schranz-templating/spiral-twig-integration

Add Twig Renderer integration into the Spiral Framework.

Sadly there are 2 issues currently:

• https://github.com/schranz-templating/templating/issues/41
• https://github.com/schranz-templating/templating/issues/42

Similar to LaminasView and SpiralView the Mezzio adapter should be renamed to MezzioTemplateAdapter to make clear its the integration of Mezzio/Template namespace.

Beside the TemplateRendererInterface a separate package is in mind for a total different usecase then the exist Renderer. It is targeting Framework authors which want to provide Framework functionality to different Template engines.

Most PHP Frameworks provides for there Template engines some functions commonly is something like generate a URL based on a named Route. In most Template engines this kind of things are handled via Extensions like in Twig or Latte.

There are currently some issues with a TemplateFunctionProviderInterface abstraction.

A. Different implementation of TemplateFunction

The most common Template engines which does not have such implementation of Extension is Blade. Blade work the way that you can access all PHP functions and methods as it is {{ any_method($part) }}, as this is just PHP code which has advantages and disadvantages. Blade is by default used in Laravel which make a lot of usage of Global Function to provide helpers which are used in PHP Code but also in the Template itself. With this opens two questions. A1 should a TemplateFunctionProviderInterface for Blade under Laravel just register Global Function. A2 should a TemplateFunctionProviderInterface for Blade under different decorate Blade emulate global functions. A different way could be used that TemplateFunctionProviderInterface provides in Blade instead of functions Blade directives but as there usage is very different I'm not sure here. Other template engine like Spiral Stempler uses directives more often for things like route generation like here, so how this kind of mechanism should be implemented for this kind of engines is very complicated.

B. Not all Template engines has extensions

This is also the part why it make sense that the whole TemplateFunctionProviderInterface is totally seperate from the Rendering of templates. Library and Framework authors should keep in mind that not all Template engines so they always should have the possibility todo the things already in the controller which is the way why the TemplateRendererInterface is also small and should be keep small. That way this Controller can not support only rendering the content via any template engine but also provide the data as JSON for any API based data receivers.
Still from a Framework perspective a TemplateFunctionProviderInterface make sense so atleast a few engines can has full access to all available Template Functions of a Framework

How could a TemplateFunctionProviderInterface look like?

As background of CMS where a lot of TwigExtension exist we did see a lot difference in performance how many Twig Extensions are registered. This means the TemplateFunctionProviderInterface should solve this issue that providing which functions are available does not required to initialize the Service. It is very common how in twig the twig.runtime works. A TemplateFunctionPRoviderInterface requires a static function this means the class don't need to initialized when it is checked what functions exist. Example:

<?php

namespace App\Templating\FunctionProvider;

use Schranz\Templating\TemplateFunctionProvider\TemplateFunctionProviderInterface;

class MyFunctionProvider implements TemplateFunctionProviderInterface
{
    /**
     * @return iterable<string, string> FCQNorServiceId and Method Name
     */
    public static function getFunctions(): iterable
    {
         return [
              'my_method' => new TemplateFunction(MyFunctionProvider::class, 'myMethod'),
         ];
    }
    
    public function myMethod(string $text): string
    {
        return $text + '-modified';
    }
}

There will then be a TwigExtension for example which will be a Bridge to all TemplateFunctionProvider and uses a PSR Container to access the service:

namespace App\Twig;

use Psr\Container\ContainerInterface;
use Twig\Extension\AbstractExtension;
use Twig\TwigFilter;

class TwigFunction extends AbstractExtension
{
    // maybe $providerClasses and $container can be combined but not sure
    public function __construct(private array $providerClasses, ContainerInterface $container)
    {
    }

    public function getFunctions()
    {
        $functions = [];
        foreach ($this->providerClasses as $class) {
             foreach ($class::getFunctions() as $functionName => $function) {
                 $functions[] = new TwigFunction($functionName, function($params...) {
                      $this->callFunctionProvider($function, params);
                 });
             }
        }
    
        return $functions;
    }

    public function callFunctionProvider(TemplateFunction $function, $params)
    {
        $serviceName = $function->getServiceName();
        $methodName = $function->getMethodName();

        $service = $this->container($serviceName); // only when really used a TemplateProvider will be initialized here
    
        return $service->{$methodName}(...$params);
    }
}

We should be notified if there are new versions of specific engines and framework available. So the integrations and adapter could be updated to the new versions.

For legacy project it make sense to provided integrations also for Pimple based frameworks. This would for example be Silex.

https://github.com/silexphp/Pimple

Mustache is for example also provided for Pimple: https://github.com/bobthecow/mustache-silex-provider/blob/master/src/Mustache/Silex/Provider/MustacheServiceProvider.php