An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

Model-Glue, ColdSpring and Reactor

March 5, 2006 · 3 Comments

As part of the preparation for my talks at cf.Objective() (it's not too late to buy your ticket!), I've been working quite a bit more recently with both ColdSpring (for my factories talk) and Reactor (for my persistence talk). ColdSpring has recently been enhanced to support factory-bean and factory-method attributes in a bean definition so that you can declare beans that are actually created by external factories such as Reactor. You declare the Reactor factory as a bean (managed by ColdSpring). Then you can declare DAO and gateway objects, in the ColdSpring XML file, which are created by the Reactory factory bean. It's very slick. However, most Reactor operations are focused on record objects which are transient (not singletons) and whilst those could be managed by ColdSpring, generally only singletons - per-application objects like services - should be managed by ColdSpring (since it adds a layer of complexity to object creation in order to leverage the power of the framework). I was attempting to apply AOP to Reactor-generated objects so that I could simulate the security model in ggcc9 (the ninth variant of my frameworks comparison code - see the software pod on my blog). ColdSpring assumes that AOP-controlled objects are simple concrete classes and therefore it doesn't work with the nested inheritance hierarchy of the Reactor-generated DAO and gateway objects. I did eventually make it work but it requires changes to ColdSpring and, for some of the autowiring I was doing, some changes to Model-Glue as well. I've submitted the patches to the revelant mailing lists for consideration but it means that I can't realistically release the ggcc10 variant's source code. Despite my minor frustrations, the combination of the three frameworks is immensely powerful. If you look at the ggcc9 variant, you'll see it has several model CFCs and several bean CFCs. The ggcc10 variant has none of that. The model was really just DAOs and gateways which Reactor provides automatically and the beans become records which, again, Reactor manages automatically. About a dozen CFCs went away in the conversion. That's a lot of code I wouldn't have to write!

Tags: coldfusion · coldspring · modelglue · orm

3 responses so far ↓

  • 1 Rob Gonda // Mar 6, 2006 at 6:48 PM

    man, I'm really looking forward to see that ggcc10; you can't tease us like that!
  • 2 Chris Tilley // Mar 23, 2006 at 9:23 AM

    Any ideas when you can share the code for ggcc10? I can't wait to see it.
  • 3 Sean Corfield // Mar 23, 2006 at 10:20 AM

    The ColdSpring team are working on some dependency resolution issues around AOP that are currently preventing the example from working the way I would like...

Leave a Comment

Leave this field empty: