I agree that it is a good idea to have a general TemplateInterface instead of a string representing the template. However I don't think we should then also have a TempleteRendererInterface to render this template: this would require that any implementation of TemplateInterface could be rendered by any implementation of TempleteRendererInterface which would definitely not be the case: a MustacheTemplate could not be rendered by a TwigRenderer.
Concerning the type of the data that is passed to the render function (aka context): If we don't use the native array and/or ArrayObject the defined interface should allow the possiblity to cast to an array. I don't think using ContainerInterface alone would be enough for two reasons: Many template engines rely on extract() to allow access to the context. Merging multiple contexts together would become impossible. Instead for every access multiple contexts would have to be searched, which would probably lead to performance problems. I think using Xedin's StringableInterface <https://github.com/Dhii/stringable-interface/blob/master/src/StringableInterface.php> as the return type is a good idea. Using StreamInterface is probably not necessary in a lot of cases, but since the two interfaces are not mutually exclusive it would be possible to return a StreamInterface if the implementor wants to do so. @FGM Are you suggesting that the abilty to return metadata should be part of these interfaces? Or was this a concern if the render function returns a string? I'm not sure if it would be possible to define a common MetadataInterface. On Monday, September 25, 2017 at 11:48:24 AM UTC+2, FGM wrote: > > Something else could be missing: metadata attached to the rendered result, > like caching tags, contexts, which need to be gathered when assembling > render results to build an actual HTTP response (coming from a Drupal > "render array" background, as some can guess). > -- 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/ba901677-002b-440d-ab6b-eddd6472d187%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
