Brian Kotek wrote: > First, I just want to be sure you understand what the fuseaction > actually is. [snip]
Yup, I understand all of that. But thanks for making sure. > 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. I can see how abstraction of a file's location might be beneficial, but I'm not sure I would agree that it's a *HUGE* benefit. As I see it, this kind of abstraction provides 2 kinds of benefit; security and, for lack of another term, abstraction as to where a file (or in your example, a circuit) is actually located to aid in team development. It provides security because a would-be hacker doesn't necessarily know where your file or files are actually located. However, I think this is more a form of security through obscurity rather than true security. The truth is, if someone were to hack your web server, they'd very easily be able to determine the true names and locations of your files. And, they probably wouldn't care much anyway since there's more valuable loot in the database than in code file. Concerning the benefit to team development, I'm not sure I see it. You're right, the members of your development team don't need to know that the store circuit is actually a directory called "MungeMe" but they still need to know that they are to use the circuit named "store." In essence, you're creating a virtual file system and requiring that the development team learn the virtual file system instead of the physical file system. With a well documented development plan, the benefits of this virtual file system are negligible to none to, maybe even, harmful. At least with a physical file system you can open up a file browser and see the actual structure. With a virtual file system you have to either remember it (bad), open and parse the code (bad), or read the documents (please god no 8^>). And this just speaks to the development team. How does this benefit the architect(s)? The way I see it, it makes their lives more difficult because they now need to craft a physical and a virtual file system. > 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. As Benoit indicated, and as I mentioned above, you're still hard coding targets, you're just targeting the virtual file system instead of the physical one. > 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. My question was really more about the benefits of a central spine (hub and spoke pattern) than Fusebox, and I'm not trying to start a holy war (nor am I suggesting that you are), but since we're here... I'm all for reuse (actual reuse, not cut & paste reuse) of code. But in practice, how often does the same one form need to be used in different situations? I can see reusing a form to add and edit a specific type of item/object but don't see reuse of a single form much beyond that. The only other time I've seen where something like this would be reusable is in a security context where you want to assign permissions or ownership to an object regardless of object type. In the case or add/edit, instead of dynamically setting the form action to "addThing" or "editThing" you could just decide in the action page whether the request is meant to add or edit (usually by detecting the presence of an ID). > 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. Practically, how often do you truly need to restructure your entire site? When your client insists that the name of the directory (or circuit) should be "ShoppingCart" instead of "Cart", he deserves to pay a ridiculous amount of money for what can easily be accomplished with a simple search and replace. Again, my question wasn't really directed solely at Fusebox. Nor was it meant to be any sort of swipe at FB. I'm just curious as what the practical and realized benefits and downsides are of using a central spine architecture. -- 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 Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
