You could also of course (instead of using a form option) populate the object before passing it to the form, or after you have bound the form, before calling save. (if you want to keep the account_id logic completely out of the form class).
Russ. On Feb 5, 10:30 pm, "rooster (Russ)" <[email protected]> wrote: > I would pass the id as an option to the form (if the id is decided in > the action, and cannot be derived from the object itself) then add the > value using the updateObject() method. Since the value never enters > userland, there is no real need to run it through the validators in > this case, so I'd just unset() it from the form entirely. > > You should have db level validators that sanity check the value anyway > "lower down", the form validators are best for validating user input. > > Russ. > > On Feb 5, 9:24 pm, kris chant <[email protected]> wrote: > > > I'm trying to set a value in my form, before validation, and running > > into problems. > > > The value I'm setting is an account_id, which should never be known to > > the user, thus I don't use a hidden_input form value. > > > I want to preserve the form validation (a sfValidatorDoctrineChoice > > validator that ensures that the account_id exists in the database), > > and therefore haven't overriden the updateObject method on the form. > > > I recognize that I could simply set the validator to > > sfValidatorPass(), and insert the value either in the controller or in > > $form->updateObject() but that seems hacky. > > > Any suggestions? -- You received this message because you are subscribed to the Google Groups "symfony users" 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-users?hl=en.
