Application Components

Overview

ADF Applications serve many purposes. One of those is to easily manage components (CFC's) that serve a common function. Although an application can contain many different types of custom coding (e.g. custom scripts, render handlers, datasheet modules etc...) one of the most powerful pieces of custom coding are components.

Anatomy of an ADF Application Component

ADF Application Components can have any type of functions and accomplish any type of task. However in order to make your component available you not only need to include it in your Applications appBeanConfig.cfm you must also extend your Applications App.cfc.

For example, a component named "twittyDAO.cfc" would essentially look like this:

<cfcomponent displayName="Twitty Data Access Object" extends="ADF.apps.twitty.components.App">

... functions here ...

</cfcomponent>

Using an ADF Application Component

Since ADF Application Components get injected into your Application it makes it easy to write code like this whenever you want to call methods on your components:

<cfscript>
  application.twitty.twittyDAO.addTweet("How awesome is this");
</cfscript>

An application scope variable is created with the name of your application and then each component is loaded into that variable using the configuration provided in the appBeanConfig.cfm.

Recommendations

You are free to construct any type of custom components but as a part of constructing the core ADF Applications shipped at release time we have tried to construct a set of best practices around how to organize your components. We are trying to assimilate the naming convention with a general MVC style application.

In most of the applications built by the PaperThin Professional Services team you will see the following naming convention used

• <component>DAO.cfc - in this component we place all of the "Database" access calls. Gets, Adds, Updates and Deletes. Since most of the data for ADF Applications is stored in Custom Elements most of these methods are either making calls to ceData or using the CCAPI
• <component>Service.cfc - we use this component to do "Utility" work. Most of the methods contained within this component either call other Utilities or maybe do some work prior to calling a DAO method
• <component>Controller.cfc - when your application needs to step through multiple processes (e.g. update an element via the CCAPI then create a page (again using the CCAPI) and maybe a few other utility calls - we usually package them up in a controller component.