Ask a Muse Asks:
Do you know if there are limitations to either the file-size or the number of fields in a flashform?

There is indeed a limitation to the "flex compiler" that is included with CFMX. The limit is either 32k or 64k depending on who you ask. I cannot find (off hand) the actual MM document that describes the limit. The limit is to the amount of "compiled actionscript". It is affected by pretty much everything you do in the CFFORM tag. Even adding a style can cause a change in the size.

[More]

To follow up on my previous post regarding Coldfusion Flash Forms Limitation Too Draconian. Both Paul Hastings and Ryan Guill have blogs on the topic that add additional information. Paul added in an list post that even actionscript comments are disallowed by the parser. So in other words if you do the following:

The flex compiler will complain that the words are not "legal actionscript". That's a bit ridiculous. I'm betting that CF does a pre-compile "dumb" check of the code snippet string using a regex before it's even handed off to the flex compiler - that way they didn't even have to install a modified version of flex.

You probably know that when you use flash forms in Coldfusion MX 7 you are not allowed to use the word "new" in any of the actionscript event handlers you choose to create. For example, you could not write "myvar = new Object();" in your actionscript. If you tried, you would get a message saying that it was an "illegal use of actionscript". What you may not know is that you cannot even use the "new" keyword as a string!

[More]

When it comes to form elements, which kind of validation is appropriate? The new CFFORM with the flash format comes with very nice client side validation with highlights and feedback. Is that enough? Should you validate on the client using JavaScript or should you just stick with server side validation? In my opinion you should do both - but if you have to cut corners, make sure and validate on the server. Note, by validation I'm referring to checking values of a form for the correct type or requirements. For example, you might want to make sure an Social Security Number is 9 digits, or a phone number is 10 digits, or that an email address has been filled in and is the correct format. You get the idea. Here are the pros and cons of both approaches.

[More]

Figuring out the nuances of formatting and positioning flash forms in CFMX is a challenge - especially when you first start out. I found this link to the flex style explorer yesterday on an MM blog by John Dowell. We are not involved in a flex project at the moment - although I have installed and played with te flex server and IDE a little bit. Even so I found this to ap to be very useful. You might know that the flash forms that are a part of CFMX 7 are created by a restricted version of the flex server. Many of the styles listed and explored by the explorer ap are available within the flash forms of a cfmx server. In fact, you can copy styles out of the flex style explorer directly into the styles attribute of a cf form item and it will work (if it's one of the valid flash form style attributes).

[More]

Although I love flash for UI's, there are things about it that are tough to work around. One of them is the "fixed size" nature of the medium. When working with a multi-paned Flash object I often find myself writing javascript functions to resize the movie container based on the amount of data in the pane. I hate having tons of empty space in pane "A" just because pane "B" needs the real-estate. Or having to size the movie quite long because one of the panes is extra long. I want the embeded object to work like a really well-made CSS site. I want to "fix" the size of some things (navigation, info or helper clips), but make the "content area" fluid - like a good three column layout (is there such a thing - ha). It would be great if the publish options simply included an "auto-size" option that embeded the necessary JS in the page. Maybe an item for the wish list eh?

Silly me, I assumeed you couldn't insert images into a flash CFGRID. I stumbed across this example on an excellent blog by As Fusion (laura Arguello and Nahuel Foronda). Apparently you can insert thumbnails right into the grid using an HTML element. That's a new one on me. The trick is to bind a column in the grid to a CfFormItem. As always, someone will always find a way.

We've begun using the flash form of the cfform tag to prototype UI's that will eventually be built in flash. While you cannot duplicate the functionality of a flash UI with remoting and listeners etc., you can get pretty close to duplicating the data and UI display. Let me explain.

[More]

It's trying not to have adequate access to the client side movie produced by a flash form. For example, I Have a large number of panels in an accordian pane and I want to hide or unhide them based on user preferences. I also want to resize the form movie as the panels are "hidden" to make better use of the visible area of the screen. I wanted to be able to change the "height" and "width" parameters of the movie.

The problem is, that while the "NOSCRIPT" block has an ID parameter to it, the "document.write" block that outputs the object tag does not have and ID parameter attached to it (in spite of my putting ID="blah" in the CFFORM tag). That seems like a bug. Anyway, I went about trying to find another way to access the properties of the embeded movie. I came up with the following:

[More]

While I'm enjoying the power and especially the "look and feel" of the new flash forms interface I'm are a little frustrated with the lack of good debugging information. It would be nice if additional information could be ported into the Coldfusion debugging info at the bottom - or a perhaps a log file could be written. It's very hard to know what's going on. When a flash form is long it takes a while to compile anyway. Because I don't know how long it should take I end up sitting on my hands waiting for the little "initializing" to appear. If it doesn't I assume something has gone wrong internally and start looking at the code. That's not exactly slam dunk debugging.