Presto makes liberal use of the ColdFusion application programming environment.  Presto uses a memory resident application variable called application.sites to store its own special data structure which represents a website's site architecture (and which is synchronized with any changes made in the Presto backend to this structure).  This greatly simplifies the coding of menu systems.

Cold Fusion Application Environment Overview

In general, Cold Fusion allows a website to have more than one application.cfm file in a hierarchy of web folders. Each application.cfm creates a programming environment with its own set of application, session, and request variables.  To be precise, if a request comes in, e.g. http: //foo.com/myfolder/anotherfolder/index.cfm, each successive parent folder is checked for an application.cfm, and the first one found is used as the template/program environment. The application.cfm environment that is triggered depends on the requested template's position in the folder hierarchy.

By default, Presto installs with a single application.cfm environment controlled by the installation's root webfolder application.cfm file.  More information about what analysis and variable setup this file triggers is available in the "Presto Request Process" section.

However, subfolders can be created on a website that have their own application.cfm's.  This can enable all the session & request variables for custom applications to be kept separate from the Presto settings.  This makes sense if the application is a 3rd party one, or if there are naming or functionality conflicts occuring between Presto and a 3rd party cold fusion application.

Presto's use of the CF Application Environment

A few general notes on the design of Presto, which have motivated the creation of the sizable and more complex application.sites variable described below:  Presto aims to be: 

• Able to manage several websites at once.  These website may share content and so draw upon the same database driven content.  They may look entirely different.  The websites may be for an intranet and a public website, or for the public and membership, or a consortium of associations, for example.
  
  
• Thoroughly multilingual.  Every page title, content area, navigation menu item, or form label or button, will be displayed in the user's preferred language if the language appropriate text has been entered into Presto.
  
  
• Thoroughly able to incorporate quick change to website structure as well as content.  Moving a page to another location, or linking it under two sections, shows an immediate effect on the page navigation menus of all its siblings and parents.
  

To accomplish a merger of the above design goals, we have focused on placing much of the website navigation information in an application.sites variable, with more sophisticated tools in the Presto backend for keeping this variable up to date with changes.

As much as possible, Presto setup parameters have been located in the Presto backend, with minimal amount of setup parameters hard coded into an installation's /application.cfm template.

Technical Notes

Presto works with any ISP that supports Cold Fusion MX.  Cold Fusion MX generally no longer requires application and sesion variable locking, and so the <CFLOCK> tag appears rarely.  <CFLOCK> is still required for an update that is self-referential, e.g. app.x = app.x + y.

Current code makes reference to a number of request.server and request.site variables.  These are actually pointers to application.server and application.site variables.  In the future, we may change request.server to always read "application.server".

<- ->