> 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.
I think your DRY concerns are valid. I typically include this sort of conditional logic in the form configure method, then simply check whether a field isset() in the template. This is DRY, and works most of the time for me. That being said, what you're asking for is a widget class with a very simple render method. Why don't you package this up as a plugin? > 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(). I agree that the forms could be easier for web designers to work with. I am working on a "view" panel for the symfony 1.3 web debug toolbar that will provide information about the variables passed to a response's templates and partials, including form objects. Please take a look at this WIP when you have a moment; I'd appreciate any feedback. > (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 -~----------~----~----~----~------~----~------~--~---
