On Wed, Dec 27, 2023, at 3:29 PM, Matthew Weier O'Phinney wrote:
> Returning to Larry's argument...
>
>> Personally, I prefer the full-on view model approach. PHP types can
>> encapsulate quite a bit these days, which would (as in PSR-14) offer decent
>> fallback support via parent types and interfaces, as well as be more
>> self-debugging, etc. It would also be template agnostic. Additional
>> context could be provided by optional named arguments (like $format for
>> "html", "rss", "text", etc.), and those could be engine-specific-extended
>> without breaking anything if we define a few base ones.
>>
>> There's probably somewhere that would break, but the biggest blocker is, as
>> noted, getting existing engines on board with this. If we can do that, we
>> have options. If not, there's nothing to do.
>
> Having worked with PSR-14 a fair bit, I _do_ like this approach.
> Mapping a _type_ to a _template_ is relatively easy, and allows for
> both a variety of approaches as well as things like extension and
> decoration. I disagree with having named arguments to determine format;
> I think that information can be baked into the view model. One way to
> do this effectively would be to decorate a view model into a generic
> one representing the content type to generate, and then allow the
> renderer to compose strategies based on that:
>
> final class RssViewModel
> {
> public function __construct(public object $decoratedModel) {}
> }
>
> The renderer sees the RssViewModel, and passes it to a strategy that
> knows how to render an RSS feed, which in turn pulls the
> $decoratedModel to get the data to use in the feed. This would allow
> having helpers like the following in your handlers:
>
> private function decorateViewModel(ServerRequestInterface $request,
> object $viewModel): object
> {
> return match ($request->getHeaderLine('Accept')) {
> 'text/html' => new HtmlViewModel($viewModel),
> 'text/xml' => new RssViewModel($viewModel),
> 'application/json' => new JsonViewModel($viewModel),
> default => new HtmlViewModel($viewModel),
> };
>
> Allowing you to then:
>
>
> $response->getBody()->write($renderer->render($this->decorateViewModel($viewModel)));
>
> (Clearly, you'd use something like willdurand/negotiation for the
> actual matching, but you get the gist).
My concern here is how it interacts with inheritance, give that value objects
these days generally use both readonly and CPP. I'd expect the above to match
to something like
readonly class ArticleView {
public function __construct(
public string $title,
public UserView $author,
public string $body,
public array $tags = [],
) {}
}
readonly class ArticleViewHtml extends ArticleView {]
readonly class ArticleViewRss extends ArticleView {}
etc.
The problem there is that if you want to add a constructor argument to one of
the child classes, PHP itself now makes that really ugly to do. (This is a PHP
limitation.) It also means an explosion of child classes even if you don't add
properties; Adding a new output type to an existing system with 300 view
models means adding 300 classes. That's not good.
If we instead did:
$engine->render($articleView, format: 'rss')
The logic inside render() to locate the template becomes a lot simpler. The
degenerate case is probably something like (mostly copying from PSR-0):
public function render(object $viewModel, string $format = 'html'): string
{
$className = $viewModel::class;
$fileName = '/template/root/';
$namespace = '';
if ($lastNsPos = strrpos($className, '\\')) {
$namespace = substr($className, 0, $lastNsPos);
$className = substr($className, $lastNsPos + 1);
$fileName .= str_replace('\\', DIRECTORY_SEPARATOR, $namespace);
}
$fileName .= str_replace('_', DIRECTORY_SEPARATOR, $className) . '.' .
$format;
return $this->doRender($fileName, $viewModel);
}
(Which, assuming I didn't typo something, would turn App\Views\ArticleView into
/template/root/App/Views/ArticleView.html. More robust engines would of course
do something more interesting.)
Adding fallbacks there to make additional formats easier is fairly
straightforward.
> The view model approach has another benefit: you can't forget
> _required_ data when you render. I can't tell you how many times I've
> discovered that the reason a page is broken is because of a mistyped
> array key, or just plain missing keys. Having actual typed view models
> helps developers ensure that they are providing all the information
> necessary to render a template.
Absolutely. Easily half the argument for "use a defined type for things" is
"because I keep typoing otherwise and losing hours debugging it." :-) (And
related benefits, of course.)
> I don't think we necessarily need to worry about having buy-in from the
> various template engines, either. The nice part about this is that all
> of this work — mapping view models to templates, calling the engine
> with the appropriate data — can all happen in _third-party libraries_
> that _implement_ the FIG standard, but _proxy_ to the underlying
> engine. Those implementations can handle how to pass data from the
> model to the engine, or even have their own conventions that then _work
> with_ the engine. (As examples, they could pull data from any public
> properties of the view model; or they could pass the view model as a
> "model" or "view" template variable; or the renderer could make use of
> JsonSerializable or a `__toString()` method; or the view model could
> be bound as "$this" in the template; etc. Application developers would
> choose the implementation that suits their application and/or
> development needs.)
>
> This approach sidesteps the whole "template composes its renderer".
> View models can compose other services if they want, but the point is
> that they do not contain the information needed to render themselves;
> that's up to the renderer.
>
> On top of that, it bypasses the whole "create a spec for referencing
> templates", which is very difficult to test, harder to enforce, and
> likely leaky (talking from experience here!).
>
> So, I'll toss my hat in the "go with a view model" ring. I think the
> following is as simple as it gets and as flexible as it gets:
>
> interface Renderer
> {
> public function render(object $viewModel): string
> }
An additional wrinkle is nested templates. Both where the template engine
itself nests things (a la Twig blocks et al), or where different parts of the
page are rendered down to a string separately so they can be separately cached,
rendered in parallel, etc. (Something Drupal did, badly.) At minimum that
means a Stringable AlreadyRenderedString class, which some template engines
already have, to avoid double escaping. There's probably other concerns there
but I haven't had a chance to think all of them through yet.
--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/db002f1f-a6c8-4e55-837a-a8ee4c740942%40app.fastmail.com.
