I've been working on a tool for a client that wants to be able to create web forms to use on their site without learning any programming at all. At the same time, I don't trust any data from the browser side on a web site. I always assume that the browser side is open to hackers. That means any submitted form data has to be validated before it is accepted. Here's what I did...

For publishing, I used the CKEditor, which is the web browser rich editor I've standardized on. For most web publishing uses, I use an icon set that doesn't include the buttons for creating fields and forms. For this use, I turned those back on. The result is that right off the bat I've got a slick editor that lets the publishers lay out the form any way they want. The output from the editor is a big chunk of html stored in a text field on the Domino form when it is submitted.

The tricky part comes when the new form layout is saved. A webQuerySave agent reads the html that contains the form and parses out all the fields, keeping track of the field names, values, option lists, field types, and so on. In short, the agent quickly grabs all the information needed to validate the forms that will ultimately get submitted by an end user. This was really the tricky part, since the HTML isn't xml compliant enough to use existing parsing tools. You've got to account for all kinds of perfectly common variation in how field parameters are specified. Once you get it right though, the possibilities really open up. Field names are checked against a list of reserved field names, and a simple list of the field names is saved back so that the publisher can pick from them to indicate which are to be required fields.

Displaying the finished form to users could be done several ways. One way to do it would be to use DXL to generate an actual Domino based form that matches the fields defined in the layout. The advantage there is that Domino would do all the validation for me and it would be immune to many of the kinds of security attacks that I'd otherwise have to code for myself. In my case, I opted not to go that way because there will be so many different forms. In my case, each of these custom forms has an ID that is used on the website using a special form built into those publishing tools. The custom form's ID is passed as a parameter to a generic form display page. The ID is taken from the parameter and an AJAX call quickly grabs the custom form code and inserts it onto the page. When the form is submitted, the action points to another agent which receives the user data and validates it against the form's definition.

The benefit here is that where we've already empowered non-technical content owners to create and manage rich sites themselves, now we've added the ability to let them design and publish their own forms right within the site in a way that doesn't limit the way the forms are laid out in any way.

Very cool stuff.