CODEWITHSUNDEEP
phpformssymfony1
xil3
xil3

Reputation: 16439

Symfony form generation - why?

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?

Upvotes: 8

Views: 1526

Answers (3)

rjmunro
rjmunro

Reputation: 28056

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.

Upvotes: 2

Aston
Aston

Reputation: 3712

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).

Upvotes: 4

richsage
richsage

Reputation: 27102

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 :-)

Upvotes: 6

Related Questions