Digital Ninja

Tonight I flexed some brain matter and delved into some previously-uncharted realms of modern Fuseboxing and Coldspring. To understand where I'm coming from, keep in mind that only a year and a half ago I was a Fusebox 3.0 guy and even today about 90% of our existing applications are still running on that version. Where Coldspring is concerned, I haven't yet found the time to test the waters with that enough to see it into a production application. This evening has made some great progress on that particular front, however.

The Coldspring Integration Into Fusebox

I'm building a simple user manager tool, which is powered by ExtJS (if you're following my journies you may have noticed that I'm fond of ExtJS lately). Taking the serious leap into Coldspring for the first time, I downloaded and installed the custom Fusebox lexicon for Coldspring and found enough documentation and examples to get that running. I added this to my fusebox.xml:

Please bear with me, I'm still working on the Mango Blog code output.ﾠ :(

<globalfuseactions>
<appinit>
<fuseaction action="core.coldSpringSetup" />
</appinit>
<preprocess></preprocess>
<postprocess></postprocess>
</globalfuseactions>

The coldSpringSetup fuseaction performs the following actions:

<fuseaction name="coldSpringSetup">
<cs:initialize coldspringfactory="servicefactory" useexisting="true" defaultproperties="#StructNew()#">
<cs:bean beanDefinitionFile="#ExpandPath('/coldspring.xml')#" />
</cs:initialize>
</fuseaction>

That takes care of all the bean loading as far as the Fusebox framework is concerned. Now this was working great so far; I was really digging on it. The login piece to the application was retrieving the user object from the service factory and performing the authentication without a hitch.

A Wrench in the Gear: AJAX

Here's where the problem comes in. Right past the login screen is the one stable piece of the application I've built so far, which happens to be (conveniently) managing users. An editable grid is loaded up and immediately calls out on-page-load to a service.cfc that returns a collection of User objects in JSON. It quickly dawned on me that it would be a good practice to use Coldspring from the service component just as I am doing in the Fusebox. While we're wearing our "good practices hat" let us also state that since we're already using the bean factory in the application framework it would be silly not to use the same one we instantiated over in the component. Otherwise, we'll have two factories in memory and that's just plain waste.

Here's where I ran into trouble. The lexicon inside Fusebox sets up the factory inside the myFusebox application data cache. This is not available to the service component sitting out there receiving AJAX calls. What's a developer to do? Let me show you where the lexicon puts the factory:

myFusebox.getApplication().getApplicationData().servicefactory = createObject("component", "coldspring.beans.DefaultXmlBeanFactory").init();

As you can see that's going to be handy for Fusebox but not for the service component. I emailed into the Fusebox mailing list to see what kind of advice I could scrape up. Barney Boisvert was the only person posting at my late hour, and he was very helpful. Basically there is no shortcut to get what I wanted. Some modification to the lexicon was going to be necessary if I was going to re-use an existing Coldspring bean factory in the Fusebox framework that had already been instantiated in a scope available to my service component as well.

New Lexicon Attribute

What I have so far, and it's working on my development server, is a mutation of initialize.cfm (from the Coldspring lexicon) that contains an optional boolean parameter "useexisting". In my situation I was already feeding it the "coldspringfactory" attribute with a value of "servicefactory". My thinking here was that if I wanted it to keep doing what it always had done before I started meddling, it wouldn't do to pass in a scoped variable name for this value, such as "application.servicefactory". I wanted to try to keep the operation of this parameter untouched.

So what I did instead is check to see if "useexisting" is true, and if so take a tour through the three main persistent scopes in a narrow-to-widest order: session, application, and server. In each one look for the variable with the name passed in through the "coldspringfactory" attribute, which in my case was "servicefactory". Here's what some of that checking code looks like:

// check to see if the user has requested that we re-use an existing copy of the bean factory in a persistent scope
if (fb_.useexisting) {
fb_.arPersistentScopes = arrayNew(1);
// We'll go in order of narrowest to greatest scope
arrayAppend(fb_.arPersistentScopes, "session");
arrayAppend(fb_.arPersistentScopes, "application");
arrayAppend(fb_.arPersistentScopes, "server");
fb_.blnFoundBeanFactory = false;

for (i = 1; i lt arrayLen(fb_.arPersistentScopes); i++) {
if (structKeyExists(evaluate(fb_.arPersistentScopes[i]), fb_.coldspringfactory)) {
// Now check its meta data to make sure this is really a Coldspring bean factory
fb_.stMeta = getMetaData(evaluate("#fb_.arPersistentScopes[i]#.#fb_.coldspringfactory#"));
if (fb_.stMeta.name eq "coldspring.beans.DefaultXmlBeanFactory") {
fb_.blnFoundBeanFactory = true;
fb_.sServiceFactoryInit = "#fb_.arPersistentScopes[i]#.#fb_.coldspringfactory#";
break;
}
}
}

if (not fb_.blnFoundBeanFactory) {
// User wanted to re-use something, but we couldn't find a valid object
// Standard bean factory creation, like it always was
fb_.sServiceFactoryInit = 'createObject("component", "coldspring.beans.DefaultXmlBeanFactory").init(defaultProperties="#fb_.defaultproperties#" )';
}
ﾠﾠﾠ ﾠﾠﾠ }
ﾠﾠﾠ ﾠﾠﾠ else {
ﾠﾠﾠ ﾠﾠﾠ ﾠﾠﾠ // The user does not wish to re-use a Coldspring bean factory
ﾠﾠﾠ ﾠﾠﾠ ﾠﾠﾠ // Standard bean factory creation, like it always was.
ﾠﾠﾠ ﾠﾠﾠ ﾠﾠﾠ fb_.sServiceFactoryInit = 'createObject("component", "coldspring.beans.DefaultXmlBeanFactory").init(defaultProperties="#fb_.defaultproperties#" )';
ﾠﾠﾠ ﾠﾠﾠ }
ﾠﾠﾠ ﾠﾠﾠ // set ColdSpring in this fusebox instance's application space
ﾠﾠﾠ ﾠﾠﾠ fb_appendLine('<cfset myFusebox.getApplication().getApplicationData().#fb_.coldspringfactory# = #fb_.sServiceFactoryInit# />');

ﾠ

Not quite finished yet

Barney pointed out on the mailing list, pretty much after I had coded the majority of all this, that it could indeed be troublesome for the lexicon's initialization code to go poking around through various scopes. A dead-certain and straight-forward command telling the lexicon where to find the factory might just be cleaner, and in retrospect I have to agree. I'll see how this can be done, perhaps another day. When I've got the full solution, I'll send it in to the FB mailing list and maybe it will become something we can all use. Let me know if you have any suggestions, I'm all ears!