This is a rough sketch of how this project can be done. There are many ways to tackle it, but only a few are truly Drupal-like.

Overview

Because this project will result in a true Ajax application, a lot of client side code will have to be written. This is in contrast to Drupal's current Ajax features (like autocomplete) which rely on server-side PHP logic for everything.

Still, there might be some benefit to be gained from not doing everything on the client side. Whatever the client does, the server will need to do (e.g. verify validity of properties). Some things will be server-side anyway (e.g. generating the code).

So, the client-side code should very much be only UI code and aggregating data.

Creating forms

Creating forms requires two things on the client-side: a UI to create and edit forms and an underlying data structure representing the forms.

Data structure

For the data structure, it might be tempting to start from scratch. That way, you could tailor your Javascript code to your usage. But, that would mean you'd need to convert your data structure to a $form array sometime later. Either on the client side, or on the server side.

It would be much better to try and replicate the entire $form array on the client side and manipulate it directly. We already have a lot of form.inc api functions which could be ported to Javascript easily. PHP maps easily to JS if you keep some things in mind (associative arrays become objects, foreach becomes for...in, etc).

To date in Drupal, JSON has been used to pass data from PHP to Javascript (see the function drupal_to_js()). For the form builder, JSON could be used as the format of the $form array. (Doing so would require some additional code on the server side, as we currently lack a method for converting JSON to PHP.)

A second option would be to pass data in XML format, using XSLT on the client to render content. This option would be a new direction for Drupal Javascript and would require new parsers (PHP methods to serialize and unserialize XML). Potential tools might include the Sarissa library, used to facilitate cross-browser client-side XML handling, including XSLT. The http://www.formassembly.com/form-builder.php uses XSLT and, while not itself open source, is built on two GPL libraries, wForms and Freja.

UI

For the UI, you could try to build a small set of flexible base functions in JS. These would be used to alter the form in generic ways: insert a new item, move an item, delete an item, etc. Likely these would have the form of a DOM element manipulations (insertNode, createElement, ...) with some simple templates. The resulting HTML structure should be logical and clearly delineated using classes and id's. This allows a proper styling to be added later by a designer (less work for you!).

Then you'd have more specific functions for dealing with the individual form element types (checkbox, textfield, fieldset, ...). So to create a new checkbox, you'd call item = createNewItem() and then createNewCheckbox(item). For each manipulation of the internal $form array, there should be a corresponding UI modification and vice versa.

Obviously there needs to be a lot of verification going on here. It does not make sense to nest a textfield inside another textfield for example. Radio buttons come in two or more. Etc.

To achieve this, it might be possible to use a general constraints system that either takes very simple conditions, or hardcodes in a flexible way the various requirements for elements.

Saving forms

When the client side is done, following the approach above, there should be a valid $form array being submitted. The server-side would parse it back in. It is very desirable that there is no extra processing here. The entire $form array can be encoded in the HTTPPost data and read in transparently.

Still, if possible the validity of $form needs to be verified here too. So the client side constraints would need to have both a JS and PHP validator version. To avoid too much duplication, the client side could focus only on simple constraints (proper nesting, uniqueness of names, ...) while the server-side could do more in-depth checks (valid attributes, valid callbacks, ...).

Once the $form structure is generated, it needs to be saved. At first, simply saving it to the database as a serialized PHP structure should do. Later you can add output as PHP code: the code is written to a PHP file and appropriate skeleton hooks are added.

Here, it might be interesting to look at module_builder module. While a complete merging of module_builder and ajax_form_builder is a lot of work way beyond the scope of this project, it would be nice to already tune the two modules for eachother. That way, if someone does want to merge the two, the amount of code to be rewritten should be tiny.

About complexity

The forms API is a very large system with lots of elements and properties. It would not be very smart to try and tackle all of it at once.

For the beginning start with some simple cases. For example, only stick to basic element types (textbox, button, textarea) at first, move on to trees (checkboxes, radios, ...), then nesting elements (fieldsets, ...). Stick to the essential properties first (#title, #default_value, #description, #name, ...).

Of course, while doing this you still need to keep in mind that whatever you do, it needs to be expandable to accomodate dozens of element types and properties. If you find that for each property you need 30 lines of code, then something is definitely wrong. Your code should be generic and take its behaviour from easily defined structures (e.g. arrays of allowed properties, flags for nesting and trees, ...).

The same goes for the client side: take things one step at a time, but be sure to accomodate future modifications. Write your JS code with the least possible number of assumptions. When you move an item, all you need to know is where from and where to. What's inside it does not matter. When you edit a checkbox's label, it should follow exactly the same code as editing one label of many checkboxes, or even a label for a fieldset.

The most important thing is to validate all your work along the way. Don't code away, hoping it will all fit together at the end. From the start, make sure you can always see and verify your code immediately. From the moment you're generating a $form array, you can see the result of drupal_get_form('test', $form).

If you keep this in mind, you will spend your time much more wisely and efficiently.