Frameworks Conference: Leveraging ColdSpring To Make Better Applications - Kurt Wiersma
ColdSpring is something I've been meaning to look at for quite some time, so I was very interested in this presentation from Kurt. As before - pardon any randomness/scatteredness of the notes.
Kurt described CF almost like a box of legos - holding all of your components.
Life before CS - lots of createObjects, manual services, difficult testing. His old code (which looks a lot like most of mine), contains numerous createObject type calls. After CS - his code now uses get/set so that needed CFCs are passed in.
Main point of CS: make configuration and dependencies of CFCs easier to manage. CS enables dependency injection (Inversion of Control). Unlike the factory (see my earlier post), my CFC has the things it needs passed to it.
Interesting - so CS uses an XML file to describe all the CFCs and what they need. But - CS is smart enough to actually look at your CFC and if it sees the right methods, it knows what to do anyway. Kurt made the point though that it is nicer to keep the XML there anyway so you can see what is going on.
By default CS will create singletons (just think of this as a single instance of a CFC, not multiple instances).
Another big aspect of CS is AOP (Aspect-Oriented Programming). Allows you to generate remotely accessible objects (think support for Flash Remoting). Plugins available for Fusebox, Mach-II, Model-Glue. It can also integrate with a factory. Configured via XML. I if I get it - it looks like there is a style of CFC you can use that will work with CS and provide the remote API and connection to core CFCs. Don't think I got it completely yet but it looked interesting. AOP is useful for security, caching, logging, via remote methods. Basically allowing a remote API and being able to intercept and do stuff before/after the method is called.
Summary: After this presentation and the object factories one by Rob Gonda, I'm more than convinced I have to change how I'm creating my CFCs in my applications.
Comments
stupid chai tea burning my hand atm from trying to catch that before it posted ow.
http://jroller.com/page/kwiersma
Also I have started a project on Ray's excellent RIAForge for AppBooster.
Thanks for the live review Ray!
--Kurt
When I was learning ColdSpring I remember struggling with what I needed to add to my components to get the right composition. get set methods, init-constructors, it was a little bit confusing to get started.
Now, I am suprised by how much code I don't need to write to get what I want. I've actually worked on Apps that are so heavily configured by ColdSpring, it is possible to make an entire new application by just moving the XML declarations around.
Having an App built around ColdSpring makes it super easy to change the location of the components and in the case of using a prebuilt app, if I want it in another directory, I simply edit the ColdSpring.xml and I am not bound to the original paths the Author built upon.
It is helpful to have a good instance factory so you can manage your instance objects as well. the makeEventBean command in ModelGlue will take a path, or a reference, so thank you Joe R. for that little feature...
<sung_to_the_tune of="Jingle Bells" />
Oh what fun it is to code, with ColdSpring in your day...
Ok, that was lame..
But like another person put it, your posts are perfect for my attention span.
I'm actually thinking of converting a lot of my code to use CFC's and possibly IOC, and CS.
cheers,
Ali
I've had CS on my dev box for awhile now and its still one of those I need to get some free time to play with this. Maybe I'll try to dive into it this afternoon some, it sounds really interesting.
reading all these though makes me yearn to bust out of this procedural-eaque framework we use atm haha.