A little update. I wonÂ’t be speaking at MXDU as originally planned. I was really looking forward to it but my visa has yet to arrive from the Australian Embassy. Geoff has been really understanding about it and will have some contingency plans in place. Maybe IÂ’ll make it next year, and Peter take lots of pics!
If you’re developing components using UIObject as a base class you may want to know that in order for your component to use styles you’ll need to still include UIComponent in your asset layer. The CSSSetStyle class is initialized through UIComponentExtensions and thus is not available if UIComponent is not included in your asset layer.
When you dump CFCATCH ColdFusion says it’s a structure. But when you try pass it to a UDF that expects a structure you get an error.
So how does CFDUMP treat CFCATCH as a structure and how can we do the same thing? Through duplicate(). When you pass CFCATCH to duplicate() it returns a structure. After that you can pass it to UDF as a structure.
#duplicate(cfcatch).getClass().toString()#
S.Isaac Dealey posted an interesting blog entry about whether or not certain functionality should be added to the core CFML language. He was talking specifically about the ability to work with zip compressed archives but the argument applies to many other things.
His assertion is that since a lot of functionality can be easily added through the use of ColdFusion extensibility options–User Defined Functions, Custom Tags, and ColdFusion Components–and because of this some common functionality does not need to be added to the core CFML language or function library.
I completely agree that developers should take full advantage of extensibility and the great resources available to us such as cflib.org and Macromedia Exchange. With these options individuals can add functionality to CF and share that functionality with others.
However, I disagree that this replaces the need for new functionality to be added to the core language for several reasons.
Continue reading
Last week I got my first PocketPC for some development work and ran into some issues that I havenÂ’t seen mentioned. The PocketPC is a pretty powerful little machine, but what I didnÂ’t realize at the beginning was that Pocket Internet Explorer and most browsers for other pdaÂ’s, and slimmed down devices do not support any JavaScript.
This may not seem like a big issue, but if you visit any of your projects that were working before applying a workaround, you will probably find that the project does not anymore. It really depends on what kind of work-around you implemented. The most widely suggested work around seems to be a JavaScript re-write of the object/embed tag. Which works great, but as you probably guessed it completely fails under Pocket Internet Explorer and will fail under other slimmed down browsers/devices. So what is the best work around?
I would recommend a combination of server-side and JavaScript. On the server-side you would check to make sure that the user is a desktop user using the value return by user agent propert, and if so present them with the JavaScript workaround (You can even isolate IE users if you wanted). If they are not a desktop user, then present them with a static version.
Hope someone finds this information useful. This should be good workaround until Microsoft ends up changing Pocket Internet Explorer 
Maybe I’ll provide full code in a future entry.
Update: Thank to Chris Brandt for pointing out that Pocket IE does support some JavaScript. From my testing the Eolas workaround I had implemented was failing. I will have to track down the exact reason specific to Pocket IE. I would still reccomend the same workaround though as there are bound to be more browsers out there with no JavaScript support.