This evening I released AMF Explorer 0.6. This version adds a custom binary cache that should fix issues some users were seeing with AMF response deserialization. I'm still waiting for AMO public approval, so if you are using AMF Explorer you will need to manually update the add-on from the AMO site. Please be sure to report any issues to the AMF Explorer bug tracker at RIAForge. Thanks.
I've released a few updates to AMF Explorer over the last week or so. Improvements include support for small messages, better formatting, and better error messages. You can get the latest from the AMO site.
Unfortunately automatic updates are not enabled because AMF Explorer has yet to go public. If you are using AMF Explorer please consider taking the time to register and review the add-on on the AMO site as this will help with the AMO review process. Once the add-on is public it will be easier to find and install as it will not be marked as experimental and automatic updates will be enabled. Thanks!
Back in late 2008 the nsITraceableChannel interface was added to the Mozilla browser allowing extension developers to intercept incoming HTTP responses. At that time I pondered the possibility of adding AMF support to Firebug, however life got in the way and I never really had time to fully explore what it would take to do this. That is until now. Today I'm happy to announce that I'm finally releasing AMF Explorer.
Just a quick post to let folks know the source for the Swiz RPC Library, as well as the compiled SWC, are now available on RIAForge: http://swizrpc.riaforge.org.
A couple of weeks ago Joe Rinehart blogged about his RemoteMethodMediator for Swiz. Like Joe, I've found that most of my executeSeviceCall callback methods were just dispatching events via Swiz, so I liked the idea of skipping callbacks completely. However, I didn't really like Joe's implementation, so I yesterday I did some playing around and came up with the a Swiz RPC library. The library has swiz specific implementations of mx.rpc.remoting.mxml.RemoteObject, mx.rpc.remoting.mxml.Operation, and mx.rpc.CallResponder. These classes can be used in your bean loader in place of the standard mx:RemoteObject, mx:method, and mx:CallResponder tags.
The second part of my Data-Centric Development with ColdFusion 9 and Flash Builder 4 tutorial is up on DZone. This tutorial builds on the project introduced in part one of the series and covers the new paging and client-side data management features available in Flash Builder 4.
If you want to find out even more about these seriously cool features be sure to check out the following links:
I just posted the first of a two part tutorial over on DZone which walks through using some of the new data-centric development (DCD) features in Flash Builder 4 with ColdFusion 9.
While Flash Builder is still in beta, the DCD features are very impressive and should simplify many ColdFusion/Flex work flows. Please check out the tutorial and let me know what you think. (And be sure to vote it up if you like it!)
ColdFusion 9 introduced the new onCFCRequest method. Unfortunately, this new method breaks Flash Remoting requests. To get around this issue you can resort to a modified version of the old onRequest hack. If you have an Application.cfc that covers remote components that will be used for Flash Remoting, you can add the following to your onRequestStart method:
This will remove the onCFCRequest method for the current request and allow your Flash Remoting call to work. (Note: you may need to search for different paths depending on your BlazeDS endpoint configurations. If you don't know what I'm talking about here you will most likely be fine with the default "/flex2gateway".)<cffunction name="onRequestStart">
<cfargument name="targetPage" />
<cfif findNoCase("/flex2gateway",arguments.targetPage) gt 0>
<cfset structDelete(variables,"onCFCRequest") />
<cfset structDelete(this,"onCFCRequest") />
This question comes up quite a bit on the Swiz mailing list so I thought I'd write a blog post on how I handle this. For those new to Swiz, one very cool feature of the framework is the DynamicChannelSet wich allows you to remove the dependency on services-config.xml. Here is an example, from the Swiz docs, of how you would use DynamicChannelSet in your Bean Loader: