ColdFusion: a History of Portable Code?
(December '04)
(Commentary) This time I'll skip the blasphemy and get straight to the commentary. After all, this particular
piece is aimed at the Allaire Brothers themselves, rather than my favorite long-necked chickens: Macromedia.
Until the advent of "real" functions in ColdFusion (which I haven't bothered to take advantage of yet),
writing "Portable Code" for ColdFusion was rumored to be difficult to impossible. Naturally, a few of us knew
better, but this misperception was stubborn indeed. The questions of course is, "Why so stubborn?"
Perhaps the central need for Portable Code in web programming is... FORMs. Building the forms in HTML,
and processing the client submissions on the server. Because this is the central portability need,
it's a safe bet that it also is a central cause of the "non-portable" misperception. Hence our field of inquiry
has narrowed.
For portable form processing, we need two things:
- A list of the form fields received from a submission, and
- the ability to access the values in the form fields w/o hard-coding.
Sounds simple, doesn't it. And actually it is simple. But why the mystery? Upon reading through the ColdFusion
Manuals (version 4.0), the reason becomes so obvious you can see it with your mouth.
The picture below is scanned from page 163 in the ColdFusion manual. It is the ONLY place I've found where
item (1)
above is referenced. If you overlook this one little paragraph, then you miss the boat completely.
You will NEVER know about the "fieldnames" variable.
But in addition to being obscure, it also appears to be almost intentionally hidden. It isn't in a section
about FORMs, see. Instead, it's in a section about Queries. Hmmm...
Ok, so now we found this "fieldnames" thing. What can we do with it? Well, if we move toward the front of the manual,
we find some information on pages 114 to 118. In particular, we learn about the "Evaluate" function. We learn
that we can use the Evaluate function to get the value of dynamic variables.
Of course there's no mention of the MOST IMPORTANT dynamic variable: fieldnames, and consequently we may
see this entire discussion go in one ear and out the other of many neophyte readers.
NEVER in these manuals is there an explicit discussion of dynamic processing of form fields. Never. Why?
Well, on page 119, we get a clue. This type of discussion is... "advanced." So, even though it could very well
be the MOST IMPORTANT discussion in the ColdFusion manuals, it is omitted. Sure, the relatively stubborn and
creative reader
can put the puzzle together. However, the whole pupose of ColdFusion is to make server-side programming easy.
And if the instructions are omitted, then it is NOT easy.
So, HERE ARE THE INSTRUCTIONS, a few years late. You can print out a list of fields and values returned
from ANY form as follows.
<CFLOOP index="i" List="#fieldnames#">
<CFOUTPUT>
#i# = #Evaluate("FORM.#i#")#<br>
</CFOUTPUT>
</CFLOOP>
And that's all there is to it. If this one little chunk of code had been presented clearly, concisely
(what could be more concise?), and OBVIOUSLY, then the entire issue of non-portability would not have surfaced.
Ever. And that's the plain truth.
(Blasphemy) Naturally, Macromedia is bound to carry on the Allaire tradition. They're so proud of their
manuals they don't print them. Naturally, lots of folks will crow that printing manuals drives up cost and
wastes paper. Therefore, NOT printing the manuals is good.
However, again, the whole point of ColdFusion is to MAKE THINGS EASY. If a manual isn't included
with a product, then it must not be very important. Or... maybe it just sucks. Either way, no manual is
no manual.
