ColdSpring News, CFConversations RoundTable and other cf.Objective() tidbits

While I am recovering from the Australian WebDU conference, a few days before that started I got off a plane after the end of the wonderful cf.Objective() conference.

I have to say, this year's cfObjective() was the best organised out of all the years I have been to.  As per usual, the content was stellar, the hotel was lovely, and it was an absolute pleasure to catch up with everyone at the conference.  I have to give a big 'congratulations' to Jared, Steven, Jim and the rest of the cf.Objective() crew for putting together such a smooth and professional conference.

I had the pleasure of doing two sessions, Rapid OO Development with ColdFusion Frameworks, which covered a variety of techniques on how to increase your development speed when building OO models, and I was very happy to see that it seemed to have been very well received.  I had one attendee let me know that 'Now I know why I'm using ColdSpring! I was using it before, but now I know why', which is an amazing thing to hear as a presenter, that you've managed to create an 'Aha!' moment for someone.

I also did my Introduction to Building Applications with Transfer ORM, which was a repeat of the session that I did last year.  Unfortunately Ray Camden couldn't make it to do his Transfer session, so I was called in at the last minute to take his place.

The big news that we announced at cf.Objective(), is that I will now be the lead developer on the ColdSpring project.  Since Chris Scott's major focus these days is the Swiz Flex framework, he decided it was time to pass on the reigns, and since I tend to talk to him regularly about Cold/Spring, have contributed code to ColdSpring , and know about running an Open Source project, he seemed to think I would be a good fit.  I'm pretty excited about the opportunity, and have discussed some great ideas with theColdSpring development group, of which Chris is going to stay on as lead architect.  I expect we will start off by building the infrastructure around the project, e.g. a centralised wiki, ticket tracker etc, and then move on to some more interesting items.

The obvious question there is, of course, what does this mean for Transfer? (I think I need to start writing down how many times I've been asked if it's 'Dead'.  Does anyone actually expect a 'yes' for an answer?), and quite frankly, I don't see this impacting on Transfer much at all, simply because this is going to be code that I would have probably ended up writing on ColdSpring anyway, but it is now a more formalised relationship.  When I run into a feature or a bug on an Open Source project, that I want to be implemented, my first natural reaction is to start looking into the code, and writing the feature.  This was first exemplified by my contribution toColdSpring of annotation based pointcuts.  There are several aspects of ColdSpring I wanted to improve on, so it was just a natural reaction for me to end up writing code for it.

As stated, the content at cf.Objective() was brilliant as per usual, with my own personal highlights being, Advanced ColdFusion Server Administration (Adam Lehman), Advanced ColdFusion 9 ORM (Terry Ryan) and ColdFusion Portlets (Adam Haskell).

Thinking about the content, I have a little confession to make, that I realised on the way back from cf.Objective() this year.  I have a tendency to go to the wrong sessions when at a conference. This may sound like a weird thing, but I realised the last few years I tend to go to sessions that I already know a lot about, just to see if they say something a little bit extra that I can add to my knowledge base.  Quite often I end up walking out feeling like I haven't added much to my repertoire.  Really what I should be doing is going (mostly) to sessions in which I know absolutely nothing about, which means I actually get the best return on the my investment in the conference.  While it may not be specifically applicable to what I'm currently doing, at the very least it will inspire me to do some interesting new things, and may give me some knowledge that I can then apply at some point in the future.  This is a philosophy I plan on applying to all future conferences that I attend.

Finally, I also had the opportunity to be part of a CFConversations round-table on the second night of the conference.  Brian Meloche, Andy Powell, Andy Matthews and I had a really good chat about the conference in general, our thoughts on some of Adobe's upcoming products, various other topics relating to ColdFusion.  It was lots of fun to do, and you can download and/or read more about it here.

Again, thanks to all the cf.Objective() crew, and look forward to seeing many of you again at cf.Objective(ANZ).

ColdFusion & Flex Data Transformations with Conduit Filters

Previously I discuss a simple mechanism in Conduit to enable you to apply data transformations on outgoing data from ColdFusion to Flex, using a simple inheritance strategy, to overwrite how the CFC=>Flex VO object translation occurred.

The only issue there is, if you need to be able to do different transformations, you end up having to combine separate code-bases into a single CFDeserialiser or CFSerialiser , which is not very portable, or decoupled.

To solve this problem, Conduit has filters that can be applied at different points in the AMF communication life cycle, and manipulate the data that is being passed through.

So, if we take the example we looked at previously, where we reversed every simple value that was travelling from ColdFusion to Flex, we can convert this into a simple filter, which is much easier to apply, and can be combined with other filters to do fairly complex data manipulation.

An example ReverseFilter looks like this:

<cfcomponent hint="filter that reverses all strings" output="false">

<cffunction name="init" hint="Constructor" access="public" returntype="ReverseFilter" output="false">
    <cfargument name="args" hint="the argument ConfigMap" type="struct" required="Yes">
    <cfscript>
        return this;
    </cfscript>
</cffunction>

<cffunction name="doFilter" hint="does the filtering - reverses strings" access="public" returntype="void" output="false">
    <cfargument name="filterData" hint="the data for the filter" type="struct" required="Yes">
    <cfargument name="filterChain" hint="the filter chain" type="conduit.core.filter.FilterChain" required="Yes">

    <cfscript>
        >//we know there will be a 'result', in the after filter
        if(isSimplevalue(arguments.filterData.result))
        {
            arguments.filterData.result = Reverse(arguments.filterData.result);
        }

        >//push on to the next filter
        arguments.filterChain.next();
    </cfscript>
</cffunction>

</cfcomponent>

The doFilter() method is the method that manipulates the incoming data, in this case, looking at the 'result' argument that is being passed in, and if it's a simple value, reversing it.

The Filter is then passed on to any subsequent filters, by calling the next() method on the filterChain.  If we didn't want filtering to continue, we could simply skip that step.

We then configure this ReverseFilter against the CFSerialiser, to convert outgoing data that is going to Flex, like so:

<destination id="Conduit">
     <channels>
        <channel ref="my-cfamf" />
     </channels>
     <adapter ref="conduit" />
     <properties>
         <source>*</source>
         <cfcs>
             <!--- cfc config --->
         </cfcs>         
         <filters>
            <!-- This is an example filter that reverses strings -->        
            <filter>
                <path>conduit.core.filter.example.ReverseFilter</path>
                <apply-after>serialiser</apply-after>
             </filter>
        </filters>
    </properties>
</destination>

The 'apply-after' section, tells Conduit to fire the ReverseFilter after the processing of the CFSerialiser, rather than before, although in this case, it won't make that much difference.

This is just a simple example for the sort of things that can be done with Conduit Filters, but it should give you a good idea on how with a few simple filters, you can drastically change the way data is sent to and from Flex and ColdFusion.

If you want to read more about Conduit, please have a look at the wiki, and daily builds can be downloaded from the google group.