Port form_builder to Drupal 7

subscribing

Nate told me he doesn't have time to do this right now, but I'm sure he'd welcome patches to get this ported :)

What happened to the form builder?
This looked very promising when it came out...
Sad to see this project not evolving because of lack of time :(
Or was it a part of Buzzr that was published?

Form builder was updated to work with the "official" release of jQuery UI 1.6 (the version compatible with jQuery 1.2.x) and I'm actually working on implementing full Form Builder functionality in the Webform 3.0 version. Form Builder is actually functionally complete as far as I've found any use for it, it's just a matter of 1) updating for jQuery 1.3 / jQuery UI 1.7, 2) finding what's missing in "true" implementations of the module in Webform and CCK, and 3) porting to D7.

Of course time limitations are real and there's not much that can give me more time to work on it. Getting FileField or ImageCache into core is much more important to me than Form Builder. Wouldn't it be nice to upload a picture for the first time ever in Drupal core? Anything I've got on Form Builder is already published to Drupal.org, after getting Webform 3.x updated for Form Builder support I'll at the very least publish a beta release of Form Builder for Drupal 6, but right now I've got several other commitments for D7 and it's unlikely that this will be updated in time for inclusion in core on my behalf.

For Drupal core there are quite a number of design issues with Form Builder, but the current interactions would be sufficient to start work for Drupal core. I am very interested in the port to Drupal 7, so we might trow this at MDB for a bit.

Thanks for the Info, Nathan. One just one didn't know if it still was going.

Here is a first pass at porting the module to Drupal 7. Good news is that the example/demo form almost completely works. There is a strange caching issue (sometimes form elements from the past show up on the page), but otherwise it looks pretty awesome. It works with jQuery 1.3.2 in Drupal 7 and jQuery UI 1.7.2, which jQuery UI module 7.x-1.x supports in Drupal. The jQuery UI library weights patch is also required: http://drupal.org/node/503848 (the whole stuff can be tried at once with checking out from http://code.google.com/p/d7ux/)

Changes include (in order of changes in the patch):

- core=7.x in info files
- files[] list in info files
- wrapping for $ -> jQuery mapping in JS files
- required behavior attach method change in JS
- clear-block to clearfix
- connectToSortable on the draggable() does not support arrays anymore, fixed by using a single string
- file attributes removed in module files
- form_builder_menu_field_access() is called even if the menu path is actually not invoked, so fixing lots of errors there via checking whether actual arguments were passed
- because the registry, functions defined in node.inc, upload.inc, etc. on behalf of the respective modules don't actually show up in module_invoke_all() type of calls, so we needed to add a hook_registry_files_alter() implementation to wire in these files under the respective modules
- drupal_get_form() returns an array now, and we are supposed to return an array from a page callback, so apply that
- then we need to drupal_render() our stuff ourselves when doing JSON output
- blocks table was renamed to block
- children should be rendered with drupal_render_children() to avoid pretty darn nice endless loops
- form_builder_cache_load() was used at least one time where it was not reliably return the form; maybe this change is source of caching problems as mentioned above? Or other standalone uses of this elsewhere?
- drupal_retrieve_form() changed to take arguments via $form_state['args']
- removed body form item for now from node.inc, since node_body_field is gone; should rethink these items based on field API I guess
- node_get_types() was removed in favor of other functions (appears at multiple places)
- upload.inc is used without upload module surely loaded, so use drupal_function_exists() on the form we are trying to use
- content type editing was moved to admin/build from admin/content
- file_scan_directory() parameters changed, it now actually requires preg delimiters

This is it. The example form almost totally works as said above. Reordering, deleting, editing, adding new options, adding fieldsets and editing their content, etc. works. The node form module does display the node form now, but fails in actually editing items. This was a huge undertaking in itself, so I decided to stop here a bit instead and post the progress, so people can help with whatever JS/jQuery issues come up.

However, that porting the code from Drupal 6 to 7 and jQuery 1.2 to 1.3 and jQuery UI 1.6 to 1.7 took so little changes in terms of JS code, I think is another testament that we should not be freaking out of including jQuery UI in core. Will cross-reference this actual experience there too (http://drupal.org/node/315035)

Attachment	Size
form_builder_to_d7.patch	22.79 KB

Marking as needs review.

Found out that what I experience is that the new form items are actually saved, but none of their customized properties, such as weight, title, options, etc. are. So all the added form items ended up at the bottom of the form. Also, removing did not work. Found out that the use of #form_id as a memory between the form and the submit functions was the problem, since #form_id is used internally by Drupal 7, so when I removed or customized stuff, the changes were saved under a different form id, not under the form I was actually editing. Modifying those to use #_edit_form_id and friends solved the problem. We just need to work around the #form_id collision here, and I picked the _edit prefix, but we can obviously change that too to something else.

So *now* the example form builder works, you can export it as you edited it and all :) Yay!

Attachment	Size
form_builder_to_d7.patch	25.65 KB

Actually, removed some failed attempts to fix the previous bug, which were harmless but not required. Also, added Konstantin's form.js fix from http://code.google.com/p/d7ux/source/detail?r=59#

Attachment	Size
form_builder_to_d7.patch	26.01 KB

Is there an open issue yet for how this gets used by fields ui? Or an IA/mockup? If so, please link from here. thanks.

I spent some time trying to figure out how to integrate this with fields and gave up. Maybe Gabor or someone else sees a way to do it. There's a discussion at http://groups.drupal.org/node/23545 about the Field UI for D7 and what it ought to look like and do with some thoughts about how Formbuilder would or would not play in.

KarenS: can you detail here or in another issue(s) for formbuilder, the limitations you found and why did you gave up?

This looks great Gabor! Thanks for this patch. I'm ready to commit it but I'd like to make one change to the syntax.

Rather than using:

I'd prefer to use this, which will maintain consistency between the 6 and 7 versions and not break the indentation:

@Gabor, I was trying to apply this patch to Drupal HEAD and see how it would let me do anything with fields and I couldn't even get it working. After spending a bunch of time on that, I found that the 7UX site has working code with lots and lots of patches that I didn't have and presumably will work better, but by then I was out of time to do anything more, so that's where I stopped.

@quicksketch: I am fine with that change, feel free to go ahead and do that.

Uploading our latest changes from the google repository. Although we did not work on formbuilder since the d7ux code sprint (given more important focus on general d7ux implementation), this might have some little improvements over the previous one. Seutje and others fixed issues like dangling commas at end of lists, which cause problems in certain browsers. Might be a good idea to fix in the D6 version too. Also, the patch might contain development code snippets, so review carefully.

I'm going to remove the code from our repository, given that it is not going to be worked on there anymore, so this is most probably our latest patch on the form_builder before D7 code freeze at least.

Attachment	Size
formbuilder-7.patch	36.31 KB

subscribe

+    $files[$file->filepath]['module'] = $file->name;
should be
+    $files[$file->uri]['module'] = $file->name;
no?

changed

to

not sure if this is the way to do this, but it made the error go away

removed $form_settings[$node_type]['body_field']['min_word_count'] = $type->min_word_count; as per #522184: Remove the 'minimum number of words' feature from Drupal

shouldn't

be moved from form_builder.admin.inc to form_builder.module, since the idea is to use this as a menu-call and it is annoying to have to include the admin file

should the admin/build/form-builder URL's be reformed to admin/structure/form-builder or would this go under another category?

attached file is based on Gábor's patch in #17
sry if I left some stray dsm() call behind

Attachment	Size
formbuilder-8.patch	38.17 KB

subscribing

sub

subscribing