Creating “dynamic” form fields in ColdFusion Flash Forms — how and why

Posted August 10, 2005 4:35 pm
Filed under: Articles by Paul, ColdFusion Flash Forms, Flash, Tutorials

Part 3 of My first foray into ColdFusion Flash Forms.

If you are used to using ColdFusion (or any other web development language that outputs HTML) you are probably used to the conceptual notion that these pages are like “templates”:

You create a file containing static text (generally HTML code) mixed with programming code
The server works through the code, processes it all (resolves all variables, loops, etc. to fixed values), and generates text output (the HTML page)
The server sends that text output to the browser, which renders it.

While the CF Flash Forms work in a similar way, the process has some differences which are important to understand in order to make your forms work the way you want them to:

You create a file containing static text mixed with programming code.
For any code inside a CFFORM tag with type="flash", the steps change a bit:
1. The server works through the code, resolving all variables, loops, etc. to fixed values as though you had hard-coded them within your ColdFusion code.
2. The server converts the now static CF code within the CFFORM tag to Flex MXML.
3. The MXML code is sent to the Flex compiler, which generates a SWF file from it.
Within the HTML page that the server sends to the browser, the server adds the appropriate tags to load the SWF file that is dynamically generated by the Flex compiler.

Note: this is just a conceptual explanation of the process, based on my experimentation. I have no idea whether this is actually how the process works, but this seems to be close enough to the reality to help me understand some important details about CF Flash Forms.

The critical part of this explanation is in point 2. Before the CFFORM content gets converted to Flex MXML (which will ultimately become the SWF file), all the variables, loops etc. — essentially, anything within a pair of # signs — gets resolved. The then-static CFML tags are converted to MXML. Why is this important? Compare the following examples.

These are two different ways of creating a dynamic list of checkbox controls in a CF Flash Form, based on data from a query (e.g. a database query). Both assume you have a query named q1 with three fields (id, firstname, lastname). In case you’re curious, these snippets are portions of the code presented in the previous article on two ways to create a “select all” button for checkboxes in a CF Flash Form.

<cfform name="form1" format="flash" height="600" width="450">
	<cfformgroup type="repeater" query="q1">
		<cfinput type="Checkbox" name="chk" Label="{q1.currentItem.firstname + ' ' + q1.currentItem.lastname}">
	</cfformgroup>
</cfform>

In order to create one checkbox instance per item in the query, this first example uses cfformgroup type="repeater" with a single cfinput type="checkbox" tag nested within it.

<cfform name="form1" format="flash" height="400" width="450">
	<cfformgroup type="VBox">
		<cfloop query="q1">
			<cfinput type="checkbox" name="boxMBAa_#id#" label="#firstname# #lastname#">
		</cfloop>
	</cfformgroup>
</cfform>

This second example uses a different approach to the same task. In order to make one checkbox per item in the query, this example uses a cfloop tag with a single cfinput type="checkbox" tag nested in it.

The SWF file output of these two examples is practically identical, at least visually. However, behind the scenes there is a significant difference between them. Let’s compare the MXML generated by each of them (obtained by adding a cfdump var="#form1#" to the page after the closing cfform tag).

MXML generated by Example 1 CF code:

.
.
.
<mx:Repeater id="q1" dataProvider="{remoteObject_form1.getData.result.q1._items}">
	<mx:Form marginTop="2" marginLeft="2" marginBottom="2" marginRight="2" widthFlex="1" heightFlex="1">
		<mx:FormItem>
			<mx:CheckBox selected="{UtilFunctions.isTrue(remoteObject_form1.getData.result.chk)}" id="chk" label="{q1.currentItem.firstname + ' ' + q1.currentItem.lastname}"/>
		</mx:FormItem>
	</mx:Form>
</mx:Repeater>
.
.
.

Notice that the cfformgroup type="repeater" gets turned into the MXML mx:Repeater tag, which still contains only a single checkbox tag. In other words, when the CF gets turned into MXML (and when the MXML gets compiled into a SWF) the process of generating the dynamic checkboxes hasn’t happened yet. Not until the SWF file loads in the browser, when the ActionScript underlying the mx:Repeater control loops through the query and creates its child controls, is the actual process of “dynamically generating the checkbox controls” carried out.

On the other hand, compare this to Example 2’s MXML output:

.
.
.
<mx:VBox creationPolicy="all" widthFlex="1" heightFlex="1">
	<mx:Form marginTop="2" marginLeft="2" marginBottom="2" marginRight="2" widthFlex="1" heightFlex="1">
		<mx:FormItem>
			<mx:CheckBox selected="{UtilFunctions.isTrue(remoteObject_form1.getData.result.boxMBAa_1)}" id="boxMBAa_1" label="Rob Smith"/>
		</mx:FormItem>
		<mx:FormItem>
			<mx:CheckBox selected="{UtilFunctions.isTrue(remoteObject_form1.getData.result.boxMBAa_2)}" id="boxMBAa_2" label="John Doe"/>
		</mx:FormItem>
		<mx:FormItem>
			<mx:CheckBox selected="{UtilFunctions.isTrue(remoteObject_form1.getData.result.boxMBAa_3)}" id="boxMBAa_3" label="Jane Doe"/>
		</mx:FormItem>
		<mx:FormItem>
			<mx:CheckBox selected="{UtilFunctions.isTrue(remoteObject_form1.getData.result.boxMBAa_4)}" id="boxMBAa_4" label="Erik Pramenter"/>
		</mx:FormItem>
	</mx:Form>
</mx:VBox>
.
.
.

As you can see, by using cfloop to create the checkbox controls, what (conceptually) happened was that the cfloop was processed and created one cfinput type="checkbox" tag for each item in the query. Each of those items in turn became a MXML mx:CheckBox control. This means that the process of dynamically generating the checkboxes happened on the server, within the ColdFusion processing, rather than on the client in ActionScript (in the SWF file).

Again we ask, then, why does this matter?

Since we are dynamically generating checkboxes from a query, the assumption is that the data will be changing. With the approach in the second example any time the underlying data changes the resulting MXML that is generated by ColdFusion will also need to change. Consequently, any time the data changes (and maybe each time the page is requested, regardless of the underlying data), the server will recompile the SWF file and users will have to download the SWF file again.

On the other hand, with the first approach, in Example 1, no matter how the underlying data changes the MXML that is generated by the ColdFusion page will always be the same. That means that when the data changes, the CF/Flex servers don’t have to recompile the MXML and make a new SWF — they can just use the one that was already generated and is stored in the server’s cache (and the browser’s cache, if the user has browsed to this page previously).

As stated in the ColdFusion Flash Forms documentation, compiling the MXML to SWF is a time-consuming and server-resource-demanding part of the process, so it should be avoided whenever possible. Only if the number of records and number of loops over those records is large should you consider dynamically generating the SWF each time.

As a side note, you may be wondering how the newest data get into the SWF file running on the browser each time, if the same SWF file is reused. Once the SWF loads, it calls back to the CF server (through Flash Remoting, I believe) and loads the data.

Notice in the MXML the mx:Repeater tag has an attribute dataProvider="{remoteObject_form1.getData.result.q1._items}". If you look at the complete MXML generated by the form, down near the end of the MXML code this “remoteObject_form1” object (which is the Flex mechanism used to get the data) is defined in this MXML tag:

<mx:RemoteObject id="remoteObject_form1" source="coldfusion.flash.adapter.CFFormAdapter" endpoint="@ContextRoot()/CFFormGateway/" concurrency="multiple" showBusyCursor="true" fault="appInitFault(event.fault)"/>

And near the top there is a function “appInit” which contains this line of code which actually makes the call to load the data from the server:

remoteObject_form1.getData(__form1_cacheid);

And that’s how it’s done!

Next: Getting meaningful data from dynamically generated fields in ColdFusion Flash Forms

Comments/trackbacks are closed for this post.

11 Comments so far

September 10th, 2006 at 8:37 pm
ColdFusionUsers.com is reported to have said:

Ever wanted to see the flex behind your flash forms (say that 10 times fast!) ? I inadvertantly learned of a great little trick over at Paul Robertsons Blog to do just that. It‚Äôs actually quite simple. After building your flash form, simply dump the form variable to the page. Example:
August 27th, 2005 at 4:11 pm
Andy Clark is reported to have said:

Nice set of articles which I will go through in more detail soon

Slightly OT but would you know if this is possible
and, if so, how?

I want to access a dynamically created URL for an image in a cfform
A hard coded version would look something like

This alternative also works
“>

The jpg I want will vary acording to a field, imageID, (in this case with a value 123) which I am calling via flashremoting by an onChange in a cfselect. The remoting works fine so that for instance the imageID value can be shown in a cfgrid but I cannot create a string that results in an image appearing
Thanks
October 6th, 2005 at 10:14 am
Andrew is reported to have said:

How can one get dynamically-named checkboxes and still use the repeater cfformgroup? When I attempt the first, I cannot bind data from a query to the checkbox’s ‘name’ value. This is frustrating!

-Andrew
October 6th, 2005 at 10:48 am
Paul is reported to have said:

Andrew,
Unfortunately the short answer is that you can’t have both dynamically named checkboxes and use a repeater cfformgroup. There are two options I’ve found to working around this issue, described in detail in this article:

http://probertson.com/articles/2005/08/10/select_all_cf_flash_forms/

To summarize the article, you can either use cfloop to create the multiple checkboxes, giving them different names (described as “approach 2” in that article) or you can use the cfformgroup type=”repeater”, but in that case you must give an explicit name to the checkbox and it will be used as the name for all the checkboxes (described as “approach 1” in the article).
October 15th, 2005 at 12:50 pm
Neil Bailey is reported to have said:

Paul,

Can you use a repeater to create a series of select boxes (which would then each be populated with their own queries)? or is the repeater really a nifty little component that is meant for radio buttons/checkboxes and not much else?

Any guidance here would be appreciated more than you know.

Thanks in advance.
January 26th, 2006 at 10:57 pm
Sterling Ledet is reported to have said:

So how would I create a Flash form of dynamically generated checkboxes correctly if I want them in a 5 column wide grid?
July 28th, 2006 at 12:23 pm
ColdFusionUsers.com » Blog Archive » Check Out that Flex! is reported to have said:

[…] forms (say that 10 times fast!) ? I inadvertantly learned of a great little trick over at Paul Robertsons Blog to do just that. It’s actually quite simple. […]
September 7th, 2006 at 7:12 pm
Fort Worth Marketing » ColdFusion Flash Form and Dynamic Checkbox Labels is reported to have said:

[…] Labels
Posted by brian under Uncategorized

Found the code above on this great site: http://probertson.com/articles/2005/08/10/creating_dynamic_form_fields/ It’s pretty straight forward and will give you dynamic labels for your C […]
April 8th, 2008 at 11:38 pm
digital primates IT Consulting Group - Blogs - Mike Nimer's Blog: Paul Robertsons on Flash Forms is reported to have said:

[…] Part 3: Creating “dynamic” form fields in ColdFusion Flash Forms — how and why […]
September 3rd, 2008 at 11:03 am
cfSearching: CFCALENDAR Tip - (..This must be Belgium) is reported to have said:

[…] flash/actionscript/flex coder. Let me be honest… I do not have one. But I found a great tip by Paul Robertson (thanks to an entry on coldfusionusers.com) which helped me get started. It showed how cfdumping a […]
March 12th, 2009 at 4:26 am
TechnicallyChris.com » Check Out That Flex is reported to have said:

[…] flash forms (say that 10 times fast!) ? I inadvertently learned of a great little trick over at Paul Robertson’s Blog to do just that. It‚Äôs actually quite simple. After building your flash form, simply dump the form […]