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/cabbfab5-11ff-48d8-9fa7-5979ebfbb775%40app.fastmail.com.
