Mosh Teitelbaum wrote: >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.
It really is a big benefit. >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. using circuits has very little to do with security, though with Fusebox 4 you can place access modifiers on a circuit to prevent a public user from accessing it (for model and view circuits). Security through obscurity is not the point of circuits, and should always be replaced with true security. Incidentally, Fusebox 4 also has an integrated permissions system. >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. This is not accurrate. All the developer knows is that a link or a form in the page they are working on must use an XFA varible such as xfa.submitForm. With XFA's the developer actually doesn't even know what the actual target fuseaction is. This is determined outside of the context of the individual file the developer is working on. Instead, the architect has the power to determine program flow by setting the XFA's in the switch files or circuit.xml files. >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. Isn't this what the architect is SUPPOSED to do? >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. Benoit's assessment is making the incorrect assumption that the developer needs to "memorize" a ciruit structure. They do not. They are given XFA variables and that's all. No knowledge of the circuit structure or the directory structure is needed at all by any developer. >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. This was a simplistic example...surely you can think of instances where creating generic content components that need to respond differently in different situations would be a benefit? >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. Refactoring parts of an application is an incredibly common act, in fact I would say a constantly ongoing act. It does not necessarily mean changing the name of a circuit, this happens rarely. Far more common is the act of breaking up a circuit, realizing that you've grouped too much together, or realizing that you've split things up too much, or a dozen other refactoring considerations. The point is that the logical structure of the application is totally separated from the physical structure of the application. >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. No problem Mosh, and no swipes or attacks are percieved. I love the chance to talk about Fusebox and understand things about it that people don't like or don't understand completely. Thanks for your views. Regards, Brian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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
