I have just tested to be sure, and the disabled field's value is not passed on with the form submission.
I think this rules out the raw html 'disabled' and 'readonly' attributes then. I would expect it to be fairly common for forms to contain read-only fields. It sounds like the only way currently to handle this is to leave the automatic form magic behind and splat out each field manually? Which sounds troublesome and counter-intuitive given all of the good work done on decorators and other magic The other option mentioned elsewhere was to hold the original field value in a HiddenInput widget, and then create a new read-only TextInput for the user to see. Besides being a little bit 'hacky' the following bind then isn't expecting this field to have been passed and responds appropriately. Perhaps if the fields were 'disabled' by a method or setOption on the widgets that stopped the subsequent form->bind() from looking for their values in the form submission? Jake > On May 16, 9:16 pm, Jake Press <[EMAIL PROTECTED]> wrote: > Oh i see..... > > That wouldn't work, i believe setting a disabled attribute on a field > would result in the users browser potentially not including the field > value in the form submission. > Which would do bad things > > Jake > > > On May 16, 9:07 pm, Fabien POTENCIER <[EMAIL PROTECTED]> wrote: > > Jake Press wrote: > > > I have done a quick google and grep of my latest project (RC1) to no > > > avail. > > > Where is the method "getHtmlContent" defined? > > > The getHtmlContent() is just an example. The $form->getObject() returns > > the object associated with the current form. So getHmltContent() is just > > a method of this object model class. > > > > Are you saying the auto forms goodness will not support read-only > > > fields at all? > > > If it's a read-only form field, the you can add a disabled HTML > > attribute to the widget. > > > Fabien > > > > By 'auto forms' i mean the magic around printing the form-object and > > > having the form laid out for you: > > > <?php echo $form ?> > > > > Thanks > > > > On May 16, 8:24 pm, Fabien POTENCIER <[EMAIL PROTECTED] > > > project.com> wrote: > > >> The form system generate form widgets for editable fields. If you want > > >> to output a field from a Propel form, you can use : > > > >> <?php echo $form->getObject()->getHtmlContent() ? > > > >> Fabien > > > >> Jake Press wrote: > > >>> With the recent removal of sfWidgetFormIdentity, where does this leave > > >>> us with creating fields that are not editable by the user? ie only for > > >>> display purposes > > >>> I could be mistaken but as far as i can see, the only thing we can do > > >>> is set a raw 'readonly' attribute on our fields? > > >>> - This will not work on all fields of course, for starters the HTML > > >>> SELECT element does not support this :) > > >>> I would have expected a nicer setReadonly() or similar method at the > > >>> widget and maybe even the form level - to have a field or entire form > > >>> rendered read-only. > > >>> Thoughts? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
