"it is REALLY nice to be able to edit a few lines in your circuit definitions and be done with it, instead of having to change links all over the place."
I agree with most of your points. But if you decide to change your fuseaction names and circuits structure, don't you have to change links all over the place, plus the fusebox configuration files? (fuseaction names and circuits are also "harcoded" all over the place, instead of file names and directories) It solves the problem by adding another one and add complexity/overhead to your app. Always the same dilemma : when to stop to add levels/layers of abstration... :) Benoit Hediard www.benorama.com > -----Message d'origine----- > De : Brian Kotek [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 17 juillet 2003 19:48 > À : CF-Talk > Objet : Cons to Fusebox > > > First, I just want to be sure you understand what the fuseaction > actually is. It's in the format "circuit.targetfuseaction", > where the "circuit" part is the alias of a Fusebox circuit, and > the "targetfuseaction" part is the actual action within that > circuit that you want to execute. I just wanted to make sure that > was clear. So... > > Abstraction is one huge benefit of circuits. When I do > "index.cfm?fuseaction=store.productdetails", I don't know, or > care, WHERE the store circuit is. This applies to both the > logical and physical structure of the site. Using circuit > aliases masks these dependencies because the core file handles > translation of the alias to a directory path to be called. So as > a team developer creating a link to that section of the site, I > don't need to know anything about the application's directory > structure or where that part of the site is located. > > On the other hand, using > "/root/store/products/productdetails.cfm" in a link requires you > to know EVERYTHING about the physical structure of the site for > EVERY link. And if for some reason I refactor the site, and part > of the change is to alter the physical location of my products > directory, or break it up into more than one directory? Better > open up a lot of files or break out the extended search and > replace, because every link that points there is going to have to > be changed. > > Circuits also allow for very easy dynamic links. If I have a > component that creates a form, and I want to reuse that form in > multiple places in the system but I want it to post to different > things, this is really easy with circuits. You do: form > action="index.cfm?fuseaction=#xfa.formAction#". Then at runtime, > you can set xfa.formAction to be anything you need it to be. > Bam...like magic the form can now post to any fuseaction you need > it to...and you never need to touch the code itself, only set the > xfa variable. > > Pretty much, your question goes right to the heart of why Fusebox > uses circuits in the first place. The answer is that when > related code is grouped together, that code is easier to maintain > and change. Placing code into directories can do this as well, > in fact Fusebox circuits are aliases for directories. But with > circuits, you get that layer of abstraction between the alias of > the circuit and it's actual path. I can tell you from real world > experience that when you have to make significant changes to the > structure of your application, it is REALLY nice to be able to > edit a few lines in your circuit definitions and be done with it, > instead of having to change links all over the place. > > Hope that helps, > > Brian > > Mosh Teitelbaum wrote: > >I've been pondering the benefits and downsides of this approach > for a while > >now. Since you bring it up, I was wondering what everyone else thought > >about all requests having to come in through an application > spine? That is, > >what benefits exist and/or are perceived to exist from structuring all of > >your HREFs like "index.cfm?fuseaction=foo.bar" or > "index.cfm?displayPage=5" > >instead of "/foo/bar.cfm" and "page5.cfm" respectively? > > > >Anyone? > > > >-- > >Mosh Teitelbaum > >evoch, LLC > >Tel: (301) 942-5378 > >Fax: (301) 933-3651 > >Email: [EMAIL PROTECTED] > >WWW: http://www.evoch.com/ > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
