If you’ve been using Zend Forms for any length of time, you’ll know just how flexible and configurable they are. There’s not much that you can’t do with them, But it’s not always easy and there are catches. Today we look at ensuring that module-based Zend Forms using the ViewScript decorator can always be initialised no matter what.
If you’ve been using Zend Forms for any length of time, you’ll know just how flexible and configurable they are. Whether you’re initialising them in code or via Zend_Config with one of the adapters Zend_Config_Xml, Zend_Config_Ini, Zend_Config_Json, Zend_Config_Yaml. There’s not much that you can’t do with them, besides link them to a database model for validation - but that’s another story.
What’s more, we can, as I’m quite fond of, use the ViewScript decorator. This allows us to have nearly 100% control of the configuration of the look and feel of our rendered forms. Take the following script template, of a user profile form, as an example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
<td class="code">
<pre class="php" style="font-family:monospace;"><form action="<span style="color: #000000; font-weight: bold;"><?php</span> <span style="color: #b1b100;">print</span> <span style="color: #000088;">$this</span><span style="color: #339933;">-></span><span style="color: #004000;">escape</span><span style="color: #009900;">(</span><span style="color: #000088;">$this</span><span style="color: #339933;">-></span><span style="color: #004000;">element</span><span style="color: #339933;">-></span><span style="color: #004000;">getAction</span><span style="color: #009900;">(</span><span style="color: #009900;">)</span><span style="color: #009900;">)</span><span style="color: #339933;">;</span> <span style="color: #000000; font-weight: bold;">?></span>"
method="<?php print $this->escape($this->element->getMethod()); ?>"
name="<?php print $this->escape($this->element->getName()); ?>"
id="<?php print $this->escape($this->element->getId()); ?>"
class="<?php print $this->escape($this->element->getAttrib(‘class’)); ?>">
<div>
<fieldset>
<legend><?php print $this->translate(‘Profile Details:’); ?></legend>
<div class=“control-group”>
<label class=“control-label” for=“username”>
<?php print $this->element->username->getLabel(); ?>
</label>
<div class=“controls”>
<?php print $this->element->username; ?>
</div>
</div>
<div class=“control-group”>
<label class=“control-label” for=“email”>
<?php print $this->element->email->getLabel() ?>
</label>
<div class=“controls”>
<?php print $this->element->email ?>
</div>
</div>
<div class=“form-actions”>
<?php print $this->element->submit; ?>
<?php print $this->element->cancel; ?>
</div>
</fieldset>
</div>
</form>
You can see that we can layout forms exactly where and when we want them. There is a bit of a catch that we have to remember all the options that we want to display, but that’s not really an overarching concern.
Caveat Emptor
But buyer beware, there is a catch. Depending on how long you’ve been using them you may or may not have come across the situation where involving the viewScript decorator. That is, it’s alright when the form’s being rendered in the module that it’s created in, but in any other module, it fails to find the view template.
What’s The Solution
If you’ve come across this situation, there is a solution. When you’re using the ViewScript decorator, pass the viewModule parameter as an argument when initialising it.
Similar to rendering partials within other view template scripts, the viewModule parameter provides a module-specific path for finding view script templates. Have a look at the following example to see just how simple it is:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<td class="code">
<pre class="php" style="font-family:monospace;"><span style="color: #000000; font-weight: bold;">class</span> Default_Form_MyForm <span style="color: #000000; font-weight: bold;">extends</span> Zend_Form
{
public function init()
{
// … other form initialisation …
// do custom rendering of the form
$this->setDecorators(array(
array(‘ViewScript’, array(
// the view template script
‘viewScript’ => ‘forms/myformtemplate.phtml’,
// the module that contains our view templates
‘viewModule’ => ‘default’
))
));
}
}
We have now specified that the viewScript template will be under application/module/default/forms/. So irrespective of where in the application this form is initialised, if the template is in that location, the form will render with it correctly.
Your Thoughts
Having troubles with the viewScript decorator? Put your thoughts in the comments.
Image courtesy: kiler129
During the recent development of the new PHP cloud development casts site, which has been developed with the Zend Framework, so much development time has been saved by using one of the simplest and arguably best features of the framework: Controller Plugins. So today I want to introduce you to them and walk you through a working plugin so you can see just how effective and efficient they can make your development workflow.
Welcome to the fourth and final part in the Zend Form Mastery with Zend Config series. Previously we looked at the basic form options, element and form wide prefixes, filters and element options. In this installment, we’re going to look at configuring Zend Validators via our XML config.
When you’re working with Zend Form you keep your configuration as much out of code as you can - right? Well, if you’ve been working withZend Form for more than a little while, you know that Zend Config really makes that pretty simple - well, some of the time. In this series we look, comprehensively at how to do it all with Zend_Config.
If I have seen further it is by standing on the shoulders of giants.
It’s a really exciting time at the moment with Zend Framework 2 gaining so much traction, after being stable for some time now.
Though I and countless others really enjoyed the 1.x series, it did leave some things to be desired - to be fair.
But the more I explore of the 2.x series, the more I honestly can say that I’m very impressed with it. It may not be as fast as the previous series, but with respect to development, there’s so much going for it it’s worth shouting about.
So it really is rewarding and exciting to begin covering all that it has to offer us. In part one of this series, I looked at a central concept of the revised framework - Dependency Injection.
Join the discussion
comments powered by Disqus