June 13, 2005

Sorry Coldfusion MX 6.1, we've gotta let you go

Sorry Coldfusion MX 6.1, but.... we've got to let you go. It's an unfortunate turn of events, but when you can't hold up to our expectations as an application server it's time to turn to different options.

Yes, we did try all kinds of things to get you to understand utf-8. From setting every page, component and function we could think of to use encoding utf-8 to even setting the cfprocessingdirective on EVERY SINGLE PAGE but you refused to understand the global language of utf-8. We also tried the far fetched idea of importing the data as binary and converting it over with the (newly added to 6.1) ToBase64 function to utf-8, but you spat out nothing but gibberish.

How sad we felt when we thought our savior was at hand after we tested Colfusion MX 7 with our new code and it worked! Praise the new version of Coldfusion! Even though setting everything under the sun to utf-8 didn't work, our far fetched idea of reading the data in as binary and converting it to utf-8 did! How surprised we were...

Unfortunately when we visited the Macromedia "Worldwide" store with our credit card in hand and eagerly tried to buy your newest sibling, Coldfusion MX 7, our "worldwide" Visa card was regected due to the application not understanding Japanese characters.

Feeling slightly dejected we decided to run off to the Japanese store, but to no avail as they are much too cool to offer the upgrade version of yourself and sent us off to a "partner" company who did not offer "real" online shopping as it said on their site. We would have been forced to make a bank deposit and only after that confirmation would we have received up to one week later our very much needed upgrade to make our application work as needed.

So alas, we gave up as our "experience" so far was quite disappointing and started to wonder if really it would be worth the cost of the upgrade. We have no clients that have asked for your services, which is most unfortunate but it is a fact, and to tell the truth most choose not to have their apps developed with you. Why? we can only guess...

So without further ado we set about to recreate your functionality with another application server... ASP.NET Thanks to our server being windows 2003, ASP.NET is in actuality, free. Just a bit of studying to be done on reading XML data and parsing it though. A small cost compared to over 600 dollars for upgrading we thought.

It's an unfortunate series of events that has lead to your demise here as we were actually so close to having you all sparkly in your newest duds. *sigh*

But have no fear as we still need you for one thing that upgrading to the newest version will have absolutely no effect, FLASH REMOTING. Yes, we still love your remoting ability, and that is what you shall do from now on. We use you profusely with our FCS apps, and our desktop flash CMS apps, which means you are still useful to us and that means you are needed.

Anyways, keep your chin up and turn that frown upside down because even though we've given up on you for normal application development, when it comes to ease of use of flash remoting you're tops in our books :)

Posted by Graeme at June 13, 2005 03:04 PM
　



Comments

this entry sounds like a whole lot of nonsense. cf 6 certainly supports utf-8.

Posted by: PaulH at June 13, 2005 04:28 PM

sounds like the problem is between the monitor and the chair, thats a crazy childish rant!

Posted by: dave at June 13, 2005 04:51 PM

Uh.. ColdFusion MX is by default encoded in UTF-8?? You don't have to SET the encoding at all. And if things DO go wrong it's probably your database or the driver.

But hey.. good luck with asp.net!! did you know that flash remoting is also available for that platform, you can skip the whole "NOT WORKING" Coldfusion bit and go develop tags in .NET..

Posted by: Tjarko at June 13, 2005 06:10 PM

Uhoh, the CF community attacks again, how obvious.

I believe the writer had issues with the fact CFMX uses UTF-8 by default, but previous versions of ColdFusion always used ISO-8859-1. This can lead to alot of nasty situations where foreign characters don't show up.

Although CFMX 7 is a good release, we also experienced alot of issues when migrating from CF5, and it sure has put a stamp on the product inside the company regarding robustness (and proving CFMX being a "need to have" product as opposite to a "want to have" product is already very hard). Things like broken QoQ, stability of the server, changes in how structures are handled. They all took alot of our valuable time.

I pretty much understand why he is making the move. Especially when more competiting products are becoming more oriented at quick development.

Posted by: M. Schopman at June 13, 2005 06:26 PM

micha, that's not what he said at all. he said cf "refused to understand the global language of utf-8". which simply isn't true no matter how you take it.

Posted by: PaulH at June 13, 2005 09:33 PM

We have been using CF 6.1 with Chinese, Japanese, Korean and Arabic with no difficulty. As stated above, UTF-8 is set as default. As for migration issues, the have been a relatively non issue, as well.

Posted by: D. Ringley at June 13, 2005 10:54 PM

Damn, who released the hounds....

Posted by: Kris at June 14, 2005 12:00 AM

Wow.. thanks for the snipes guys. :|

Well.. CF does support UTF-8, I agree. But in this case it is NOT reading in certain feeds that ARE utf-8. Some, it did. I took out all possibilities of problems like the DB driver and DB. Tried different browsers just in case, and writing the feed to a file didn't work either. CF just could not understand the codeset in the feeds.

Just to let you know, I'm working with the MXNA1.0 code. So go snipe at MM and fullasagoog 'cause it's the same code. :p

But we also don't have any problems using coldfusion with flash remoting which means that yes, it does support utf-8 when it's coming from itself.

Posted by: Graeme at June 14, 2005 12:06 AM

Graeme, do you have any code samples online? It might help others facing the same issues.

Posted by: M. Schopman at June 14, 2005 12:10 AM

And to top it all off, it DOES NOT work in CF6, but it works in CF7 and worked right off the bat with ASP.NET.

Code samples.. yes.. but you'll have to get the MXNA code from MM (it was on the DRK3) or from Geoff over at fullasagoog. I'm afraid I can't put it out. But either way, it's just a cfhttp call to read in a blog feed and put it into a DB (I took this step out and dumped to the page). Absolutely nothing special at all.

Posted by: Graeme Bull at June 14, 2005 12:15 AM

SIC EM BOYS!!

Posted by: ballz at June 14, 2005 12:27 AM

Hi, Graeme. MXNA 2.0 is completely UTF-8 compatible (the 1.0 version was based on the Fullasagoog code base, but 2.0 is a complete rewrite). It did take a bit of work to get it there, but it works perfectly, and parses feeds in any language. If you need some specific help, send me an email. I'm pretty sure it will be easier to get it working in CF than to switch to .NET.

Christian

Posted by: Christian Cantrell at June 14, 2005 03:56 AM

you might want to talk to roger benningfield about this, we worked thru some encoding issues for his app early last month. i think these are summarized here:
http://mxblogspace.journurl.com/users/admin/?mode=article&entry=7288

Posted by: PaulH at June 14, 2005 02:27 PM

ahh, thanks Paul for that! I'll give it a shot and see if it solves the problem.

But it does go to show that something very odd is going on in CF. Good to see that there is a light at the end of the tunnel as it's not by desire that I turned to asp.net to solve the problem.

Posted by: Graeme Bull at June 14, 2005 02:41 PM

I'm extremely happy to announce it worked. Thanks again Paul!! You've saved us a bit of work on porting to asp.net (which we never wanted to do from the beginning)

Posted by: Graeme at June 14, 2005 03:25 PM

i guess next time, ask first, *then* throw the baby out with the bath water.

Posted by: PaulH at June 14, 2005 10:29 PM

agreed :D

Posted by: Graeme Bull at June 15, 2005 12:22 AM