Bastard child of a bastard child… Part 2, Application Management

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/)

  Description:
    Application file for the NMI application.
  Parameters:

  Usage:

  Documentation:

  Based on:

--->

<cfsetting enableCFoutputOnly="yes" showdebugoutput="false" />

<!--- set application to use --->
<cfset variables.serverName=lCase(listFirst(CGI.SERVER_NAME,".")) />
<cfif REfindNoCase("stage|sitecentral|preview",variables.serverName)>
  <cfset variables.applicationName="ITRStaging" />
<cfelse>
  <cfset variables.applicationName="ITRProduction" />
</cfif>

<!--- initialise the application --->
<cfa_applicationinitialize
  name="#variables.applicationName#"
  setclientcookies="True"
  sessionmanagement="True"
  sessiontimeout="#CreateTimeSpan("0","0","30","0")#"
  bactivelog="True"
  mode="default" />

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.

In the 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

In preProcess, we:

  • 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

In preEvent, we:

  • mess with the User Façade by using a Memento, updating any session preferences the user may have set

In postProcess, we:

  • 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.

2 Replies to “Bastard child of a bastard child… Part 2, Application Management”

  1. Surely if your reintegrated the existing data cache logs with the java module object controls there would be some overhead saving within the pre-load framework. Configuring new data types in this way would stack CODB hits away from the facade and back on the server.

    Just a thought.

    OMG What the hell are you talking about. I just hope that this makes sense to me one day.

  2. I am NOT familiar with “Spectra”; but I am currently diving into “FarCry”.

    Since I am also considering the Mach II framework for developing demanding app functionality, I would be very interested to know: Do You think that Your experience with regard to Spectra-to-Mach II-migration/integration could be of relevance for FarCry-Mach II-integration ?

    A positive answer would be cool …

Leave a Reply