On Fri, Jan 12, 2024, at 6:50 PM, Rasmus Schultz wrote:
> what's wrong with this?
>
> $engine->render('models/user', $data);
>
> every engine takes a logical template name, and applies whatever
> convention it uses - which for
> most engines would mean adding the appropriate root path and file
> extension, while other engines
> might use the first part of the logical name to map to one of several
> registered root paths.
>
>> the only viable approach I've heard is to not do that and instead use view
>> models, so the
>> type system becomes the abstraction
>
> this doesn't really change anything though - under the hood, that
> view-model name still needs to
> be resolved to an engine-specific absolute template path with a file
> extension.
>
> so you still have the exact same problem - now it's just one layer
> below the thing you're looking at.
>
> the ViewModelRenderer needs to do everything a TemplateRenderer would
> need to do, and more.
>
> I don't think there's any way around that - but that's probably okay?
> depending on what you think
> this kind of abstraction buys you in the first place? :-)
>
> for me, it would be something like: I can ship a login service module,
> and this module can send a
> password recovery email - that service can call
> $engine->render('login-service/lost-password', $data)
> and by injecting a different $engine you can choose the template syntax
> you'd like to use in your
> project for that service, with the path/filename conventions
> appropriate for that engine.
>
> in terms of interoperability, what else were you hoping for? :-)
>
> Rasmus
Agreement from the major template engines to omit the extension in their code,
and standardize on what / means. :-) Note also that some (eg, Twig) commonly
include a format in the file name that needs to be thought through, as well.
(IMO, moved to a named arg.)
That's a solvable problem. But so far, no one has done the work to try and get
the right parties in the room.
--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/b2667b3a-a819-4877-86ae-c1e93edac2bd%40app.fastmail.com.
