Fusebox Enhancement: Type Converters

How many times do you have boiler plate crap in your controller to wire up a domain object(s). Even worse have you ever passed a string ID throughout your system? Type Converters to the rescue. Type Converters offer an elegant way to move Domain creation code out of your controllers (or delegated from your controller into your service). It also allows your system to focus on object interaction not string manipulation/passing. Best of all since I am fairly simple minded they are dead simple to use. You write the object creation code in a Type Converter, register the converter with Fusebox as well as the url/form parameter to convert. When Fusebox detects that url/form parameter it will call on the converter to create the Domain object. Converters could be as simple as hydrating a Bean from an ORM or more complex using caching stategies to find the bean, since Fusebox exposes it's applicationData you can even delegate to ColdSpring for most of the object creation. Any way you choose the point is it removes this logic from your controllers or various other non standard places and puts it into a standard (hopefully) well organized place.

Why are they called type converters? To understand this it's important to know where this concept comes from. As of late I've been doing a fair bit of Java development and we use a framework called Stripes for all our web based java apps. Stripes too has Type converters. Type converters make a bit more sense, semantically, in Java since one of the tasks of a type converter in Java is to take a browser response of YES and turn it into a true boolean type (humm sound sorta like a really cool dynamic language we all know and love). Type converters can be more complex in Stripes as well taking an arbitrary string and allowing you to return an object. I found this functionality extremely useful in my Java app. When I looked back at my Fusebox app I've also been pecking away at I quickly realized how adding type converters to Fusebox would allow my controllers to become even dumber and more OO (read: less string based) at the same time.

I know historically a large segment of the CFML community has not looked to Fusebox for OO capabilities. I get that this feature could have a small # of folks that will enjoy it but I felt it was a very good addition and worth a blog entry. The code is in its very early stages and is fairly rigid right now; this should change over the next couple of iterations as I play with the functionality more. Feel free to check it out and give me some feedback. I've provided an interface (fuseboxTypeConverter) for documentation sake. There is no reason to ever implement the interface as all Fusebox really cares about is that the converter has an init constructor and a convert method. The only other thing you'd need to know to start to play would be how to register the converter with Fusebox.To register the converter add this to your fusebox.xml (the fuxebox.dtd is updated so you should see it in there):

<converters>
<converter class="full.path.to.Component" parameter="someId" target="Object">
</converter>

Target is optional and if it is left off Fusebox will replace the current string value with the returned value from the converter. The code is available in the BER, as well as in SVN.

Got the Beta Blues?

Rightly or not the cf-talk boards have had threads where it was made known ColdFusion 9 is in beta testing. Last year Adobe announced they would be more transparent in the development, even announcing the ColdFusion advisory board. It seems like that transparency is a slow build, which I understand as nothing happens over night. I did want to take a second to pimp OpenBlueDragon and say we are working hard to be as as transparent as we can be. If you have the Beta Blues and want to share some ideas on how you thinkCFML can be made stronger, more competitive, or otherwise improve your life check out Open BlueDragon's google group and feel free to submit a ticket to our ticket system! CFML is a great language and I am confident ColdFusion 9 will deliver a great new set of functionality, I also have to say I am very impressed with how OpenBD has progressed through the months. Did you know we are considering adding cfvideoplayer and well as cfvideo? We'll talk more about this as soon as we figure out how we think it should work, until then you tell us how you think it should work. Also add it as a favorite so we can gauge the interest in this feature!

CFUnited session # 2!!

I know at least one man will be very happy to know I will be presenting Red Green Refactor at CFUnited! I gave a presentation at bFusion about TDD and MXUnit with the same title that got a lot of great feedback. This presentation will follow a similar tone as that one, only less MXUnit and more rants about BDD. I've previously ignored talking specifically to BDD as I felt (and still feel to an extent) that BDD is really just TDD done right. After the recent cfSpec announcement I got to talking to Sean Corfield about BDD and he made a comment of getting BDD over TDD. This leads me to think I should talk more about BDD (it seems to make more sense to more folks). I'm still of the mindset that BDD is little more than TDD done right but, I think BDD is starting to become more relevant as the concepts mature and evolve. I will probably focus more on some BDD concepts than I previously had planned. This should give me a chance to learn more about BDD in the process, I can't wait to give this presentation!

Fusebox back under development

A while back, maybe September or so right after finishing up a couple of additions to Fusebox, I decided to take the rest of the year off from coding. I had done some work with MXUnit, Fusebox and OpenBD and thought, I need a break. During that time I had the opportunity to fix up one of the worse Fusebox Apps I've ever had the misfortune to lay eyes on, internally at my company. It was great to get my hands dirty in an application to test out some of the new stuff I've added to Fusebox, as well as our base application we use at work. It gave me some really good insight into things I could add to Fusebox to make life easier for No XML development, and Classic Fusebox as well. John Bliss also made a feature request the other day which I've already made some additions (this will be the topic of a future blog entry).

Before I get back to too much coding though I am working with Simeon to take over Fusebox's ticket, wiki and version control. I expect the switch to happen sometime this month, there's a bit fo coordinating that need to be done. I want to give a HUGE thanks to Viviotech for donating the VPS for all this to live on now and into the future. As part of this move to the new server I'll be changing some of the software being used for the project. Fusebox's wiki will be moving to Confluence (from Trac) and the ticket system with move to Jira (from Trac), I've not drank the git cool aid yet so for now we'll be sticking to SVN. Confluence is a very powerful wiki which I hope will improve documentation, the templates for pages is very nice and powerful and I can add work flows which might open the window for more open security for editing pages. Jira is equally as nice and quite frankly I am much more knowledgeable about these 2 products than Trac and I'll be able to do more with them than Trac. Another driving factor for Jira is the integration in Mylyn (for eclipse) and IntelliJ is bar none. Due to how Trac was configured, I was unable to integrate my IDE with Trac and it was really irking me. My hope is to sooner or later get around to looking at Bamboo as well and getting that to do some continuous builds for some other projects that I've not talked about yet.