> Isn't this exactly the situation for which #fusebox.rootpath# is > intended, ie for calling common pieces of code from whatever circuit > you happen to be in at the time?
Actually, #fusebox.rootpath# was designed to allow one to get to the root of the app for references in *HTML* (such as <IMG> or <SCRIPT language="javascript">) or anything in-line that wasn't in the actual served page. We really wanted to get away from an assumption that we know at design time where actual code assets are located. That's the point of FBX_Circuits. Using fusebox.rootpath as a substitute for something like "../../../myFuse.cfm" still creates file-path references that cause code to break too easily. > > Tom, the decision about whether a certain piece of code should be a > fuse or a fuseaction should not be dependent on > whether it is going to be used by multiple circuits. If it's a fuse, > then leave it as a fuse, and use <cfinclude> to > call it. It simple, it's quick, it's efficient, it's completely > standard,it's common practice. Lee and I agree that the decision about circuits should be made before decisions about fuses and fuseactions. We simply disagree that the following is a coding practice that leads to successful projects: <cfinclude template="../../../../../here/is/a/path/to/some/other/fuses/hope/you/can /find/it/6/months/later.cfm"> There's another problem with this. Let's say that you're in circuit A that has this in its FBX_Settings file: <cfset request.dsn = "Products"> and you're <cfinclude>ing a query in another circuit, "qry_DoThis.cfm" residing in circuit B. The FBX_Settings.cfm file for circuit B has this code: <cfset request.dsn = "Admin"> If you just try to <cfinclude> qry_DoThis.cfm, your query will either break or will connect to the wrong datasource. This is really an argument for encapsulation - that each circuit should handle its own business. Instead of reaching into another circuit's fuses directly, you ask the circuit to perform a fuseaction. <cfmodule> will work fine in this context: <cfmodule template="#fusebox.rootpath##self#?fuseaction=circuitB.doThis"> Before FuseQ, this was really the only appropriate way of doing this, and it still works fine in many places, particularly where an immediate evaluation is needed. But in many cases - and Hal will argue that MVC architectures is one of them - having to use <cfmodule> calls for everything is kludgy and impacts performance. With FuseQ, Tom's example problem simply defines a fuseaction as made up two processes: "first go do the query, then come back and do something else". It's an extremely clean and straight-forward. If both fuses were in the same circuit then the standard FB3 approach works fine. It's not a matter of one being "right" and another "wrong", but of trying to keep ourselves out of trouble. Lee's approach will work in many cases, but, as Tom describes his query, it is common enough that multiple circuits need to use it. By implementing hard-coded file references, as Lee suggests, Tom's code is subject to very easy breakage. If he ever moves where the queries are, or more likely, gets so many queries that he decides to break them up into small groups and several directories, Lee's solution means that Tom has to know every fuseaction that might refer to these queries and then track them all down and make all the changes . If he forgets even one, the application will break. When using <cfmodule> or FuseQ, any such changes will be reflected in one place (the fbx_circuits.cfm file) and poof, Tom's good to go. > FuseQ may solve a whole lot of problems that Fusebox developers > commonly face. But this situation is > not a problem, it is a perfectly well-understood and well-handled situation that standard FB3 (as written by John et al) > copes with brilliantly. The rush by FB3's authors to marginalise the > basic FB3 core is a little puzzling. Slow down, slow down. > Lee is absolutely right in saying that for many, many things standard Fusebox works great! Heck, that's why we all adopted it, right? But in some situations, a slightly different approach works better. For example, when the Fusebox 3 core file executes, it does 12 different things in a linear fashion: it starts at the top and works its way down. FuseQ does exactly the same 12 things but forms them into a loop, so that we can execute multiple fuseactions in the same HTTP request. This is what makes it so useful in some situations. What I want is the *ability* to take a different approach when circumstances dictate it, but not the *obligation*. Sort of like deciding whether to use <cfinclude> or <cfmodule>. They both have their own uses. FuseQ gives you just that ability without obligation. You can use it right outta the box with your standard FB3 code and your code will work just fine. You can use none of FuseQ, or a little of FuseQ or a lot of FuseQ, depending on the nature of the problems you're up against. It particularly shines if you're doing MVC, as a number of people have commented on. ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
