As I'm getting more and more into developing Flex 2 apps, I am running into silly little annoying problems and am going to start blogging them so I can find the solution when I forget and it happens again.

Problem: The ColdFusion Wizards in the Flex Builder 2 require you to connect to the CFMX server using RDS in order to get table information. In my case, I was getting to the screen where you choose an RDS server and datasource - but and the datasource box was empty. I knew there was a valid datasource at that location, and Flex Builder wasn't complaining that I'd given it a bad RDS password.

After a bit of troubleshooting, I found the following in CFMX's exception.log file: "File not found: /CFIDE/main/ide.cfm". This essentially means I didn't enable RDS when I installed CF. Whoops.

Solution: Since main/ide.cfm isn't an actual physical file, you have to tell CFMX that you want it to intercept calls for this file and handle them for you (enabling RDS). This is done via an entry in the web.xml file, typically located in [cfmxroot]/wwwroot/WEB-INF/. Just open up the file and do a find for "RDS". Two entries should be in there, both commented out. Simply uncomment them and restart CFMX.

Done.

As a side note, if Adobe's listening, it would be nice if Flex Builder were smart enough to tell you when RDS authentication fails or RDS isn't enabled on the target server.

Ben's coming to town May 1st! I just posted details to the SDCFUG website and it should be a good one since Ben's promised to demo ColdFusion integration features never yet seen outside of Adobe! Hope to see you there!

As it turns out, coldfusion.runtime.Array datatypes turn into java.util.Vector datatypes after WDDX deserialization. This isn't much of a problem for the most part. After all, the CFMX Array datatype is based on the Java Vector datatype. CF still views it as an array, and you can still treat it just like an array in CF code. However, there is at least one place it *does* matter - invoking and consuming webservices. It seems that when one of these java.util.Vector datatypes is passed to certain webservices, you will get the infamous and annoyingly indescriptive error that it "Could not perform web service invocation "X" because java.lang.IllegalArgumentException: argument type mismatch". Yowza. I've confirmed the behavior with some folks at Adobe, so hopefully it will be corrected with the Scorpio release. In the meantime however, I am getting around this problem by recreating/rebuilding the array before posting it to the webservice. A little annoying, but it works. If you want to test this gotcha yourself, here's some sample code to play with: <cfscript> testObj = arrayNew(1); </cfscript> <!--- returns coldfusion.runtime.Array ---> <cfoutput> Object Type Before: #testObj.getClass().getName()#<br /> </cfoutput> <!--- serialize/deserialize array ---> <cfwddx action="cfml2wddx" input="#testObj#" output="x" /> <cfwddx action="wddx2cfml" input="#x#" output="testObj" /> <!--- returns java.util.Vector ---> <cfoutput> Object Type After: testObj.getClass().getName()#<br /> </cfoutput>

Being built in the spirit of Ruby on Rails, ColdFusion on Wheels is very promising.

As posted to Slashdot today, the source code for an algorithm has been posted that promises to find MD5 collisions, making it even more important to add some salt to any use of hash().

Two posts back to back about the same SDCFUG meeting? Yes! In addition to talking about Lazlo and WebOrb, Charlie Arehart will be giving us an update on integrating .NET with CFML on BlueDragon. This is a welcome and timely update for our group as several of our SDCFUG members work in shops where both .NET and ColdFusion are used side by side, with varied levels of success.

This week at SDCFUG, Charlie Arehart will be presenting Lazlo and WebOrb, which provide functionality similar to Flex and Flash Remoting, respectively. If you are in the San Diego area this Wednesday, I would strongly suggest checking the presentations out!

Occasionally, when dealing with a CFMX cluster you are unsure of which instance or even what machine is really executing the code you are running. In these cases, the following codebit can be a lifesaver to discover where your code's really running. Hat tip to Pete Keleher for the instance code.

I just noted today that the login screen for CFMX 6 and 7 includes a version number and patch level. Using this information an attacker can readily identify unpatched machines which are ripe for attack. This is yet another reason to protect your entire CFIDE directory from prying eyes, and perhaps it would be a good idea for Macromedia to remove this information from the administrator login screen in future versions.

I was participating in a thread today on the ACFUG email list and something occurred to me about many developer's mental quest to develop the "Perfect Application". The thread was about the use of "SELECT *" in SQL code and debated the real performance cost or gain from using or not using "SELECT *". Lots of people had opinions, and in the end a semi-consensus was reached that while it was important to consider the implications of using "SELECT *", there are plenty of scenarios where it doesn't really matter. So many development questions are answered with "it depends". On the CFCDev list, I see so much "it depends" that I can predict the contents of some replies before even opening them. If I only had a nickel... But "it depends" isn't satisfying! A frequent lifecycle of a CF developer begins with a budding newbie roaming email lists and websites seeking "rules of thumb" and dutifully collecting them, jotting them down and attempting to "follow all the rules". They may learn that "SELECT * is evil", that "stored procedures are better for performance", or that slightly different syntax in an if statement results in some virtually unperceivable performance gain. As your bag of tricks grows, you mentally start to build the Perfect Application in your head. You think that if only you could implement all the things you've learned in one application it would be Perfect! It would be speedy and sexy and would finally prove you've arrived as a seasoned developer! As you continue to grow as a CF developer you realize that this list is not, in fact, the guide to the Perfect Application. You learn that while using Stored Procedures can speed up code, it can also increase development time and make the code less portable. That your tweaked if() statements are confusing to other developers on your team and slow development down. One by one each Rule of Thumb from your collection is slowly disassembled as you learn that there are very few actual Rules of Thumb. Perhaps along the way you discover Design Patterns and add them to your list, only to find out that they too have exceptions. In the end you realize that there is no such thing as the Perfect Application. Every rule has it's exceptions, and everything has a time and place. The makings of a great developer include not only knowledge of the tricks from your former Rule of Thumb list, but when NOT to use them.