8

I've been pondering this for awhile now - I never fully grasped why you'd want to generate all your forms programmatically, unless they were going to be fully dynamic. But from my experience, most are static.

Now, getting to the main question at hand - with Symfony, it generates all your forms for you based on the table that you associate a module to (when building it). My question is, why would you want these forms generated? For the most part these are static forms, which should be easy to edit in the template.

The main issue for me, is if you have a team of back-end and front-end developers, and maybe some designers, for example. And the designers or front-end developers (who may or may not have much or any PHP experience) want to change the form around (for aesthetic purposes) in the template directory, which houses all the views. Well, they can't really, because it's all generated by a form class which was built specifically for that form. So, now they need to go back to the back-end developers and ask them to change things for them?

I may be missing the point with the form generation, but the way I see it - if it's static, there is no need to generate it programmatically, but if it's totally dynamic, then yes, it's alright.

Any views on this?

BradleyDotNET
  • 60,462
  • 10
  • 96
  • 117
xil3
  • 16,305
  • 8
  • 63
  • 97
  • 1
    Don't know Symfony. But the programmatic form generation approach is usually the lazy solution. For the developers of a framework. It would be entirely feasible to speed parse a HTML5
    (or XForms for that matter) and use that for interactions. But alas, nobody has attempted that yet.
     – mario Feb 03 '11 at 10:07
  • Yeah, I was considering to just ignore the form generation, and just create the static forms manually in the template files. I really despise most of the Form libraries anyways. It's nice to get other peoples views on this, though. – xil3 Feb 03 '11 at 10:10

3 Answers3

6

Because for the most part, the field types used are pretty similar to the schema columns, assuming you designed your schema correct in the first place ;-) eg varchar(200) translates to a single-line text input, a MySQL longtext translates to a textarea and so on. Quick and simple to then move to rendering, after maybe a couple of tweaks. The form classes generated also give you a place to pop all your form widget validators for form validation.

You can of course use the validator classes wherever you want, but the forms framework encapsulates this nicely I feel.

Rendering the form though is a separate issue - as you mentioned, you have a view for this. The lazy approach in Symfony is to simply do <?php echo $form; ?> but it's preferable to render the individual fields themselves eg: <?php echo $form["fieldname"]->render(); ?> and so on. If your views are structured like this, then your front-end developers should be able to re-order the fields as they want.

Edit: Adding classes and other attributes during rendering:

<?php
  echo $form["fieldname"]->render(
    array("class" => "myNewClass", "title" => "My Title", ...)
  );
?>

Edit 2 Essentially what I'm trying to convey is that you will always be able to find a corner case for where the forms framework in Symfony isn't appropriate. You'll be able to find that for probably every component in every framework ;-) But for the majority of the time, it does the job fine and with relative ease. If you find yourself continually fighting against it, then I would suggest that either you're coming at it from the wrong angle or you've just found all those corner cases mentioned above :-)

richsage
  • 26,912
  • 8
  • 58
  • 65
  • What if they wanted to do more than re-order the fields? For example, if they wanted to add a new class (for new styling) or add an alt or title attribute? The list is endless... – xil3 Feb 03 '11 at 10:26
  • To me it just seems like a lot of overhead. So you'd need a Form class, plus you need to echo out each field (via render method). All that versus just doing this: `` - this is a lot easier for designers, as they would already know the HTML4 or 5 syntax. Plus, this is static, so why do it programmatically? I just don't see the point, unless the forms are going to be fully dynamic (in which case they most likely wouldn't need to be edited by design). – xil3 Feb 03 '11 at 10:40
  • I would argue that your designers are there to design and not to implement wrt actual development. If your design is signed off, at whatever stage, it can be empty input elements, empty links etc. Your job as a developer is then to implement that however best. In most cases this is back- & front-end devs working together. – richsage Feb 03 '11 at 11:04
  • The potential overhead is a side effect of easier to maintain code, and separation for unit testing. Having the forms framework (and dare I say it, the ORM too!) abstracted makes unit testing these components far simpler. – richsage Feb 03 '11 at 11:06
  • In reply to your `Edit 2` - I guess it's just not for every project or every person. I can see it improving productivity in certain circumstances, but for what I'd be doing, not really. Thanks for your input though :) – xil3 Feb 03 '11 at 11:06
  • Pleasure :-) you're not compelled to use it, just like the ORM - you can do raw SQL if you please ;-) but it's definitely up to the individual and/or project. Onwards :-) – richsage Feb 03 '11 at 11:09
  • Oh I definitely use the ORM (can't live without it) - just not a big fan of the Forms library. – xil3 Feb 03 '11 at 11:33
  • I love struts forms and I find them very useful giving me freedom to do whatever I want. In symfony2 forms I keep figuring out how to do this and that. – Shwetanka Jul 21 '12 at 05:14
4

The form generation is a feature that aims to solve a particular problem. The main issue is that most of the time if you create a model object then you will need a form that is simple, contains only your fields and can be generated based on your model description.

If you want to keep your application "well designed" your BaseForm classes will contain all the fields of the model object, and you can extend these classes to create specific forms. For example let's say you have a User object and you want two different types of registration based on the age of the registrant. The two forms will be 90% the same, so you can create a nice design with your BaseUserForm and extending it with two different specific forms just like you need it. An extra benefit is when you want to change a name of a column, you don't have to do it at many places, only at one place, and so on.

This code generation is just like the same thing as the ORM file generation when you use Propel or Doctrine or whatever, most of the functions of these files will never be used but it gives you a nice tool set to be used for development.

As a plus: The Symfony Form Framework was always subject of HUGE refactoring since the first version, through 1.1 to 1.3 they have always changed it and as far as I know the 2.0 version will be something completely different either (also it is going to be an independent bundle and reusable outside of Symfony). So if you don't find the current form framework useful I'm not too surprised, they are not too happy with it either (as far as I know).

Aston
  • 3,654
  • 1
  • 21
  • 18
  • I know what it is, what it does and how it works. My main concern was the whole point of using it. In a large development environment, where you have multiple teams working on the same project, you'll have designers looking at templates and modifying static mark-up code (HTML). This would just make things more difficult for them, and for the back-end developers, who will end up having to do everything. The reason I'm saying this is because it's happened to me... – xil3 Feb 03 '11 at 10:44
  • Then the current form framework was just not designed for your needs. We had the same issue as well. Probably the thing is that what this framework was designed for is useful only in a very limited number of cases. – Aston Feb 03 '11 at 11:03
  • Yeah, I agree - thanks for the different points of view though. – xil3 Feb 03 '11 at 11:05
2

Most forms need to be generated programmatically so that if they are submitted with errors, the errors can be validated and the form can be returned to the user, partially pre-filled, with errors inserted into the labels as appropriate.

If your form is static, there is no way to return validation error information, or to pre-fill the form with data from the database, or from the fields that the user filled in.

rjmunro
  • 27,203
  • 20
  • 110
  • 132