Adding UCM web forms to Site Studio web pages
By Kyle Hatlestad on Nov 23, 2009
UCM has a great built-in feature for handling HTML forms called Hypertext Content Server Forms (HCSFs). They are basically dynamic server pages that are checked into the server and rendered using Idoc Script. When a form is submitted on a HCSF, the data is stored in a newly checked-in HCSP file. The data within that HCSP is contained in a XML data island. You can then render that HCSP and get access to that data through Idoc Script, render that data through Dynamic Converter, publish it with Content Publisher, or add an '?IsXml=1' to the end of the web URL to get the data back as a pure XML file. UCM even has a WYSIWYG utility to create your own forms called Web Form Editor. To read more about HCSFs, they are covered in the Dynamic Server Pages guide.
Traditionally, these forms are presented as standalone pages. They would contain the HTML form code and the <!--$idcbegindata--> ... <!--$idcenddata--> section that stores the data. They would be checked in and accessed with their web URL (e.g. http://server/idc/groups/public/documents/system/permit_form.hcsf). This works well if your form is an independent entity. But what if you want that same forms capability, but in context of a Site Studio web site?
Well, there is a subtle trick to get this to work. The form itself does not need to be rendered in an HCSF file but rather POINT to an HCSF file. So the form can be presented on a Site Studio page and have a reference to a simple HCSF file that is already checked in. To point to that HCSF, simply add the form field for 'dID' with the dID value of that HCSF. For example:
<input name='dID' value='123'>
The easiest way to get the HCSFs dID is to go to its Content Information page and look at the URL. It should reference its dID.
The HCSF itself can be very simple thanks to the ability of the ExtraRootNodes input value to dynamically add form fields to the XML data island. So the HCSF can be generic and look like:
So now all of the forms on the sites can point to this one HCSF as the starting point.
The next logical question is "Can content contributors build their own forms?". With some fancy scripting, absolutely. You can make it very simple for them to add their own forms using standard WYSIWYG contribution elements. Below are the basic steps:
- Create and check in an HCSF file to use as the pointer for the form. Make note of its Content ID. Here is a file that will allow you to display the submitted HCSP with the form and data.
- Create an Element Definition based on WYSIWYG with the Form Support checkbox enabled.
- Create a Region Definition with the Element Definition created above. (If you want to use the sample Region Temple provided below, name the element 'Content')
- If using the sample Region Template, set the 'HTMLFormTarget' variable to the Content ID of the HCSF submitted in step 1. Then set the 'ConfirmationPage' variable to the Node ID of the section to redirect to after submitting the form. Then set the 'SecurityGroup', 'ContentTitle', and 'ContentType' variables to define the default metadata for the form.
- Add the Region Definition and Region Template to your Placeholder Definition.
Now if users create new content, they can insert form fields and a submit button and it will become a live form.
The way this sample was created could be built in many different ways. Originally this was done as a fragment (prior to 10gR4). Or you could make the choices for the Confirmation Page and metadata as contribution elements as well in the Region Definition. So then the contributor can control those things. Or you can add custom tools in the editor to drop in validation script for the user. It could be extended in many different ways.