Post cfObjective decompression

Another cfO has come and gone, and once again it was a completely incredible event. I tried to see more sessions this time around, since I usually get caught up in conversations in the halls, but I'm not sure I was entirely successful. Of course, for me all the networking is what it's really all about. Friday night I sat with Sean for a while and had a really interesting conversation about his soon to be release Edmund framework. I had already marked his cfUnited session as a must see, so now I am really excited. Mark Mandel and I spent quite a bit of time together this time around exchanging clothing and planning world domination, er, I mean further work on coldspring's tools for remoting with Transfer, so hopefully the fruit of those long evenings will come quickly.

Of course, what I was particularly excited about was the amazing buzz at the conference about my new Swiz Framework for Flex, which I was able to release to google code on Saturday. Many people asked me to see examples, and a slight oversight with time management in my session gave me the opportunity to show Swiz to a large audience. Overall it seemed very well received. Afterwards I sat with Maxim, Laura and Nahuel looking over each other's source code and sharing ideas. This had to be the top highlight of the conference for me. Mate looks really interesting, and both Laura and Nahuel are amazing AS programmers. Really awe inspiring work. I have been reading their blog for a long time now, and it was just a real pleasure to share some time with them.

I am sure it will take quite a bit of time to decompress from cfO this time around. It seems every year Jared and Steven take it up a notch, which continues to amaze me. I went to quite a few conferences this past year, and none come close to cfObjective in terms of the top quality speakers and session. This year really seemed to be exploding at the seems. I'm not sure I can even take it all in. So long to all my friends until the next conference, I am sure I will see many of you at cfUnited in a few months, thanks for a wonderful time!

Congratulations Jared and Jenna!!!

Elisabeth Pearl Rypka-Hauer ROCKS!

Possibly my last ColdSpring update this weekend...

At least I hope so, my fingers are getting tired! This last update is a little on the experimental side, but I have just committed AbstractAutowireTransactionalTests to cvs (CSP-89). Basically this works exactly like AbstractAutowireTests, except that it begins a transaction before each test and rolls it back after the test, unless you call setCommit() somewhere in your test. Like AbstractAutowireTests, you just supply the location of your config file, and setters for any beans you want to test. From there, go crazy inserting, updating and deleting things in your db, after the test everything is rolled back. This is so handy, we use it all the time (I know, I said that about AbstractAutowireTests, but what can I say? They are REALLY useful!).

Just a few things I need to point out. I took a very, very heavy handed approach to making this work. It's not going to be the fastest because Paul creates a new instance of your test class for each test method. At that time (in setUp()) I am doing some crazy proxying and method injection. I am actually creating a proxy, and then taking it apart, it's a bit on the nuts side. However, if Paul would make a tiny change to cfcUnit, I could clean a lot of that up. Anyway, I hope this one is even more useful than the last, and feel free to send bugs along to the coldspring list. Enjoy!

Even More ColdSpring Updates!!

Ok, this is something my coworker Cliff Meyers has been trying to get me to write for ages. We use the Spring equivalent of this literally every day. Now, unit testing ColdSpring managed beans is not really all that hard, all you need to do is create a bean factory, load your config file, and call getBean() for anything you want to test. But you know what? That's too much work! Enter AbstractAutowireTests, which you will find in the new coldspring.cfcunit package (yes, I do intend to make more!). Here's how it works, extend this class instead of Paul's TestCase, override the getConfigLocations function, and that's it, everything else is handled for you! Oh yeah, this is an Autowired test case too, so just add setters for whatever bean you want to write tests against, VERY handy. Here's an example of a test case using this new component:

<cfcomponent extends="coldspring.cfcunit.AbstractAutowireTests">

    <cffunction name="getConfigLocations" access="public" returntype="string" output="false">
        <cfset var path = GetDirectoryFromPath(getMetaData(this).path) />
        <cfreturn path & "/testBeans.xml" />
    </cffunction>

    <cffunction name="onSetUp" access="public" returntype="void" output="false">
        <!--- this is where my setup would be... --->
        <cfset variables.sys = CreateObject('java','java.lang.System') />
        <cfset variables.sys.out.println("onSetUp executed!") />
    </cffunction>

    <cffunction name="onTearDown" access="public" returntype="void" output="false">
        <!--- this is where my teardown would be... --->
        <cfset variables.sys.out.println("onTearDown executed!") />
    </cffunction>

    <cffunction name="setStructBean" access="public" returntype="void" output="false">
        <cfargument name="structBean" type="coldspring.tests.structBean" required="true" />
        <cfset variables.structBean = arguments.structBean />
    </cffunction>

    <cffunction name="testNothing" access="public" returntype="void" output="false">
        <cfset variables.sys.out.println("some structBean data: " & variables.structBean.getData().intOne) />
        <cfset AssertNotNull(variables.structBean) />
    </cffunction>

</cfcomponent>

A few things to point out here. Right now setConfigLocations is not 100%, it only works with 1 config file, but I will have that done any time now. Also, paths are difficult with cfcUnit as far as location of your config file. Using GetDirectoryFromPath(getMetaData(this).path) ensures that I can refer to a path relative to the cfc being tested. And finally, I am using setUp and tearDown, which are called by cfcUnit's test runner to preform my own set up and tear down actions, so instead you should use onSetUp and onTearDown, which will be properly called by the AbstractAutowireTests. For me, this has been an incredible time saver at work, so I hope you enjoy and find this useful! Now if Paul Kenney answers my email I have even more to commit. Cough, cough...

More ColdSpring updates!

One thing I love about Spring is every once in a while you wish you had some special type of bean only to find that Spring already has it. Collection factory beans are some of these types of objects, which I actually use quite a bit at work. Let's say you have configured a component you use across many of your applications, so you put its configuration in a base file and include it in each application with ColdSpring's <include> tag. This is a great approach for reusability, but if you want to use arrays or structs to define application specific parameters to that component you're stuck. A lot of times we end up creating special 'config beans' so we can use the ref tag, but many times these are just wrappers over structs anyway. Why use that type of component at all, if you could just define a struct in your config file and reference it wherever you need it? Well, that's the point of the collection factories. Here's an example of these two new components at work:

First I have a ListFactoryBean instance, which you need to remember from spring semantics will return an Array.

<bean id="list.factory" class="coldspring.beans.factory.config.ListFactoryBean">
    <property name="sourceList">
        <list>
            <value>one</value>
            <value>two</value>
            <value>three</value>
        </list>
    </property>
</bean>

And now here's a MapFactoryBean, which will return a Struct:

<bean id="map.factory" class="coldspring.beans.factory.config.MapFactoryBean">
    <property name="sourceMap">
        <map>
            <entry key="one">&tl;value>hello&tl;/value>
            <entry key="one"><value>world</value>
        </map>
    </property>
</bean>

Now I can use the ref tag for these maps and lists instead of directly defining them.

<bean id="testBean" class="coldspring.tests.testBean" lazy-init="false">
    <property name="myList">
        <ref bean="list.factory"/>
    </property>
    <property name="myMap">
        <ref bean="map.factory"/>
    </property>
</bean>

This may seem like a lot of extra xml, but it can really help with configuration reuse, or providing simpler mechanisms for overriding properties for unit tests. Of course if you find yourself wrapping structs or arrays with components just because you are working with ColdSpring, well, now you don't have to.

Long, long awaited ColdSpring updates!

Ok, it's been a while I admit, and I have been pretty damn quiet up in this here blog, however, I have a serious new goal. That goal is a ColdSpring 1.2 release, and it's going to be SOON!. So, to that end, I'm just going to post my activity so you know where we're at. 

I have committed 2 fixes that should make Mark Mandel and Barney B really happy. CSP-84 has been fixed, which is a problem where setting lazy-init to false does nothing at all. (Ooops it was never implemented, sorry...). You can now define the lazy initialization on a per bean basis with the lazy-init attribute, or set the global default by specifying default-lazy-init on the root bean element. CSP-83 was a semi bug that actually resulted in extraneous try/catching, but basically I had a bug that made it a little difficult to create custom factories. This is different than defining one bean as a factory for another bean with the factory-bean attribute. If you register a bean that extends coldspring.beans.factory.FactoryBean, that bean will automatically have getObject() called on it when you call getBean(). This can really come in handy for some advanced configuration. I know Mark Mandel was working with it, but ran into some bugs. But it is now fixed, happy day!

OK, that's it for right now, there is A LOT more to come...

Flex 3 beta Now on Labs!

Well, that pretty much sums it up, Flex 3 aka AIR (not too sure of that codename myself!) is now available on Adobe Labs. It sure looks like the RIA space is really heating up now. I know a lot of Flex developers have had harsh criticism on MS Silverlight, and based on current tools alone, I would say rightly so. But the fact of the matter is, MS has arrived at the party. There was also a very interesting exchange in the interview with Bill Gates and Steve Jobs where they discussed the importance of RIAs, both clearly stating that their companies where committed to the idea of richer applications connected to what they called the 'swarm', I believe. And today, we have a brand new beta of Flex, Adobe is clearly leading this market right now, it's so exciting to see the technology pick up in pace! So get yourself some air and enjoy!

cf.Objective() session updates

I finally got my sessions to Jared, and he has posted an updated list. I'm going to be doing an introduction to AOP as well as a session concentrating on using ColdSpring to power your Flex applications. Don't forget, early bird pricing will end April 1st, so you better get on your tickets quick! Honestly, $395 is an absolute steal for the amazing amount of top notch sessions that your going to be getting. Last year cf.Objective() was no doubt the best CF conference around, and this year it looks to be even better, so go register! Right now!

I am also bringing my Flex/ColdSpring session to CFUnited, which is also shaping up to be another great conference, so go register for CFUnited too! Honestly, the value of conferences like these cannot be measured. I got my shinny newish job at Cynergy Systems through contacts I made at CFUnited last year (along with Dave Carabetta). If your looking for the best way to advance your career with marginal expense, these conferences are surely your best bet. See you there!