AJAX Form creator

This project aims to create a browser-based form builder for Drupal. Examples of such form builders include:

• http://www.jotform.com/index
• http://wufoo.com
• http://www.formassembly.com/form-builder.php

In this case, though, what a form builder will build is not directly an HTML form. Rather, we need a UI for building a data representation of the form.

Background and need

In the recently-released 4.7 version of Drupal, a "Forms API" was introduced. The API includes a well defined data structure - a structured PHP array, typically defined as a variable, $form - through which forms are defined and rendered. For more information, see the links at http://drupal.org/node/37775, especially the Forms API Quickstart Guide and Forms API Reference.

Currently, module developers need to write PHP code to create forms through the Forms API. This has two disadvantages: a) not everyone can do it b) it's just plain boring and tedious. So there's a lot of interest in the community in seeing an intuitive UI for building $form arrays, complete with all their attributes.

Objectives

The eventual end goal is a client-side UI for building $form arrays that implements all the element types (checkboxes, fieldsets, etc.) and associated properties found in Forms API. Aside from the HTML form elements (checkbox, etc.), this means the possibility to group fields into a subtree (#tree), specify callbacks, and so on.

But, within the scope of this project, a sound design is much more important than a complete feature set. An early goal will be to establish realistic objectives, which likely will stop short of the whiz-bang does-everything app that everyone's hoping for.

Approach

The above mentioned examples are useful for inspiration, but won't provide the code needed in this application, as these form builders are not open source. Our solution must be GPL, and so will involve significant new development.

There is a number of directions that could be taken. Please see the page Suggested approach for some ideas--keeping in mind that these are guidelines and suggestions for further discussion and development.

Necessary experience and skills

We are aware that this is a particularly demanding project. If you don't have the following knowledge already, you probably should consider picking a different project:

• You have strong JavaScript skills, including an understanding of AJAX.
• You've studied the Forms API of Drupal 4.7 and know what we're talking about when we say "the $form array".
• You already know PHP.

There are some projects which can serve as good learning projects for Drupal, JS and/or PHP, but this one is not one of them. This is more for the student/expert who isn't a newb, and ideally already has some Drupal knowledge.

Thanks for your interest, and we look forward to discussing this project further as we seek the right fit!

Comments on this proposal

A few Questions....
silence - May 3, 2006 - 08:01

Hi!

A few questions...

1. The UI's of the examples vary a lot. Which one of http://wufoo.com, http://www.formassembly.com/ and http://www.jotform.com/index is preferred?

2. Any restrictions on how the drag and drop are implemented? (I dont know if wForms and Freja libraries have features like this. I am asking this to know if the public libs like the ones by script.aculo.us can be used.)

3. What are the general target browsers for this module?

4. Were there any previous attempts to make it? If yes where can I find the details?

Thanx in advance :)
======================================================
======================================================

Some quick responses
nedjo - May 3, 2006 - 13:10

1. This is an item for discussion.

2. There is a scriptaculous module implemented for Drupal (S/P Ajax), so it would be a candidate for using.

3. Likely, broad support (Safari, Firefox, IE, etc.).

4. Not that I'm aware of.
======================================================
======================================================

What about GWT?
jasonwhat - May 26, 2006 - 14:34

I might not understand ajax properly, but seeing as this is for Google Summer of Code it might be a good time to integrate Google Web Toolkit for Ajax creation and compiling. http://code.google.com/webtoolkit/
======================================================
======================================================

GWT
silence - May 28, 2006 - 05:58

A few notes about GWT:

1. When we use GWT, we program in simple JAVA using AWT and SWT.
2. GWT will be best used when we are creating a complete web based application. I think it might be difficult to use it with our own code. Does java offer drag and drop (I dont know) ?
3. Is GWT available as GPL? - I cant see the name mentioned anywhere though I see Apache License v. 2.0.

anyways could you explain the integration part in more detail.
======================================================
======================================================

I'm ignorant
jasonwhat - May 29, 2006 - 00:10

No, I can't really explain it more. I'll I know is that several different libraries are working their way into Drupal apps. Maybe I'm blinded by the big name, but GWT seems like a good stable library, compiler, whatever to hang Drupal's hat on rather than many of the others. That said, I really don't understand how it all works. I was hoping someone who understands this more could chime in on whether this would be useful or not.
======================================================
======================================================

Formlogix.com
tsabbay - December 27, 2006 - 14:45

hi guys,
you forgot the new player, we are small and highly motivate,
our form designer is really rocks, wufoo also got a nice touch
but we still think that we are much more flexible in terms
of design free,elements and data flexibility.
http://www.formlogix.com
======================================================
======================================================

Online Form Builder
shyamanthi - August 21, 2007 - 04:08

Why don't you try the form builder at http://www.flovv.com/. Its quite easy and can be built in no time. This is new and promising.
======================================================
======================================================

Form Builder wins hands down!
BioALIEN - February 19, 2007 - 12:43

Having just tried out all the links listed on this page, my hat goes off to Form Builder (http://www.formassembly.com). Very intuitive UI, very easy and straight forward. Unfortunately, it's not open source so life goes on.

Edit:
http://www.formassembly.com/wForms/

Its LGPL!

------------------------------
BioALIEN
Buy/Sell/Trade with other webmasters: WebMasterTrader.com
======================================================
======================================================

Suggested approach

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.