| 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.
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.
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.
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.
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.
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.
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:
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".
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:
Easier debugging, faster coding.
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.
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).
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.
Data integrity, satisfactory user experience.
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.
Site last modified: 10/30/2010
© 1999-2013, Jeffrey Marsh. All rights reserved.