Arf! was my own toy in which I created a "record factory" that would basically create a mixin that "blended" persistence and relational/composition functionality into any CFC extending a base ActiveRecord CFC. It had a bit of a Rails flavor to it, and I do have a production application running with it.
However, it causes a lot of "kitchen sink" CFCs that act as a service layer, gateway, and bean all surrounding a single entity. Great during quick prototyping, but a little bit painful when applications grow.
"Paste" never went public. It was intended to be a compliment to Model-Glue. Fueled by Inversion of Control, it was intended as a generic "inline" code generator that focused on JDBC metadata. You could define "types" of CFCs to generate via XML (like a "Gateway"), tell it where to put the "base" (like a Reactor "project" CFC) and customizable shell (like a Reactor /model/data CFC) CFC, and it'd spit out code based on whatever CFM-based template you wrote (I hadn't learned XSL yet, and stuck with what I know.)
Basically, you could plug in your own types of code to generate, and use statements like paste.create("gateway", "Contact") to generate whatever you defined a Contact gateway to be.
Heavy stuff, but a bit of the underlying architecture (generic code generation configured by Coldspring) is stuff I'm talking to Doug about for Reactor 2.0.
I just have a really strong bias against getProperty(propname:string) and setProperty(propname:string, value:any) methods. To me, it's against the concept of programming to interfaces. However, I really like how easy this one is to use. It was a little like Arf!, but sort of different in that you just ask for an object instead of dealing with a hard CFC. I'm also not sure how you'd add additional business logic to a given entity.
Transfer is, to say the least, looking very robust. It's just not quite as easy to use (for me) as Reactor. Basically, I saw Reactor, it clicked in my brain, and I've been able to use it very well while never actually reading the documentation. Haven't quite had the same luck with Transfer, but some of its capabilities (such as caching) look very promising. If it exposes table metadata, it'd be pretty interesting to try to build another ORMAdapter and ORMController implementation to see if I could scaffold and generic ORM using it instead of Reactor.
I played with it for a bit, trying to use its libraries to generate basic persistence CFCs etc, but it didn't provide implementations of the patterns needed for MG:U, and was Oracle specific (I was doing an Oracle project at the time - it uses Arf!).
Reactor simply worked. Out of the box. It was simple, and it works the way I think (in respect to bean/dao/gateway CRUD). It allows me to simply add business logic where necessary, and doesn't try to build a service tier for me, which I rather like - I can refactor to one as necessary.
What this means is that you don't run code generation scripts or utilities. You just set up Reactor, ask it for something, and it hands you back what you've asked for.
I think this is a great advantage - when you do something like add or remove a database column, the change is simply reflected. There's no script to run or code changes to make (unless, of course, you delete a column something else needs!).
I really like the concept of the Reactor.xml file. I've written my own little ORMs (see: Rocket, Paste, Arf!), and they all relied on the Rails-style hasMany() methods within each CFC and the like.
It was quick, it was dirty, and the moment I had more than 15-20 entities in an application, this became completely unmanageable! Reactor.xml's <objects> block functions much like a high-level diagram of your model in that you have a "birds-eye" view of the data relationships within your model. It feels very natural to me, much in the same way ModelGlue.xml lets me "see" my application's flow and relationships of pages to business functions from a high level.
Sorry for the audio, I used my laptop for this, and it seems to skip a lot and eventually get out of sync. It's about all I can do while on the road, though.
I am looking into a copy of Captivate to provide proper video tutorials once Model-Glue:Unity is released.
The result: whoa, that's fast.
Here's a few benchmarks from a 100-concurrent-user load test:
Model-Glue 1.1 - 3095ms avg. request time
Model-Glue 1.1.1 RC1 - 1428
Model-Glue:Unity Beta 1 - 1430
Model-Glue:Unity BER - 596
Model-Glue 1.1.1 RC1 - 2892ms avg. request time
Model-Glue:Unity Beta 1 - 2602
Model-Glue:Unity BER - 2115
Lesson learned: ColdFusion checks metadata for typing and requirements at runtime. If you're in situation where every ms counts (like the Model-Glue request lifecycle), you may want to thing about loosely typing your code.
Today was a little different.
Today, Danny Jung decided to send me a carton of individual servings of CheezIt crackers.
Um, thanks, Danny? My wife and I got a good laugh out of it.
Dude, you paid more for *shipping* than you did for the crackers!