Get burnt using underlying java method in CF array

Today I received a bug report.  When I took a closer look at the bug, I realized that I used x.contains() method where x is a CF array.  The code needs to determine if an integer is in the array x, and the java contains() method does exactly what I need. (FYI: CF array == java.utils.Vector)

However, since the array is from JSON, hell breaks loose...

<cfset a = [0,1,2]>
<cfset json = serializeJSON(a)>
<cfset b = deserializeJSON(json)>
<cfdump var="#a.contains(0)#">
<cfdump var="#b.contains(0)#">

You would think both cfdump will give you "YES", but they do NOT!

YES NO

Why? if you try it you'll find that after serialized and deserialized to and from JSON, the array actually became [0.0,1.0,2.0] ! You may verify with #d.toString()# if you don't believe me.

So... how do I continue to use contains()?  You would think b.contains(0.0) would work, but actually this is what you need:

b.contains(javacast('double',0))

...and this finally returns 'YES'.

However, since my code need to work with both [0] and [0.0], I ended up writing the contains function in CFML instead with <cfloop> and <cfif>.

I thought I would save time by calling underlying java method, but I actually ended up spending more time fixing this 'bug'... For those who use underlying java methods in CF, watch out! Especially when you use JSON!

Have I used CF8 to its fullness?

Our team is starting on a new project, and we will be in the low level design phase soon.  One question that popped in my mind over yesterday's meeting: Have we used CF8 to its fullness?

CF8 brought a lot of new and improved features to the table.  Some of them I don't see us using any day, like .NET integration & Microsoft Exchange Server integration, while some of them we have tried, but then realize that they are not as useful as they seem at first.

Here are some CF8 functionalities that we tried or looked at but didn't get to use:

• Ajax tags are cool at first, but they turn out to be a big turn-off when...
  • we realize how many .js files the client need (20+ on average from Ext JS 1.1.1, YUI 2.3.0, & custom CF js from Adobe).
  • there are only so many additional theme available for Ext 1.x (1 to be exact) and none of the 2.x themes work with Ext 1.x. CF8 comes the following themes in /cfide/scripts/ajax/et/resources/css:
    • default (ext-all.css)
    • aero (xtheme-aero.css)
    • gray (xtheme-gray.css)
    • vista (xtheme-vista.css)
  • we realize how many hacks it takes to add functionalities to CFGRID that Adobe missed (calendar picker for type datefield anyone? context menu?).  For all hacks, at least 2 CF tags are needed: <cfsavecontent> and <cfhtmlhead>
  • the documentation of Ext 1.1.1 is not even linked by the main ExtJS page anymore and took us a while to find.  Good luck with the download link of Ext 1.1.1. :)
  • <cfwindow> doesn't work inside a <cfinclude>, so it becomes a mess when you use any template system provided by your MVC framework.
  • <cflayout type="border">cannot be nested, and css inside the <cflayoutarea> can be problematic.
  • <cflayout type="tab"> looks funny for a split seconds when the JS has not been processed by the browser
  • <cfsavecontent> fails to save functionality of tags that generate JS scripts to head in order to function (e.g. cftooltip)
  • <cftooltip> would sometimes show up on the lower left corner of the browser.
• Server monitor, as cool as they seem, do not work well with our framework of choice (i.e. Model-Glue)
• <cfinterface>, anyone use it when one can duck type?
• <cfpresentation> (demo), anyone uses it on a public site?  Somehow I can see it getting obsolete in the same rate of <cfform format="flash">.  It provides only limited customization on the look, and therefore very hard to incorporate it into a site.

Then after a while, we come to the conclusion that we only like CF8's native JSON support, easier to cfloop an array, and the improvement in performance...

What is your answer to the question: Have you used CF8 to its fullness?