Quantcast

RFC - View Layer

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

RFC - View Layer

weierophinney
Administrator
I've posted the View Layer RFC:

    http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+View+Layer

I gave a sneak preview to some folks in the #zftalk.2 channel on
Freenode IRC late yesterday, and have incorporated some of the feedback
already, though more is still under discussion. Please review, and help
us finalize this part of the MVC!

--
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
|  
Report Content as Inappropriate

Re: RFC - View Layer

keith Pope-4
On 11 January 2012 17:21, Matthew Weier O'Phinney <[hidden email]> wrote:
> I've posted the View Layer RFC:
>
>    http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+View+Layer
>
> I gave a sneak preview to some folks in the #zftalk.2 channel on
> Freenode IRC late yesterday, and have incorporated some of the feedback
> already, though more is still under discussion. Please review, and help
> us finalize this part of the MVC!

Looks really good to me, I notice though there are no details on
escaping of view data, have I missed the discussions on this? Also
where do view helpers fit in, I suppose if you are having View Models
for user-land helpers you could place these within a custom View Model
right?

Maybe multiple action aggregation/merging could also be a strategy
like the renderer, giving us the option to select our preferred
method, this would also allow custom strategies.

Thx

Keith

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



--
------------
http://www.thepopeisdead.com

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC - View Layer

Jurian Sluiman
On Thursday 12 January 2012 10:54:12 keith Pope wrote:
> Looks really good to me, I notice though there are no details on
> escaping of view data, have I missed the discussions on this?

A while back (can't remember when) it was determined to get variables escaped
by default:

<?php echo $this->foo ?>           returns escaped 'foo'
<?php echo $foo ?>                     returns escaped 'foo'
<?php echo $this->raw('foo')?> returns raw 'foo'

> Also where do view helpers fit in, I suppose if you are having View Models
> for user-land helpers you could place these within a custom View Model
> right?

As of what I understood from Matthew, the Renderer is pretty untouched in this
RFC. It's rather the layer on top of rendering. The Renderer atm takes care of
view helpers, having a broker Zend\View\HelperBroker for
Zend\View\PhpRenderer.

However, I am not sure if there are plans to remove plugin handling from the
renderer and put it somewhere else.
--
Jurian Sluiman

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC - View Layer

weierophinney
Administrator
In reply to this post by keith Pope-4
-- keith Pope <[hidden email]> wrote
(on Thursday, 12 January 2012, 09:54 AM +0000):

> On 11 January 2012 17:21, Matthew Weier O'Phinney <[hidden email]> wrote:
> > I've posted the View Layer RFC:
> >
> >    http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+View+Layer
> >
> > I gave a sneak preview to some folks in the #zftalk.2 channel on
> > Freenode IRC late yesterday, and have incorporated some of the feedback
> > already, though more is still under discussion. Please review, and help
> > us finalize this part of the MVC!
>
> Looks really good to me, I notice though there are no details on
> escaping of view data, have I missed the discussions on this? Also
> where do view helpers fit in,

Currently in master and in ZF1, we have a _renderer_ -- in ZF2, we have
actually named it the PhpRenderer. The proposal does not affect it at
this time, but is instead a layer _above_ the renderer, and composes
renderers as well as strategies for selection of renderers.

The PhpRenderer in ZF2 right now auto-escapes data and composes a helper
broker - and we've had a ton of discussions on it in the past 6-9 months
on the list. :)

> I suppose if you are having View Models for user-land helpers you
> could place these within a custom View Model right?

Potentially, yes, depending on the implementation and usage -- right
now, however, they are renderer-specific.

> Maybe multiple action aggregation/merging could also be a strategy
> like the renderer, giving us the option to select our preferred
> method, this would also allow custom strategies.

I was even thinking an "AggregateRenderer" or some such might work.

At this point, though, I need some use cases and expected usage to be
able to better propose how we might handle this.


--
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
|  
Report Content as Inappropriate

Re: RFC - View Layer

gargoyle-3
In reply to this post by weierophinney
On 11 Jan 2012, at 17:21, Matthew Weier O'Phinney wrote:

> I've posted the View Layer RFC:
>
>    http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+View+Layer
>
> I gave a sneak preview to some folks in the #zftalk.2 channel on
> Freenode IRC late yesterday, and have incorporated some of the feedback
> already, though more is still under discussion. Please review, and help
> us finalize this part of the MVC!

DISCLAIMER - My overall understanding on the view stuff is pretty thin, so these thoughts could be the result of lack of understanding.

My initial thoughts are that ViewModel is a bad name! (Not entirely sure why any model would actually be called SomethingModel).

This could be what you were aiming for, but I was thinking that a view would be made of of nested viewSections. So you would have a top level ViewSection which would be the layout, then you could add subsections to it. (I'm not sure if there is a use case for the being more than one layout in any single response?)

Each ViewSection could be something like you are explaining with your ViewModel, it would get the variables assigned from the controller, and set the renderer, etc. This should allow for a single response to have sections made up from output from different modules layouts and even renderers.

I'll try and clarify with some code. Imagine this is a snippet from a controller action:-



// Get the top level view instance (Is the the V in MVC?)
// This could also implement a ViewSection interface.
$view = Zend\View::getInstance();

// Configure our section for this action.
$mySection = new Zend\View\Section();
$mySection->setRenderer('phpRenderer');
$mySection->setLayout('foo/bar/bazlayout');
$mySection->setScript('foo/bar/baz');
$mySection->addVariables(array('foo' => 'baz', 'bar' => 'buz'));

// Add it to the main view
$view->addVariable('content', $mySection);


Does that make sense? or have I totally missed the boat? (or just not explained it properly?)


Paul
(Gargoyle)


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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC - View Layer

weierophinney
Administrator
-- Paul Court <[hidden email]> wrote
(on Thursday, 12 January 2012, 04:31 PM +0000):

> On 11 Jan 2012, at 17:21, Matthew Weier O'Phinney wrote:
>
> > I've posted the View Layer RFC:
> >
> >    http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+View+Layer
> >
> > I gave a sneak preview to some folks in the #zftalk.2 channel on
> > Freenode IRC late yesterday, and have incorporated some of the feedback
> > already, though more is still under discussion. Please review, and help
> > us finalize this part of the MVC!
>
> DISCLAIMER - My overall understanding on the view stuff is pretty
> thin, so these thoughts could be the result of lack of understanding.
>
> My initial thoughts are that ViewModel is a bad name! (Not entirely
> sure why any model would actually be called SomethingModel).

ViewModel is actually a design pattern, often used with the "Model View
Presenter" pattern, or sometimes a "Model View ViewModel" pattern.
Google for "view model" or "fowler view model" to find some articles on
the pattern.

> This could be what you were aiming for, but I was thinking that a view
> would be made of of nested viewSections. So you would have a top level
> ViewSection which would be the layout, then you could add subsections
> to it. (I'm not sure if there is a use case for the being more than
> one layout in any single response?)

This is possible with the extends stack I proposed in the RFC (which was
suggested to me by Artur and Ryan), and is renderer-specific anyways. In
fact, this is is also achievable _now_ via render() (which allows
passing an array of variables or object variable container), and the
proposed changes to allow render() to receive a ViewModel object make
this even simpler to achieve (in your view script, call
$this->render($someVariableWhichIsAViewModel).

The RFC is really proposing a layer above renderers, for managing the
request, response, and attached renderers and coordinating them. How
sections/template inheritance/what have you work is really up to the
renderers and/or strategies you implement.

> Each ViewSection could be something like you are explaining with your
> ViewModel, it would get the variables assigned from the controller,
> and set the renderer, etc. This should allow for a single response to
> have sections made up from output from different modules layouts and
> even renderers.
>
> I'll try and clarify with some code. Imagine this is a snippet from a
> controller action:-
>
>
>
> // Get the top level view instance (Is the the V in MVC?)
> // This could also implement a ViewSection interface.
> $view = Zend\View::getInstance();
>
> // Configure our section for this action.
> $mySection = new Zend\View\Section();
> $mySection->setRenderer('phpRenderer');
> $mySection->setLayout('foo/bar/bazlayout');
> $mySection->setScript('foo/bar/baz');
> $mySection->addVariables(array('foo' => 'baz', 'bar' => 'buz'));
>
> // Add it to the main view
> $view->addVariable('content', $mySection);
>
>
> Does that make sense? or have I totally missed the boat? (or just not
> explained it properly?)


I'd argue this:

    $article = new ViewModel($someVars, array('template' => '/foo/bar/baz');

    $layoutContent = $view->render(
        'foo/bar/bazlayout',
        array('article' => $article)
    );

and then the script would do this:

    <html>
    <head>
        ...
    </head>
    <body>
        ...
        <article><?php echo $this->render($article) ?></article>
        ...
    </body>
    </html>

The renderer sees the ViewModel, determines the template to use from its
options, and then renders that template with the variables from the
ViewModel.

Alternately, use extends:

    <?php $this->extends('foo/bar/bazlayout'); ?>
    <?php $this->placeholder('article')->captureStart() ?>
    ...
    <?php $this->placeholder('article')->captureEnd() ?>

and your layout does a "echo $this->placeholder('article')".

I definitely see some interesting ideas in the syntax you propose -- but
I think it's the topic for a separate RFC at this point.

--
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
|  
Report Content as Inappropriate

Re: RFC - View Layer

weierophinney
Administrator
In reply to this post by weierophinney
-- Matthew Weier O'Phinney <[hidden email]> wrote
(on Wednesday, 11 January 2012, 11:21 AM -0600):
> I've posted the View Layer RFC:
>
>     http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+View+Layer
>
> I gave a sneak preview to some folks in the #zftalk.2 channel on
> Freenode IRC late yesterday, and have incorporated some of the feedback
> already, though more is still under discussion. Please review, and help
> us finalize this part of the MVC!

In order to test and play around with some of the proposed concepts,
I've begun a branch:

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

Do not take this to mean the RFC is approved -- it's simply to prototype
some of the ideas and see what we may need to add/change/etc. However,
if you're interested in the proposal, this is the place to look for
potential implementation.

--
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
|  
Report Content as Inappropriate

Re: RFC - View Layer

Stewart Lord
In reply to this post by weierophinney
On 12-01-11 9:21 AM, Matthew Weier O'Phinney wrote:
> I've posted the View Layer RFC:
>
>      http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+View+Layer
>
> I gave a sneak preview to some folks in the #zftalk.2 channel on
> Freenode IRC late yesterday, and have incorporated some of the feedback
> already, though more is still under discussion. Please review, and help
> us finalize this part of the MVC!
>


Hi Matthew,

Looks good! A few questions came to mind as I was reading the RFC:

1. This snippet suggests that the action decides the response format:

     public function bazAction()
     {
         $result = new JsonModel();
         ...

I trust that we wouldn't *have* to return a 'json' model to get json
output? We have actions that support several response formats and the
decision is often made without any explicit code in the action (e.g. by
the content switch plugin).

It seems that we could retain that behavior with a custom rendering
strategy. Is that correct?


2. Regarding the proposed use of 'extends' to replace the two step view:

// in a view script:
<?php $this->extends('layout/mobile'); ?>

This suggests that each view script would control whether or not a
layout is used. How does this interact with the 'use_layout' view model
option?

It also suggests that each template would need to indicate which layout
to use. If I have one or two layouts, but many templates would I need to
call extends (repeating the layout name) in every template?

We have some templates that do double duty as partial responses and full
page responses (the difference being the full page response uses a
layout and the partial responses don't). How would we achieve that
behavior with your proposed design?


3. How do you envision the JsonRenderer behaving? Currently we compose
the bulk of our JSON responses in 'phtml' scripts (using data
fetched/prepared by the action). This has the advantage that some
decision making *can* occur in the final rendering of the JSON response.
It also acts as an extension point because someone could add a template
to the view script stack and modify the response (otherwise they would
have to modify the action).


Thanks,
Stewart

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC - View Layer

weierophinney
Administrator
-- Stewart Lord <[hidden email]> wrote
(on Thursday, 12 January 2012, 10:39 PM -0800):

> On 12-01-11 9:21 AM, Matthew Weier O'Phinney wrote:
> > I've posted the View Layer RFC:
> >
> >     http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+View+Layer
> >
> > I gave a sneak preview to some folks in the #zftalk.2 channel on
> > Freenode IRC late yesterday, and have incorporated some of the feedback
> > already, though more is still under discussion. Please review, and help
> > us finalize this part of the MVC!
>
> Looks good! A few questions came to mind as I was reading the RFC:
>
> 1. This snippet suggests that the action decides the response format:
>
>     public function bazAction()
>     {
>         $result = new JsonModel();
>         ...
>
> I trust that we wouldn't *have* to return a 'json' model to get json
> output? We have actions that support several response formats and
> the decision is often made without any explicit code in the action
> (e.g. by the content switch plugin).
>
> It seems that we could retain that behavior with a custom rendering
> strategy. Is that correct?

Correct. The idea is that you can hint what rendering strategy you wish
to select via the ViewModel you return -- but you can always use a
generic ViewModel implementation. In fact, my recommendation is that if
you are building a re-usable module, you _always_ return the generic
ViewModel implementation so that end-users can use custom rendering
strategies to select the output format/renderer.

> 2. Regarding the proposed use of 'extends' to replace the two step view:
>
> // in a view script:
> <?php $this->extends('layout/mobile'); ?>
>
> This suggests that each view script would control whether or not a
> layout is used. How does this interact with the 'use_layout' view
> model option?

This is simply one way to do it, and the question you raise is one I
raised to both Artur and Ryan, who initially suggested this potential
usage. Basically, if you make it explicit, you're also making it
non-reusable.

One way to get around this is to set up the "extends" information
_outside_ the view script. In Smarty, for instance, you can do this at
render time:

    $smarty->display('extends:layout.tpl|myproject.tpl|mypage.tpl');

In this case, you'd have some logic in the renderer that would then
build up the inheritance chain for you (the above would render mypage,
then myproject, then layout, essentially -- and mypage and myproject
would populate blocks for layout).

What's interesting about the above usage is that you could have a
listener inject the extension chain when a layout is required, and omit
it when not. More on that below.

> It also suggests that each template would need to indicate which
> layout to use. If I have one or two layouts, but many templates
> would I need to call extends (repeating the layout name) in every
> template?

See the above. :)

> We have some templates that do double duty as partial responses and
> full page responses (the difference being the full page response
> uses a layout and the partial responses don't). How would we achieve
> that behavior with your proposed design?

This was my second question to Artur and Ryan -- because, like you, I
often enable/disable layouts based on request type. I think this is an
important criteria, as it allows re-use of actions for multiple response
types.

So, basically, you wouldn't use template inheritance in such situations,
or you'd have listeners/strategies that would inject the template
inheritance if and only if a layout is required.


> 3. How do you envision the JsonRenderer behaving? Currently we
> compose the bulk of our JSON responses in 'phtml' scripts (using
> data fetched/prepared by the action). This has the advantage that
> some decision making *can* occur in the final rendering of the JSON
> response. It also acts as an extension point because someone could
> add a template to the view script stack and modify the response
> (otherwise they would have to modify the action).

The dirt-simple JsonRenderer I plan on building will simply serialize
the variables from the ViewModel, potentially using options from the
ViewModel to determine which variables might need to be omitted.

However, I'd expect that in most applications, how you want to render
JSON will be highly specific -- for instance, you may want to include
status codes, metadata, etc. in addition to the main payload. As such,
I'd expect you'd write custom renderers, and attach your own strategies
that then select these renderers.

--
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
|  
Report Content as Inappropriate

Re: RFC - View Layer

Stewart Lord
Thanks Matthew, sounds like you have the bases covered.

Cheers,
Stew


On 12-01-13 6:56 AM, Matthew Weier O'Phinney wrote:

> -- Stewart Lord<[hidden email]>  wrote
> (on Thursday, 12 January 2012, 10:39 PM -0800):
>> On 12-01-11 9:21 AM, Matthew Weier O'Phinney wrote:
>>> I've posted the View Layer RFC:
>>>
>>>      http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+View+Layer
>>>
>>> I gave a sneak preview to some folks in the #zftalk.2 channel on
>>> Freenode IRC late yesterday, and have incorporated some of the feedback
>>> already, though more is still under discussion. Please review, and help
>>> us finalize this part of the MVC!
>>
>> Looks good! A few questions came to mind as I was reading the RFC:
>>
>> 1. This snippet suggests that the action decides the response format:
>>
>>      public function bazAction()
>>      {
>>          $result = new JsonModel();
>>          ...
>>
>> I trust that we wouldn't *have* to return a 'json' model to get json
>> output? We have actions that support several response formats and
>> the decision is often made without any explicit code in the action
>> (e.g. by the content switch plugin).
>>
>> It seems that we could retain that behavior with a custom rendering
>> strategy. Is that correct?
>
> Correct. The idea is that you can hint what rendering strategy you wish
> to select via the ViewModel you return -- but you can always use a
> generic ViewModel implementation. In fact, my recommendation is that if
> you are building a re-usable module, you _always_ return the generic
> ViewModel implementation so that end-users can use custom rendering
> strategies to select the output format/renderer.
>
>> 2. Regarding the proposed use of 'extends' to replace the two step view:
>>
>> // in a view script:
>> <?php $this->extends('layout/mobile'); ?>
>>
>> This suggests that each view script would control whether or not a
>> layout is used. How does this interact with the 'use_layout' view
>> model option?
>
> This is simply one way to do it, and the question you raise is one I
> raised to both Artur and Ryan, who initially suggested this potential
> usage. Basically, if you make it explicit, you're also making it
> non-reusable.
>
> One way to get around this is to set up the "extends" information
> _outside_ the view script. In Smarty, for instance, you can do this at
> render time:
>
>      $smarty->display('extends:layout.tpl|myproject.tpl|mypage.tpl');
>
> In this case, you'd have some logic in the renderer that would then
> build up the inheritance chain for you (the above would render mypage,
> then myproject, then layout, essentially -- and mypage and myproject
> would populate blocks for layout).
>
> What's interesting about the above usage is that you could have a
> listener inject the extension chain when a layout is required, and omit
> it when not. More on that below.
>
>> It also suggests that each template would need to indicate which
>> layout to use. If I have one or two layouts, but many templates
>> would I need to call extends (repeating the layout name) in every
>> template?
>
> See the above. :)
>
>> We have some templates that do double duty as partial responses and
>> full page responses (the difference being the full page response
>> uses a layout and the partial responses don't). How would we achieve
>> that behavior with your proposed design?
>
> This was my second question to Artur and Ryan -- because, like you, I
> often enable/disable layouts based on request type. I think this is an
> important criteria, as it allows re-use of actions for multiple response
> types.
>
> So, basically, you wouldn't use template inheritance in such situations,
> or you'd have listeners/strategies that would inject the template
> inheritance if and only if a layout is required.
>
>
>> 3. How do you envision the JsonRenderer behaving? Currently we
>> compose the bulk of our JSON responses in 'phtml' scripts (using
>> data fetched/prepared by the action). This has the advantage that
>> some decision making *can* occur in the final rendering of the JSON
>> response. It also acts as an extension point because someone could
>> add a template to the view script stack and modify the response
>> (otherwise they would have to modify the action).
>
> The dirt-simple JsonRenderer I plan on building will simply serialize
> the variables from the ViewModel, potentially using options from the
> ViewModel to determine which variables might need to be omitted.
>
> However, I'd expect that in most applications, how you want to render
> JSON will be highly specific -- for instance, you may want to include
> status codes, metadata, etc. in addition to the main payload. As such,
> I'd expect you'd write custom renderers, and attach your own strategies
> that then select these renderers.
>

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


Loading...