> 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.)
Hi. Blade kind of supports view models when using components. In the internal framework of my organization I developed a wrapper around the views, which is a View class partially based on the spatie/laravel-views-models package ( https://packagist.org/packages/spatie/laravel-view-models). My controller methods usually return views like this: *"return new RandomView(pieceOfInfo: $info, contentTitle:'My page');"*. But this view class is entirely optional. In our team, when it's overkill to create a view model to render just one small stuff, one can still call the template rendering function directly. The ViewModel class can guess the template file name or you can set one yourself. About adoption of this possible PSR: If we look at the usage of this spatie package, it has almost 2 million downloads, but I think Laravel does not want to integrate it in the framework because as it did with the spatie/laravel-blade-x components package ( https://packagist.org/packages/spatie/laravel-blade-x). I feel they don't want to spend lots of time with the template engine because of the JS FE libs/frameworks and their Inertia lib. But if we think of interoperability, maybe think on a higher level, like a Renderable or something like that, it could have a higher acceptance among the community. Best regards, Erick Em seg., 18 de dez. de 2023 às 15:32, Larry Garfield <la...@garfieldtech.com> escreveu: > 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 > . > -- 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/CAGS0MVA-HT%2Bb0fuQ7qD%2BV0Kdj9VMTG-MDoi072L4S-KYhpZr%3DA%40mail.gmail.com.
