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 parsed etc. *Hari K T* You can ring me : +91 9388 75 8821 http://harikt.com , https://github.com/harikt , http://www.linkedin.com/in/harikt , http://www.xing.com/profile/Hari_KT Skype : kthari85 Twitter : harikt On Sat, Sep 23, 2017 at 11:15 PM, Thomas Gnandt <[email protected]> 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/16475a0c-f46b-4478-ac99-5e9003a97d19%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/16475a0c-f46b-4478-ac99-5e9003a97d19%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAESZFt%2BoXNBazEvqMmeJu%3DWkQDpAdLh8bod7SS6ObK4YzHxOAw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
