ZendView 3: Rendering engine simplification

[weierophinney]

Seeing that work on ServiceManager and EventManager is progressing, I'd like to start discussing new Zend\View.
My goals are to:

1. reduce overall complexity
2. keep as much backwards compatibility as possible
3. add more flexibility, so that Zend\View can be nicely integrated with non-ZF app (or outside of MVC flow).

As a first step, I prepared a proposal for rendering mechanism.

Responsibility issue

A this moment, rendering nested view models happens in two places (I'm skipping console for simplicity):

• in Zend\View, when rendering phtml templates (other renderers can be used here as well)
• in JsonRenderer, when rendering JsonModels

Here's how rendering is done now within application flow:

                 ViewManager
                      |
            DefaultRenderingStrategy
                      |
                 Zend\View
                  /      \
 PhpRendererStrategy     JsonStrategy
         |                    | 
     PhpRenderer         JsonRenderer

Basically, right now different layers are responsible for the same thing.

I suggest to make it look like this:

                              ViewManager
                              /         \ 
        DefaultRenderingStrategy     JsonRenderingStrategy
                  |                             |
               Zend\View                    JsonRenderer
                  |
          PhpRendererStrategy
                  |      
              PhpRenderer     

New listener (JsonRendererStrategy) would be replacing JsonStrategy. It would be attached to the same events as DefaultRenderingStrategy. This fixes responsibility problem, while keeping amlost full compatibility with typical application. Only thing to update would be a requirement to register JsonRenderingStrategy somewhere else within the config. Perhaps we should also consider different naming: we have a concept of "Strategy" related to different layers.

With this approach, whole system can be simplified (I also listed simplifications that are not related to this issue):

RendererInterface

• getEngine() appears not to be used anywhere - it can be removed.

• setResolver() can be also removed, and resolver can be injected via constructor

• ideally renderers would only render ViewModels (it shouldn't accept template names), but this may be too big BC break. So, I suggest following signature:

  interface RendererInterface
  {
  public function render($nameOrModel, $values = null);
  }

TreeRendererInterface

• interface to be removed

PhpRenderer

• init() logic appears not to be used anywhere - it can be removed.
• for simplicity, addTemplate method can be removed as well (I don't see it being needed anywhere)
• tree rendering logic can be removed

I have more ideas for Zend\View class and helper system, but I'd like to see where this goes first (other proposals will depend on this one). Does it make sense? If yes, I can start working on prototype implementation.

---

Originally posted by @mtymek at zendframework/zend-view#19

[weierophinney]

It is possible to remove the magic get/set methods for variables? They are slow and people are forced to check if variables are set. Could avoid Bugs. Another point is the PHPDoc block for variables in the view script, so code completion is available.

This reduces the complexity too.

---

Originally posted by @sandrokeil at zendframework/zend-view#19 (comment)

[weierophinney]

It would be nice if the ViewManager or View would support rendering outside the MVC lifecycle e.g. for rendering the body of a mail.
The view manager does not expose the functionality to get the configured ViewStategies, and the view does not expose how to get a configured Renderer for a template/ViewModel.
Hooking into the rendering events of the view requires a response to be present when render is called and it cannot be unset.
Since ViewStrategies are supported it would be nice to profit from that everywhere, directly getting a Renderer and using that builds a dependency that the specified renderer is present. It would be better to just use the view strategies and have the application define/fetch the renderer itself.

Best way I know currently is to set 'has_parent' option to true in the view model and use $view->render($modelWithHasParentOptionSetToTrue), but that relies on $view->render(...) to return the rendered content if that option is set, which might change at any time.

---

Originally posted by @hoppithek at zendframework/zend-view#19 (comment)