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/0ed12b49-54f0-4157-bd2a-332f80018ab7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
