“Templating guys” is another point where Zend_Form is lacking, in comparison, but as i said before you should keep an eye on those guys not changing the input names
Also, i don’t think we should allow “templating guys” to use evil includes/requires in templates at all.

Without (basic) php skills one can only influence Zend forms via CSS, which sometimes may not be enough.

Parameter remapping as principle is counter-productive imho. Yes, you can correct any bad template with PHP workarounds – but not only in Agavi

I appreciate your deep insights as a certainly more experienced agavi user

@Veikko:
Valid point.

To conclude (again), i’d say that i personlly, for some small html-only forms, which don’t need extensive/non-standard styling, still prefer Zend_Form. I do have disadvantages for not being able to use one validator setup for multiple output types, as Agavi allows me, yes, but it fits for the project

I should add that, working without that templating guy for almost a year now, i had to create the full forms stuff for myself…

I also didn’t want to start any religious framework-fight, dear “Agavi-Polizei” ^^

Agavi validation can remap parameter names easily, so you rarely have any case where you really need to change the input names at all.

Having the HTML-Code for the form separate from any logic is a major advantage IMHO:
- you can have a dedicated template builder change the html at his liking as long as he keeps the parameter names. Often dedicated template builders know HTML very well, but little in terms of real programming language.

- HTML/CSS offers all required capabilities for arbitrary complex form layouts out of the box. With a form builder you often have to modify program code to achieve a result that was not intended by the developers.

cheers

felix

That’s not true. You can reuse the html template even if you have different Input and Error views.


//re-use Input template in FooErrorView
$this->getLayer()->setTemplate('FooInput');


In my opinion the dry principle is broken by the need to put the raw html-code for the form in not only one view. If you wanted to change the input-names of the form, you’d have to change them in 2+n places (validation + form + any other place/view you put that form).

I didn’t think of other output types and their validation, but you certainly have a point there. This may be an area where the encapsulation of the Zend_Form has its disadvantages – you should only use it for pure html documents (ajax too). The advantage it gets therefore, in my opinion, is its integration into *any* template engine – by using a __toString() mechanism, you just have to pass a string (which includes the whole form html and errormessages) to your view/template.

Zend provides different classes for SOAP/XmlRpc/JSON-RPC, where you can not (without obstacles) reuse validation from a Zend_Form object.
This is a major design difference imho, and I’d say that both approaches are suitable for different purposes.

Btw, i don’t think my post was neutral, either

This is true but it’s not the whole truth – web applications are getting more and more user input from other sources too and this is where built-in form helpers that try to do everything (output rendering, data population, input validation, data re-population, error message injecting etc.) usually start to go sour.

I don’t know much about Zend so I’d be really interested to see how you’d handle a situation where input for an action can come from a HTML form, from another action (forwarding) or JSON. Can you still use Zend_Form? I can tell you this is easy with Agavi

-veikko (a long time Agavi user and contributor and probably just as much biased as Felix

The validation definition is separate for a reason:

- The validation may incorporate parameters that are not held in the form, but in a cookie, a header, the url or any other source. Splitting the validation up in multiple definitions would be worse.

- The same validation definition is used for form posts, SOAP requests, XML-RPC, JSON-RPC or any other request method.

- The same validation mechanism can be used for pure PHP templates, Tal/Metal templates, Dwoo, Smarty or any other templating engine you choose to use. How does Zend integrate with those?

I also don’t get the point where code duplication occurs? Are you referring to the fact that agavi encourages you to create a separate error view? I’d argue that the error view serves a different purpose than the input or success view – it’s less obvious when you’re using pure HTML, but saves you a ton of work when you’re using any other response type – JSON, AJAX, SOAP, name it.

However, I admit that I’m certainly opinionated here as I’m an agavi developer.

Cheers

felix