Unit testing is testing a fuse file in isolation, outside the context of the application. It's a very effective way of testing code before you insert it into an application. The typical method of doing this is by creating a test harness that sets all required input variables and then includes the fuse file. The test harness also sets "self" to a dump-variables tag of some kind, such as CF_DUMP or CF_showAttributes, so you can observe the results of processing.

To test using the xFAT scenario, you would need to change the target of all your exit actions from the xFAT address to the dump-variables tag, then put them all back after you're done.

> > What if your IT department says "that worm that's putting 'f**ck USA > > Government' all over web sites is a threat; we're setting our > > servers to use > > start.cfm as the default filename; all index.cfm files must be renamed > > immediately"? > > No big deal. > You could easily define #request.self# in application.cfm and use that > instead of hard coding.

If I understand your explanation correctly, you have a hard call to an xFAT file for each exit point in each fuse, instead of all exit points pointing to the fusebox. This means you can't use a variable, as all the targets are different. Have I missed something?

> > What do you do when you want to change what happens after a user > > logs in? > > Okay, just change <cflocation url="DoThis.cfm"> to <cflocation > url="DoThat.cfm">

> > Looks like you have to chase around the fuse files AND the xFATs > > to find out > > how things work, then makes changes to the existing fuse file and its > > associated xFAT. > > Not really. Just do the above. > When you make a change in XFB you just change the XFA, here you just change > the XFAT (XFA Templates).

If that's all you do, your app breaks, because DoThat.cfm doesn't exist. You have to add a new XFAT file for the new fuseaction. And if you need to find out where the app goes next, you must look in index.cfm, the XFAT file, and the fuse file to see how it all works before you can make the new change.

> I actually made a "viewer" to view xFATs. > It uses cfdirectory to get all the files and reads the file to give you the > fuseaction. > You can sort by fuseaction which is neat. > You can even click a link to create a static html file for any fuseaction.

That's good; you'd need something to help manage all those files.

> > Why even pretend that this approach is Fusebox? It violates the > > one tenet that > > makes Fusebox what it is: all calls go back to the Fusebox. > > Everything still goes through index.cfm. > You could just as easily point to index.cfm?fuseaction=login and it works > fine.

But you've lost the advantages of using a fusebox file, in that instead of each fuse having a single relationship with one other file (the fusebox), each fuse has a relationship with the fusebox file and all of the XFAT files that represent its exit points.

Yes, everything goes through index.cfm, but only AFTER routing through another file. That's another layer of maintenance and another set of potential failure points. It also competely removes the ability to use the app as a circuit in a larger nested application without app-wide recoding or reorganization.

Don't get me wrong here--you've invented an interesting means to adapt a Fusebox site so that it responds well to search engines. I can't, however, see it as a recommendation for general application development.

- Jeff

============================================================== | Jeffrey S. Peters | "Specialization is for insects." | | jeff@GrokFusebox.com | - Lazarus Long | | PGP key for Jeffrey S. Peters at ldap://keyserver.pgp.com | ==============================================================

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm

Archives: http://www.mail-archive.com/fusebox@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists