Widgetize your app! Reusing code needed to show blocks of content in ZF2 with Controller Plugins and child views

So you are developing a ZF2 application and you have a block of content which needs to be insert in several places within your application. Using a forward could work but it renders the whole page, not the part you are interested in. So here comes in the rescue two concepts: controller plugins and child views.

Here is how it looks a controller action with this method:

It looks good, isn’t it ?
“employer” is registered as controller plugin.
We create a parent view called $viewModel. The child view is returned by the plugin method getProfile(). It is then inserted as child to $viewModel and made available as “employerInfo”.

In the view:

And here is a trick to show variables from the child view inside the parent view:

In order to accomplish all this, we need to create the controller plugin:

and register it in the service manager:

THe only thing remaining to do is to create the view for the content block. In our example it is located in module/Employer/view/employer/plugin/info.phtml

Now you can insert this content block in another place by adding a different controller action, which renders a custom parent view.

In the view you can put whatever you want, and include $this->employerInfo in the place where you want to render the content block.

What about having different links ?

In some situations, your content blocks may contain links or actions to use different URLs. These need to be dynamic also. I’ve created a view helper for this.

Here is the helper class:

To use it I pass an array with link information to the controller plugin. Bare with be because I will explain later how this array will be used.
controller code

from inside the plugin method I make the links var available for the view:

plugin code:

Finally I use the PluginLink helper to create the URLs. pluginLink has two parameters.
The first parameter contains the link configuration array, having some keys like: route, param, options.
The second parameter contains a list of variables used to replace those $ placeholders inside the link definition.
$0 is replaced by the first item. $1 is replaced by the second item and so on.

view code:

Notice the line with ‘secondary_id’ => ‘$0’ on the $options definition from controller ? This will instruct the helper to create an url having the link definition in “view” and replace the secondary_id route param with the first array item given (the user id).

Here is an extended example where I pass dynamic query params:
controller code:

the view for this link:

Conclusions

Using controller plugins is an easy method of reusing controller related code, and child views allows for easy reuse of view blocks. You can have in your plugin logic to get the route params and use them to filter results or make decisions. Having a viewModel (child view model) returned allows for html rendering as is, or using only the variables declared within it in order to create a totally different view.

You could use a normal service instead of a controller plugin, but controller plugins are types of services especially provided by the framework for handling controller related logic – you have the getController() method included and they are available on all your controllers.

Share This:

Leave a Reply

Your email address will not be published. Required fields are marked *