Yes, remember also the ('#type'=>'hidden') they're good for passing data from the form.... just like making hidden fields in html. These are all passed to the $form_values section of the form array.
I also wanted to make sure you know using form_set_error to indicate what fields contain errors etc.
It took me a while to find this the first time.
Happy coding :)
Dave
-----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Ivan Sergio Borgonovo Sent: Wednesday, February 06, 2008 9:56 AM To: support@drupal.org Subject: Re: [support] FAPI and "returned" page
On Wed, 6 Feb 2008 08:26:37 -0800 "Metzler, David" metzlerd@evergreen.edu wrote:
Yes this is correct. Submit and validate fire before any form rendering is done. It's not perfect but it's what is there. Part of the rational for doing this is that if you return path from a submit handler drupal will redirect to that page.
If you want to multiply the contents of two fields you are going to do it like this:
- IN the submit handler modify the data that your application is
based on, using session variables or some other permanent data store (the database is most common) and alter data.
- Reference these structures in the form rendering function to
display the data.
[snip]
function test_form_submit($formid, $form_values) {
$_SESSION['mymodule']['total'] = $form_values['value1'] * $form_values['value2'];
}
OK... at least I know there aren't smarter routes. A bit painful if you've large forms.
Nothing forbid to catch the $_POST since it is conserved.
Part of FAPI still remain useful, but _validate becomes cosmetic. It'd be nice to have a _display hook that just takes the same arguments as _submit and if present directly show some output in spite of returning drupal_render_form...
I think something can be recycled out of FAPI for my scenario... but it won't be as elegant as if we had a _display hook.
thanks