Zend Framework forms, decorators and validation: s

2019-01-16 05:37发布

I am currently working on a pretty large application which contains a lot of forms.

Up to this moment, I have always been writing my forms by hand and writing my own validation logic, but I have decided it was about time I started using Zend_Form and it's built-in validation routines.

However, I keep stumbling upon more and more problems concerning the (lack of) flexibility caused Zend_Form_Decorator. Simple tasks like adding an extra button to a single input-element become incredibly difficult tasks.

I have now reached a point where I am seriously considering dropping the Zend_Form_Element + Zend_Form_Decorator approach entirely, but I do not want to lose the excellent validation options.

Basically, I want the best of both worlds:

  • Write forms the way the end-user sees them: in plain HTML
  • Easily add server-side validations to form fields without breaking too much of the ZF standard behaviour

A possible solution I am considering is writing the forms both on the server side as in the views. This would allow me to easily validate my own forms, but the (in my eyes quite big) downside is that each form should be defined twice, which just feels plain wrong.

Are there any guidelines to do this? Have any of you experienced the same, and if so, how have you solved these issues?

I'd very much like to hear your points of view.

10条回答
Lonely孤独者°
2楼-- · 2019-01-16 06:20

I too find the default decorators to be a massive pain. I understand why they are the way they are, but I think the 'inconvenience factor' has been grossly underestimated.

Anyway, I would recommend using ViewScripts for your forms. Note that these are not the same as Views -- instead, ViewScripts are referenced explicitly in your Form class, act as a "sub-view" of sorts and allow you to control the layout of each and every element. Examples how to use ViewScripts have been somewhat hard to find in the past, but I'll try to take a stab at providing something useful.

First, override loadDefaultDecorators in your form class:

public function loadDefaultDecorators() {
     $this->setDecorators(
         array(
             array('ViewScript', 
                 array('viewScript' => 'foo/bar.phtml')
             )
          )
      );        
} 

This will reference a ViewScript named bar.phtml located in /views/scripts/foo. Note the case-sensitive differences in "ViewScript" and "viewScript" above.

Next, you'll have to tweak the decorators applied to each element to ensure it displays but without the annoying dt/dd wrappers. For instance:

$baz = new Zend_Form_Element_Text('bazInput');
$baz->setDecorators(array('ViewHelper','Errors')); 

Finally, you'll need to build your ViewScript, such as:

<form method="post" action="<?php echo $this-element->getAction() ?>">
    <table>
        <tr>
            <td><label for="bazInput">Baz:</label></td>
            <td><?php echo $this->element->bazInput ?></td>
        </tr>
    </table>
    <input type="submit" value="Submit Form" />
</form>

Obviously this is a very simple example, but it illustrates how to reference the form elements and form action.

Then in your View, simply reference and output your form as usual. This way you can have much finer control over your form layouts -- to include easily adding Javascript.

I believe this approach resolves both your requirements: you can build forms in plain HTML and still take advantage of the Zend Form validation mechanism.

查看更多
不美不萌又怎样
3楼-- · 2019-01-16 06:23

If you want validators and filters without the forms: Zend_Filter_Input

22.5. Zend_Filter_Input

Zend_Filter_Input provides a declarative interface to associate multiple filters and validators, apply them to collections of data, and to retrieve input values after they have been processed by the filters and validators. Values are returned in escaped format by default for safe HTML output.

Although - My personal suggestion is to learn to craft custom decorators and view helpers. Zend_Form is very powerful, and I've never had problems trying to position/decorate things. Even when building a complex table of permissions and auto generating columns and rows using jQuery - I found the Zend_Form interfaces a time saver. If you have a specific question about how to approach Decorating something I'll gladly help. Open a new question and comment it here or something....

查看更多
姐就是有狂的资本
4楼-- · 2019-01-16 06:24

Here's what I've learned with Zend_Form:

Let it do it's thing, and it will save you a ton of lines of code in the long run.

The trade off is you end up writing more CSS to get things to display the way you want to. Remember, almost any HTML element can be styled to look like anything. By default, Zend_Form gives you plenty of CSS selectors to get as specific (or broad) as you need to get. I've yet to see a case where I couldn't work the default decorators in to exactly what I wanted them to be.

Granted, I have a big, ugly CSS file, but in my experience, it would probably be a big, ugly CSS file eventually anyways. I take the trade off of not worrying about application specific form coding/validation/filtering/handling/etc but dealing with some specifically styled elements in a CSS file.

Tip if you decide to go this route: make sure you're using a CSS style reset script

查看更多
淡お忘
5楼-- · 2019-01-16 06:27

I have been using as many Zend components as possible over the past 10 months, on a large project, and Zend_Form has been the biggest pain in the ***. The forms are slow to render, and hard to make pretty. Don't even get me started on Sub-Forms. I saw an interesting article called "scaling zend_form" but it didn't seem to help much with render speed :(

I am thinking about making all my forms using straight HTML in the view, and only using Zend_Form to do the validation and filtering (not rendering). Either that, OR I will just use Zend_Validate and Zend_Filter, without the Form aspect at all.

A tool is only a tool if it helps you. Otherwise, it's just a hindrance.

查看更多
登录 后发表回答