In the absence of a printable schedule - sorry, Joe Rinehart says it's a problem with the Media3 hosting and he's been trying to get them to fix it for months! - here is my schedule for cf.Objective() 2009:

[More]

One of the neat features of the Railo Administrator console is that you can easily install pre-packaged applications with just a few clicks. As part of my recent presentation comparing application frameworks, I installed ColdBox, ColdSpring, Mach-II and Model-Glue via the Web Administrator. There are a couple of "gotchas" about the current default settings for those installations that I wanted to cover in a blog post.

[More]

Brian Kotek has begun a series on using Swiz, the Dependency Injection framework created by Chris Scott of ColdSpring fame.

Brian's first post just shows the very basic setup (how to specify the classes that Swiz manages and how to load them into your application).

If you're using ColdSpring today in CFML and you're interested in learning Flex, Brian's series might be very useful to you.

If you're tired of the boilerplate code that Cairngorm makes you write (or generate), Swiz might be just what you're looking for and Brian's series will be good reading for you too.

We use Swiz at Broadchoice, in our Workspace for Salesforce desktop application (built with Flex and AIR) and we all love working with the framework!

As "usual", I start the year with a round-up of the highlights of last year, based on things that I blogged. It's been a strange year for me. After (seven) years with Macromedia / Adobe and most of 2007 spent freelancing, I took a full-time job with a startup and hired some amazing CFers to be part of my team. I (finally) learned Flex (and AIR). I learned a new language (Groovy) and did a lot less CFML programming than I've done in years while at the same time joining first the Open BlueDragon Steering Committee and then the CFML Advisory Committee, as well as attending more ColdFusion-related conferences than usual (cf.Objective(), Scotch on the Rocks, CFUNITED, Wee Dram of Scotch, MAX).

[More]

Today was our official launch, just in time for MAX! Now anyone can download the Broadchoice Workspace AIR application and create a 30-day trial account.

Commercial use will be just $99/user per year with educational licenses at $49/user per year. Registered non-profit organizations can get free licenses.

If you're also a Salesforce user, you'll love the integration between groups in Workspace and your company's Salesforce account, allowing you to see open opportunities directly in the Workspace and create collaborative spaces based on opportunities so that you can work with your non-Salesforce peers on closing deals!

Working with Brian Kotek, Joe Rinehart and Ray Camden on this application has been a wonderful experience. We've all learned a lot from each other as we've learned a lot about Flex, AIR, Groovy, BlazeDS, Spring, Hibernate and integration with CFML via Model-Glue 3 (Gesture) and ColdSpring!

Also, for Workspace users on-the-go, there is an iPhone-compatible web application (with plans for full Blackberry support by year end).

Adam Lehman kicked off the day with some upbeat news about ColdFusion 8 (about 75,000 new developers since 2007!) and then covered potential features for Centaur. I'll blog more about this later.

Next up was Mark Drew, covering ColdSpring. A great introduction to basic ColdSpring then on to AOP and remote proxies. I acted as a "bean factory" that helped Mark get ready for work: he asked me for his jacket and I ensured that it contained his iPod and his cigarettes, which in turn meant adding his headphones and his lighter. His examples were amongst the best I've seen for introducing ColdSpring concepts.

Peter Bell is up now, giving his Rapid OO talk - similar to what he did at Scotch. Some good, pragmatic advice about when to bend (or even break) the "rules" of OO that can make you more productive.

After lunch, it's Mike Brunt (Clustering), me (Subversion branches), Kurt Wiersma (development environment) and Gert Franz (Railo 3.1). More on that later.

ColdSpring has a brand new website and an official 1.2 release that you can download immediately!

There is a brand new quick start guide fully updated for the 1.2 release courtesy of Broadchoice's own Brian Kotek. It covers everything from the most basic usage of ColdSpring up to AOP and remote proxies and includes parent beans and factory beans, both of which I use a lot.

A Wee Dram of Scotch has a location - The Square Pig in Holborn - and has posted the full schedule for the day:

• Adobe Keynote - Adam Lehman and Claude Englebert
• ColdSpring - Mark Drew
• RAD Object-Oriented CFML Development - Peter Bell
• High Availability: Clustering ColdFusion Applications - Mike Brunt
• Subversion: Better Living Through Branches - Sean Corfield
• Setting up a Solid Local Development Environment - Kurt Wiersma
• Railo 3.1: The Open Source Story - Gert Franz

Gert is a new addition to the schedule - it'll be great to hear an update on Railo going open source! Mark's talk went over extremely well at cf.Objective() this year - if you're curious about ColdSpring or just starting down that path, this will be an excellent talk for you! Kurt's talk was also very well received at cf.Objective(), as was Mike's. Both talks have a lot of solid, "from the trenches" experience in them. Peter's talk was very well received at both Scotch on the Rocks and CFUNITED - I really enjoyed this talk at Scotch and learned a lot from it! Mine is a new talk I was planning for CFDevCon, that looks at how Broadchoice is using Subversion for more than just simple version control.

Our original speaker had a schedule conflict and our backup speaker just pulled out so there will be no BACFUG meeting tonight. Sorry.

We'll be back in September with Seth Duffey and image manipulation.

We have a live system with customer data and a new requirement comes along that a particular piece of customer data must be encrypted in the database from now on. We already encrypt some columns (using Triple DES - which you might have guessed given the recent posts on my blog and here about mimicking ColdFusion's encryption in Java/Groovy). What is the smallest possible code change to ensure that as any user updates their data in future, this item will automatically be encrypted - whilst still handling the case of legacy data being unencrypted?

We use Transfer for all our persistent business objects and almost all of our business objects have a decorator defined (for validation or some additional business logic). We also use Brian's TDOBeanInjectorObserver to automatically inject services into our business objects - just add a setter for a service and the bean injector takes care of the rest.

Here's the bean injector definition in our ColdSpring file:

Normally you would declare it non-lazy but we already do other non-lazy initialization so in our ColdSpring factory initialization code, we do this: to force the bean injector to be initialized which, in turn, registers itself as a Transfer event listener (so that it can intercept object creation). The suffixList specifies that any set*Service() method or set*Datasource() method on the business objects managed by Transfer should be matched to beans defined in ColdSpring and injected.

So how do we add the on-demand encryption to our business object's data?

[More]

May has been a quiet month on the blog because it has been an extremely busy month at Broadchoice. We completed our 2.0.2 and 2.0.3 releases and launched the new platform with a fair bit of press coverage.

The platform is powered by ColdFusion 8.0.1, running Model-Glue 2 (BER), ColdSpring 1.2 BER and Transfer 1.0 BER and runs on a cluster of 64-bit Linux servers with synchronization of the Transfer cache managed through a set of ActiveMQ JMS server instances. The database is MySQL.

We're continuing to work on a stream of minor releases as well as planning our next major release with a lot of new features.

I'll be pulling together some presentations and articles about how we're using the frameworks together (because I think we're doing some interesting and unusual things, behind the scenes). I'll some a few snippets of code at Scotch in both of my presentations (and again at CFUNITED). I'm talking to the CFDevcon organizers about appropriate topics and they suggested a framework-related session so that might be the first unveiling of some of our ColdSpring / Transfer tricks and tips. I expect Ray will also be blogging about some aspects of our application architecture in due course.

Feel free to sign up for a free Broadchoice account and see what we've been up to! Our support site (also powered by the Broadchoice Web Platform, as is our public website - we like to eat our own dog food!) has several ways for you to provide feedback to us!

Kay Smoljak is running a series of interviews with framework developers and has a summary article on SitePoint that includes a survey of people's framework usage. It's going to be a great series of articles and makes interesting reading (FarCry and COOP have been covered so far with Fusebox, Mach-II, Transfer and ColdBox coming soon - and Model-Glue and ColdSpring et al to follow). The survey will only be open for a few more days so rush over and make your voice heard!

Mark Drew will be presenting an Introduction to ColdSpring on Saturday in the SA5A slot at 2:40pm as Hal Helms is unable to attend the conference. Thank you Mark for volunteering at the last minute - and we're all hoping Hal feels better soon.

If you use Mark Mandel's awesome Transfer ORM in a cluster, you've probably wondered what to do about keeping the cache in sync across servers in the cluster. I've had to solve this problem a couple of times now and I figured I should publish an example of how to do this.

[More]

That's a question that crops up over and over again. I've blogged about it in the past. My answer - as I'm sure most folks would expect - is "it depends". The question came up on a mailing list again the other day and someone jumped in full of praise for ColdBox and then someone else said "Sean would say it depends" and went on to plug cf.Objective() as the "perfect place" to answer the question, wishing they could be there.

Here's what I said in response:

[More]

This year's cf.Objective() has a lot of firsts. If you're not attending, you're going to miss out on a lot of world premier events!

We've worked hard to make cf.Objective() 2008 a "must see" event. We have a number of firsts this year that we're very proud of:

• The public release of Open BlueDragon on May 3rd!
• The public unveiling - and Alpha - of Model-Glue 3: Gesture!
• The public unveiling of Mate, the new Flex framework from AsFusion!
• The first conference to feature the latest rising star in the frameworks world: ColdBox - with an introductory session and a two hour, hands-on advanced workshop!
• The first public information about Swiz, the new Flex framework from Chris Scott of ColdSpring fame!
• Speaking of Chris Scott, we're the first conference to feature a two-hour, hands-on workshop for ColdSpring!
• We're also the first conference to feature a two-hour, hands-on workshop on agile development for ColdFusion developers by the leading light in automated process & testing, John Paul Ashenfelter!

How can you pass this up? $629 for three full days of brain-cramming, enterprise-level information in a hotel that's only $120 a night! Register Now! The room rate is only guaranteed for a few more days!

If you're a Mach-II user - or thinking of using Mach-II - you might also be interested in the pre-conference classes.

Brian Kotek has released his Transfer decorator bean injector observer which I'm very excited about because I just needed this functionality for a client's project and had to write a version myself. Brian's is more sophisticated and, hopefully, will be integrated into ColdSpring in due course. Now I can use his version instead of mine and know that I'm using a community-supported resource.

I know Brian Ghidinelli also ran into this issue and had started to write his own as well. I expect he'll switch to Brian Kotek's version now.

So what does it do? Well, as you build complex domain objects by writing decorators for Transfer objects, you find you need access to services that you are managing with ColdSpring. Transfer provides an event model so you can add a listener (observer) for the afterNew event and use that to inject dependencies into your domain objects. It's a fairly manual process. What Brian's CFC does is completely automate the process. You declare the injector in your ColdSpring file and pass in Transfer to its constructor. When ColdSpring initializes the injector, the injector registers itself as an observer for that event and then it automatically injects any matching services, based on setters in the decorator. Very slick!

You can download the 1.2 Release Candidate from the ColdSpring site. The documentation has yet to catch up but there are a lot of changes since the 1.0 release including aliases, abstract/parent beans, various useful factory beans, support for cfcUnit (with abstract test beans), the ColdspringProperty for Mach-II and all sorts of other goodies.

Thanksgiving is a time to be thankful and this year many of us will want to give thanks to Chris Scott for an amazing series of updates to ColdSpring that complete what will be ColdSpring 1.2 (there was no 1.1). Over the last few days he has committed fixes for two bugs including enabling lazy-init="false", configuration factory beans, autowired test cases for cfcUnit and a transactional autorwired test case. This is great news for people using cfcUnit (you all are, aren't you?) as well as providing a number of great usability additions.

This is also great news for folks who feel constrained to only use official releases. The last official release of ColdSpring (1.0) was so long ago that lots of great features are only available in the BER: aliases, includes, abstract beans etc. This has been particularly troublesome for such folks trying to use Model-Glue with Transfer (or Reactor) since that has relied on aliases for quite a while. A new official release of ColdSpring (1.2) is just around the corner!

Today I discovered an unpleasant aspect of working with Reactor and ColdSpring: if your database and code don't match and you have ColdSpring creating gateways or DAOs using Reactor as a factory bean, you can get the very helpful "Fatal Error" and nothing else.

The exception from Reactor - about the database mismatch - is swallowed by ColdSpring and reported as a bean initialization exception. If that in turn is caught and dealt with by the application's initialization code, you no longer have any indication of what the problem might be.

Fortunately, we have a great tool at our disposal to dig into these buried exceptions: the ColdFusion 8 debugger!

I fired up the debugger in Eclipse and enabled break on CFML exceptions and write exceptions to the Eclipse log. As expected with ColdSpring and its exception-happy nature, I hit a few false starts but then I hit the Reactor exceptions. There are a couple of harmless exceptions as it tests for some optional plugin points but then you get the real exception, showing up in the Eclipse log. Very convenient!

If you've been following my blog over the years, you'll know that I pretty much stopped using Mach-II a few years ago, switching to Model-Glue instead (and, of course, continuing to use Fusebox for a variety of projects as well). At the time, I felt Model-Glue had leapfrogged Mach-II - as each new framework might be expected to do to existing frameworks - and I liked it's built-in bean factory and cleaner implicit invocation mechanism.

Model-Glue has come on in leaps and bounds - the rearchitecture based on ColdSpring, the scaffolding infrastructure, the integrated support for Reactor and Transfer for "generic database messages". It's very impressive. And now we're got the beginnings of a Flex version, which is very promising.

Now that I'm consulting and have a number of clients, I'm encountering Mach-II quite a bit and looking at the 1.5 release. I've mentioned in the past that I think 1.5 looked quite impressive (when Peter Farrell gave the "what's new?" talk at cf.Objective(), for example). Recently, I've been making recommendations for frameworks for clients and finding myself recommending Mach-II for some clients, mostly due to the new features in 1.5. For some of the sites my clients are trying to build, the modules, includes and subroutines really do allow you to build much larger, much more modular sites than earlier versions of Mach-II.

The extended property semantics in Mach-II 1.5 are also very nice, allowing you to specify structured configuration data - including full-on CFCs - as well as allowing property values to be dynamically substituted into parameter values throughout the configuration.

I still don't really like the direct invocation model (with <notify>) compared to Model-Glue's broadcast / listener mechanism, but the other features are pretty compelling.

One thing I have seen mentioned, but cannot find, is Peter Farrell's new ColdSpringProperty CFC, to replace the old ColdSpringPlugin. Anyone know where to get a copy?

Here's an interesting approach to advocating change for an open source project: Brian Kotek has made a Connect presentation explaining some changes he'd like to see in ColdSpring, to tackle what he sees as limitations in the Remote Proxy generation code in the AOP subsystem.

I haven't actually watched the preso but I have said publicly that I don't use the proxy generator in ColdSpring - because I don't think you can automatically generate an appropriate remote proxy for a model in the general case.

The all-new Bay Area ColdFusion User Group website just went live. It is based on Matt Woodward's open source Capitol Hill User Group application, built with Mach II 1.5 and ColdSpring 1.0. It's still a bit of a work in progress (both as an application and as a website) but more content and functionality will be added over time.

After the networking event, Joe Rinehart hosted a Birds of a Feather session on frameworks. He covered the new release of Model-Glue 2.0 for ColdFusion, the Alpha 1 release of Model-Glue for Flex (which looks very exciting!) and said that Model-Glue for Java, developed by Chris Scott (I think) would also become an official Model-Glue project - all on the new Model-Glue website.

Next up I covered the Fusebox 5.5 release which is currently in limited Alpha with a public Beta planned in July (as soon as we can get enough documentation together on the new features). I also announced publicly that providing a migration path for Fusebox 3 was on the roadmap (for Fusebox 5.7 probably).

Matt Woodward (and Peter Farrell) presented Mach II 1.5 which is in Beta right now, and the new website. He also talked about plans for their 2.0 release (but didn't go into specifics).

Next up was Chris Scott, who said that an official 1.2 release would appear within a few weeks and then they would be working toward a 1.5 release. This will be the last release of ColdSpring that will run on CFMX 7 - ColdSpring 2.0 will require CF8 because they want to take advantage of cfinterface and onMissingMethod() to make ColdSpring faster (and simplify the core files).

Last up was Doug Hughes who assured us that Reactor would hit an official 1.0 release as soon as the documentation was complete. Ah, the dreaded documentation...

Brian Kotek has an excellent post about using ColdSpring to its full potential, in response to a series of articles on Tom Chiverton's blog about building services with ColdSpring and Reactor.

Brian shows how to use the factory-bean and factory-method descriptors in your ColdSpring XML file to handle automatic injection of beans obtained from factory objects that are also managed by ColdSpring. It's a powerful technique that helps completely remove a number of dependencies from your application code.

I use the same technique with Transfer and ColdSpring:

This allows me to inject the data source object and the main Transfer API object directly into my service layer objects so they don't have to know about the Transfer factory at all.

Mark Drew has posted a new video introducing the Frameworks Explorer on the CFEclipse TV page. If you haven't seen this great new plugin, check it out! I'm finding it invaluable every day!

Well, we want a good user experience designer / user interface developer and a good ColdFusion developer.

For the first role, we want someone who can create crisp, clean user interfaces that are intuitive and easy to use. You'll have good graphic design skills and the ability to take a UI vision and turn it into lightweight HTML + CSS, with slick JavaScript for interactivity. If you've got ColdFusion skills, that's a bonus.

For the second role, we want someone who can build high-performance, highly scalable ColdFusion systems. You'll have a good grasp of application frameworks and object-oriented development (preferably Fusebox + ColdSpring + Transfer since that's what we use - but experience with otherwise frameworks and a willingness to learn will count).

For both roles, you will be able to work independently (and remotely, if appropriate) but with a focus on delivery and collaboration. Familiarity with source code control (e.g., SVN) and bug tracking software (e.g., Trac) is a requirement.

It's early days for Scazu so we're looking for folks who can be creative about compensation in exchange for a stake in the company. Our collective success will mean you'll be in at the ground level and able to build your own teams over time so it's a great opportunity for the right folks!

Jared has posted a partial session list for the upcoming cf.Objective() conference. I'm speaking twice on related topics. I'll be talking about the work my team has been doing in the Adobe Hosted Services group, explaining our architecture - based on ColdSpring and Transfer - as well as looking at one particular area that has caused us a lot of pain: error handling.

You'll learn how we built the back end that supports several functions behind Acrobat Connect and Adobe Document Center - and Kuler - as well as some of our pain points and, in particular, the problems that arise when dealing with error handling around the boundaries of systems in a Service-Oriented Architecture.

Update: this proxy is not needed to have a single instance of the Transfer factory shared between multiple Model-Glue applications. You can simply have an alias tag in each application that references the single transferFactory object in the parent factory: So why did I think this wouldn't work?

I created a test case for parent / child bean factories and aliases, I put nothing but aliases in the child factories. ColdSpring couldn't find the aliases. I deduced (wrongly) that ColdSpring did not allow aliases in child factories to redefine beans in the parent factory.

Silly me. Turns out that my test case uncovered a bug in ColdSpring: aliases only work if the factory contains at least one real bean. At least, that's what my test cases seem to show. I'm going to run this past the ColdSpring crew for confirmation.

---

Want to share a single instance of Transfer between multiple Model-Glue applications?

Original code / post edited out.

The definition of transferFactory is in your parent bean factory which you tell Model-Glue about by putting this line in your index.cfm:

(assuming your overall Application.cfc is creating application.cs).

All the Model-Glue apps share that Application.cfc and so they all have the same parent bean factory which contains the single instance of the Transfer factory object. Each Model-Glue app has its own proxy object that delegates an alias that refers to the single factory object.

Thanx to Jared Rypka-Hauer, ColdSpring now an import tag, just like Spring! This will actually be very useful in my project: we have multiple ColdSpring XML files and right now we have a central CFML page that creates the factory bean and includes all of the XML files using the loadBeans() method calls. With the import tag, we can replace all of that code with a single loadBeans() call and have the main XML import all of the other XML files. Thanx Jared!

After Peter Bell stirred the pot, Peter Farrel wrote a fairly explosive post (repeating a lot of what he said on the cfweekly, episode ?) and it spurred Joe Rinehart to respond with an impassioned blog post defending the design choices made in the development of Model-Glue: Unity.

As someone who has contributed extensively to Mach II, Model-Glue, Fusebox, ColdSpring and Reactor (phew!), I would like to step up and defend Joe's decisions - he's done a sterling job, sticking to his vision for the framework and has been very clear about what should be in the framework and what should not. As a framework developer myself, I can tell you it's a rocky road. The "community" deluge you with requests for all sorts of features and you have to stand firm and defend your vision. None of the popular frameworks are "kitchen sink" efforts - there are countless feature requests that have been denied by the framework authors.

I've requested enhancements to all these frameworks. Some of those requests have been implemented but most have been denied. Even as lead developer on one of the Mach II releases, some of my suggested enhancements were turned down (and some of the changed Peter implemented in Mach II were reverted as inappropriate for the framework).

When I built Fusebox 5, I was deliberately very conservative about what went into the framework and what didn't. I implemented a few things the community really wanted that I didn't think were great ideas but I also did not implement several things that I thought were great ideas that the community weren't very interested in.

Fusebox 5.1 will be a fairly conservative enhancement release. Fusebox 6 has more scope for adding features but, even so, backward compatibility will be maintained and the addition of features will be strictly controlled but community-driven.

I don't know how community-driven Mach II is. I don't think it has a public bug tracker (Model-Glue, Fusebox, ColdSpring and Reactor all do). I get the impression that Application.cfc support was added for coolness (the other frameworks have taken great pains to remain compatible with CFMX 6.1 and equivalent competing ColdFusion engines).

Now that Mark has added a configuration object to Transfer, it's time to document how you can configure Model-Glue to use Transfer for the ORM integration which drives GDMs (Generic Data Messages) and scaffolding. First off, you need the very latest version of Transfer from CVS (see the transfer.riaforge.org website for details). Second, you need a fairly up-to-date version of Model-Glue (from SVN).

Third, crack open Model-Glue and edit one of the core files - shock! horror! Edit ModelGlue/unity/config/Configuration.xml and change the definitions for ormAdapter and ormService as follows:

The transferConfiguration bean definition will appear either in your Model-Glue's local ColdSpring.xml or a global configuration that is used as the parent bean factory for Model-Glue (see earlier blog posts about this sort of configuration).

Your Transfer configuration might look like this:

That's all there is to it! Model-Glue will now use Transfer for scaffolding and GDMs. Bear in mind this is an early cut of the integration right now. In particular, it doesn't support validation or any form of relationship yet. However, it should be enough to let you do basic table-based operations using Transfer.

Joe and Mark and I are still looking at what it will take to support relationships with Transfer in Model-Glue. To be clear, Transfer has sophisticated support for relationships but Model-Glue's ORM support is very Reactor-centric right now which makes this level of integration somewhat more difficult!

My lack of blogging lately is because I've had my head down coding, along with my colleagues Matias and Paul. This week we had several important milestones on our current project so we have been putting the finishing touching to some of our web services (Matias), build system (Paul - learning to love ant) and administrative consoles (me).

I've talked before about the structure of our service-based system: we use ColdSpring to manage all of the model components; we have simple web service / Flash Remoting facades in front of that model; we share that configuration with our Model-Glue applications using the parent bean factory feature of ColdSpring. I've been focusing on the Model-Glue side of the things this week, so I thought I'd blog about how that's working out for us.

[More]

Mark Mandel just made me a committer on the Transfer project so I added the first cut of the Model-Glue adapter (and metadata and dictionary objects) to CVS (on transfer.riasforge.org). No documentation yet - we need a separate Transfer configuration object (yeah, like Reactor has) before it becomes easy enough to use to be worth documenting. And I've realized that there are a couple of small enhancements to ColdSpring that will make it easier to swap pluggable adapters inside Model-Glue (already raised on the coldspring-dev list).

Nathan Strutz has created a couple of Fusebox 5 lexicons that make it easier to use ColdSpring and Reactor with Fusebox 5. Nice work Nathan!

My team is building a lot of web services right now. Although we have a number of discreet groups of services, they share some common infrastructure and they all interact with a common database schema. We decided early on that we would use ColdSpring to manage the model components behind our web services and, as we've been building out the code base, we've settled on what seems to be a nice structure that allows each group of services to be developed fairly independently but still all be wired together as part of one ColdFusion application (so we can share data cached in application scope, for example).

[More]

You can now register for MAX 2006. The sessions & tracks are all listed as well. Plenty of ColdFusion sessions this year with a good range of levels. I'll be there as part of a three hour session covering frameworks and methodologies - ColdSpring, Fusebox, Mach II, Model-Glue and Reactor will all be covered. Yes, Fusebox at MAX!

Just in time for CFUNITED, ColdSpring 1.0 Final Release is now available!

Big congratulations to Dave and Chris and the gang - this is an awesome piece of work!

Chris Scott is wondering if folks would be interested in an AOP BOF at CFUNITED this week. Let him know in the comments over there.

Wow! I've been following the development of Model-Glue 2.0 a.k.a. Unity pretty closely but even that hadn't prepared me for just how impressive Joe's video demo would be! In about eight and a half minutes, he builds a blog application (including manually creating the post / comment tables in the database).

From the video, you'll see that Unity uses Reactor to drive the database access and ColdSpring to manage both the Model-Glue service components and the Reactor factory itself. A very powerful combination!

I take off on vacation and ColdSpring reaches a major milestone! Someone even emailed me asking why I hadn't blogged it already! For anyone using the 0.5.0 release, this Release Candidate will be a major step forward. For folks already using a recent CVS bleeding edge release, you'll already know about the goodies in this new official release.

Caveat: the documentation has not yet been updated so you may find yourself asking questions on the coldspring-dev mailing list!

For those of you unable to attend last night's BACFUG meeting, you can now watch the recorded presentation. Enjoy!

Jennifer just posted another reminder about this meeting (see her blog posting for more details). To assist the building security staff, you must RSVP on the BACFUG website before 5pm on Tuesday (today - it's 3:20pm PDT as I write this)!

I'll be presenting my "Managing ColdFusion Components with Factories" talk to BACFUG on May 17th (and then my "Objects and Persistence" talk on June 21st).

Adobe San Francisco, 601 Townsend, 7pm

The members of my team, Hosted Services, has a wide variety of backgrounds and experience but, until I joined the team, had not looked at ColdFusion as a viable technology for doing integration work.

The benefits of ColdFusion are slowing becoming apparent to my (formerly non-ColdFusion) colleagues: Java integration is fairly seamless, exposing code through web services or Flash Remoting is almost trivial, high-level tags that simplify integration tasks.

Within my overall team, I run a small group focused on core infrastructure and integration and we're getting into some prototyping work now and for that we're going to use Model-Glue to build quick HTML user interfaces and test harnesses and Reactor to simplify the data access layer, with a view to moving to custom SQL queries for performance later on. Given the ease of using ColdSpring with Model-Glue to manage the service layer, I strongly suspect we'll end up using all three frameworks together for our prototyping.

Over time we'll build out Flex 2 user interfaces, probably even for the internal administrative consoles that we might initially build using Model-Glue. The service layer we build should be directly reusable in that situation.

So far, the initial response to Model-Glue, ColdSpring and Reactor has been positive and we're looking forward to Model-Glue 2.0 a.k.a. "Unity".

This weekend I had a little chore, courtesy of my wife and her cat fancy involvement: a simple web application to manage some remote files on the regional website (for which I am webmaster). The website is hosted on GoDaddy so quite a few tags are disabled. What my wife needed was a way to upload and manage files on that website, in a way that let her control what information was shown on the website's finances page (she's treasurer).

I wrote a small Model-Glue / ColdSpring application that runs on her machine (which already runs the IRC bot) and lets her push files from the local financial folder tree to a specific directory on the remote website.

I figured it might be useful to someone so you can download the code from my software pod (right hand side of my blog).

Here's the code embedded in the web page on the regional website:

The files.cfm file is created and managed by the File Manager app as a way to control what is shown on the website.

To configure the app, edit filemanager/config/beans/beans.xml and change the local home directory and the remote server configuration.

The UI is very basic (hey, I'm an engineer not an artist!) and is modeled after the "webpush" utility Macromedia used to manage content on macromedia.com (with color-coding to indicate files that are the newer locally, the same, missing locally and missing remotely).

Anyway, if you find it useful, have fun with it. If nothing else, it's another example of using Model-Glue and ColdSpring together.

Jared Rypka-Hauer is maintaining up-to-date versions of the CFC Documentation of these frameworks for the community.

By way of a teaser about Fusebox 5, here's how using ColdSpring might look...

In your fusebox.xml file, you can define a fuseaction that is executed at application startup (on the first request after the application loads):

In your model circuit ("m"), you can declare the (imaginary) ColdSpring custom lexicon: Here's the application initialization fuseaction, using the ColdSpring lexicon: Elsewhere in your model circuit, you might ask ColdSpring for a bean: That would retrieve the userDAO bean from ColdSpring and place it in a variable of the same name. You might store it in a differently named object like this: The ColdSpring lexicon would be a directory containing implementations of the initialize, loadBeans and getBean verbs that encapsulate how to interact with ColdSpring.

I just added my two talks and the persistence sample application to the software pod on my blog.

As an example of how to hook these together, here are two bean definitions (from the ColdSpring XML config file) that show how to have ColdSpring create and inject a Reactor gateway into your Model-Glue controllers: Kurt Wiersma recently updated ColdSpring so you can define a factory and specify that other beans are obtained from that factory instead of directly from ColdSpring.

In the ModelGlue.xml file, specify the ColdSpring loader and that you want autowiring:

Finally the controller has a setter for the task gateway: ColdSpring will create the Reactor factory bean and then use it to create the task gateway and will then inject it into the controller for you.

Magic!

Model-Glue, ColdSpring and Reactor have all been updated in their repositories to handle the issues that I have talked about over the last couple of days. I'll be packaging up "ggcc10" for release at / after cf.Objective() - the Model-Glue / ColdSpring / Reactor variant of my frameworks comparison sample application.

Reactor is also getting some performance tweaks - some are already in the repository, more will be committed before cf.Objective() (do you see a pattern here?).

Check out the latest "BER" versions to try out the new abilities!

After review by some of the ColdSpring dev folks, I committed fixes to support duck typing (omission of type= on setter argument types and returntype= on functions) but we're still reviewing the inheritance hierarchy changes. Part of the issue is philosophical - should ColdSpring work with concrete types or with full-blown polymorphic types? - and part is the breadth of the potential changes (42 matches in 8 files for code that walks the function metadata). I'll keep you posted.

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!

Fusion Authority has another great interview / article about one of the topics coming up at cf.Objective(). This time it's Kurt Wiersma, talking about combining Mach II and ColdSpring. The article gives a short overview of each framework and then talks about the benefits of combining them to produce enterprise-grade applications that are easier to maintain and enhance. Kurt's blog also has some good information about the conference, about ColdSpring and about Mach II.

I made a minor update to my frameworks sample code. Jared pointed out that ggcc9 - the Model-Glue / ColdSpring variant - was still using my old "autowire" controller. I updated the example to use the built-in ColdSpring autowiring in Model-Glue.

I added the following setting to ModelGlue.xml:

and removed the declaration of the "csaw" controller.

At some point I'll update this variant with the feedback I had from Chris Scott and/or Dave Ross who suggested (correctly) that the aspect should call the model and the actual check identity code should be there instead.

Frameworks certainly stir up some passionate debates! Bob Lee says "I Don't Get Spring" and it gets picked up by The Server Side and both posts generate a lot of commentary. ColdSpring implements, in ColdFusion, several features of Java's Spring framework features so some of the discussions linked should prove interesting to you, as a ColdFusion programmer.

The CFCDev mailing list continues to be a fantastic resource for people building applications with ColdFusion Components. Today, Dave Ross posted a great explanation of how factories help address the problem of object creation dependencies. He starts out by explaining how the dependency problem arises and what our typical steps are to solve it and how that can lead us to a dead end (hand-coded factory objects). Next he talks about why the Service Locator pattern doesn't really work in ColdFusion and finally he introduces dependency injection a.k.a. inversion of control (which ColdSpring provides).

The thread continues to be interesting so watch the responses over the next day or two. In particular, I like Chris Scott's response that explains why he prefers setter injection (over constructor injection) and then he clarifies the potentially four-step object creation / initialization process that ColdSpring uses (it's much more sophisticated than I realized).

Chris Scott reports that Scott Barnes and Matt Woodward are blogging about ColdSpring. It's always good for framework developers to read other people's experiences of using their frameworks. As Chris says, it's hard to write objectively about your own code.

Matt's post talks about specific benefits of ColdSpring for Mach II developers and gives a good example (data source configuration). In particular he is "already seeing a huge benefit to doing things this way" and notes that using the two frameworks in combination "reduces complexity and increases flexibility". That may seem counter to your initial perception: after all, you need to learn another framework and deal with two XML files. I think he's right tho': it helps you focus on the two very different pieces of your application independently which means fewer moving parts to consider at the same time (Mach II for the controller; ColdSpring for the model).

Scott's post is typically more expansive, expressing his initial skepticism (ColdSpring looked like people pushing ColdFusion into the Java mold again) followed by a fairly enthusiastic adoption of ColdSpring. Scott already had some familiarity with the Java Spring framework, which helped him get up to speed. He gives some slightly more involved examples and gives the "MossyBlog stamp of approval".

So there you are: two frameworks together can be simpler than one framework on its own.

Kurt Wiersma explains the application context and hierarchical bean factory support that was added in release 0.5.0.

It's taken me a few reads to get my head around this and, right now, I don't know how I would use it in an application but it's good to know the functionality is there. I might look at revising the Model-Glue AutoWire controller to use ApplicationContext...

ColdSpring 0.5.0 Alpha is now available. AOP is much faster now, my Model-Glue autowire controller is included and there is now (as-yet-undocumented) support for AppContext and hierarchical bean factories...

Chris Scott has just published the second part of the AOP tutorial that shows, briefly, how "after advice" could have been used for the "before advice" logging example in part one, as well as delving into the (extremely powerful) "around advice" using method interceptors. The example he uses is to add caching to a DAO using external advice.

I've been playing with Arf! quite a bit lately and I thought I'd share some of the code in my little sample app, just to show how useful Arf! can be for small dynamic applications.

Naturally it's cat-related. I built the On Safari website last year (I am not responsible for the visual design!) using Fusebox and what little dynamic content I needed I was loading into the database from CSV files.

This year I decided to build a small content admin section to make this a more pleasant process as I add more content that people send me about past On Safari shows. For the admin, I decided to use Model-Glue, ColdSpring and Arf!

Code to fetch all the awards and sort them by year and sequence number:

Code to read in a single award record by ID:

I treat the record as a bean later on in the code so I actually reuse this method for both the 'add' and 'edit' scenarios. If the awardId is blank, then I get an empty 'bean' to populate the form - otherwise I get real data (my add and edit forms are the same view).

Code to save an award (either new or edited - Arf! knows that a blank ID means add a new record):

And, finally, code to delete an award:

You can decide for yourself how much work this saves. The cataward CFC is essentially empty (just the Arf! template). It was certainly nice not having to write CRUD SQL but in an app this size there wouldn't be very much of it.

It works, it's reasonably fast - certainly fast enough for my little admin needs.

What could I do better? Well, I ought to have a separate DAO layer and isolate the use of Arf! inside that rather than just manipulating Arf! in my controller but I just wanted a quick'n'dirty content admin. I'm only using ColdSpring to create and load the Arf! Datasource and RecordFactory objects (overkill but convenient). I'm using the autowire feature (in the ColdSpring CVS version, not yet released).

ColdSpring now has a website of its very own, containing the latest stable alpha release (0.2.1 at this point), information about anonymous CVS access, documentation, forums and information about the mailing list.

Dave Ross reports on the CFUG where he presented ColdSpring and Elyse gives an attendee's report. Check out the slides for the talk and the sample code - both linked from Dave's blog post!

I mentioned this feature earlier as an add-on but wanted to let folks know that the next release of ColdSpring will include the Model-Glue autowiring code (Dave Ross gave me commit access to the CVS repository - thanx!).

That means that the Model-Glue / ColdSpring integration will be as simple as:

Specify the ColdSpring bean factory loader and location of the ColdSpring bean definition file in ModelGlue.xml:

Adding the autorwiring controller (as the first controller): Adding setXxx(yyy) methods to your controllers, where xxx is the name of the ColdSpring bean you want to be injected automatically.

If you've already downloaded my frameworks sample app you'll have seven variants of a single application, all using different frameworks in different ways. Tomoaki Tanaka created an eighth variant, blending Model-Glue and Tartan (mentioned previously on this blog - thank you!). I have now created a ninth variant using the tiered OO model of variant #5 (a Mach II variant), the Model-Glue framework and the ColdSpring framework.

In order to try it out you will need the BER of Model-Glue (which has Joe's latest ColdSpring integration), the 0.2.1 release of ColdSpring which includes both AOP and the Model-Glue adapter from Dave Ross, and you will also need this extension to ColdSpring that adds auto-wiring for Model-Glue controllers.

In this variant, ColdSpring manages all of the model (except the transient note, task and user beans - I may convert these later) and it also autowires the various beans into the controller objects at startup (so the controller objects have no internal initialization code!).

I've also modified how security is managed to use ColdSpring AOP. In the previous Model-Glue variant (#7), security was checked explicitly in various event handlers by broadcasting the checkIdentity message. Now it is handled through "before advice" on the taskDAO and taskGateway objects, using ColdSpring AOP. The advice performs the security check and throws an exception if the user is not logged in. In the exception event handler, a message is broadcast that causes event results to be set if the exception can be handled by another event (in this case the security exception can be handled by the ggcc.identify event, which challenges the user to login).

I think this shows the power of these two frameworks in combination!

This Thursday, October 13th, Dave Ross will be presenting ColdSpring at the Albany NY CFUG. If you're in the area, don't miss this! ColdSpring is a very important development in the ColdFusion framework arena - hear it from the horse's mouth!

ColdSpring can deal with the drudgery of creating and initializing all of your model CFCs. Very nice. But when you're using a framework, you still need to explicitly 'wire' the model to the controller - by calling ColdSpring's bean factory to obtain the bean and storing it locally inside your controller. No big deal, you might think, but if ColdSpring can build all of your model for you, why can't it wire it into your controller as well?

The simple answer is because it doesn't know about your application framework so it doesn't know about controllers.

Dave Ross and Chris Scott are working on a plugin for Mach II that will allow ColdSpring to automatically locate the listeners, plugins and filters in your "controller" and look for setXxx(yyy) methods in them. If it can match a setter to a bean that it knows about (from the ColdSpring bean XML file), it will automatically invoke the setter for you.

I thought that was a great idea but I wanted it for Model-Glue!

So I wrote an AutoWire.cfc for Model-Glue. It relies on Joe's BER changes to Model-Glue to support the ColdSpring bean loader. I've submitted it to Joe, Dave and Chris so hopefully it will be incorporated at some point.

---

How it works: Model-Glue creates the bean factory, then creates the controllers. With the ColdSpring changes that Joe listed, Model-Glue creates the ColdSpring bean factory instead of its own (ChiliBeans). My AutoWire.cfc is a controller that you declare in the XML (as the first controller). At startup, when Model-Glue creates that it, AutoWire then modifies the in-memory Model-Glue object so it can intercept subsequent controller creation. Then, as Model-Glue creates the remaining controllers, AutoWire searches for setXxx(yyy) methods on each one and attempts to match them to beans declared in the ColdSpring XML file.

If anyone is desperate to try this out, I'm happy to send you the work-in-progress code...

After my previous post about integrating ColdSpring, Model-Glue and AOP, Joe went ahead and incorporated a hook for ColdSpring directly into Model-Glue. It works beautifully!

I was able to remove the ColdSpring bean factory 'hack' from my controller (see link to Dave Ross's post in my previous entry) and just make the ModelGlue.xml changes that Joe mentions. Using ColdSpring is now so easy with Model-Glue that I expect this is how I'll be building applications moving forward!

After a little bit of trial and error, I just succeeded in (a) integrating ColdSpring with Model-Glue, (b) defining logging advice after a method call and (c) actual logging results returned from methods!

Dave Ross shows how to use the Model-Glue adapter in ColdSpring - the returnType= attribute should actually specify the fully-qualified return type tho'. That combined with Chris Scott's AOP tutorial and a quick read of the source code (download from coldspringframework ).

My LoggingAfter CFC extends coldspring.aop.AfterReturningAdvice, implements afterReturning() which logs a message and then returns arguments.returnVal (very important!).

My ColdSpring XML file specifies:

• xxxTarget - my actual bean that I want to log methods in
• xxx - a coldspring.aop.framework.ProxyFactoryBean that references xxxTarget and uses the logAfterAdvisor intercepter (below)
• logAfterAdvice - my simple logging class
• logAfterAdvisor - a coldspring.aop.support.NamedMethodPointcutAdvisor that specifies my logAfterAdvice as the advice property and * as the mappedNames (matches anything)

The results of calling methods in xxxTarget are logged automatically!

Logging can be disabled by renaming the xxx and xxxTarget beans (so that my application code calls the actual bean, via the name xxx, instead of the proxy).

Very slick...

---

Update: see the next blog entry for an even simpler integration!

Just a reminder that there's a set of fairly active (if often off-topic) chat channels established on DAL.net IRC for ColdFusion developers. The main channel is #coldfusion which has a bunch of irreverent and fun regulars and then there are channels registered for several of the application frameworks: #fusebox, #machii, #modelglue, #tartan. In anticipation of ColdSpring becoming increasingly more popular, I have just created and registered a #coldspring channel.

The #coldfusion channel is often all over the shop and sometimes politically incorrect in the extreme but the framework-related channels are generally much quieter and much more on-topic.

Chris Scott has posted the first in a series of tutorials on ColdSpring AOP. It's a very good tutorial but it'll probably leave your head spinning the first time you read it: AOP allows you to change the behavior of your code, applying external code before and after certain method calls, without touching a line of code in your original application!

Well, assuming your application is built with ColdSpring in the first place - which is reason enough to start looking seriously at using ColdSpring to assist in managing objects in your Model.

ColdSpring AOP lets you "re-wire" the objects in your Model so that your code ends up calling proxy objects (which in turn call your original objects), and the proxy objects can execute "advice" code before, after or around calling the original methods. This lets you add logging to all or any part of your application, simply by configuring the XML file that defines the objects that ColdSpring manages. Or security. Or...

Chris Scott has posted a good overview of what AOP is and why it can be useful. He also talks about what ColdSpring AOP will provide - and code examples will be forthcoming after the Fusebox / Frameworks Conference this week.

Dave Ross has posted details about ColdSpring 0.2.0 and announced an AOP sub-project. For those who don't know, AOP means Aspect-Oriented Programming and there's a huge amount of hype around this in the Java world these days. Java, being a static language, needs preprocessors and other special tools in order to support aspects and cross-cutting etc. ColdFusion, being a dynamic language, is actually more amenable to such techniques performed programmatically at runtime. I'll be very interested to see what Dave and his pal Chris Scott have come up with in this arena! Read more on Chris's blog.

Dave asks for feedback on whether he should attend the Fusebox & Frameworks Conference and run a BOF style session on ColdSpring (since he's too late to get a speaker's slot). Let him know he should go!

Curious about what it would look like to use Dave Ross's ColdSpring framework with the Mach II framework? Check out the great diagram on Dave's blog.

Trond has posted a useful high-level summary of various application frameworks on his (beautifully designed) Waterswing blog.

I've already added a comment in response to several other comments there but I want to highlight a couple of observations he makes.

He draws a clear distinction between the primary application frameworks (Fusebox, Mach II, Model-Glue) and the "supporting" frameworks (Tartan, CFHibernate, ColdSpring). This is important to understand: you can use the supporting frameworks on their own, i.e., with your own ad hoc code, but they really work well when used with the primary application frameworks. Indeed, Tartan includes a Mach II listener and Model-Glue includes a Tartan proxy.

He also notes that Mach II gives the appearance of a framework that is not evolving very fast and compares it to Model-Glue, saying the latter "might very well take over". It will definitely be an area to watch closely.

More on this topic when I speak at SacCFUG, BACFUG, CFUNITED and PDXCFUG over the next few months. After CFUNITED, I'll make seven variants of a sample application available - each variant shows a different framework or a different style within a single framework.

Dave Ross has released a pre-alpha version of ColdSpring on CFOpen - his proto-implementation of Java's Spring for ColdFusion.