Mosh Teitelbaum wrote: >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)?
On a small project this might not happen very often. But as a project gets bigger, or especially as changes are made to existing code, the benefits get bigger and bigger. >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. This isn't quite correct...the developer making changes to the code still needs to know nothing about the redirect target. That change is made to the XFA variable by the architect. In fact, if the only thing changing is the redirect, you don't even have to open the code file. Just edit the circuit.xml file (in Fusebox 4) and change the target of the XFA. >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. Again, for a small system this might be feasable. But for large applications with hundreds of files, dozens of directories and thousands of lines of code, there is simply no way for all of the developers to know and understand all the internals of the system. Because Fusebox handles each small piece separately from the others (fuses don't know about how they are called or what happens after they are called, logical and physical structure are separate, control logic isolated in circuit.xml file, etc.) it handles large applications very nicely. >> 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. First, managing the circuit structure is incredibly easy, so it's not like this is a lot of extra work. But along with separating the logical and physical structure of the application, circuits have other advantages. In Fusebox 4, there are access modifiers. There are logical hierarchies, where settings in parent circuits can be inherited or overridden by children. You have the ability to invoke fuseactions in parent circuits without know what the parents are (similar to super() in OO). And these logical hierarchies can mimic the physical structure, or they can be totally different. There are many very useful ways to exploit a logical, hierarchical application structure that is independant of the physical structure. The point is, all of this power is in your hands when you use Fusebox and you can use as much or as little as you like. It's always there, ready for you to use when the need arises. >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. Not really. You'd set up different fuseactions to build different parts of the form, and call them only when you need them. If one part of the form is only used some of the time, it's only invoked and used in some of the fuseactions. Fusebox 4 has the ability to call any number of fuseactions internally, with no performance penalty, and capture the resulting output into content components that can be used later to build a final display. This is incredibly powerful, and would easily solve the problem you specified in number 1). >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. Nope...using XFA's you'd point to different fuseactions that handle the action code in their own way. Or better yet, point to one fuseaction that handles the actions common to multiple uses of the form, then call other fuseactions specific to handling the current, specific use of the form. >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)? Again, the dynamic nature of XFA's negates this percieved problem. At runtime, insert the proper XFA that points to the appropriate fuseaction and runs the appropriate query. As an aside, would your solution to these problems be duplicating code in multiple forms and action files? Again, the point isn't that code reuse is the be-all-end-all. It's great, it's a goal to strive for, but it isn't everything. However, it IS something that Fusebox delivers very well under most conditions. To say it again, the benefit of Fusebox isn't totally in any ONE thing, it's in ALL the useful things that it does. >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. They don't always require renaming of files or directories, but it's great to know that when it does, the change is painless. And as crazy as it sounds, no architect, whoever they may be, will always design the perfect system up front. There will ALWAYS be problems with the original design of the system, because in the real world, things change. Being able to make changes quickly while isolating the effect of those changes is a huge plus...and did I mention Fusebox helps greatly with this? >> 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^). I wonder how long we can do this before our heads start hurting. ;-) 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 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
