Web Form Logic in Drupal

A recent client requested a user-friendly (aka, web interface) means for creating web forms, logical workflow between forms and form-pages, and user-specified actions to invoke upon completion of these forms. What I'm getting at here is a solution comparable to Form Assembly, JotForm, and Wufoo.

The client wanted to move away from the above solutions in order to have a solution that's integrated into his site, rather than embedded using iframes, such that the data is accessible in whatever form he so desires. Being the Drupal nut I am, we decided to use ye ol' CMS. However, I soon bumped into a little problem... Drupal web forms aren't quite there yet. For those of you not familiar with this ongoing complaint, to which I came late on the scene, let me fill you in:

Drupal really depends on a two contributed modules: CCK and Views. CCK (content construction kit) allows users to define different content forms with different fields. For example, a cck-built content type would be a form that has a textfield called "Name," and number field called "Zip Code," and so on. Views lets the user specify how this content is displayed on different pages, the sort criteria, the filters applied, etc. Seems like a natural-enough solution for the aforementioned problem, right? The downside to CCK is that its robustness tends to get in the way when you're trying to create simple things... like forms... rather than robust things, like realty home-listings with Google maps, prices, nested views, etc. Every page of every form is its own content type, and every filled-out form is its own node... this creates some hectic database clutter, and kinda scrambles you when you're working with CCK and Views for their designed use-cases. However, the upside to CCK is the external module integration, especially by way of a little something called Worlfow-ng. Workflow-ng ("next generation") allows users to specify field-specific logic in a series of workflow steps, and a slue of out-of-the-box actions to perform at any given step (as well as an API for specifying custom PHP actions). An example scenario would be:

if the user clicked "yes" for question 1, "no" for question 2 then go to the podcast page otherwise email the site administrator with the following information: "blablablabla"

Of course you don't write it out like that, the web interface has buttons and checkboxes... but you get the gist. In short, this is exactly what I need. But... to go with this solution, I'd have to incur the cost of big fat ugly forms, where each page of each form is considered it's own "content type," stored all over the database for the sake of extensibility, etc.

For this reason, one "quicksketch" created a nifty module called Webform. Webform allows you to create simple forms, with a much slicker interface for building such forms than what CCK offers. The resultant forms are nodes rather than content types, the filled-out forms are aggregates under those nodes, and each form only requires one node for multiple pages -- all of which drastically saves on database clutter. The forms are much more intuitive to build than via CCK, and statistical reports are even generated for submitted forms. Quite sexy. There is one issue here, that the resultant form isn't quite as robust as a CCK-generated content type. Do I sound like a flipflop yet? Like I want to have my cake and eat it too? What I mean by this is that Webform is not extensible... if in the future I wanted to add a different field type, I couldn't just hit up the CCK-geared modules repository and nab a field-type. But more importantly, I can't use workflow-ng. Webform.module does let you add PHP logic for the forms, but it's not quite as intuitive as workflow-ng.

So the last alternative? Building the damn forms myself, using Drupal's built-in FormAPI. This is probably what a lot of programmers will do on their own sites, but it's not the recommended solution nowadays. Think of FormAPI as the method for building the forms for building forms. In other words, say we're using CCK to build web-forms, well someone had to build the administration form you use for building a CCK webform, right? In other-words, FormAPI is the programmer's enabler of webform solutions, but not to be used for anything I've been discussing in this post.

Ultimately, given some more (or easier) control over the CCK content types such that one can make content types multi-page and form-friendly, I think that the CCK solution will be the be-all-end-all. And eventually I'll stop whining and get off my ass to develop some module to provide that functionality. But until then, let me wrap up these alternatives with what I believe to be the ideal solution for three different scenarios:

• Webform.module: Your client needs to be able to create very simple forms -- little or no field-logic. You can still use workflow-ng to provide post-completion actions (like page-redirects and shooting off emails), but only PHP for the form-filling process itself.
• CCK + Workflow-ng: Your client wants to be able to create multiple forms, driven by logical workflow that acts upon the fields themselves (aka, if Field1="Yes" and Field2="No", etc). This is the ugliest, but most robust solution, and provides the client with all the power he so desires.

A few quick words if you decide to go the CCK route: get the auto node title module so your end users don't have to provide a title for the forms they fill out, lol. There's something floating around called CCK Wizard that lets you split your content types into multiple pages, but it's broken. If it was fixed, there would be some uber points for the CCK route. Also, I've heard it recommended to use Pageroute which allows the client to specify that one content type leads to another upon completion (think multi-step forms). My opinion is to not use this module, since workflow-ng provides that very functionality, along with all of it's logic sexiness.

Last, a bit off topic, but somewhat related: Actions + Workflow. If you're a Drupaler, you've likely seen these modules. They're not really an ideal solution for the situation at hand, and let me explain. Workflow-ng is something of a combination of these two modules, but with out-of-the-box defaults. Think of the actions/workflow combo as requiring PHP-customized actions based on given logical workflow steps. Very similar, but with that keyword "PHP-customized" being the real difference between actions/workflow and the workflow-ng module. Workflow-ng still lets you program custom workflow steps and actions, but it provides more defaults to work with. Honestly, past that I don't really know the difference between the actions/workflow combo and workflow-ng, maybe someone can inform me. Also, I think that actions.module made it into core for Drupal 6 (and therefore don't bother with the contributed module???) and I also think that the workflow module is being fazed out to the new core triggers module. Correct me if I'm wrong on either of these, but that's my $.02 on why to use workflow-ng instead of actions/workflow.