Quantcast

Rendering ViewModels

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Rendering ViewModels

Wesley Overdijk
Hi all,

This is the first time I _really_ write something on the mail list, so sorry if the format of this e-mail is not what it should be.

I'm currently having some issues with Zend\View. This is the case:

I have created a view helper in which I populate a new ViewModel. I set the template and eventually return $this->getView()->render($viewModel); 
As you can see, this is a pretty normal implementation. Now here's the problem, we're using ZfcTwig (which, obviously, uses twig). When my view helper gets called inside of a twig template, the renderer that's going to parse my ViewModel is in fact the twig renderer. I'd assume that this would just grab the PhpRenderer and resolver. Currently I have this workaround: https://github.com/RWOverdijk/SxRequireJs/pull/2 (sorry for the trailing space changes in the diff)

I don't agree with this workaround. I think that "return $this->getView()->render($viewModel);" is a pretty common implementation, and that we should fix this in the framework (because I'm not the only one that will be doing this, and we can not force modules to implement this support.). It could well be that I'm doing something wrong somewhere else, which is partially the reason I'm sending this email. I'd very much like your feedback on this as I'm stuck on this.

Thank you for reading, I'm looking forward to your replies.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Rendering ViewModels

weierophinney
Administrator
-- Wesley Overdijk <[hidden email]> wrote
(on Friday, 10 August 2012, 04:25 PM +0200):

> This is the first time I _really_ write something on the mail list, so sorry if
> the format of this e-mail is not what it should be.
>
> I'm currently having some issues with Zend\View. This is the case:
>
> I have created a view helper in which I populate a new ViewModel. I set the
> template and eventually return $this->getView()->render($viewModel);
> As you can see, this is a pretty normal implementation. Now here's the problem,
> we're using ZfcTwig (which, obviously, uses twig). When my view helper gets
> called inside of a twig template, the renderer that's going to parse my
> ViewModel is in fact the twig renderer. I'd assume that this would just grab
> the PhpRenderer and resolver. Currently I have this workaround: https://
> github.com/RWOverdijk/SxRequireJs/pull/2 (sorry for the trailing space changes
> in the diff)
>
> I don't agree with this workaround. I think that "return $this->getView()->
> render($viewModel);" is a pretty common implementation, and that we should fix
> this in the framework (because I'm not the only one that will be doing this,
> and we can not force modules to implement this support.). It could well be that
> I'm doing something wrong somewhere else, which is partially the reason I'm
> sending this email. I'd very much like your feedback on this as I'm stuck on
> this.

Well, there's a mismatch in place. The "View" assigned to a helper is
actually the renderer; the terminology "get/setView" is a holdover from
ZF1 -- it's really a renderer instance. As such, I'd really only expect
$this->getView()->render(...) to use whatever renderer is represented by
$this.

If you're using a Twig renderer, why would you expect the helper to use
the PHP renderer? I'm not sure I understand what kind of workflow would
lead to that, to be honest.

As an additional note, a renderer has no knowledge of the View
object itself, and only the View object currently has any logic for
selecting an appropriate renderer. Most such logic looks at either the
Accept header, the ViewModel, or the template name in order to determine
the renderer. I'd expect that in a given call to render(), we'd only
call a single renderer at a time, and any partials it might render would
be handled by the same renderer. To do otherwise makes for a very
complex system that will be hard to understand or explain to end-users.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Loading...