Port form_builder to Drupal 7

subscribing

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)

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!

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#

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.

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:

Drupal.behaviors.formBuilder = {
attach: function() {

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

Drupal.behaviors.formBuilder = {};
Drupal.behaviors.formBuilder.attach = function() {

@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.

subscribe

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

changed

$result = db_query("SELECT * FROM {node_form_settings} WHERE type = '%s'", array($node_type));

to

$result = db_select('node_form_settings', 'nfs', array('fetch' => PDO::FETCH_ASSOC))
  ->fields('nfs')
  ->condition('nfs.type', $node_type)
  ->execute();

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 function form_builder_interface($form_type, $form_id) 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

subscribing

sub

subscribing

subscribing

While it's clear that Form Builder isn't going to be a part of Drupal 7, I did a small update to this code to make it more likely to continue on Drupal 7 branch.

- I reverted the form_builder_cache to cache_form_builder change. The table was intentionally named this because it's not a typical cache table. It MUST be persistent across cache clearings and Form Builder manages this itself. Views does the same thing with the views_cache table.
- I removed all Options Element changes, since I've moved that to a separate project and ported it to Drupal 7 separately. You can get it from here now: http://drupal.org/project/options_element
- Other than that, a reroll for current HEAD of Form Builder. This patch also needs to be updated for the new theme system and DBNG, so we're still a ways from a Drupal 7 version.

I removed Form Builder integration from Webform 3, which was the first place I expected to see Form Builder put to practical use. However since it would add a significant overhead to maintenance of Webform maintaining two completely different editing interfaces, I removed it for the time being. It's unclear at this point when Form Builder will get further attention.

Ok, here is a version where the form_builder_example works I think as intended :) Yay! Delta from the last patch above is following:

- configure form now includes submit button; as the weights form also has this nice code comment, Drupal needs a submit button to execute the form and actually save the configuration elements; it is hidden with CSS though, so its not visible; this CSS is not loaded when on the standalone config page form, so the submit will show there
- no need for a hook_install() anymore, schema installed automatically
- DBTNG updates to .install, .admin.inc and .cache.inc files with all the funky db_delete(), db_merge() and friends used (there is surprisingly not that many queries in the module actually)
- no registry anymore, so form_builder.module's hook_menu() needed file and file path information for callback; same goes for form_builder_example.module
- removed input_format element on textarea; I guess we need to figure out how to support textarea and the now different text_format element
- I did not remove hook_registry_files_alter(), but suspect there is no need for it anymore :)
- drupal_json() became drupal_json_output()
- formAPI introduced $form as the first argument for each form callback; I just added this in and did not modify current logic (which works fine)
- reworked CSS and JS addition with #attached css, js and library; I generally believe we should make theme_form_builder_preview a #theme_wrapper but I was not actually successful in making that work
- class attributes became arrays, not strings
- theme callbacks now get a $vars array, from which we need to gather the elements ourselves; similarly, theme() invocations needed to use arrays
- drupal_render() becomes drupal_render_children() where we are already in rendering
- in form_builder_field_render(), the way we add on arguments and other form_state values changed due to how core changed (eg. args goes under build_info now)
- light updates in form_builder_node.module (but see below)

The main goal of this update was to make form_builder_example work as in Drupal 6, and as far as I'm seeing, that is how it does with the attached patch. The focus is to bring back webform integration in a way, not to make it work as a CCK / node form editor replacement, so I did not look into node.inc, path.inc, etc. The formapi level fields defined in the example module should work as designed however :)

I've also submitted an independent report to options_element at #949556: for (var n in ...) not reliable which I've experienced in my environment but will not be apparent to people just running a stock Drupal 7.

What do you think about opening a Drupal 7 branch, so we don't need to toss around a huge patch?

Thanks Gabor! Back for round-2. ;-)

I think a D7 branch is a good idea, when I get a chance to review this patch I'll branch HEAD for 6--1 and use HEAD for D7. Please continue to split out changes that will affect new versions into separate patches as you did with #949556: for (var n in ...) not reliable, much appreciated.

sub

Rerolling the patch to fix one bug: Neither radios nor checkboxes were displaying titles when used inside the form builder.

This turned out to be due to #914792: Custom element properties entirely override default element info properties (which is a D7 core bug). The patch here contains a quick workaround for that which could perhaps be simplified if the patch in that issue is eventually committed to D7.

Hi Gabor! thanks for your new patch.
But I have a bug when view checkboxes configuration, It did not display form option as it was displayed in Drupal 6. When I printed $form, it still display options's values. what's the matter with theme form???
I'm looking forward to hearing from you.
Best Regards
Lauren

P/S: I fixed a bug above. I didn't install module Options Element.

As an update on this issue, we've been developing some more D7 code for this module - despite the silence here :) We still need to get the work from our local repository split off into different patches though, since as we've been developing this further to actually use the module in production, there's been a mix of D7-only bugfixes, D7 improvements that aren't really bugfixes (e.g., switching to #theme_wrappers in some places), bugfixes and improvements that could be backported to D6, etc.

The above patch, though, is already over 50kB, and last I remember was pretty functional by itself - I believe the form_builder_examples module is mostly usable in D7 with the above patch applied. So do you think you'll have a chance to create a D7 branch soon? With that, it will be easier for us to split off our other changes into dedicated issues with patches against the branch, rather than adding to an already gigantic patch.

Thanks!

Subscribe, waiting for D7 branch

Subscribing

Subscribing

subscribe

Subscribe.

Hey David, with your D7 version now completed I've "officially" branched HEAD for D7 work and will be using DRUPAL-6--1 for D6 work. Would you prefer the above patch going directly into HEAD or a reroll based on your current work?

Great, thanks!

I'd prefer the above patch going directly into HEAD. (Some of the more recent work involves bug fixes that probably apply to D6 also, feature-y things that would be better in their own issues, etc.) If this gets committed then it would be easier for us to make patches based off CVS HEAD in the followup issues.

Okay I revised a few minor points (restructured the JS for compatibility) and included a set of changes to the D6 version.

Thanks! I think the commit accidentally missed some important parts of the original patch, though. See attached.

The CSS change I assume you intended to include since it was in the D6 backport, and the rest should be relatively self-explanatory... :)

Thanks, with commits this fast and furious I've gotten a bit sloppy. :\

Committed your follow up patch directly.