Fabien Potencier wrote: > There is no such thing as a plain field. It does not make any sense to > me. The form system is about form fields. So, we manipulate form > widgets. The power of the form system is that you can display your form > the way you want by using the form API (see > http://www.symfony-project.org/forms/1_2/en/03-Forms-for-web-Designers): > > $form['subject']->renderLabel() > $form['subject']->renderError() > $form['subject'] > /// and so on > > So, if you want to display something, like a property of the object > related to the form, it is quite easily to insert wherever you need it > code like this: > > <?php echo $form->getObject()->getFoo() ?> > > Am I missing something here?
Yes. Let's assume that "subject" can be read-only depending on some user level (as you wrote later). So we have to inject the user into the form class, check the user level and disable the form field (unset it or set sfvalidatorpass or whatever). This is what you also described and it's fine for me. The problem comes now: we ALSO have to put the user level check into the template to display either the field ($form['subject']->render()) or $form->getObject->getSubject(). This is a fairly ugly redundancy, and it is error prone (imagine you change the user level check but forget to change it in the template too). It's also difficult because the subject should appear the same way the form field does (the same visual label). We either have to code this by hand (thus breaking the form formatter dependency) or use a "dummy" field - and this is where a text-output-only field screams at you "implement me, so you will have much less work!". To summarize this: having read-only form fields removes redundancy and application process dependency from the templates. I want to call $form['subject']->render() and totally ignore if the field is a text input, a select or just a text output. It just shouldn't matter for the template. This also helps "Forms for web designers", because the designer shouldn't have to know about user levels and getObject()->getSubject(). (Good, reusable) Forms are NOT only a bunch of input fields (if you look at them beside simple stuff like CRUD interfaces). Forms should be a combination of input fields AND application logic AND text outputs and the form framework should honor this (as it does regarding to labels, error messages and help texts). "Forms for web designers" is fine, but let's have more "forms for coders" first, because there's much more (hidden) work in there at the moment. David --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
