Eventually, I plan to be able to write something like this:
// my-template.php
echo "Hello, {$c->get('name')}!";
// Elsewhere
$path = 'my-template.php';
$template = new PhpTemplate($path); // TemplateInterface, currently
ContextRendererInterface
$context = new DataObject(['name' => 'Xedin']); // This is a
ContainerInterface, see dhii/data-container-interface:dev-develop
$block = new GreetingBlock($template, $context); // The context can of
course be determined in a different way
$mainContext = new DataObject('greeting' => $block);
$mainBlock = new HtmlBlock($mainContext); // Some super block for an outer
template, implementation detail really
// Outer template
<div class="greeting">
<?php echo $c->get('greeting') ?>
</div>
As shown here, this approach allows standardization of template mechanics,
including what happens inside the template, and very importantly
compilation. All data inside any similar template, be it a purely HTML
template, or a Mustache one, is available via the context (in PHP, a
`ContainerInterface`. Something like `{greeting}` (Mustache style) can very
easily be interpreted as `$c->get('greeting')` in the engine, etc. This
looks to me like excellent SoC and interoperability.
On Sunday, September 24, 2017 at 10:32:17 AM UTC+2, Xedin Unknown wrote:
>
> Hi all,
>
> This is a good idea, and we are already working on this for the project
> that is being built. Please take a look at dhii/output-renderer-interface
> <https://github.com/Dhii/output-renderer-interface/tree/develop>. The
> readme should explain most of the things. I will try to describe how things
> will work below. Please note that this is a work in progress; however, many
> hours have been dedicated to making this standard as useful as possible. I
> hope that it will be a good inspiration for a PSR.
>
> To put things simply, you have a `RendererInterface`, which is anything
> that can produce output. This requires it to already have access to all
> data that is necessary for rendering. A `BlockInterface` is a renderer that
> can be cast to string, which is possible if it has sufficient data.
> Interoperability is ensured via `StringableInterface`. A
> `ContextRendererInterface` is something that can use a context, i.e.
> additional data, for rendering. This is great for renderers, the instances
> of which can be re-used to render the same "template" multiple times with
> different data. The "aware" interfaces are for greater interop between
> consumers of the main interfaces. Exception interfaces provide access to
> aspects of the rendering, which allows obtaining information about the
> rendering process without being aware of the internals of the
> implementation, and without having prior reference to the instance, which
> is very helpful and is a rule that we use in all standards.
>
> dhii/output-renderer-abstract
> <https://github.com/Dhii/output-renderer-abstract/tree/task/initial-classes>
> is
> an abstract implementation, and a work in progress as well. Blocks are free
> to produce output in any way they wish, so this package has just the most
> abstract functionality. Right now, I am working on an
> `AbstractTemplateBlock`, which uses a template to get rendered. While
> designing this class, I realised (and this is a very important point) that
> very good SoC can be achieved by encapsulating templates in a class that
> represents a template. Without this, it doesn't seem practical to
> standardize block logic to work with different templates. With templates as
> a class, it's possible to render a template that works in any way inside a
> block (or elsewhere). A template IMHO is just a way of saying "a form for
> output that can be filled with values". In this case, a value is a
> rendering context, and there is already an interface that does this - the
> `ContextRendererInterface`. This is why a rename of this interface to
> `TemplateInterface` is pending - because this is exactly what it is, and
> it's more concise and expressive. I will be pushing the rename, as well as
> the `AbstractTemplateBlock`, in a couple of hours, so that you can see the
> usage.
>
> If a workgroup is being assembled to work on this standard, I would very
> much like to be part of it. I have spent a lot of time standardizing output
> mechanisms, and other things, very much inspired by the spirit and letter
> of FIG. I will also gladly share my plans for the future standards and
> implementations, as well as present other standards which I have been
> working on. Many of them are being used in production by me and my team,
> and are working very well so far.
>
>
>
> On Saturday, September 23, 2017 at 7:45:53 PM UTC+2, Thomas Gnandt wrote:
>>
>> With the upcoming http-middleware PSR which defines the
>> RequestHandlerInterface it becomes possible to write framework independent
>> modules that include ready-to-use actions (instances of
>> RequestHandlerInterface). However this is not possible, until a common
>> interface to render a template exists.
>> Any action that should work in multiple applications has to render the
>> body of the response using templates, that are not part of the module
>> itself. While example templates may be included in the module, these are
>> generally not usable by the application that uses the module.
>> It therefore doesn't make sense to include a specific template engine as
>> a requirement of the module. Since templates are written using engine
>> specific syntax it is not feasible to use multiple template engines.
>> Consequently an application could only use modules that support the
>> engine the application wants to use.
>>
>> In order to make the used template engine interchangeable a simple
>> interface could be defined:
>>
>> interface TemplateRendererInterface
>> {
>> public function render(ResponseInterface $response, string
>> $templatePath, array $data = null): ResponseInterface;
>> }
>>
>> This would render the defined template with any data provided and write
>> it to the body of the response.
>> Alternatively the following interface could be defined:
>>
>> interface TemplateRendererInterface
>> {
>> public function render( string $templatePath, array $data = null):
>> string;
>> }
>>
>> This provides greater flexibilty while the first interface provides
>> easier usage in the specified use case (for request handlers).
>>
>
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/456f0cb1-7c03-4e7a-a170-ab4066a5567c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
