On Tue, May 31, 2022, at 6:12 PM, Alexander Schranz wrote:
> *The proposal* > The interface for a TemplateRender I would recommend is the following > based on my analysis of exist template engines and what is the easiest > way to put them together and have maximum interoperability: > > /** > * Render the template with the given context data. > * > * @param string $template > * @param array<string, mixed> $context > * > * @return string > * > * @throw TemplateNotFoundExceptionInterface > */ > public function render(string $template, array $context = []): string; > For maximum compatibility we even could consider to publish 2 version > of the template renderer v1 without typehints so exist template engine > still supporting old php version can already implement it and v2 with > typehints. > > *Exist TemplateRenderer Discussion* > There was already an exist disussion about implementing a > TemplateRendererInterface here: > https://groups.google.com/g/php-fig/c/w1cugJ9DaFg/m/TPTnYY5LBgAJ. > > The discussion goes over several topics just to mention the main parts: > > * Template should be objects > * Context should be objects > * TemplateRender should stream to output even asynchronity > To target this specific points. I would focus in this PSR on exist > solution as we see most work for template with logical string based > names and do not require an object. I was one of the people arguing in the past that a templating interface needs to be more robust than a dict->string mapper. It does seem that there is a de facto consensus on that model anyway, so even if it's a poor model there is potential value in standardizing that much. My concern is that while there's obviously a straightforward way to make common render() methods *type* compatible, that doesn't mean they're *semantically* compatible. The template name string is, AFAIK, wildly variable between different systems right now, and the value part of the replacement array is also a huge ball of undefined. For a standard to actually be viable, those would need to be standardized at least enough that a library could use it and expect it to then "just work" whether it's plugged into Twig, Plates, Sulu, TYPO3 Fluid, or whatever. That also gets into questions of escaping, and what is escaped where. Those are extremely non-trivial questions. I don't know how resolvable those are in practice, but they would all happen outside the type system, or else involve not passing primitives (eg, a template object instead of just a string name, and then we're right back where we started). If the major players in the template world are on board for a working group to sort out *that* part of the problem space, I'm happy to support them doing so. But it would need buy-in from the major players there, because otherwise it wouldn't be useful. --Larry Garfield -- 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 php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/fafd7eb9-7986-40c4-a955-4726b55f8ec4%40www.fastmail.com.
