Fwd: [Proposal] TemplateRendererInterface

Sorry for the late response, sent the mail from another address earlier, but that one isn't subscribed to the group and got rejected. > Hi Niklas, > > Always having to return an object might be bad for the developer experience > > > Which is why I allow an object that can be cast to string.

Re: [Proposal] TemplateRendererInterface

Some more alternatives for streaming (also, the other methods described so far for completeness): 1. *Async stream* (new). Unlike the buffered stream, this stream can respond to events. The streams of ReactPHP are an

Re: [Proposal] TemplateRendererInterface

Another possible approach that helps avoid contaminating `TemplateInterface#render()`, but allows writing via a stream. Although not strictly part of the "template" standard, but definitely solves the problem. Being permitted to return an stringable object, the implementation may choose to

Re: [Proposal] TemplateRendererInterface

Hi Niklas, Always having to return an object might be bad for the developer experience Which is why I allow an object that can be cast to string. Please take another look at the code . Also, only

Re: [Proposal] TemplateRendererInterface

> > Having given it quite a bit of thought, and passing this by @mecha, I > would like to provide some feedback with regard to working with streams. As > a disclaimer, I would like to mention that I do not make solving a specific > problem the target of this standard; however, I do want to

Re: [Proposal] TemplateRendererInterface

On Tuesday, September 26, 2017 at 12:04:27 PM UTC-5, mecha wrote: > > If I may give my two cents, I also find anything that has to do with files > extra. > Agreed, the engine spec shouldn't really be dealing with files, and I completely forgot about streams. For reference to our own standard:

Re: [Proposal] TemplateRendererInterface

Having given it quite a bit of thought, and passing this by @mecha, I would like to provide some feedback with regard to working with streams. As a disclaimer, I would like to mention that I do not make solving a specific problem the target of this standard; however, I do want to make sure that

Re: [Proposal] TemplateRendererInterface

If I may give my two cents, I also find anything that has to do with files extra. I think a renderer is, at its very core, something that simply renders. i.e. something which, when told to `render()`, simply renders no questions asked. An `EnglishAlphabetRenderer` will quite simply give

Re: [Proposal] TemplateRendererInterface

On Tuesday, September 26, 2017 at 4:17:38 AM UTC-5, Xedin Unknown wrote: > > `Template#file()` seems extra to me, because it breaks ISP. > This method is used by the Context to be able to determine whether the data it contains actually applies to the template. > `Engine` also looks very

Re: [Proposal] TemplateRendererInterface

@FGM If the template returns a StringableInterface , as Xedin suggested, then you can create your own return type that is standards-compliant and also contains other information.

Re: [Proposal] TemplateRendererInterface

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

Re: [Proposal] TemplateRendererInterface

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). 2017-09-25 8:21 GMT+02:00 Xedin

Re: [Proposal] TemplateRendererInterface

I believe that's a great argument for not including the template *source* in the description. A template instance can encapsulate `vsprintf()`, for example, and there's never going to be a file or a path resolution. This is all implementation detail that can be handled via IoC. $template = new

Re: [Proposal] TemplateRendererInterface

> Granted, the majority of template engines use a template file-name and a set of name/value pairs Twig also doesn't reference templates by file name. It references them by logical name instead, and uses loaders to resolve that to whatever storage you'd like to use for the template strings. --

[Proposal] TemplateRendererInterface

Granted, the majority of template engines use a template file-name and a set of name/value pairs. This template engine uses neither: https://github.com/mindplay-dk/kisstpl I'm sure you won't care because it's not popular or well-known ;-) We use this at work because: 1. code-sniffer

Re: [Proposal] TemplateRendererInterface

Marco, Please take a look at my examples, and the other interfaces in dhii/output-renderer-interface . Above I wrote about how it is very useful to have a template know how to render itself, which would allow for unified logic,

Re: [Proposal] TemplateRendererInterface

Hi all, it would be really nice to have a standard template renderer interface. Two quick ideas aroud what has already been proposed: - having the `render` method receive an array as input looks too vague to me. I would expect it to receive a template and some data, so something like public

Re: [Proposal] TemplateRendererInterface

The changes that were pending are now merged, and can be found on the `develop` branch of the repos I mentioned. I hope this helps. The next step for be is to create package with base abstract implementations, which still lack the key logic, but save time for the implementors by including

Re: [Proposal] TemplateRendererInterface

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 . The readme should explain most of the things. I will try to describe how

Re: [Proposal] TemplateRendererInterface

Yes, we have something like this for quite sometime. https://github.com/zendframework/zend-expressive-template If every framework authors agrees it will be an easy move. Regarding your suggestion I am for 2. You can do what you need with the rendered string. Eg : An email template being

[Proposal] TemplateRendererInterface

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