matthijs wrote:Following along as well. I just want to say that Arborint is right that you can only have a useful discussion if you take one use case and then compare different solutions.
And then second, you have to look into different use cases, from a simple login form to a complex, 50 fields form with a lot of logic.
The thing is, for a default simple login form, the more automated echo $this->form() works ok. But if you have a large registration or shopping cart form, it's a completely different situation. And my feeling is that most of you guys are mainly programmers (no offense if you're not!) so are looking at this from a programmer's viewpoint. So you want to be able to do echo $this->form and be done with it. But the (graphic) designer or front-end guy will have a very hard time with that and might not accept that. Because he wants to design field 8, 16 and 23 just a bit different. And he wants to be able to add a small extra note with field 26. And have a slightly different behavior in field 4. Etc etc. Or he wants to add another fieldset around a few form fields. Now, does he have to go back to the programmer and ask the programmer to add a few extra lines to the RegistrationFormcontroller class? No. he should be able to just edit his template file. And maybe you think these issues are not important, but I think they are. As Ninja said, forms are an important part of the site/app. They are tedious for the user as well! So every small detail that improves that user experience will make a big difference. And that's why it's difficult to have a solution in which you just dump out those 40 fields in some standard html.
Anyway, that's just to say that, I think, first, you have to support multiple situations (automated code generating versus customizable template like) and second, that you have to clearly define the use cases if you want to compare apples to apples.
Ok, yes, I had trouble reading it too...was in a hurry.
I think such cases where you have to handle really per field rendering stuff is quite rare. I mean in normal workflow you should have pattern after all, like all fields around some li tag or whatever, some label, a comment..then this and that...if has errors, append one div after each field or the like. I am not saying comment or whatever should be there for each field..but you should have some pattern.
- Still, even if per field specific rendering is needed , I don't see much trouble doing it in ZForm. For example you can use the viewScript decorator, it allowes you to define a view script to use for rendering per field.. So what you can do is set 'my_option' for each form element like 'element_1' etc etc. Then you can extend this viewScript decorator (so actually you'll use my_view_script decorator for each element, and not the default viewScript)...and this my_view_script instead of using the generic view script (which is like 80% of all you're fields), it will first check if file with 'my_option' exists ..(somewhere..a matter of convetion), and will use that file instead to render.
So at the end your designer can always create such file and know that this specific field will be rendered with this code/html. Of course you'll probably want to do this naming like form_element_1 or the like to be more flexible and have no collission with different forms containing same element names.
Also, it is really rare case , at least in my practice, that desginer will change something that will not require developer to hit in, either new functionality or the like....other stuff is just css + overwritte of images.
Other thing is, you can render the form in the tempalte element by element... this way you can add whatever additinal html around that you want.....this makes sense if no pattern you see in the html. After all I think we all agree that nowdays design is dones mainly with css and not some twisted tables that you donno what goes where.
It's doing the persistance for you (autoprefill), validation,filters, error messages and everything all at once.... you will have reaaally hard time following/maintaing this yourself...with html and tons of php doing some weird stuff around.
Bottom line, ofcourse there is nothing in the world that can make it all for you, I think such framework should do/solve your 80-90% scenarious that are most common - this will still saves you tons of time maintaining...even if the rest you have to do old style way.
And I certainly cannot imagine design without pattern whatsoever. With ZForm's decorators you can built anything you want.
You can enable,disable fields to be render for specific scenarios, enable/disable validation in certain cases etc etc.... I think it trully just gives you freedom.