Give access to node form array.

This is a very small , but very very important patch.

It allows us to take in multiple node forms, and remix them to create a single new forms .. for relations.

It also allows remote node creation, by creating an xmlrpc function which accepts a node object, and tries to run the drupal_form_validate and drupal_form_execute on it, based on the node type definition on the remote end.

+100

++

I would only say, that the absence of this I would consider a bug - it limits too much the application of the forms api.

And it keeps the interface the same, so no change outside to the existing world.

+++

a related issue, is that we can't call more than one form _submit, because the node_form_submit does a drupal_goto.

For that reason i've changed the form_id_submit to return a page to redirect to instead, and introduced a #redirect property that the form can set.
This can also be considered a bug (i can create an extra ticket for it, if that's needed)

Why?

Just in case Dries' "Why?" meant "Why do we need this?", I'll describe one possible case; concerts. Concerts are events that have locations, called venues. Concerts come and go, but venues stay, so they should be reused. When someone announces a concert, it might be at an existing venue (Carnegie Hall), or in a new venue. If the venue is new, they need to create it at the time they create the concert.

This type of thing is the whole point of the relations work that several people are pursuing. If there is no good way to present the possibility to create more than one node type either all at once (combined form), or in rapid succession (wizard), the relations work is useless.

I'm currently solving this problem by having people create a concert, and if no venue is assigned, a "select venue" link and a "create venue" link appear as sub-tasks of the "Edit" tab. My client actually would rather have the venue form inside of the concert form, so my solution is an unhappy compromise, and I would rather be able to do what my client wants.

I'll most likely use these patches and maintain them for my installation whether or not they hit core. I'll be testing them over the next days.

Here is something that Chad and I have been working on. I believe that this patch will make some of this possible.

Form Remix: Customize your forms
Link: Create a project page and put what you have below into the form

Benefits:
-Train developers about the power of the Forms API and why they should use Drupal 4.7
-Improved user experience through managed presentation of form options
-Accomplish tasks faster with work flow designs for forms
-Customize the appearance of your site, so it doesn't look like Drupal

How:
-Forms API: allows changes to display order, regrouping, hiding existing elements, adding new elements
-Theme overrides: theme_form_id() and form_render() allow individual rendering of elements controlled by the site designer, not the module programmer

What: Node Remix Module
-Node custom layout module
-Custom form element defaults per node
-Custom weighting of form elements per node.
-Multiple tabs for forms

that is a very useful piece of code

i agree w/ all comments here. +100, this is a no-brainer. adds quite a bit more flexibility and power to the api in only four lines of code, and will help greatly w/ the forms remix module that amazon and i are cooking up.

Big +1 on this patch. As others have mentioned, it makes relationship based data structures a lot easier to maintain, and lets us imbed node-creation logic in places it was previously impossible. As we move forward to creating custom distributions (some with streamlined interfaces for data entry), this will allow more to be done without hacking core.

Makes form and content remixing very clean. Brings forms to elegance.
+1

chx, can you confirm whether the only patch here to be applied is #12? Or is the original node_44.patch still relevant in some way? Dries, a lot of people are interested in seeing this go in. Do you have any questions about it?

I disagree with the final patch on this item greatly, and Dries is right for not committing it.

Introducing a property that allows you to extract the form array from anything is a really really bad hack.

The only patch I will support is the original patch which splits the node form into two functions.

A future version of the forms api will allow you access to ANY form array, but it will be done cleanly.

Here is an updated version of the original patch.

This version is cleaner and keeps the concerns separate, which is a good thing.

Committed to HEAD. Thanks.