Words, punctuated » ColdFusion Flash Forms

Loading a cfform SWF into another SWF

Paul Robertson — Tue, 06 Mar 2007 17:27:30 +0000

I haven’t written about ColdFusion Flash Forms in a while (I’m a Flex user now that you no longer need a server to create the content). However, this morning I got an interesting question from “trifide” that I hadn’t considered before, so I’m making a brief return into cfform land:

There are many attempts to loading external swf into cfform… But what about the contrary? Do you know a way to embed cfform into a flash movie? i.e. call a cfform in a movieclip without getURL and external pop-up ..

I started writing a comment response, but naturally it was getting pretty long-winded so I decided it deserved its own posting.

When you use cfform in a coldfusion page, the server generates a SWF file, with its own URL. (I don’t know whether it actually writes it to the disk, or whether it just keeps it in it’s memory — but from the end-user perspective that doesn’t really matter.) More specifically, it generates a SWF, then sends the appropriate HTML to the browser including the URL of the SWF. From the browser’s perspective the SWF is a completely separate item at a different URL — the browser doesn’t know that the programmer wrote it all in a single document. You can see the generated SWF’s URL by looking at the HTML source code of the CFM page.

For example, consider the page at the following URL (an example accompanying an article by the folks at ASFusion):

http://www.asfusion.com/blog/examples/cfdj/

If you view the source, you’ll see that the page includes some JavaScript that is used to write the appropriate object and embed tags into the browser page. Right in the middle of that you’ll see this line (today at least; the file name may change in the future, as explained below):

document.write("   src='/blog/examples/cfdj/859792312.mxml.cfswf' ");

That’s the line of JavaScript that’s writing the SWF’s generated URL into the page. So we know that there is a URL that the web server will recognize and, when a computer requests that URL, the server will return the appropriate SWF.

You can try it out if you’d like — try requesting the SWF’s URL directly (i.e. http://www.asfusion.com/blog/examples/cfdj/859792312.mxml.cfswf) and you’ll see the same SWF, without the HTML page wrapper.

So, knowing the URL of the generated SWF, you can use it in the same way you’d use any SWF. As I mentioned, you can type the URL in the browser to request it directly, or you could alternatively load it into another SWF using MovieClip.loadMovie() or any other MovieClip loading technique (e.g. the Loader class in ActionScript 3.0).

Potential issues

There are, of course, a couple of gotchas that you’ll want to keep in mind.

First of all, notice that the generated SWF’s URL is really just a number with a couple of file extensions. The reason for that is because this generated URL represents a single version of your cfform SWF. If you change the source code of the cfform in such a way that it needs to recompile the SWF, then the server will generate a new SWF with a new URL. So any time you change your cfform, the URL will change too (and, obviously, you’ll need to change the URL that’s called by the other SWF doing the loading). The reason the URL changes is to prevent the browser from using the cached (old) SWF — with a new URL, the browser loads a new SWF.

An obvious workaround is to just make a copy of the generated SWF and put it at a permanent URL. Like I said, I’m not sure if ColdFusion actually writes the generated SWF to the server’s hard drive, or whether it just keeps it in memory. If it does write it to disk it should be easy to get a copy from the server. If not, you can just load the SWF directly in a browser and then choose “Save As…” (or whatever) from your browser to save a copy of the SWF locally. BUT, by using a single URL, you lose the automatic versioning that prevents the browser from caching the SWF. You can find one idea to work around that issue (i.e. to do your own SWF versioning) in my article “Using URL Variables and FlashVars” (specifically the URL Variables part of the article).
Second (and this is a big one): From my rudimentary tests, it looks like any queries in the CF page that the cfform uses are not available when you load the SWF separate from the CFM page. I’m not sure why — I’d have to look more at the generated MXML to try to figure it out — but my guess is that the SWF makes use of the URL of its container HTML page to figure out where to communicate to get its data (rather than having the CFM page’s URL hard-coded into the SWF). Depending on what you want to use the cfform for, that probably throws a big wrench into things.
If you’re actually using the cfform for its intended purpose — that is, as a form to submit data — you’re going to have some issues with loading it into another SWF. When you submit a cf flash form, it navigates away from the current URL to the cfform tag’s “target” URL (essentially using LoadVars.send(), so clicking that button on a cfform SWF loaded into another SWF would navigate away from the container SWF as well.

Finally, I can’t help but mention that loading a cfform SWF into another SWF may be a case of over-complicating something that can be done better in other ways. The obvious alternative is to just use Flex directly to create the form SWF, then loading the Flex SWF into the other SWF. Naturally, that means you’ll need to learn Flex…but if you’ve used cf flash forms then you’re already well on your way into that territory — just write out the generated mxml and take a look at what it consists of; then change a few things in the cfform and see how that changes the generated mxml…and so on. Don’t get me wrong — I’m sure there are legitimate reasons for using cfform rather than Flex in this situation, and I obviously can’t predict all the use cases. But over the long run I think you’ll find it’s a lot easier, without any of the issues or side effects, to use Flex.

Dynamically change a cfinput field’s label (new and improved)

Paul Robertson — Mon, 03 Oct 2005 16:29:59 +0000

In a previous article I demonstrated a workaround approach to dynamically changing the label of a cfinput field in a ColdFusion Flash Form. Thanks to some great feedback from Laura Arguello, I’ve now worked out some improvements to the solution, so that it doesn’t require a “fake” label as the previous approach did. So, here it is, the new and improved way of dynamically changing the label of a cfinput field. (If you read the previous article, the explanations are similar — the solution is just simpler.)

If you want to skip the explanation, here is the finished working code.

Note: this example is intentionally more complicated than it might need to be — in some cases, it is possible to accomplish the same results using only data binding and without needing any additional ActionScript. Laura’s post gives a great example of this. For these examples, I intentionally decided to make it a bit more complicated, because it also allows for more flexibility in the final result. I recommend looking at both the simpler and the more complex approaches, and deciding what meets your needs best.

To begin, in this example there is a combo box () in the form, as well as a text input field with a label (). The selected item in the combo box determines the label that is assigned to the cfinput text field; to control this, we will write some ActionScript for the cfselect’s onchange event (but we’ll get to that later). So that I don’t have to keep repeating it in later code listings, this is the CF code for the combo box and the form. To make this example more real-world, I’ve put a number as the value in each

I think much of the confusion about being able to change a cfinput text field’s label dynamically lies in the way you define the label on a cfinput text field (by setting the “label” attribute in the tag — very easy). Naturally that leads to the (incorrect) assumption that you can just access a “label” property of the text field in ActionScript to change that label. Therein lies the biggest complication with using ActionScript in CF Flash Forms. Remember, the tags you define, and their attributes, are all part of ColdFusion. However, this is really all just a wrapper for the real Flex engine that is under the hood. Once the ColdFusion code gets turned into Flex MXML, the ColdFusion code is gone and you need to use the Flex object model to access the properties of your form fields (more on this subject).

One of the places this gives us trouble is with the label of a cfinput field such as an ordinary text input field. In CF, you might define it something like this:

We have a basic cfinput text field. Pretty straightforward. Under the hood, this cfinput field gets turned into the following MXML:

Notice the critical difference here: the single cfinput tag actually gets turned into two distinct MXML tags (which means they are two different objects from the perspective of accessing them using ActionScript). The name you give to the cfinput field (“payDetail”) is assigned as the id of the control. This is useful so that we can set it’s value, for instance. However, notice that the label we assigned is actually part of the tag that wraps the control. That means that the label itself is not a property of the mx:TextField, and the mx:TextField control knows nothing about it. In addition, the mx:FormItem tag doesn’t have any id assigned to it. This is critical — the id attribute of the MXML tag is what you use in ActionScript to refer to that object, so an item with no id can’t be accessed with ActionScript. This means, of course, that you can’t change the label directly using ActionScript. Ugh.

The new solution

(If you’ve been following along, here is where things start to change from the previous approach.)

So there is no way to directly change the actual label using ActionScript. However, as Laura kindly pointed out, we can define a binding statement for the label attribute of the cfinput tag, and that binding will cause the label to dynamically change any time the value it’s bound to changes:

So we can get the text into the label dynamically using a binding statement; the only question is, what do we specify as object/property to “bind” our label to? It can’t just be any ActionScript or other code — it has to be an actual object or property of an object.

We need to have a form field whose content will control the label of our text input field. Since we probably don’t want to have some random control appearing in the form, our best option is to use a hidden form field (cfinput type="hidden"). The hidden form field won’t actually serve a purpose in terms of the data that is submitted by the form — it will simply act as a container that the label attribute is bound to. When the user chooses an item from the combo box, we will use ActionScript to set the value of the hidden form field to whatever we want the label to show, and Flex’s data binding will automatically update the label to match. Here’s what the CF code looks like with those changes:

If you haven’t worked with them before, Flex (and CF Flash Forms) binding statements are always surrounded by curly braces. The natural inclination might be to just use the name of the hidden form field (“payDetailLbl”) in the curly braces, but that doesn’t work. In fact what you need to do is use [form name-dot-hidden field name] (“paymentForm.payDetailLbl” in this case). The reason for this is because hidden form fields are not actually added to the MXML as Flex controls, as visible controls are. Rather, they are added as elements in the mx:Model tag (which is essentially a general data repository that ultimately contains a value for each form field, which is how they get submitted back to ColdFusion when you submit a CF Flash Form). Those mx:Model elements are given names, and can be accessed in your cfform’s ActionScript as child properties of the form, as we do here.

All that’s left to do now is to write the ActionScript which will change the label when a new value is selected in the combo box (its onchange event). Just for looks, we’ll also make it so that when no payment method is selected in the combo box, the input field is hidden. That means it will be hidden by default, so we need to make a minor change to our text input field so that it looks like this (the change is bolded):

visible="false" width="85" />

Finally, the ActionScript itself will be written like this (yes, I’m still using cfsavecontent until my server admin installs CF MX 7.1):


payDetail.visible = true;

switch (payMethod.selectedItem.data) {
	case "10": /* Department acct */
		paymentForm.payDetailLbl = "Account #:";
		payDetail.width = 85;
		break;
	case "11": /* PO */
		paymentForm.payDetailLbl = "PO Number:";
		payDetail.width = 100;
		break;
	case "12": /* Check */
		paymentForm.payDetailLbl = "Check #:";
		payDetail.width = 85;
		break;
	case "13": /* Credit Card */
		paymentForm.payDetailLbl = "Card #:";
		payDetail.width = 120;
		break;
	default: /* no selection */
		payDetail.visible = false;
		break;
}

The code checks the value of the selected from our tag . In ActionScript you access this using the selectedItem.data property of the combo box (whose id comes from the cfselect’s name). So in this case the value of whichever item is selected in the combo box appears in the code as payMethod.selectedItem.data. The code does the following things:

The most common case (with the text field visible) is set (payDetail.visible = true). Otherwise this line would need to be repeated for almost every one of the possible conditions.
The switch statement checks the selected item in the combo box. (payMethod.selectedItem.data).
Depending on the item that is selected, the width of the text field is adjusted (since credit card numbers are usually longer than check numbers) and the hidden form field’s value is set (paymentForm.payDetailLbl = "[some label]"). Setting the hidden form field causes the label to be changed, because the cfinput tag’s label attribute is bound to the hidden field’s value.

A couple of other points to note:

The “default” case (which in this case is triggered if no payment method is selected) hides the text field completely by setting its visible property to false.
For the “case” values in the switch statement, even though the values are numbers they are wrapped in quotation marks. This is because the payMethod.selectedItem.data value is a String, and the switch statement in ActionScript uses strict equality to make its comparison (meaning it checks both the value and the data type of the variable being compared).
If you try this out at this point, you’ll notice that the form is “jumpy” — every time the label of the text field changes, the position of the form fields shifts because the label’s width changes. To get around this, in the final code I padded the combo box’s label with spaces on the left hand side so that it is always wider than the text field’s label — so it’s width (which doesn’t change) determines the position of the form fields.

That’s all there is to it. You can download the final code if you want to try it out..

Dynamically change a cfinput form field’s label (ColdFusion Flash Forms)

Paul Robertson — Fri, 30 Sep 2005 17:16:24 +0000

Note: After I wrote this article, Laura Arguello offered some valuable feedback which led me to a similar but better solution. Since I learned something new, I wanted to pass it along, so this article is now superseded by (a better way to) dynamically change a cfinput field’s label.

I’ve seen a couple of entries in my server logs for people trying to figure out how to dynamically change the label of a cfinput field in a ColdFusion Flash Form. This is something I ran into myself a few weeks back, so I thought I’d share what I learned.

Unfortunately, this seems like it should be really easy, but it’s actually impossible to do “for real” (at least as far as I’ve found). I did figure out a way to get the same result using a bit of a workaround. To demonstrate this idea, I’ve built a simple CF Flash Form that has a combo box (cfselect) that lets you choose a payment method. Depending on your choice, the label of a cfinput type="text" field changes. If you want to skip the explanation, here is the finished working code. If you want to know more of the how and why, here goes:

Before I start, in this example there is a combo box () in the form, as well as a text input field with a label (). The selected item in the combo box determines the label that is assigned to the cfinput text field; to control this, we will write some ActionScript for the cfselect’s onchange event (but we’ll get to that later). So that I don’t have to keep repeating it in later code listings, this is the CF code for the combo box and the form. Notice that to keep this example simple I’ve just put the desired label in as the value in each

One of the places this gives us trouble is with the label of a cfinput field such as an ordinary text input field. In CF, you might define it something like this:

We have a basic cfinput text field. Pretty straightforward. Under the hood, this cfinput field gets turned into the following MXML:

So there is no way to change the actual label using ActionScript. There is there an alternative, a way we can simulate a label in a way which will allow it to be changed. One way to add arbitrary text to a CF Flash Form is using a element. So rather than using the built-in label for our form field, we can add a text formitem and use it as our field label. In order to get them to display like the form field’s label did, wrap them both in a cfformgroup type="horizontal":


 	PO Number:

In order to make it match the look of the real form field label, you will need to add some style attributes to the cfformitem element, but I left that out of this example for simplicity (the final code does contain styles). This ColdFusion code gets turned into the following MXML:


	
		{remoteObject_paymentForm.getData.result.CFFORMITEM_4}

Something interesting to note is that the label text that is specified in the ColdFusion (“PO Number:”) doesn’t actually appear in the MXML — instead it is represented by the Flex binding statement {remoteObject_paymentForm.getData.result.CFFORMITEM_4}. That’s very promising — it means that that text is actually being accessed dynamically, which means we can probably also change it. In fact we can. The mx:Text control that is created from our cfformitem type="text" tag doesn’t have an id attribute, so we can’t access it directly using ActionScript, but one of the attributes we can use in the cfformitem type="text" tag is the “bind” attribute, which allows us to specify an object property that will serve as the source of the text. So we’ll get the text into the label dynamically using a bind statement; the only question is, what do we specify as object/property to “bind” our label to? It can’t just be any ActionScript or other code — it has to be an actual object or property of an object.

Remember I warned you, this does require a bit of a workaround. We need to have a form field whose content will control the label of our text input field. Since we probably don’t want to have some random control appearing in the form, our best option is to use a hidden form field (cfinput type="hidden"). The hidden form field won’t actually serve a purpose in terms of the data that is submitted by the form — it will simply act as a container that the label formitem is bound to. When the user chooses an item from the combo box, we will use ActionScript to set the value of the hidden form field to whatever we want the label to show, and Flex’s data binding will automatically update the label to match. Here’s what the CF code looks like with those changes:


	bind="{paymentForm.payDetailLbl}" />

For me, one tricky part was figuring out the exact syntax to use in the “bind” statement to refer to the hidden form field’s value. If you haven’t worked with them before, Flex (and CF Flash Forms) binding statements are always surrounded by curly braces. First I tried using just the name of the hidden form field (“payDetailLbl”) but that didn’t work. After a bit I figured out that I needed to use [form name-dot-hidden field name] (“paymentForm.payDetailLbl” in this case). The reason for this is because hidden form fields are not actually added to the MXML as Flex controls, the same way visible controls are. Rather, they are added as elements in the mx:Model tag (which is essentially a general data repository that ultimately contains a value for each form field, which is how they get submitted back to ColdFusion when you submit a CF Flash Form). Those mx:Model elements are given names, and can be accessed in your cfform’s ActionScript as child properties of the form, as we do here.

We’re almost there now — all we have to do is make it work =). More specifically, we need to write the ActionScript which will change the label when a new value is selected in the combo box (its onchange event). Just for looks, we’ll also make it so that when no payment method is selected in the combo box, the input field is hidden. That means it will be hidden by default, so we need to make a minor change to our text input field so that it looks like this (the change is bolded):

visible="no" type="text" width="85" />

Finally, the ActionScript itself will be written like this (yes, I’m still using cfsavecontent until my server admin installs CF MX 7.1):


if (payMethod.selectedItem.data == "") {
	payDetail.visible = false;
	paymentForm.payDetailLbl = "";
} else {
	payDetail.visible = true;
	paymentForm.payDetailLbl = payMethod.selectedItem.data;
}

The code uses the value of the selected from our tag . In ActionScript you access this using the selectedItem.data property of the combo box (whose id comes from the cfselect’s name). So in this case the value of whichever item is selected in the combo box appears in the code as payMethod.selectedItem.data. The code does the following things:

The if statement checks if the default (blank) item was chosen.
If so, it hides the input field (payDetail.visible = false) and sets the label to "" (an empty string).
Otherwise, a real value is selected, so the input field is shown (payDetail.visible = true) and the hidden form field’s value is set (paymentForm.payDetailLbl = payMethod.selectedItem.data). Remember that setting the hidden form field causes the label to be changed, because it is bound to the hidden form field through the “bind” attribute.

That’s all there is to it. You can download the final code if you want to try it out, or to see how I added style formatting to the field to make it look like a real field label. One thing you may notice is that in the final code I added a label to the combo box as well. In order to make things line up nicely, it uses another fake label created with cfformitem type="text", even though in that case the label isn’t actually dynamic.

Getting meaningful data from dynamically generated fields in ColdFusion Flash Forms

Paul Robertson — Wed, 10 Aug 2005 21:36:25 +0000

Part 4 of My first foray into ColdFusion Flash Forms.

Note: This article will make more sense if you read the previous one first.

In the previous articles I talked about two approaches to creating a repeating set of form controls (in this case checkboxes) in a ColdFusion Flash Form, based on data in a query. I recommended one approach, which is to use a cfformgroup type="repeater" tag to create multiple controls, because it doesn’t require the SWF file to be regenerated each time the underlying data changes. The alternative, using a cfloop tag to create cfinput type="checkbox" controls, does require the SWF file to be regenerated each time the underlying data changes.

However, the cfloop approach has a big advantage. By creating the checkbox controls separately within your CFML, you can specify a separate name for each checkbox control, and it is easy to differentiate between them when the form is submitted.

Consider these two examples (which are the same as in the previous article, except that I have added a “submit” button to the form).

As described previously, this example uses a cfformgroup type="repeater", which dynamically generates the checkboxes on the client, using ActionScript in the SWF file.

Again, the difference here is that a cfloop is used to generate the checkboxes in the server, so in the generated MXML (and the generated SWF file) they are separate checkbox controls.

When you submit these forms, the results are surprisingly different.

The output of the first example (using cfdump var="#form#") looks like this (assuming the first and the third checkboxes are checked):

While the output of the second example looks like this:

Obviously there is a significant difference. When we submit the first form, we only get one name/value pair containing the values for all the checkboxes. Not only that, but all we get for each checkbox is a true/false value. There is no practical way that we can figure out which associated value in our underlying data source was selected. However, with the second example, because each checkbox was created separately on the server (and we were able to give each one its own name) we see four different name/value pairs — one for each checkbox.

This is a serious problem for the cfformgroup type="repeater" approach to dynamically creating form controls. If there isn’t any way to get the data back, there isn’t really any point to creating the form a in the first place. I hoped that there would be a way to assign a “data” value to each checkbox which would get returned in place of the true/false value (in the same way that multiple checkboxes with the same name in an HTML form return a value). But there doesn’t seem to be a way to do this.

Unfortunately, I think this boils down to a limitation in the fact that the CF Flash Forms are using Flex but are submitting their data as if they were HTML forms. If we were actually building this same form using Flex, then there would be no need to get anything more than a true/false value from the checkbox. If we wanted to know which underlying values were selected, within our Flex application we could write code that would loop through the checkboxes to find out which ones are checked, and use that in combination with the underlying data (which would also be available to the ActionScript) — we could then manipulate that data, send it to the server, etc. however we like.

But that isn’t how CF Flash Forms work — they submit their data to the server as though it was from a traditional web form. Note that we could actually use an alternative approach (e.g. Flash Remoting) to submit our data, rather than using the standard “submit” behavior of the Flash Form — but that seems like a lot of extra work just so that we can have a dynamically generated set of form controls built the right way according to Macromedia’s recommendations.

However, I was able to come up with a workaround. Admittedly the data submitted by the form isn’t necessarily as clean and convenient as with the “checkboxes generated by cfloop” approach, but it at least makes it possible to get the data associated with checkboxes.

The solution: input type="hidden". As you probably know, within an HTML form you can use a “hidden” form field to store a value which gets submitted by the browser but which doesn’t have any visible manifestation on the page. With a CF Flash Form, you can add an input type="hidden" field to the form which has the same effect. So to get the id values associated with our checkboxes, we just need to create a hidden form field which contains all the id values in a comma separated list. Just add these lines to your code:

.
.
.


	

.
.
.

.
.
.
	
	

.
.
.

Notice that outside the cfform tag we use cfloop to create a variable that is a ColdFusion “list” containing all the id values from our query. The contents of that variable are then set as the value of our hidden form field.

So now when we submit our form, we see results that look like this:

Notice the one (significant!) difference — there is now an extra name/value pair being submitted by our form, containing a comma-separated list of the ids from our query. Within the page that processes this form submission, we will have to loop through the two form fields (the one containing the true/false values and the other containing the ids) to match them up, in order to determine which values are the “selected” ones.

At this point, astute readers will probably be thinking “wait a minute, in the last article Paul said that it’s bad to use cfloop with CF Flash Forms, because the server has to regenerate the data each time the data changes. What gives?”

That was exactly my concern with using this approach. However, the CF engineers apparently anticipated this need (and here I have to give big kudos to those CF engineers, because I think what they’ve done is just brilliant). Take a look at the MXML generated when the is included. Try to find what the gets turned into in MXML. Give up? Look near the top for a tag named mx:Model. It looks like this:


	{chk.selected}
	{remoteObject_form1.getData.result.ids}

Notice that it contains two elements, which correspond exactly to the values that are submitted with the form. The is how the true/false values actually get put into the form field named “chk” that is submitted with the form. And there’s our hidden form field, in the tag. Notice something very important about it: it doesn’t contain a hard-coded list of values which would need to be recompiled each time. Rather, it contains a binding to an ActionScript value (the stuff in curly brackets {}). At the end of the previous article I pointed out that the “remoteObject_form1” is an object defined in the Flex MXML that essentially is how the SWF file gets the latest data each time it is loaded in the browser, without needing to recompile on the server. The value contained in the tag is a binding to the “ids” property of that same remote object. This means that each time the SWF file loads and gets the latest data from the server, it also gets the latest values to submit as the ids form field — but still without requiring the server to recompile the MXML.

Again, all I can say is that whoever wrote the code that is smart enough to turn my ColdFusion code (that I just wrote off pretty much off the top of my head)…

…into this MXML…


.
.
.
{remoteObject_form1.getData.result.ids}

…is just brilliant.

(Well, either that or I just got really really lucky and happened to type just the right CF code that gets turned into that MXML. Okay, we all know how likely that is. =)

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

Paul Robertson — Wed, 10 Aug 2005 21:35:14 +0000

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.

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.

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:

.
.
.

	
		
			
		
	

.
.
.

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:

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:

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

Advice for building and debugging ColdFusion Flash Forms, from one beginner to another

Paul Robertson — Wed, 10 Aug 2005 21:33:52 +0000

Part 2 of My first foray into ColdFusion Flash Forms.

Just a sort of hodge-podge of things that were useful to me.

Write your event handler code using cfsavecontent, as I learned from Niklas at Prismix.
Chances are you will want to run more than one line of code when you press a button, and although you can’t define an ActionScript function that gets called by the button you can do the next best thing, which is this technique.
Give your form a name (e.g. ) and cfdump the form to see the MXML generated by it (using placed after the closing form tag).
Being able to see the actual MXML output has given me tremendous insight into what is actually happening “in the guts” and consequently helped me figure out best ways or even possible ways to do things that would have been much more difficult otherwise. You even get to see the ActionScript source code for the functions that are automatically added by ColdFusion =).
Take some time to learn ActionScript, and use the Flex reference materials to understand the Flex code. I have been doing stuff with Flash/ActionScript and some Flex for a while, so I found it pretty easy to pick up. In fact, for me personally my weak point with ColdFusion Flash Forms is the ColdFusion part. I know that may not be the case for you if you are reading this, but I’m sure we can all find something new to learn =).

Next: Creating “dynamic” form fields in ColdFusion Flash Forms – how and why

How to: Select all checkboxes in ColdFusion Flash Forms

Paul Robertson — Wed, 10 Aug 2005 21:32:33 +0000

Part 1 of My first foray into ColdFusion Flash Forms.

I actually came up with two different approaches to this problem, because we figured out two different ways to dynamically create form fields in Flash forms. Conceptually they are similar, of course; you have a button which calls some ActionScript code that loops through all the checkboxes and sets their “selected” property to true. Unfortunately the implementation details are pretty different.

Approach 1: Using cfformgroup type="repeater" (Flex creates the checkboxes)

Source Code

In this approach, the checkbox controls are dynamically created by the SWF file. The Flex code that creates them conveniently creates an array whose elements are the dynamically created checkbox controls, so we just loop through that array and set the “selected” property of each element to true (or false for “deselect”). The array variable you use has the same name as the name you give to the cfinput type="checkbox" in your ColdFusion code. Your ColdFusion code to create the repeating checkboxes looks something like this:

.
.
.

	

.
.
.

Flex automatically creates an array named “chk” which you can refer to in your ActionScript code, whose elements are the Checkbox controls.

Approach 2: Use cfloop to create multiple checkboxes in the form

Source Code

In this approach, the checkbox controls are created in a cfloop that runs on the server. To create the “select all” functionality we just loop through our query and dynamically create the ActionScript that will be used by the “select all” button like this:


	
		boxMBAa_#q1.id#.selected = true;

Note: Unfortunately the only ColdFusion servers I have access to belong to my employer, so I can only post source code and not working examples on my personal site. Sorry!

Comparing the two approaches

Approach 1 advantage

The repeating controls are actually generated in ActionScript in the SWF file, not on the server, so when the data changes the SWF file doesn’t need to be recreated by the server. See the article “Creating ‘dynamic’ form fields in ColdFusion Flash Forms - how and why” for more details.

Approach 2 advantage

Each checkbox control is submitted as a separate form field (name/value pair); you can define the names given to the form fields. See the article “Getting meaningful data from dynamically generated fields in ColdFusion Flash Forms” for more details.

Approach 1 disadvantage

The checkbox values are submitted as two lists, one containing true/false values indicating whether a checkbox was checked or not, and the other containing a list of “id” values which correspond to the true/false values. See the article “Getting meaningful data from dynamically generated fields in ColdFusion Flash Forms” for more details.

Approach 2 disadvantage

The repeating controls are generated by the ColdFusion server before creating the MXML and subsequent SWF file. When the data changes (and maybe every time the page is requested) the server must regenerate the MXML and recompile the SWF. See the article “Creating ‘dynamic’ form fields in ColdFusion Flash Forms - how and why” for more details.

Next: Advice for building and debugging ColdFusion Flash Forms, from one beginner to another

Select all checkboxes in ColdFusion Flash Forms (Intro)

Paul Robertson — Wed, 10 Aug 2005 21:27:15 +0000

One cool technology,
Two ways to do it, and
Three lessons I learned

Alternate title: My first foray into ColdFusion Flash Forms

I have to admit that, while I was wowed a bit by the ColdFusion Flash Forms demos a year ago, once I heard that Flash Forms still submitted their data just like a normal HTML form, I lost my enthusiasm.

In general I don’t do a lot of ColdFusion programming any more — most of my work is in Flash or ASP.NET, although I do maintain some CF pages that I haven’t ported over to .NET yet.

However, a few weeks ago a friend from my local Macromedia Users’ Group contacted me with a CF Flash Forms problem he was trying to solve. He was working on a Flash form with form controls (in this case, checkboxes) that were dynamically generated from a database query, making one checkbox per record in the query. He had that part figured out, but he wanted to add a “select all” button to the form that would select all the checkboxes. Since this was a problem that mostly involved ActionScript, and since I do have a CF MX 7 server available even though I don’t really use it, I decided to take the plunge.

I learned quite a bit in the process, and I’ve also gotten pretty excited about CF Flash Forms. I’m starting to see all sorts of ways I could integrate them into some of my current projects. My more CF-centric colleagues are having a good laugh over this since we have an ongoing .NET vs. ColdFusion debate =). Of course, the real solution would be to just get Flex…but maybe I’ll have to start with Flash forms so I can have some proof of the value before I make that pitch.

This actually only took me a couple of hours to figure out; of course it isn’t until now, several weeks later, that I have finally gotten time to write about what I learned. So without further introduction, allow me to present:

Select all checkboxes in ColdFusion Flash Forms

Plus three lessons I learned in the process:

MXNA Reader built with CFForms

Paul Robertson — Mon, 01 Aug 2005 22:03:19 +0000

ASFusion is at it again, this time with an MXNA Reader built with CFForms. Wow!

Remoting for ColdFusion Flash Forms

Paul Robertson — Mon, 01 Aug 2005 21:59:51 +0000

Want to use Flash Remoting in your ColdFusion Flash Forms? ASFusion has the scoop…