ZF2 layouts

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

ZF2 layouts

Mike A
This post has NOT been accepted by the mailing list yet.
This post was updated on .
Sharing my experience in the hope it will assist a few folk...

I'd taken a couple of days to understand layout and views in the context of ZF2 skeleton. The process threw up a few small unexpected issues -- after adding a second module to the skeleton (see, this for example, which no new entrant to ZF2 should be without!).

Long story short: I had two modules, each with its own view and layout -- but only one layout displayed.

From the Application module layout I had echoed "Application layout". From the other module, the same as in Akrabat's "Getting started..." tutorial (which I had named "Group") I echoed "Group layout". In the Index view script for each module I put two links: one to Application ("Home"), the other to Group. Nothing surprising so far. Except, that is, upon first browser access to the application I saw "Application layout"; after clicking the link to Group I saw "Group layout"; and after clicking the link back to Application I saw "Group layout" when I expected it should display "Application layout".

After some help and a bit of code from MWO on IRC (thanks!) I came to know that 1) my perception of ZF2 layout and view rendering was flawed (didn't surprise me), and 2) there are ways to achieve what I was doing but they are complex, unnecessary, and to be avoided.

1)...

First mistake was a highly successful attempt to foul up the intelligent hard work of ZF2 framework core developers by misapplying module orders in config/application.config.php...

    'modules' => array(
        'Application',
        'Group',
    ),

I had failed to take on board that when folk say that configs are merged with last configuration taking priority it means CONFIGS ARE MERGED WITH LAST CONFIGURATION TAKING PRIORITY. Of course they are! An array merged with another array results in the last element overwriting what was there. In my case I was overwriting the route/path to Application layout with a layout in a completely different place to the home module. I should have written...

    'modules' => array(
        'Group',
        'Application',
    ),

Small mistake -- huge difference. Also, a difference I would not so easily have spotted had I not marked each module's layout and view script files with a message displaying what they were.

Easy and trivial once I knew how. Maybe.

I'm now wondering whether the results of the forum thread about configs should flag the need for diligence when ordering, especially in applications with a lot of modules.

Beware the order of loading modules!


My second mistake was to presume the need for a separate layout template in each module (under module/<module_name>/views/layouts). That's why, in the mistake explained above, the application actually worked by finding an alternative layout to display. Working == no exception to report. I could have gone around in circles for days.

To my mind, not only should there be no need to include layouts in modules other than the Application module (not referring to view scripts, of course), it is a conceptual mistake to try to do so. A layout template belongs at the end of processing: after all modules/services/models have done their work. View output should come from the last-loaded (top-layer) module -- in ZendSkeletonApplication, the Application module (which would be more meaningful if it had two modules!).


2)...

What, though, if an application needs an additional module to produce a layout?

It was explained in IRC, with a code example, that I could register a listener in the module's Module.php class, starting with...

class Module
{
    public function init()
    {
        $events = StaticEventManager::getInstance();
        $events->attach('bootstrap', 'bootstrap', array($this, 'bootstrap'));
        ...

After considering observations in 1) above, I thought I'd leave that one to see what IRC discussions ensue during preparation for Beta 3.[1]

Given that relying on returning results so the Application layout can deliver them seems conceptually trivial, it occurred to me that it would be a positive move to form a protective organisation. The organisation would have people armed with sharp sticks who would seek out and with vigour poke any developer that tries to produce applications with multiple module layouts.

Returning results to view so the Application layout can deliver it works well enough.



My observations: hopefully they will save someone some time.


[1] It seems from IRC that views/layouts/renderers/placeholders will come under scrutiny for Beta 3 release (core developers about to give birth to Beta 2 -- keep pushing!).
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 layouts

omerida
This post has NOT been accepted by the mailing list yet.
On 12/07/2011 07:09 AM, Mike A [via Zend Framework Community] wrote:

> Sharing my experience in the hope it will assist a few folk...
>
> I'd taken a couple of days to understand layout and views in the
> context of ZF2 skeleton
> <https://github.com/zendframework/ZendSkeletonApplication>. The
> process threw up a few small unexpected issues -- after adding a
> second module to the skeleton (see, this
> <http://akrabat.com/getting-started-with-zend-framework-2/> for
> example, which no new entrant to ZF2 should be without!).
>
> Long story short: I had two modules, each with its own view and layout
> -- but only one layout displayed.
>
> From the Application module layout I had echoed "Application layout".
> From the other module, the same as in Akrabat's "Getting started..."
> tutorial (which I had named "Group") I echoed "Group layout". In the
> Index view for each module I put two links: one to Application
> ("Home"), the other to Group. Nothing surprising so far. Except, that
> is, upon first browser access to the application I saw "Application
> layout"; after clicking the link to Group I saw "Group layout"; and
> after clicking the link back to Application I saw "Group layout" when
> I expected it should display "Application layout".
>
> After some help and a bit of code from MWO on IRC (thanks!) I came to
> know that 1) my perception of ZF2 layout and view rendering was flawed
> (didn't surprise me), and 2) there are ways to achieve what I was
> doing but they are complex, unnecessary, and to be avoided.
>
> 1)...
>
> First mistake was a highly successful attempt to foul up the
> intelligent hard work of ZF2 framework core developers by misapplying
> module orders in config/application.config.php...
>
>     'modules' => array(
>         'Application',
>         'Group',
>     ),
>
> I had failed to take on board that when folk say that configs are
> merged with last configuration taking priority it means CONFIGS ARE
> MERGED WITH LAST CONFIGURATION TAKING PRIORITY. Of course they are! An
> array merged with another array results in the last element
> overwriting what was there. In my case I was overwriting the
> route/path to Application layout with a layout in a completely
> different place to the home module. I should have written...
>
>     'modules' => array(
>         'Group',
>         'Application',
>     ),
>
> Small mistake -- huge difference. Also, a difference I would not so
> easily have spotted had I not marked each module's layout and view
> files with a message displaying what they were.
>
> Easy and trivial once I knew how. Maybe.
>
> I'm now wondering whether the results of the forum thread about
> configs
> <http://zend-framework-community.634137.n4.nabble.com/ZF2-usage-of-constants-in-configs-td4127848.html> should
> flag the need for diligence when ordering, especially in applications
> with a lot of modules.
>
> Beware the order of loading modules!
>
> My second mistake was to presume the need for a separate layout
> template in each module (under module/<module_name>/views/layouts).
> That's why, in the mistake explained above, the application actually
> worked by finding an alternative layout to display. Working == no
> exception to report. I could have gone around in circles for days.
>
> To my mind, not only should there be no need to include layouts in
> modules other than the Application module (not referring to view
> scripts, of course), it is a conceptual mistake to try to do so. A
> layout template belongs at the end of processing: after all
> modules/services/models have done their work. View output should come
> from the last-loaded (top-layer) module. -- the Application module in
> ZendSkeletonApplication.
>
>
> 2)...
>
> What, though, if an application needs a module to produce a layout?
>
> It was explained in IRC, with a code example, that I could register a
> listener in the module's Module.php class...
>
> class Module
> {
>     public function init()
>     {
>         $events = StaticEventManager::getInstance();
>         $events->attach('bootstrap', 'bootstrap', array($this,
> 'bootstrap'));
>         ...
>
> Given observations in 1) above, I thought I'd leave that one to see
> what IRC discussions ensue during preparation for Beta 3.[1]  It
> occurred to me that it would be a positive move to form an
> organisation of people armed with sharp sticks who would seek out and
> with vigour poke any developer that tries to produce applications with
> multiple module layouts.
>
> Returning results to view so the Application layout can deliver it
> works well enough.
>
> My observations: hopefully they will save someone some time.
>
>
> [1] It seems from IRC that views/layouts/renderers/placeholders will
> come under scrutiny for Beta 3 release (core developers about to give
> birth to Beta 2 -- keep pushing!).
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the
> discussion below:
> http://zend-framework-community.634137.n4.nabble.com/ZF2-layouts-tp4168716p4168716.html
>
> To start a new topic under ZF Contributor, email
> [hidden email]
> To unsubscribe from ZF Contributor, click here
> <
> NAML
> <
http://zend-framework-community.634137.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
Thanks for sharing your experiences, I was dealing with Layout stuff
myself last night. What if a controller method needs to return output
like json/xml that should not be wrapped in a layout?  Is there an easy
eay to disable the layout from a controller?

The way I managed to do this was to have the controller directly set the
content of the response object.  Then in the view listener that merges
the controller view with the layout, if the response content is already
set, it returns the response object without further processing.  Is that
the right approach?


Note to self: checkout IRC channel