You might like to read Part 1 of this series first.
Anyone familiar with Spectra will be abundantly aware that it doesn’t handle itself anything like any other Coldfusion application you’ve ever dealt with. For a start, there’s the enormous
request.cfa variable scope where all the info about the Spectra app and what’s going on in it are held. Dealing with this was our first step in moving from Spectra to Mach-II.
A little examination revealed there wasn’t much hope for dealing with
request.cfa without completely deconstructing the Spectra tagbase and recoding it in a Mach-II way. We decided pretty quickly that this was plain insanity. So, our
Application.cfm, rather than calling a
<cfapplication> calls a
<cfa_applicationinitialize> like this:
$Id: Application.cfm,v 1.3 2004/05/13 04:45:23 trib Exp $
ITR Web Framework, Copyright Department of Industry, Tourism and Resources 2004 (http://www.industry.gov.au/)
Application file for the NMI application.
<cfsetting enableCFoutputOnly="yes" showdebugoutput="false" />
<!--- set application to use --->
<cfset variables.serverName=lCase(listFirst(CGI.SERVER_NAME,".")) />
<cfset variables.applicationName="ITRStaging" />
<cfset variables.applicationName="ITRProduction" />
<!--- initialise the application --->
This lets us run the application as a Spectra app, with all the useful things we need in memory. Unless we do this, none of our other Spectra calls will work, so it’s a must. But that’s about where it ends at the Spectra level.
The other thing we’ve done with our existing all-Spectra apps, is place a huge amount of information into the
application scope where we can lug it around for easy access. This didn’t seem to be a very Mach-II way of doing things, so a few weeks back I posted to the Topica Mach-II list asking for advice on what approach I ought to take. The advice I got back led me down the Session Façade path, which I again raised on the list.
So what we have now is an application plugin, doing a whole bunch of work at different points.
configure function, we:
- create a User Façade to carry changeable user prefs around
- set static application variables such as Spectra Content Object Type UUIDs, file libray paths, etc.
- carry (mostly) static information about the Site we’re using around. Our Spectra app manages many sites, and the Site is an object in our Spectra CODB. We suck it out and carry it ’round
- carry our "live data" cache around. This is very clever, and I can’t take credit for it, but I will blog about it later. Essentially, it saves us an enormous amount time in terms of CODB hits
- carry our UDFs around
- check whether we need to update the "live data" cache. It can change every 15 minutes, dependent on new content being scheduled to the site
- insert the application-wide data into the request scope, making it easy to get at
- mess with the User Façade by using a Memento, updating any session preferences the user may have set
- mess with the User Façade again using a Memento. This time it’s to update the titles and URLs of pages the user has visited to maintain their site "breadcrumb"
We also have an
applistener.cfc which deals with generic, application level tasks such as sending emails and form mamagement. But that’s a topic for another day.
That’s pretty much it at the application level. I’m sure we’re bending some rules to breaking point, or worse.
Next up, I’ll be talking about object transactions with the Spectra CODB.