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.
Subscribe to:
Post Comments (Atom)
3 comments:
you gotta register it? pshawwwww.
how's about a "converters" directory, and then fusebox just looks in there and registers them itself.
@ Marc "Pain in My Ass" Esher please reference this sentence :) "The code is in its very early stages and is fairly rigid right now"
Part of what I am evaluating is following Fusebox's implicit style of things and indeed looking in a converters directory. What I have to figure out is how I want the parameter declaration to work. Does Fusebox just rip it off the file name: OrderTypeConverter registers as looking for order in the url, or putting a custom attribute on the CFC itself fusebox:parameter fusebox:target.
On another note while I am not confident it will remain how it is currently the fuseboxTypeConverter is a stand alone class and the getter is published through myFusebox (and intended to be such really) nothing is stopping a person from adding converters on their own. One thing I am trying to do with Fusebox is open up the API a little to allow folks to wire in more functionality to the framework at the needed points. It's hard to find the balance of opening up vs making the framework hard to update over time. The nice thing about all the Type converter stuff is since it is almost entirely stand alone it is the one part of Fusebox that has nearly 100% test coverage! TDD was entirely used for this feature :)
This is interesting, but can you show me a situation where I would use this? Some pseudo code would be great, especially a comparison between the old way and the new proposed way.
Post a Comment