By The SkySkraper Development Team

Many developers have known the frustration of working with an inefficient programming methodology. A change in business logic can mean a rework of large amounts of code because your business logic, data, and display layers are too intertwined and the methodology learning curve is just too long. These inefficient methodologies often don’t scale to complex business models because of the up, down, in, and out process of nested layouts, which slow down the application.

To remedy this situation we created a program model, called SkySkraper, which is based on the concepts of modular design. Adhering to the constructs outlined by SkySkraper will greatly simplify your next application development project.

SkySkraper consists of three core components, as shown in Figure A: Layer, Floorplan, and Builder. The components are managed by a pair of actions we call Floor Access and Room Access. Let’s take a look at the basic structure of SkySkraper.

Figure A

Layer component
Six Layer components make up a single Floorplan component. The layers are listed in the order in which they are called:

  1. setVariablesIn: This layer is not only used for variable initialization, but also for variable conversion. This means the variables that the BizLogicIn layer and setData layer are expecting are initialized and their values are set. Also, this layer can be used to alias the variables that are used in those layers.
  2. setBusinessLogicIn: This layer looks for the variables that were set in setVariablesIn. If there is any business logic that must be performed before entering the setData layer, it will be done here.
  3. setData: This layer is where the interaction with a data source occurs. All variables that are to be used in queries or stored procedures will have already been initialized, aliased, and set with the correct values from the previous two layers.
  4. setVariablesOut: This layer is similar to the setVariablesIn layer, but its emphasis is on the query variables coming from the setData layer and to be used in the setBusinessLogicOut layer and Display layer.
  5. setBusinessLogicOut: This layer is similar to the setBusinessLogicIn layer, but its emphasis is on the variables coming from the setVariablesOut layer to be used in the Display layer.
  6. Display: This is the layer that will take the variables that were set in the previous two layers and display their values on the screen.

Floorplan component
The second component is the Floorplan, which implements the layers as described in the Layer component. The implementation of these layers is defined by the Builder component, which determines the layers that are to be included or excluded for a particular floor. The header and footer are also included by the Floorplan, which is again managed by the Builder component.

Builder component
The Builder component is located in the root directory of your application. This component determines which directory is to be used, which file is to be processed, and which layers are to be included or excluded by the Floorplan component based on the Floor Access and/or Room Access actions. The determination is made by true or false flags located in the call to the Floorplan.

Floor Access, represented by dot notation, determines which directory or Floor of your application will be accessed. For example, Floor Access could be FA=admin.user, which would mean the directory structure to be accessed would be root/admin/user.

Room Access, which is dependent on the corresponding Floor Access, helps to determine which file is to be accessed. For example, if the Floor Access is admin.user and the Room Access is Edit, then the file accessed might be called dsp_user_edit.cfm located in the directory root/admin/user (see Figure B). Some common examples of Room Access include add, edit, update, search, view, and redirect.

Figure B
Room Access

A scalable solution
If you’re looking for a solution for your next enterprise Web application that will solve your need for a scalable, simple, easy to implement, and easy to maintain programming model, look no further than SkySkraper. In future articles, we’ll explain in detail the individual components of the SkySkraper programming methodology and its implementation with respect to common scripting languages such as ColdFusion, ASP, PHP, and others. In the meantime, join the article discussion and let us know what you think of the SkySkraper model.

The SkySkraper Development Team

Kevin W. Ryan has over four years experience as a Project Lead and nine years of programming experience in ColdFusion, ASP, JavaScript, XML, XSLT, COM/DCOM, MSSQL and Oracle.
Jim Walker has eight years of experience in Application & Web Development using ColdFusion, VB, C++, XML, COM/DCOM, MSSQL and Oracle.
Allwyn Naik has eight years of experience in Application & Web Development using ColdFusion, VB, Java, XML, COM/DCOM, MSSQL and Oracle.
Brett Bates has three years of experience in programming Web applications using ColdFusion, Flash, VB, MS SQL Server, MS Access, PHP and Oracle, and is ColdFusion MX certified.

Development note

SkySkraper has evolved from a concept started about four years ago by Kevin W. Ryan. It was not until the addition of Jim Walker and Allwyn Naik that the framework of SkySkraper began to evolve. With the core conceptual model in place, there were a lot of rough edges that still needed to be defined. At this point, Brett Bates was added to help finish and complete the SkySkraper model. This model is a direct result of over 30 combined years of real world programming experience.