Mosh Teitelbaum wrote: > >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.
Brian Kotek wrote: > This is not accurate. 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. OK, so let me flip this around a bit (no pun intended): In your experience, how often do you have one developer working on the form and another working on the action file? Or, more generically, how often do you have developers working on individual files instead of groups of files collectively (i.e., all of the files needed to add an item to the shopping cart)? Granted, for maintenance purposes, this might happen frequently, but in most of those cases, the issue being resolved is a code error and not a redirection update. And in the cases of redirections, the person making the fix would have to know where to redirect the request, making the whole "doesn't need to know anything" point moot. On a similar note, I much prefer that my developers know the internals of a system instead of working blind. Not so much that they can make changes but rather so that they can understand the reason why things work out the way they do. > >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? I think you misread what I wrote. Whereas part of an architect's responsibility is, without a doubt, the definition of a file structure, Fusebox seems to add the additional overhead of *ALSO* having to create a virtual file structure (or more accurately, in FB terms, a series of circuits and fuseactions). So my point was that it seems to require more work from the architect instead of making her life easier. > >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. Thanks for the correction concerning XFAs. But my points earlier points about XFAs, reuse, and working blind still apply. > 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? Yes, the add/edit example was simplistic, but the application of security privileges was not. Let me give you a more fleshed out example of the security privilege dialog. Let's say I'm building a document library and I want to be able to define grant/deny privileges on whole directories or individual files. Additionally, any privileges I define on a directory can optionally be specified to cascade to the subdirectories and files contained within that directory. Regardless of whether I'm setting the privilege on a directory or on a file, the dialog itself will look the same with the exception that directory privilege dialogs have an additional checkbox concerning the cascade. In this situation, there are a few potential problems with the reuse: 1) I have to have logic in my form that, based on the object type, displays or hides the cascade checkbox. Personally, I don't have much of a problem with this example. But if we extend the example to include other systems, objects, etc. each with their own set of additional form controls, we start having problems. 2) Like the additional logic in the display code, the action code also has to include IF/ELSE blocks that check the object type, etc. 3) This can get way out of hand when privileges differ from object type to object type. Also, if each object is stored in its own table (i.e., you have separate FILE and DIRECTORY tables instead of a single DocLibObject table) then the action code now needs to determine which DB query to call (add to FILE or add to DIRECTORY)? > 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. Refactoring to optimize performance, add new functionality (fuseaction) to an existing feature (circuit), or adding a whole new feature (circuit) are common but usually do not require renaming of directories and/or files. Splitting a circuit seems to me like there was a problem with the original design of the system. > >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. Likewise 8^). -- 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 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
