Some alternative perspectives, if i may? >>> In your experience, how often do you have one >>> developer working on the form and another working >>> on the action file? > >Offhand, I would say, not often; however, fuseactions are very often worked >on by individual developers. This would imply that a developer responsible >for myApp.contact would create the query, the form, and the action for his >fuseaction while the developer responsible for myApp.search did the same for >his fuseaction. There is really no need for one to know what the other is >doing or how each fuseaction flows together within the circuit.
With an MVC approach (FB4 and FuseQ are very friendly to MVC), it may make a lot of sense to instead have particular developers working on fuseactions in one particular circuit, for example, a "model" circuit devoted to shopping-cart transactions. A well-designed and well-documented application would allow the developer with the most database/etc. knowledge to work purely on shopping cart "model" fuseactions, while other developers may work on view and controller fuseactions that all come together to create one page. I know FB4 and FuseQ are not equivalent to MVC, the formers are architectures and the latter is a design methodology. But FB4 intrinsically encourages structured design methodologies such as MVC, so MVC happened to provide a good context for explaining my 2 cents. >>> Fusebox seems to add the additional overhead of *ALSO* >>> having to create a virtual file structure > >I have never looked at it in terms of a virtual file structure. I can see >how this could seem like overhead and many have been confused by it (mainly >due to lack of documentation). The concept is simple enough; you are merely >creating an alias to a directory path within fbx_Circuits.cfm. For example: ><cfset fusebox.circuits.foo = "dir/dir2/dir3/foo";>. Instead of using the >path you can use "foo". If you need to move foo, you need only rewrite one >line of code. Nor do I look at it that way. Instead of "virtual file structure", I believe it's better to think of circuits as modeling the logical structure of your *application* itself. Especially if you are using an MVC approach with FuseQ or FB4 - circuits are members of the model, view, or controller, and the fuseactions in these circuits provide atomic, encapsulated services. In FB3, nested circuits (which are not necessarily nested directories) also provide nested/inheritable circuit-wide settings. The sentences above mention specific features of specific versions of fusebox. Regardless of all the specifics, though, a constant in this architecture during the past couple of years is the abstraction that circuits and fuseactions provide. With each version of Fusebox, the architecture provides a better way of abstracting the logic of your application above files and directories. Not only does it provide a separation between the physical/logical structure, Fusebox provides separation among circuits and fuseactions themselves which allows all kinds of wonderful things to happen, if architects are diligent in accurately documenting (think Fusedocs) the requirements and data usage for every code file. A properly designed Fusebox app allows a developer to build or maintain code in a particular file without knowing a lick about what other files are doing in the fuseaction in question. Notice the words such as "proper" and "well-designed", though - Fusebox is never as efficient in the real world as it is on paper. But what ever is? --- On a separate note, also I thought I'd mention this: As mentioned on the FB4 beta site, (every version of) Fusebox is a "pipes and filters" architectural style. For those unfamiliar with this term, the paper mentioned on the FB4 beta site provides an excellent introduction to this style of architectures. It gave me a much better understanding of the theoretical approach of Fusebox. Here's the paper I'm talking about: http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf i'll stop now before getting further off topic :) Mike Mertsock Alfred University Web Team ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
