[development] Retrieving form values during intial form rendering

Mark Fredrickson mark.m.fredrickson at gmail.com
Fri Mar 30 22:19:57 UTC 2007

I think you want to research '#button' and '#after_build'. '#button'
will send you form values without a full submission. '#after_build'
will allow you to do something with the built values (node.module uses
#after_build to prepend the rendered preview version)

You may have to supply a '#name' element for your button so that it
doesn't get stuck in 'op'. I'm a little rusty on that point.


On 3/30/07, Syscrusher <syscrusher at 4th.com> wrote:
> I'm really stumped with what I thought would be a simple thing, and I'm finally
> asking for some help. This is in Drupal 5.
> I have a form that is *not* node-related, that needs to be able to do the
> equivalent of a preview, in that it needs to be rendered with its default
> values being the fields from its previous submission. Sounds simple, right?
> Here's what's happening, though: My form gets built fine during HTTP GET, with
> #default_value being set appropriately. The user submits the form, and $_POST
> gets the right data. That data is passed to hook_form_validate() and then
> to hook_form_submit(). So far, so good.
> But when I get to hook_form(), the $_POST is no longer set, because of the
> drupal_goto() that results from hook_form_submit(). So I wondered, "Where does
> my data get stored?" Apparently, I wondered this like everyone else, because
> the Forms API handbook page says:
>   "The practical upshot to this is that many developers immediately find
>    themselves asking the question of "where does my data get stored?".
>    The answer is simply that it doesn't. You put your $form data together,
>    perhaps loading your object from the database and filling in
>    #default_values, the form builder then checks this against what
>    was posted."
> Loading from the database isn't an option, because these happen to be search
> parameters that aren't stored in the database. Most of the extant Drupal code
> I looked at for an example doesn't apply to my situation, because they all
> use $node->foo to store their data. My module is managing an app-specific
> table that isn't connected with nodes in any way, and the particular form in
> question is a query rather than data entry, so I don't have a table where I
> can put the data.
> Now, I think I can probably solve this using $_SESSION, but that seems so...
> inelegant. I've got to believe someone has solved this before, and that there
> is a "Drupally-correct" standard way to do what I need to do, which is simply
> to have a form that defaults to its previous values each time it's rendered
> after a POST operation (but not a GET).
> Can anyone tell me what I'm overlooking, or point me toward one of your own
> modules that does this that would serve as an example?
> Many thanks.
> Scott
> --
> ------------------------------------------------------------------------------
> Scott Courtney         | "I don't mind Microsoft making money. I mind them
> scott at 4th.com          | having a bad operating system."    -- Linus Torvalds
> http://4th.com/        | ("The Rebel Code," NY Times, 21 February 1999)
>                        | PGP Public Key at http://4th.com/keys/scott.pubkey

More information about the development mailing list