Zend Form: How Do I Make It Bend By My Will?

Question

I read the manual many times, I looked through the posts Google offers on this subject, I even bought a couple of books that deal with ZF. Now why am I still confused?

I can, using Zend_Form, create a form that validates and functions normally. What I cannot do is make the form look as if I want it to look with the error messages I want to have. I need custom buttons, I need funky layouts, I want to insert text in the middle of the form, etc.

Does anyone have an easy way to achieve this kind of thing? Something that makes me feel like structure is saving me, not worth it? I could refuse the Zend form ... create my own form, get its action to go to the page to check and process the published data, and I could do it as fast as I can print, but I really want to "get "this and be able to use it as it was, apparently, intended.

Any tips? Any simple “ways” for custom buttons, funky layouts, and basic ones (or rather, advanced ones, because there are tons of basic tutorials that miss more complex problems) is “done” with the zend form?

Answer 1

Barrett Conrad's advice is what I would suggest. Also, keep in mind that you do not need to use the form object to render your form.

One thing you can do is create a form in your script view that has elements with the same name as the form class.

Your HTML form:

<form action="/login/" method="post"> <fieldset> <label for="username">Username:</label> <input type="text" size="10" name="username" /> <label for="password">Password:</label> <input type="password" size="10" name="password" /> <input type="submit" /> </fieldset> </form> 

Your class:

 class LoginForm extends Zend_Form { public function init() { $username = $this->createElement('text','username'); $username->setRequired(true); $this->addElement($username); $password = $this->createElement('password','password'); $password->setRequired(true); $this->addElement($password); } } 

Your form class reflects your HTML form, each element of your class has its own validators and requirements. In your action, you can instantiate your form class and check your posts / get vars against this form:

 $form = new LoginForm(); if ($this->_request->isPost()) { if ($form->isValid($this->_request->getParams())) { // do whatever you need to do } else { $this->view->errors = $form->getMessages(); } } 

You can display error messages at the top of the form in one group using this method.

This is a basic example, but it allows you to fully control the presentation of your form without spending time studying decorators. In my opinion, a significant part of Zend_Form is in its validation and filtering properties. It gives you strength. The main inverse to a solution like this is that your HTML script submission form may become unsynchronized with your form class.

Answer 2

Mark each item individually in your view - for example

 <!-- view script here --> <form method="POST"> Name: <?php echo $this->myForm->getElement('name')->render(); ?> some other text between the fields Birthdate: <?php echo $this->myForm->getElement('birthdate')->render(); ?> <input type="submit" /> </form> 

This supports the ability to use helpers of the Zend_Form type (i.e. display error messages and maintain the values ​​of form fields when validation fails), but gives you full customization options.

If you want to go further, turn off the standard decorators of individual form elements, and then attach your own to further configure exactly which tags are used (that is, for error messages and labels) or do not use decorators for everything (except for displaying the form element itself), and then write all the surrounding HTML manually. Full customization without losing the benefits of Zend_Form, both at the form level and at the presentation level.

Answer 3

Matthew Weier O'Phinney has launched a series of blog posts about Zend_Form decorators:

• The simplest Zend_Form decorator
• Inside: How to Fold Decorators
• Customizing Zend_Form Decorators
• Creation of compound elements

Answer 4

We currently have the new and brilliant Zend\Form , which is even more complex than the old, but also much more manageable, encapsulated and powerful. So, what I said below does not apply. The new IMHO component is a huge improvement because it ...

• ... gives you complete control over how you want to display your form, you need to write a little more view code, but it's worth it
• ... separates data, logic, and presentation as much as possible.
• ... uses HTML5 form elements
• ... gives you many options on how you want to combine your forms, for example. hydration, annotation, etc.

Old answer about Zend_Form

I can't really help because I have exactly the same problem. I think that Zend_Form decorators are powerful, but certainly the least simple for programmers and non-intuitive ZF elements that I have seen so far, and I used most of ZF in various projects.

I said that I can only give some advice from my experience:

• filters are easy to use without using a form
• most, if not all, of the things you want to achieve are done with decorators.
• I started with small forms and added the material in parts, but I don’t get some things that I do in some of my forms, because the result is based on the trial version and the error (mainly with decorators)
• I have information from a zend mail list that I could not find anywhere on the Internet.

From the related questions on the right side, it is obvious that there is no complete documentation for Zend_Form, especially considering its non-intuitive nature. I would really like the ZF guys to do something in this regard as much as I like the Zend Framework.

So this answer is likely to just let you know that you are not the only one who has this problem.

---

or, alternatively, you can use Jedi skill tricks , of course!

Answer 5

To add to the above:

Do not be afraid of decorators, you will use them a lot if you decide to stick with Zend_Form. It's pretty simple as soon as you get it, "unfortunately, the documents are weak, and playing with it is almost the only way to get there.

ViewScript and ViewHelper decorators give you a lot of energy.

Don't be afraid to dig a source for the different decorators that exist and see how they do things (I got enough insight when comparing original decorators with dojo).

I think that Sean suggested that you do not need to call form-> render, you can use something like this in your viewcript.

  <someHtmlThingy name="blah" value="<?php echo $this->formInstance->getElement('whatever')->getValue(); ?>" /> 

I worked on one project (pre Zend_Form), where we built sets of validators and used standard viewing scripts throughout. It was a bit more work (plumbing for error messages, etc.), but not excessive compared to creating elements with Zend_Form.

Answer 6

If you just want to add custom markup before or after form elements without using the ViewScript decorator, you can use my AnyMarkup decorator: http://www.zfsnippets.com/snippets/view/id/62

For example, here you can add an input field with an image inside the wrapper tag (for this you need to specify the paths for automatic loading):

 $ form-> addElement ('text', 'my_field', array (
   'label' => 'Enter Info:',
   'decorators' => array (
     'ViewHelper',
     array ('AnyMarkup', array (
       'markup' => '<span class = "imgwrapper" & gt'.
         '<img src = "info.png" alt = "info icon" /> </span>'),
       'placement' => 'prepend'
     ),
     'HtmlTag',
     'Label'
   )
 );

Answer 7

Skipping on form decorators (IE - printing individual form elements, and not just using the standard View Form helper to handle everything) is one way to get a ton of control.

Another option is to simply manually format the form and use ZF only for validation and filtering.

Answer 8

Unfortunately, more complex problems are missed, because without a real specific goal or goal it is very difficult to write an example or instructions. I spent some time helping another developer here on SO who wanted to change the way that hidden elements are displayed , but his case was very specific, so it was easier to deploy the specifics.

Most of the more complex tasks really come down to extending the default helper for a specific type of field. For example, I had a project in which I wanted to apply the error class to all fields that did not pass validation after the form was submitted instead of writing the text of the validation error:

 <label for="field">Label:</label> <input type="text" name="field" id="field" class="error"> 

This was a rather complicated process because the actual form element is not available to the default view helper, so the helper cannot check if the element has a validation error. So I went through the following process:

• I needed to create a client view assistant for each type of field to which I wanted to apply the "error" class. In it, I overridden the formXXX() method and added a check to see if the element had an error. In addition, I added the setElement() method, which the decorator could call to set up an instance of the element so that my assistant could check for errors.
• Then I had to override the default value of Zend_Form_Decorator_ViewHelper . In it, I turned to the view and created a helper instance for the type of the form element and checked the existence of the setElement() method, which I created in my view helper, setting it if it exists. By doing this, I could extend some types of element elements, and not others, without breaking the entire script.
• In my init () function, for each form I had to add a new element prefix path ( addElementPrefixPath('My_Form_Decorator'), 'path/to/decorator') ), which pointed to my new form decorator.
• Finally, I had to add an auxiliary path to my application so that the Zend Framework could find the helpers that I created in the first paragraph: addHelperPath('/path/to/helpers', 'My_View_Helper');

You can understand why writing complex textbooks really requires real problems. The big role in creating such helpers or complex decorator schemes is that all this is annoying in the first place, it allows you to very easily create many forms that adhere to the same design scheme and very quickly change their output if changes need to be made . But if, on the other hand, you feel that you spend a lot of time figuring out how to do what should be a simple task for the benefit of one form, I would say skip it!

If you want to help something more specific, I would love to help you. Just ask another question (or update this one) and I will do my best to help.

Answer 9

whycantitbemorethan25c mentioned them above, but ViewScripts gives you extremely fine control for rendering forms. Zend_Form must be fast, and therefore it accepts many default values, such as standard decorators, and arranges the element as it was added to the form object. With ViewScript, you can skip most of this and put all of your elements, but you want in normal HTML.

Do not miss the concept of Decorators, though. They style individual elements, even if they are used later in the ViewScript view. For example, you can use them for error messages, as others have suggested.

If you have a very complex form with several data points with similar actions (think of a list of users with active / inactive buttons and a delete button for each), you should consider Zend_Form_SubForm . Subforms can use ViewScripts in the same way as regular forms, and if you cascade a form using ViewScript with subforms with your own ViewScripts, you will get great-looking logic and presentation that is much more powerful than just a form.

Answer 10

I wrote some subclasses of Zend_Form and decorators to make it form layout in table>. He even had some special tricks to do things like do multiple submit buttons on the same line.

Took a full day of hacking to make it work. It was written against Zend 1.5.1, so I don’t know if it will work with the current version, but if you are interested, I could probably download the source somewhere.

This seems to be a very common complaint with Zend Forms.

(I know that poo-poo purists are scared using tables in layout formats, and although I agree that CSS is better for most things, I still need to see a good form layout using CSS that doesn't "I look like ugly shred butt. Form tables "just work" in any browser where I need them.)

EDIT: Well, speaking of ugly clom butt butts, I put my code to create zend table forms on github. Go here to see him. (Because gaoshan88 asked for it.)

Answer 11

ANSWER HERE. HOPE, this will help you. I looked through a huge amount of information until I found it.

 <table> <tr> <td>Page name: *</td> <td><?php echo $this->pageForm->header_title;?></td> </tr> <tr> <td>H1 tag: *</td> <td><?php echo $this->pageForm->h1_tag;?></td> </tr> <tr> <td>Page URL: *</td> <td><?php echo $this->pageForm->url;?></td> </tr> <tr> <td>Meta Description: </td> <td><?php echo $this->pageForm->meta_description;?></td> </tr> <tr> <td>Meta Keywords: </td> <td><?php echo $this->pageForm->meta_keywords;?></td> </tr> <tr> <td>Short Description: *</td> <td><?php echo $this->pageForm->short_description;?></td> </tr> <tr> <td colspan="2"><a href="<?php echo $this->websiteUrl;?>backend_template/list?placeValuesBeforeTB_=savedValues&TB_iframe=true&height=200&width=300&modal=true" title="add a caption to title attribute / or leave blank" class="thickbox">Open iFrame Modal</a></td> <td> <a href="<?php echo $this->websiteUrl;?>backend_template/list?placeValuesBeforeTB_=savedValues&TB_iframe=true&height=200&width=300&modal=true" onclick="javascript:getDataFromAddPage()" title="Select Template For Page" class="thickbox" > TEST FORM </a> </td> </tr> <tr> <td>Featured: </td> <td><?php echo $this->pageForm->featured;?></td> </tr> <tr> <td>Mark as 404: </td> <td><?php echo $this->pageForm->is_404page;?></td> </tr> <tr> <td>Show in Navigation Menu: </td> <td><?php echo $this->pageForm->in_navmain;?></td> </tr> <tr> <td>Show in Static Menu:</td> <td><?php echo $this->pageForm->in_navstatic;?></td> </tr> <tr> <td><?php echo $this->pageForm->submit;?></td> <td><?php echo $this->pageForm->button_close;?></td> </tr> </table> 

Answer 12

You probably decided to do this, but I was doing some work and needed a similar solution.

 form-> getSubform ('subform'); 
 foreach ($ subform as $ key => $ value) {
 // some markup and custom code here
     print $ value;
 // some markup and custom code here

 }
 ?>

inside the foreach loop you can add table layout. If you correctly named your keys for table rows, they must match the keys of the form. You can even use a loop that captures the corresponding subformation by key or even an element by key. you can skip the foreach loop if you know the keys and just say print $ subform ['somekey']; if you specify the main form by specifying $ form-> setIsArray (true); (not sure if this last part is strictly necessary, but for complex forms it should be installed the same way.

I removed the default decorators so that I could fully control the printing inside each element. Zend_Form should have a built-in method to capture individual elements a little easier .. but I think it works very well.

Hope this helps someone!

Answer 13

Sean McSomething's first tip is a way to follow me. I always thought that making <?php echo $this->form ?> To render the form too magical. I will go one step further and make individual decorators, not individual elements using the $element->renderDecorator() magic methods. This way, you don’t have to worry about the order in which you defined your decorators. You just need them to be there, and you don't have to add those annoying, unintuitive HtmlTag decorators. I made a blog post about this .

Answer 14

I'm not sure that Zend already has this feature, but a quick solution would be to extend the class, force it to accept the html template.

For example:

 <?php $form = new zend_form_whatever($field_list + $validators + $template); echo $form; ?> 

template:

 <form id="my_custom_form"> <label>{label.email}</label> {input.email} <span class="red">{error.email}</span> <div> {label.password} {error.password} {input.password} </div> <div class="purple">{input.submit}<div> </form>