Needs review

+++ multiform.module	2010-03-05 03:17:58.541025196 -0800
@@ -0,0 +1,115 @@
+<?php
+

Missing CVS Id.

+++ multiform.module	2010-03-05 03:17:58.541025196 -0800
@@ -0,0 +1,115 @@
+ * @param ...
...
+function multiform_get_form($form, $form_state) {

Arguments don't map?

+++ multiform.module	2010-03-05 03:17:58.541025196 -0800
@@ -0,0 +1,115 @@
+ *   For example, if the first form is called as
+ *   drupal_get_form($form_id1, $arg1, $arg2); and
+ *   the second as drupal_get_form($form_id2, $arg3, $arg4) call
+ *   multiform_get_form(array($form_id1, $arg1, $arg2), array($form_id2, $arg3, $arg4)).

Missing @code and @endcode tags here.

+++ multiform.module	2010-03-05 03:17:58.541025196 -0800
@@ -0,0 +1,115 @@
+    // Reset $form_state and disable redirection.
+    $form_state = array('no_redirect' => TRUE);

I don't understand why no_redirect is enabled here. Multiform doesn't seem to intercept or handle form submission/redirects (yet)?

+++ multiform.module	2010-03-05 03:17:58.541025196 -0800
@@ -0,0 +1,115 @@
+  $form['save'] = array(
+    '#type' => 'submit',
+    '#value' => t('Save'),
+  );
...
+  // Do not display buttons.
+  if (isset($element['#button_type'])) {
+    $element['#access'] = FALSE;
+  }

That's a tough challenge.

Would merging the buttons be an idea?

Logically, two forms that are merged into one should be closely related to each other. Therefore, "Save" means save to both, "Delete" means delete to both, etc.

So, merge buttons into the top-level $form by their labels?

+++ multiform.module	2010-03-05 03:17:58.541025196 -0800
@@ -0,0 +1,115 @@
+// -------- Testing below.
+
+function multiform_menu() {

Move into tests/multiform_test.module

Powered by Dreditor.

Because otherwise the drupal_build_form calls would redirect.

Gotcha! :) However, multiform should try to retain the redirection target for the parent form... i.e. anything other than $_GET['q'] or FALSE in $form_state['redirect'] should be considered as redirection target. To KISS, take the first.

Mainly cuts down to documentation and markup tweaks:

+++ multiform.module	2010-03-06 17:57:16.641269156 -0800
@@ -0,0 +1,149 @@
+  // This is where buttons will be collected.
+  $form['buttons'] = array();
+  $form['buttons']['#weight'] = 1000;

s/button/actions/

+ #type 'container', or resp. 'actions', after #482816: Make a consistent wrapper around submit buttons landed

+++ multiform.module	2010-03-06 17:57:16.641269156 -0800
@@ -0,0 +1,149 @@
+    // Retrieve buttons.
+    if ($button_elements = form_get_cache($_POST['form_build_id'], $form_state_save)) {
+      foreach ($button_elements as $button) {
+        $name = isset($button_elements['#name']) ? $button_elements['#name'] : 'op';
+        $button_names[$name] = $name;
+      }
+    }

hah. Most likely only understood by a Form API maintainer :)

+++ multiform.module	2010-03-06 17:57:16.641269156 -0800
@@ -0,0 +1,149 @@
+    if (!$key) {

wow. Took a minute to understand that this means to works on the first processed form only ;)

Powered by Dreditor.

Subscribing and plan to test....

I know this patch is old, but it removes the ability to use the same form more than once since it's keyed by form_id rather than form_id and array key.