Now that we've made a component, learned how to use it, and documented its capabilities, we need to figure out how it best fits into the overall architecture of an application. The first question to answer is where to put the physical component files. They will be accessible from any of the following:
In other words, just about anywhere! The location does, however, matter very much in the way that components interact. This is where component packages come into an application architecture. As components increase in complexity, the amount of code contained in a single component file can become unwieldy. It's very useful to be able to divide your functionality among multiple files, generally grouped by common functionality. Packages really are nothing more than directories containing CFC files. They are best used for organizing the components that may be common to a particular application or task. For example, an intranet application may have our Actor Management system as one of many smaller applications. In that case, it would be wise to have a folder specifically for the intranet, under which would be a folder for each of the subapplications: [Web root]\OWS\Components\ActorManager\Actors.cfc [Web root]\OWS\Components\AnotherApplication\Another.cfc This arrangement would allow components to avoid naming conflicts as wella component for one application can be named the same as that of another application as long as it is located in a different packagein other words, in a different directory. |