View Layer -- ideas/opinions wanted

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

View Layer -- ideas/opinions wanted

weierophinney
Administrator
Hey, all --

I've been working on the view layer, and have tests now in place for all
functionality originally in the prototype.

Prototype is here:

    https://github.com/weierophinney/zf2/tree/feature/view-layer

And usage can be seen in my feature/view-layer branch of my zf2sandbox:

    http://git.mwop.net/?a=shortlog&p=zf2sandbox&h=refs/heads/feature/view-layer

(though it's slightly out-of-date with my ZF2 branch)

In doing the prototype, using it, and getting feedback, a few questions
have cropped up, and I'm playing with ideas on how to address them.

 * First, should the default rendering strategy know about and/or care
   about layouts? And should it contain logic mapping certain view model
   types to layouts?

   Rob Allen (aka Akrabat) has suggested it should not, and I'm tending
   to agree. More on this below.

 * Second, how should we handle _aggregating_ view snippets? As an
   example, you might have a view model related to navigation, another
   to the main "article" content, multiple ones to the sidebar, etc.
   These may be detailed and specified from a single controller, but
   they could also be the product of multiple controllers. In most
   cases, the results of rendering these would be captured and passed to
   the layout (or rendered directly by the layout). Regardless, we need
   a way to capture them. More on this below.

 * Third, Evan Coury (aka EvanDotPro) has indicated he'd love for the
   ability for different segments of the view to be rendered via
   different engines. As an example, your request might result in
   multiple controllers being dispatched from different modules; one
   might have default rendering provided by Twig, another by Mustache,
   and another by the PhpRenderer. Making this possible would lead to
   easier interop between modules (you wouldn't need to have templates
   for each popular type of renderer, and/or developers wouldn't need to
   translate the templates you provide to their own selected renderer).

 * Finally, Rob and I have both run into areas where we want to store
   configuration values for helpers, passing them to the helpers only
   when we need to invoke them. The way we've each accomplished this so
   far is to pass them into a special placeholder, but there should be a
   framework-supported way to do this.

For the first three points, I came up with an idea I'd like feedback on.
The basic gist is to specify two renderer options in view models and/or
expose new properties: one for "capture to" and one for "children".

 * "Capture to" would allow a renderer to render the view model and then
   capture it to a view variable.
 * "Children" would be an array of ViewModel instances that should be
   processed.

Typically, your ViewModel returned from a controller would specify a
"capture to" value. Another ViewModel would be created by the developer
to represent the layout; it would aggregate ViewModel's returned by the
controllers in the "children" array. The layout ViewModel would then be
passed to the renderer.

If a child specifies a false value for "enable_layout", it would not be
passed to the layout ViewModel, and would instead be rendered by itself
and immediately returned in the response. For things like JSON and
Feeds, we'd disable the layout by default.

When a Layout ViewModel is processed, each child would be processed
individually, including selection of renderer strategy (I'm not sure if
the Response strategy would be processed for each child ViewModel, or if
that would only run at the end.) Alternately, you could write your own
View object that passes the Layout ViewModel directly to a specific
rendering engine, allowing it to treat each child as a block (much as
Twig and Smarty do).

Basically, this strategy for view models would answer each of the first
three points above, giving us a layout-agnostic default strategy (though
not entirely, as the aggregation of view models into a parent layout
view model still must happen at some point), named captures, and
renderers per-view model.

Thoughts?

--
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

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: View Layer -- ideas/opinions wanted

Adam Lundrigan
Matthew,

Excellent work!  I really like the ease of the ViewModel method of sending
data to the view layer.  I haven't had a chance yet to do any in-depth
hacking, but updating my pre-existing ZendSkeletonApplication-based site to
use your view layer branch was pretty quick and painless.  The only gotcha
I encountered was in the layout script (quoting from memory below, so I may
be mistaken):

In ZendSkeletonApplication the content placeholder is specified like so:
<?php echo $this->raw('content'); ?>

In your zf2sandbox you do this:
<?php echo $this->placeholder('content'); ?>

Neither worked for me when using your view-layer branch from github...the
layout would render with the content placeholder area empty.  I had to use
the following:

<?php echo $this->content; ?>

You did say in your mail that the GitHub branch impl and zf2sandbox usage
example were out of sync, so I assume the above falls into that category?

One question:  is there a fallback method for determining the template when
a ViewModel is returned from the MVC without a template specified?  I like
that the ViewListener setup in the skeleton app would attempt to render a
view script :controller/:action.phtml when no template was explicitly set
via the controller.  In my test app I hook into the dispatch event and
inject the "auto" template name if one isnt already specified in the
ViewModel.  I know some people dislike that kind of view "magic", but I am
not one of those ;)

Thanks again for your work on the view layer...it's shaping up very nicely!

--
Adam Lundrigan, B.Sc, ZCE
[hidden email]

Sent from my Motorola Atrix smartphone
 On 2012-02-07 7:39 PM, "Matthew Weier O&apos;Phinney" <[hidden email]>
wrote:

> Hey, all --
>
> I've been working on the view layer, and have tests now in place for all
> functionality originally in the prototype.
>
> Prototype is here:
>
>    https://github.com/weierophinney/zf2/tree/feature/view-layer
>
> And usage can be seen in my feature/view-layer branch of my zf2sandbox:
>
>
> http://git.mwop.net/?a=shortlog&p=zf2sandbox&h=refs/heads/feature/view-layer
>
> (though it's slightly out-of-date with my ZF2 branch)
>
> In doing the prototype, using it, and getting feedback, a few questions
> have cropped up, and I'm playing with ideas on how to address them.
>
>  * First, should the default rendering strategy know about and/or care
>   about layouts? And should it contain logic mapping certain view model
>   types to layouts?
>
>   Rob Allen (aka Akrabat) has suggested it should not, and I'm tending
>   to agree. More on this below.
>
>  * Second, how should we handle _aggregating_ view snippets? As an
>   example, you might have a view model related to navigation, another
>   to the main "article" content, multiple ones to the sidebar, etc.
>   These may be detailed and specified from a single controller, but
>   they could also be the product of multiple controllers. In most
>   cases, the results of rendering these would be captured and passed to
>   the layout (or rendered directly by the layout). Regardless, we need
>   a way to capture them. More on this below.
>
>  * Third, Evan Coury (aka EvanDotPro) has indicated he'd love for the
>   ability for different segments of the view to be rendered via
>   different engines. As an example, your request might result in
>   multiple controllers being dispatched from different modules; one
>   might have default rendering provided by Twig, another by Mustache,
>   and another by the PhpRenderer. Making this possible would lead to
>   easier interop between modules (you wouldn't need to have templates
>   for each popular type of renderer, and/or developers wouldn't need to
>   translate the templates you provide to their own selected renderer).
>
>  * Finally, Rob and I have both run into areas where we want to store
>   configuration values for helpers, passing them to the helpers only
>   when we need to invoke them. The way we've each accomplished this so
>   far is to pass them into a special placeholder, but there should be a
>   framework-supported way to do this.
>
> For the first three points, I came up with an idea I'd like feedback on.
> The basic gist is to specify two renderer options in view models and/or
> expose new properties: one for "capture to" and one for "children".
>
>  * "Capture to" would allow a renderer to render the view model and then
>   capture it to a view variable.
>  * "Children" would be an array of ViewModel instances that should be
>   processed.
>
> Typically, your ViewModel returned from a controller would specify a
> "capture to" value. Another ViewModel would be created by the developer
> to represent the layout; it would aggregate ViewModel's returned by the
> controllers in the "children" array. The layout ViewModel would then be
> passed to the renderer.
>
> If a child specifies a false value for "enable_layout", it would not be
> passed to the layout ViewModel, and would instead be rendered by itself
> and immediately returned in the response. For things like JSON and
> Feeds, we'd disable the layout by default.
>
> When a Layout ViewModel is processed, each child would be processed
> individually, including selection of renderer strategy (I'm not sure if
> the Response strategy would be processed for each child ViewModel, or if
> that would only run at the end.) Alternately, you could write your own
> View object that passes the Layout ViewModel directly to a specific
> rendering engine, allowing it to treat each child as a block (much as
> Twig and Smarty do).
>
> Basically, this strategy for view models would answer each of the first
> three points above, giving us a layout-agnostic default strategy (though
> not entirely, as the aggregation of view models into a parent layout
> view model still must happen at some point), named captures, and
> renderers per-view model.
>
> Thoughts?
>
> --
> 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
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: View Layer -- ideas/opinions wanted

weierophinney
Administrator
-- Adam Lundrigan <[hidden email]> wrote
(on Wednesday, 08 February 2012, 11:17 AM -0330):

> In ZendSkeletonApplication the content placeholder is specified like so:
> <?php echo $this->raw('content'); ?>
>
> In your zf2sandbox you do this:
> <?php echo $this->placeholder('content'); ?>
>
> Neither worked for me when using your view-layer branch from github...the
> layout would render with the content placeholder area empty.  I had to use
> the following:
>
> <?php echo $this->content; ?>
>
> You did say in your mail that the GitHub branch impl and zf2sandbox usage
> example were out of sync, so I assume the above falls into that category?

I'll look into this -- there's actually tests for this in the current
feature/view-layer branch, but I'm wondering if I missed a behavior
somewhere.

> One question:  is there a fallback method for determining the template when
> a ViewModel is returned from the MVC without a template specified?  I like
> that the ViewListener setup in the skeleton app would attempt to render a
> view script :controller/:action.phtml when no template was explicitly set
> via the controller.  In my test app I hook into the dispatch event and
> inject the "auto" template name if one isnt already specified in the
> ViewModel.  I know some people dislike that kind of view "magic", but I am
> not one of those ;)

This is a planned feature -- still on my todo list. :) (Rob Allen was
asking about the same thing yesterday!)

--
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

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]