Just to clarify: I was not suggesting we switch to a view-model approach. That would fly straight in the face of interoperability for most existing template engines.
I was pointing out the fact that a view-model approach can be implemented on top of this PSR - meaning, you would be able to add a view-model library on top of the PSR template renderer abstraction. Point being, this PSR does not need to be opinionated about that - the lowest common denominator for a view-model vs filename/array-based template engine is the same. So in terms of interoperability, it would work perfectly fine as proposed. :-) On Monday, December 18, 2023 at 7:32:16 PM UTC+1 Larry Garfield wrote: > On Sun, Dec 17, 2023, at 3:08 PM, Rasmus Schultz wrote: > > Hi Alex, > > > > I was wondering how my very simple template locator would fit with this: > > > > https://github.com/mindplay-dk/kisstpl > > > > As you can see, the interface for this is radically different - there > > is no string for the template name, and no array for the data. > > > > After some thinking though, I realized this locator could actually use > > this PSR internally - meaning, my library, which currently uses plain > > PHP templates only, would be able to internally dispatch this > > interface, which means you could use the view-model approach (no > > string, no array) to dispatch any standard template engine. Pretty > > cool. :-) > > > > The one area where this proposal falls short (as, from the discussion, > > you already know) is with its inability to stream. As you can see here, > > my library addresses this by having two methods, render() and capture() > > > > > https://github.com/mindplay-dk/kisstpl/blob/7d59e10da48b2a86f14244c490231a56f78c2611/src/Renderer.php#L10-L41 > > > > What I would suggest, is to do the same for this proposal - rename > > render() to capture() and just have a second method with return-type > > void: > > > > /** > > * Render the template with the given context data, directly to output. > > * > > * @param string $template > > * @param array<string, mixed> $context > > * > > * @return void > > * > > * @throw TemplateNotFoundExceptionInterface > > */ > > public function render(string $template, array $context = []): void; > > > > /** > > * Render the template with the given context data. > > * > > * @param string $template > > * @param array<string, mixed> $context > > * > > * @return void > > * > > * @throw TemplateNotFoundExceptionInterface > > */ > > public function capture(string $template, array $context = []): string; > > > > Now, I'm sure there will be some engines that are incapable of > > rendering directly to output - in those cases, render() would simply be > > implemented as e.g. echo $this->capture() and, of course, you wouldn't > > get the performance or memory advantage of streaming here. > > > > But the proposal also wouldn't *stand in the way* of getting this > > advantage from template engines that *are* capable of streaming. > > > > Looks like a good proposal, but addressing this issue seems easy enough > > and worth while, since it doesn't add any real complexity for > > implementors. > > > > - Rasmus Schultz > > I like View Models as a conceptual design. It does side-step the "file > name" problem, provides structure, etc. It's also consistent with how > PSR-14 works, by using the PHP type itself as the branching/matching > factor. There's two problems. > > 1. Virtually all frameworks today use response objects (whether PSR-7, > HttpFoundation, or otherwise). The "streaming by default" templating > approach is not compatible with that model. Basically everyone would need > to switch from the common `render()` method to `capture()`, if done this > way, and that's definitely not going to fly. While you could stream the > template inside a streaming response object, I don't think anyone does, and > that's rarely necessary or even a good idea. > > 2. While I'd love it if ViewModels were more common, as far as I know not > a single major template engine that does that. Blade, Twig, and Smarty are > all array-based. Latte supports view models, but still requires a template > name. (https://latte.nette.org/en/develop#toc-parameters-as-a-class) > Adopting a ViewModel-centric spec would require figuring out a way to allow > the major engines to adopt it in a BC-compatible way (as PSR-14 was able to > do). > > If we could get 2-3 of the major engines on board with a ViewModel > approach, using the class as the template indicator, I would absolutely > support that. That seems like a large lift, however, especially as the two > biggest engines (Twig and Blade) are part of projects that seem to not be > interested in FIG. :-( We might be able to get someone from Twig involved, > but Blade feels unlikely. (I've no idea about Smarty or Latte.) > > (There would almost certainly be other things that would need to be > standardized, like how to mark a given property as being already escaped so > no further escaping is needed, but those discussions aren't relevant until > the above are addressed.) > > --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/6edebd5c-c901-42d7-bea5-f0e59f7e5c0an%40googlegroups.com.
