> 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.

While that may be theoretically nice, why would you have so many duplicate
links to the same thing anyway? A well-constructed site should have common,
reusable (and potentially data-driven) navigation elements. In that light,
this doesn't seem to be the huge benefit that you claim.

> 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.

If you really wanted that, you don't need circuits. All you need to do is
create a variable to store the form action attribute, right? Maybe I'm
missing something, though.

> 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.

You can group related code together without Fusebox or any other controller
structure. I've been doing that for years. 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 navigation elements and be done with it, instead of having to change
links all over the place. On the other hand, I can also tell you from real
world experience that when you have to make significant changes to the
structure of your application, that's a sign that you should've spent more
time planning and less time coding.

I'll close this by stating that I'm not against your using Fusebox, or
anyone else for that matter, but I did think it worth pointing out that a
lot of the "problems" solved by Fusebox have traditionally not really been
significant problems for lots of people. If they are significant problems
for you, then you should probably use Fusebox. Personally, since I stopped
writing CGI programs in Visual Basic 3 and started writing them in CF
instead, I haven't had much need for a controller structure, but that's just
me.

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
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

Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. 
http://www.fusionauthority.com/ads.cfm

                                Unsubscribe: 
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
                                

Reply via email to