| Nat Papovich | Scott Newsome | David Huyck

The 2-day off-site meeting the web developers had was very good. It was nice to discuss architectural and development topics without the usual interruptions. It was probably also essential to do it off-site. I think all the web developers got a lot out of it.

We discussed a variety of subjects from explicit ways to improve our application-wide ColdFusion/Fusebox coding to making improvements in communications with remote developers. What follows is a brief list of topics covered as well as a few notes on decisions we made or plans of action we will undertake in relation to those topics.

• Fusedocs Convention
• Custom Tags
• COM Objects
• Session/Client Variables
• Template Naming Schemes
• Search Engine Friendly URLs
• Stored Procedure, File, and Recordset Naming
• Confirmation Pages
• CFLOCATION and Form Processing
• Test Bed

Fusedocs Convention
We began using fusedocs to document our code some time ago. The standard/convention within the Fusebox community has evolved over time. The current incarnation of the fusedoc convention is what we use. I got this description of it from somebody on the Fusebox mailing list. I can't recall who. I will give proper credit when I find out or remember.

Custom Tags
To allow easier integration of "legacy" code to new code, to decrease the learning period of new employees, and to attempt to emulate a 3-tiered application architecture, we decided to focus on creating more and tighter Custom Tags. Currently, we use Custom Tags to provide a variety of functionality to the site such as the plug-ins. As we are coding new features for Cyclone, we need to maximize the usage of Custom Tags, which will divorce individual items of functionality from the existing user interface and the existing site.

COM Objects
Another item discussed along with encapsulating functionality in custom tags was to also encapsulate functionality in COM objects. COM objects could be invoked from the user interface layer or from inside a custom tag. In both cases the "work" of a particular web application feature should be removed from the UI tier (as much as is practical) and placed in one or more tiers between the UI tier and the database tier.

Benefits:
Maintenance of the site and integration of new functionality will occur faster if more portions of the site are wrapped into Custom Tags. Speed of eliminating bugs will decrease as well as the chance of introducing new bugs with new functionality.

Session/Client Variables
The GeoAgents.com application's current system of identifying users and storing personalized data is potentially not easily scalable. This issue does not flow over to the database; it is specific only to the web application/ColdFusion layer. Once a scenario is created to introduce a clustered environment, we may need to make a global-but-simple change to the application to handle the change in setup. Our current setup stores the information in the web server's memory. In a clustered environment, a given web server's memory is not shared across servers. We need to store this information in a database, which multiple web servers share. The process of converting from our current system (usage of session scoped variables) to the clustered solution (client scoped variables) could be a simple process. We identified some potential risk factors and read a case study of a live, commercial site making the switch.

Benefits:
We are now more prepared for moving to a clustered web server environment for the sake of scalability.

Template Naming Schemes
The Fusebox Methodology (which the GeoAgents.com site for the most part currently uses) uses a specific file-naming schema to differentiate between files that perform different tasks. We decided that we want a more specific, more complete naming schema used in GeoAgents.com. There is no fear of not being compliant with the Fusebox standard due to the fact that the standard is still undergoing refinements and we are adopting a schema that many large sites have adopted, and will be reflected in upcoming versions of the "official" Fusebox Methodology. This is a complete list the naming schema we will use from henceforth both for new development and rewriting old code:

• qry_filename - Used for SELECT type queries and stored procedure calls to the database. These files should be concise and modular. Very little other than the actual database call should be on this file. CFPARAMs used to initialize database inputs are acceptable as is minor reformatting of output data. No part of this file should contain HTML nor is it acceptable to display to the user.
• cud_filename - This file type is used only for database calls that involve creates, updates, and deletes - not select-type queries or stored procedure calls. Where qry_ files can be called will-nilly, cud_ files need greater security and care to use. Very little other than the actual database call should be on this file. CFPARAMs used to initialize database inputs are acceptable as is minor reformatting of output data. No part of this file should contain HTML nor is it acceptable to display to the user.
• frm_filename - Used to display nothing other than the opening and closing <form> tags. CFML in these files should only be used if proper outputting of the form is impossible without it, or the output pre-set variables. This file type is always married to the following file type - err_. This file should be used to display data to the user, using HTML, etc.
• err_filename - This file should have the same suffix as the frm_ file it is performing error checking for. Therefore, if an input file is named frm_InputForm.cfm, there should be a file named err_InputForm.cfm in the same directory. The only job of this err_InputForm.cfm is to handle the error checking for it's married frm_ file. No redirection CFML should be used from within the err_ file. A given err_ file should not be use for any other purpose. No part of this file should contain HTML nor is it acceptable to display to the user.
• act_filename - In the version 2.0 Fusebox spec, an act_ file is identified as one that perform database writes only. We have decided to use the prefix act_ to identify files that perform CFML logic or execute CFML syntax that is not a database call, nor perform any error processing of a frm_ file. In short, this file type is a "catch-all". CFMAIL, CFFILE, extensive CFML logic and the like are acceptable uses of act_ files. In general, we should strive to avoid putting large tracts of CFML code in the index.cfm. This is the place for that code. No part of this file should contain HTML nor is it acceptable to display to the user.
• dsp_filename - This is the primary file type used to display data to the user's browser. Commonly, these files include the opening and closing <html> tags, as well as any HTML code. It is acceptable to cfinclude or cfmodule files into this file type, if they cannot be otherwise called from the index.cfm. This file should be used display data to the user, using HTML, etc.
• app_filename - Application-wide files used for security, setting global variable, etc. No part of this file should contain HTML nor is it acceptable to display to the user.

Benefits:
Easier debugging, less-steep learning curve for new developers to begin coding, easier organization of the application and its file system.

Search Engine Friendly URLs
Search engines do not catalogue any URL beyond a ? (question mark). Because of the way dynamic sites and Fusebox in particular works, the majority of our site cannot be successfully catalogued. There is a way to convert all ? (question marks) and & (ampersands) to / (forward slashes) using Fusebox. None of us have tested this solution, but the word on the street is that it is relatively painless. We may want to implement this in conjunction with the "Open Web Site".

Benefits:
Pages can be indexed and, consequently, bookmarked.

Stored Procedure, File, and Recordset Naming
The name of any given stored procedure will also be the name of the file containing that stored procedure call (in addition to a qry_ or cud_ prefix and a file extension of .cfm), as well as the name of the recordset returned. Here's an example:

• Stored procedure name - GetUserList
• Filename calling GetUserList - qry_GetUserList.cfm
• Recordset returned from GetUserList - GetUserList[1,2,3...] or GetUserList[_LiveSet, _PaidSet] - the brackets indicate optional naming for multiple recordsets.

Benefits:
Easier debugging, faster coding.

Confirmation Pages
We need a business decision made on the universal format of confirmation/thank-you pages. Consistency needs to be achieved whereby the user expects a given sequence of confirmation and/or thank-you pages when performing an action and receives it across the application. We came up with multiple options for thank-you customization.

1. No customization across different thank-you pages. All thank-you pages display the same, non-dynamic generic text. The links off the page go up a set number of levels in the navigation tunnel.
2. Minor customization across different thank-you pages. The text would be generic and have very little dynamic content. The buttons are fully customizable.

We came to a consensus decision on our preferences as a group. We want to display confirmation pages (before the action is completed) only when the action the system is about to perform is non-retrievable/non-editable as is the case with mass-emailing. Thank-you pages show up for these actions and the conclusion of all actions. Also, all thank-you pages reiterate the information just entered or action just performed. There is no check for confirmation before the action occurs if the action is editable (most of the site).

Benefits:
There will be more consistency across the site; more satisfactory user interface.

CFLOCATION and Form Processing
After every successful form submission, the application will cflocate to a new Fuseaction, preventing a user from refreshing the thank-you page and resubmitting the form post. If a form submission fails, a cflocate will not occur. Instead, the frm_ file will be cfincluded at the end of the Fuseaction.

Benefits:
Data integrity, satisfactory user experience.

Test Bed
We are using the development of the Intranet as a test bed for the way we want to develop new features in the web application. As discussed in the meeting summary, using these techniques on the Intranet will provide valuable experience as well as validating our decisions. We believe that the techniques discussed (if borne out in the Intranet development) will make the web application code more maintainable, reduce the introduction of errors, increase scalability, and reduce the learning curve for new web developers.