Patch: allow multiple nodes of the same type; expose form values in $saved_globals [#187953]

The attached patch addresses some problems I had with making subform_element handle a complex form. Maybe it will help other folks too.

The form was for a trip reservation system, and comprises the fields for a booking node (customer and payment info) and for two reservation nodes (arrival/departure info). The problems I had were the following:

* subform_element indexes the form fields using the form_id (i.e., 'reservation_node_form'), meaning the data for the second reservation node stomps on the data from the first;

* I needed access to the form data during submit, but subform_element caches the data in the static and protected $saved_globals variable in subform_element_call().

So the patch does the following:

* allows the declaration of multiple subforms for the same node type by appending a counter to the form_id when declaring the form elements, like so:
$form['subform_1'] = array(
'#type' => 'subform',
'#id' => 'reservation_node_form_1', ...

* exposes the $saved_globals array by adding a setter/getter function:
// to read the data:
$subform_globals = subform_element_saved_globals();

// to set the data
subform_element_saved_globals($subform_globals);

Comment	File	Size	Author
#5	subform_element-1.4-1oda.patch	1.23 KB	oda
#4	subform_element_1oda.patch	1.39 KB	oda
	subform_patch_stevem_2007Oct30.patch	2.49 KB	steve.m

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

fago

German

Vienna

CreditAttribution: fago commented 13 November 2007 at 14:09

hm, subform is a really important module to be stable for all other modules depending on it. Changing it is always very dangerous, as there might be forms out there that have problems with these changes. So I just want to keep it stable and so I won't add any new features to 5.x-dev any more - sry.

I've started development for 6.x-dev now. I'll have a look at making these possible for 6.x.

Anyway thanks for the patch, hopefully interested people can find it in the issue queue.

Comment #2

rconstantine CreditAttribution: rconstantine commented 21 February 2008 at 04:25

I just found this and hope that somewhere in here is a solution to my problem. It is somewhat related to this: http://drupal.org/node/177874, but for the most part I worked around the issue - or thought I did.

As originally noted, more than just my CCKTSSU module wasn't updating. But now, I find that my module is the only one (that I'm using at least) that still has the problem.

To recap, the problem is that during the original run through the pageroute (creation stage), everything is fine. However when editing the pageroute pages through the pageroute, new values are not updated and old values can't be deleted. Printing $form_values to the screen and comparing the identical CCK field in a node outside and unrelated to a pageroute shows that they don't match. $form_values in the regular node properly updates and saves the changed info. In this case, there are a ton of checkboxes. Empty boxes correctly have 0 in them and filled ones have an appropriate number value.

In the version running within a pageroute, the $form_values of the empty checkboxes have a NULL in them or are otherwise empty. Unchecked boxes which initially had values, still retain their original values and can't be overwritten.

So I therefore think that this is a bug and not a feature request. CCK fields should be able to work on the correct $form_values. $form_values should not be overwritten with the original values that the node had when the page loaded.

I haven't tried this patch yet, but at least it looks like it has found the most likely cause of my problems. Will test and report.

@fago -> meanwhile, feel free to try out CCKTSSU inside a pageroute (as a nodeprofile content type) and see if you can edit it and save changes. It may be that I'm just doing something wrong. BTW, this issue has nothing to do with my registration_mod module as I've tried this with and without it.

Comment #3

rconstantine CreditAttribution: rconstantine commented 25 February 2008 at 21:39

Well crap. That is a cool patch, but the 'form_values' as held by the $subform_globals is still wrong - i.e. all values are the same as when the page was loaded with default values and doesn't reflect any changes made by the user. I just can't seem to figure out why the correct form_values are not being passed where they need to be when using pageroute/nodeprofile/subform_element.

Comment #4

oda CreditAttribution: oda commented 20 July 2008 at 19:14

File	Size
subform_element_1oda.patch	1.39 KB

I've made this another patch. You can apply it without backward issues because it defines another parameter, #content_type, that overwrites the #id when provided.