Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Because form_builder uses AJAX calls to the server to load the field configuration forms and submit them. I thought it would be good to use a general implementation of the AJAX calls so that they could be made more robust.
I added a default retry of 3 to all of the AJAX calls so that communication errors would be retried 3 times before the error was escalated to the user. This should cover most connectivity hiccups while still alerting the user that their connection to the server is down for a somewhat extended period.
I also added a locking mechanism so that the page would wait on a response from the server before allowing other form submissions that may also be on the same page. For example, if the field configure form is being auto submitted via keyup and the user clicks "Save" for their webform.
The deleteField() method had to be adjusted for this approach. The
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | form_builder-ajax-1010926-4.patch | 5.77 KB | grahamc |
| #2 | form-builder-ajax-1010926-2.patch | 5.81 KB | David_Rothstein |
| form_builder_ajax.patch | 5.96 KB | james.elliott |
Comments
Comment #1
quicksketchThis patch has some good ideas but the implementation is a bit wonky. I'm not really a big fan of putting things like error messages into Drupal.formBuilder.ajaxOptions and then pulling it back out in the event of an error. jQuery already provides mechanisms for passing arguments into $.ajax() commands that are then available in e.data (I think that's where they go at least). I'd much prefer to use these local variables when possible, this seems like it could be prone to reporting the wrong errors in some situations (say a user tries to update a field that doesn't work, but at the same time they drag out a new field).
So I'm marking this one needs work and I'll continue through the queue and return back to it once I've got all the easy issues out of the way.
Comment #2
David_Rothstein commentedPatch no longer applied against the latest 7.x-1.x code, so here is a reroll. I haven't addressed any of the feedback above, so leaving this at "needs work".
Comment #3
quicksketchPlease reopen or file a new issue if still interested in this.
Comment #4
grahamcQuick re-roll, to try and get Webform Alternate UI working with current Form Builder again.