Overview

FarCry proscribes a specific layout for code, how it should be stored and where specific types of function should be located in your project. The project is in effect your application and is the final arbitrator in terms of what gets included in your running application.

Understanding the format of a project is critical to the success of your FarCry implementation. It's format is mirrored in the format for plugins and the underlying core library itself. You should never need to modify the core library or included plugins - their functionality should be modifiable directly within the project itself - that's how the framework is designed.

Where Things Go

Each directory structure within your project has a specific purpose. Details of the various sections of your project's code baes are detailed below:

Project Directory	Directory Purpose
./config	This directory holds details about the global constants for your application. Many aspects of the application can be modified by making changes to these configuration files. Typically any server specific behaviour would be referenced here.
./customadmin	The "custom administration" area is reserved for modifications to the webtop. Any changes you want to effect in the webtop, for example, new tabs, menus, admin screens and so on, are defined in this location of the project.
./includedObj	DEPRECATED; Included objects are essentially chunks of code that have no where else to go. For example, if you are porting ColdFusion code from another application, or trying to integrate another framework this is a likely location to place a controller or the code itself. If you are building a pure FarCry application you should hesitate before using included objects. There is a better alternative; use type webskins instead.
./packages	Packages is the location of all components (.cfc) that are specific to your project.
./packages/types	All custom content types for your project should be stored in this folder.
./packages/rules	Any publishing rules for your project should be stored here. In the rare circumstance that you are extending a core/plugin publishing rule it would also be stored in this directory.
./packages/formtools	If you have any project specific formtools or you need to extend or modify the behaviour of a formtool defined in core or one of your nominated plugins, they go here. For example, if you want to modify the default configuration of the richtext.cfc formtool you would expect to have a richtext.cfc component in this location.
./packages/custom	Custom components that are not content types are stored in this folder.
./packages/system	If you are extending the functionality of a content type in the core library, then the .cfc gets stored here; for example, dmHTML.
./system	DEPRECATED; be aware that this directory structure has been deprecated as of v4.0.0. It will remain a viable location for v3.0.x custom configuration files and dmCron templates for the forseeable future.
./tags	If your project has a project specific custom tag library it should be stored here. The tag library can be segmented into functional groups by using sub-directories.
./webskin	This is where all content views are located; including full page displays, teasers, edit handlers and the like. The webskin sub directory structure has a folder for every content type in the system.
./www	This is the project webroot. The webserver should only point to this directory location, and the subdirectories under it.

Did we miss anything?