How do you organize your small reusable cffunctions?

Question

I am reorganizing my ColdFusion directory structures and am curious about how experienced CF developers are organizing libraries of smaller cffunctions.

I am not as

Answer 1

I realize this is an old question, but I use a little bit of a different approach for these issues.

Utility Function/Singleton Approach with 'Injection'

I create a 'core' or 'utility' cfc. In it I pack all my utility type functions that are:

• Frequently used all the time everywhere (such as a generic viewRecord() dao and a core checkSecurity() function, et al.)
• Are base functions that imho should be core in CF (such as lpad(), capitalize(), et al)
• Are wrappers of some tags that allow me to use cfscript ubiquitously (such as exit() which wraps )

On onApplicationStart(), I create an instance of this object and assign it to the Application scope thus creating a static singleton of sorts.

Then instead of extending or re-including this into nearly all my cfc's, which allows me to use extension for more traditional type of inheritance, I then inject these methods in the constructor (the init) of all my cfc's I build. I do this by calling a method on the utility object itself such that:

public/remote any function init() {
  structAppend( Variables, Application.MyApp.Objects.oCore.injectCoreMethods() ); 
  return this; // Return instance of this object
}

The injectCoreMethods() method selectively returns a structure of the utility functions I want virtually extended into all my objects. It does not necessarily inject all the utility methods. Less frequently used ones, including injectCoreMethods() itself, still would need to be addressed via the full singleton application pointer such that Application.MyApp.Objects.oCore.infrequentMethod().

By injecting into the Variables scope, which is protected, these methods will effectively be private methods. So any dumps of the objects will not show these utility functions but are perfectly accessible within the cfc by all its direct methods.

File organization:

I have generally fallen into the pattern of having one cfc per folder. In each folder, I have one cfc file for the component and the init. All other methods I break out into cfm files and incude in that cfc. I do this to:

1. Avoid giant cfc files of 1000+ lines which can slow down my IDE (I use aptana/cfeclipse)
2. Allow changes to be recorded/tracked more discretely on a file per file basis and thus recorded in my SCM/Version control software.
3. Allow more than one person to work on a given object with out bumping code into each other.

So a dao object which contains 4 crud methods would look something like this:

/code/dao/dao.cfc
/code/dao/_removeRecord.cfm
/code/dao/_addRecord.cfm
/code/dao/_viewRecord.cfm
/code/dao/_editRecord.cfm

The cfc just contains the init() and self-documenting comments and in the pseudo-constructor area I include the four methods. This also lets me grab any cfc by its folder and move it somewhere.

Same for the utility cfc. It sits in its own folder and has about 30 odd functions amongst 10 or so cfm files (some simple functions I leave in the same file such as _string.cfm which actually contains lpad(), rpad(), etc all string related. You get the idea.)

Modules and Custom Tags

I avoid these at all costs because they need to be registered and hamper easy move/deployments. I don't like things that don't just self configure on drag and drop from one environment to another. CF5- you had to do things this way a lot more. But since CF6 and the ability to use objects in a real OOP pattern, why would you want to? There are very few cases you would want/need to if any.

Other

I used to put 'core' functions into the base.cfc which is automatically extended into all cfc's generated by CF (look for it, add a function and voila! Kinda like adding things to prototype in js). I used to really like this but it was a problem for deployment/maintenance.

To some degree, I take a Factory approach. I often put a fair amount of static cfc's up in the Application like the core one. A controller reads a generic control table and sets up all the objects in a loop along with a bunch of other things on app start like app variables. But some objects are instantiated as needed, obviously heavy objects and objects that contain manipulable [semi] persistent data fall into that category

I have, in some ways, been doing this since CF7. With CF9+ it is getting pretty easy, mature and slick.