If your CFML engine does not provide a location function, FB3Lite will ensure one is available for you (simply wrapping CFLOCATION).  This has been the behaviour since the beginning.  Now, if your CFML engine does provide a location function, FB3Lite will still provide one in the variables scope (in case you're doing dynamic evaluation of it), but the engine-provided one will be used for static references (the typical case).

In general, this shouldn't matter to anyone; it's still just download and go.  The issue I alluded to above has to do with the optional parameters that CF9 provides (addToken and statusCode).  Since static invocations will use the built-in function, those optional params will be available on CF9, but will not on platforms that rely on FB3Lite's version.  Eventually I'd expect all CFML engines to provide a location function in which case there will no longer be a discrepancy, but for the meantime, if you're using multiple platforms, you'll need to ensure you're not using the optional parameters with the location function.

And before you say it, adding the parameters to the FB3Lite-provided function isn't an option, because CFLOCATION doesn't support statusCode until ColdFusion 8, which means you'd get compiler errors on CF7.

As always, the source is available, or you can check the project page for the latest info and updates.

<cfset appSearchPath = "../../../myApp" />
<cfinclude template="../com/barneyb/fb3lite/index.cfm" />

But now with mappings, you can simplify things, even if you're just using the webroot:

<cfset appSearchPath = "/myApp" />
<cfinclude template="/com/barneyb/fb3lite/index.cfm" />

This is exactly the same functionality I added to do/include.  The difference is that the top-level fuseaction is invoked via an internal call to do() which is based on appSearchPath instead of a circuit prefix.  But now both are equivalent again.

As always, source is available, along with the project page with current information and downloads.

I just wanted to provide a brief update on [Fusebox and 4CFF]. 4CFF discussed Fusebox with TeraTech (specifically John Zhu of 4CFF and Michael Smith of TeraTech) and were unable to reach an agreement on Fusebox joining 4CFF. One particular sticking point was that Michael wanted TeraTech to be paid for the Fusebox copyright and name.

This is exceptionally disappointing news.  Fusebox is an ancient web framework, regardless of what language you use, and has been under TeraTech's control for only a brief portion of that lifespan.  The vast majority of development and building of community happened before TeraTech took the reins, and even under TeraTech's "management", most contributions have come from outside their company.

Hal Helms (who helped shepherd Fusebox for many years) and John Quarto-von Tivadar (who provided both the architecture and initial implementation of Fusebox's current compiled model) held the rights to the Fusebox name and IP (via The Fusebox Corporation) for many years, and turned it over to TeraTech in 2006.  Since that time, Sean has developed and released Fusebox 5.5 and 5.5.1, and little else has happened.  This is not an exemplary track record for TeraTech.

In the past month I have made some significant optimizations inside the 5.5.1 cores to reduce memory consumption and speed the compiler.  These efforts were partially sponsored by a third party, have been donated to TeraTech on behalf of myself and the sponsor, and are slated to be released as Fusebox 5.6 sometime this year.  I also helped John with the 4.0 architecture, wrote a significant portion of the 4.5 release, and contributed much of the 'cf' lexicon, along with various smaller bits and pieces along the way.  In addition to the core files themselves, I have been a member of Team Fusebox for a number of years, and an active member in the community for much longer.  To my knowledge, I have not received official credit for these contributions aside from source comments within the 'cf' lexicon verbs and being listed on the Team Fusebox web page.

As someone who has invested significantly in Fusebox over the years, this refusal of TeraTech to contribute the name and IP to 4CFF over the issue of money is a slap in the face.  I know Fusebox has helped innumerable developers over the year (myself included), and that is more than compensation enough for the contributions I've made, but to see TeraTech have the gall to demand payment for what I (and many others) have freely donated is very disappointing.

I sincerely hope that Michael and TeraTech will reconsider their position on the issue.

In the latter case, the
tags are basically irrelevant, because they provide the same containership and semantic as the tag itself.  Fusebox 5.0 and older allowed you to omit the
tags in this case:

This only makes sense if you don't have a block, because if you have both blocks, then the tag doesn't provide the correct containership.

Fusebox 5.5, however, made the
tag required even for the simple case. This is unfortunate, I think, because it adds needless verbosity, and from digging around in the code, I suspect that it was primarily driven by implementation limitations, rather than user requests.

As part of migrating an app from 5.0 to 5.5.1, I really didn't want to have to go back and add all those extra tags, nor deal with the extra verbosity when maintaining the application down the road.  So I wrote a small patch for the core files that will allow an implicit
tag in the 5.0 style when using the 5.5.1 cores:

Index: fuseboxVerb.cfc
===================================================================
--- fuseboxVerb.cfc	(revision 778)
+++ fuseboxVerb.cfc	(working copy)
@@ -33,20 +33,26 @@

 		
 		
+		
 		
 		
-		
-
-		
-		
-
-		
-			
-			
-		
+
+		
+			
+			
+			
+		
+			
+			
+
+			
+				
+				
+			
+		

 		
 		
Index: verbs/if.cfm
===================================================================
--- verbs/if.cfm	(revision 778)
+++ verbs/if.cfm	(working copy)
@@ -35,13 +35,9 @@
 		// at most one
, at most one , nothing else:
 		fb_.hasTrue = false;
 		fb_.hasFalse = false;
+		fb_.verbInfo.hasOther = false;
 		for (fb_.i = 1; fb_.i lte fb_.verbInfo.nChildren; fb_.i = fb_.i + 1) {
-			if (fb_.verbInfo.children[fb_.i].getNamespace() is not "") {
-				fb_throw("fusebox.badGrammar.illegalVerb",
-						"Illegal verb",
-						"An 'if' may contain only 'true' and 'false' verbs in fuseaction #fb_.verbInfo.circuit#.#fb_.verbInfo.fuseaction#.");
-			}
-			switch (fb_.verbInfo.children[fb_.i].getVerb()) {
+			switch (fb_.verbInfo.children[fb_.i].getNamespace() & fb_.verbInfo.children[fb_.i].getVerb()) {
 			case "true":
 				if (fb_.hasTrue) {
 					fb_throw("fusebox.badGrammar.illegalVerb",
@@ -61,10 +57,41 @@
 				}
 				break;
 			default:
+				fb_.verbInfo.hasOther = true;
+				break;
+			}
+		}
+		if (fb_.verbInfo.hasOther) {
+			if (fb_.hasTrue OR fb_.hasFalse OR fb_.verbInfo.action.getCircuit().getApplication().strictMode) {
 				fb_throw("fusebox.badGrammar.illegalVerb",
 						"Illegal verb",
 						"An 'if' may contain only 'true' and 'false' verbs in fuseaction #fb_.verbInfo.circuit#.#fb_.verbInfo.fuseaction#.");
-				break;
+			} else {
+				// only non-true/false and not strict mode, so wrap an implicit true around the children
+				// we have to do some acrobatics around the 'children' references
+				fb_.children = structNew();
+				for (fb_.i = 1; fb_.i lte fb_.verbInfo.nChildren; fb_.i = fb_.i + 1) {
+					fb_.children[fb_.i] = fb_.verbInfo.children[fb_.i];
+				}
+				structClear(fb_.verbInfo.children);
+				fb_.factory = fb_.verbInfo.action.getCircuit().getApplication().getFuseactionFactory();
+				fb_.implicitTrue = fb_.factory.create(
+						"true",
+						fb_.verbInfo.action,
+						structNew(),
+						fb_.children
+					);
+				fb_.verbInfo.children[1] = fb_.implicitTrue;
+				// now null out the remaining children
+				for (fb_.i = 2; fb_.i lte fb_.verbInfo.nChildren; fb_.i = fb_.i + 1) {
+					fb_.verbInfo.children[fb_.i] = fb_.factory.create(
+						"noop",
+						fb_.verbInfo.action,
+						structNew(),
+						arrayNew(1)
+					);
+				}
+				fb_.hasTrue = true;
 			}
 		}

Index: verbs/noop.cfm
===================================================================
--- verbs/noop.cfm	(revision 0)
+++ verbs/noop.cfm	(revision 0)
@@ -0,0 +1 @@
+') />

The implementation is kind of hacky because the XML compiler lacks a IR transformation step, so I had to fake one.  And that was further complicated by the parallelism in the internal datastructures, necessitating the creation of a "noop" verb to use as a placeholder in certain situation. 5 minimum deposit casino  More specifically, there isn't a way to add or remove verbs from the parse tree, only to change verbs, and implementing the functionality within that constraint required some "creative" programming.  ;)

It's easiest to show with an example, so consider this contrived circuit.xml:

<circuit>

  <fuseaction name="home">
    <xfa name="page" value="page" />
    <if condition="structKeyExists(attributes, 'name')">
      <true>
        <loop collection="attributes" item="i">
          <set name="m" value="#i#" />
        </loop>
        <set name="message" value="Hello, strange unknown person!" />
      </true>
      <false>
        <set name="message" value="Hello, #name#!" />
        <relocate />
        <xfa name="exit" />
      </false>
    </if>
    <include template="dsp_home" contentvariable="bodyContent" />
    <do action="lay_default" />
  </fuseaction>

  <fuseaction name="page">
    <include template="dsp_page" contentvariable="bodyContent" />
    <do action="lay_default" />
  </fuseaction>

  <fuseaction name="lay_default">
    <if condition="structKeyExists(attributes, 'showNav')">
      <true>
        <do action="nav" contentvariable="nav" />
      </true>
      <false>
        <loop>
          <set name="message" value="Hello, strange unknown person!" />
          <do action="nav" contentvariable="nav" />
        </loop>
      </false>
    </if>
    <include template="lay_default" />
  </fuseaction>

  <fuseaction name="nav">
    <xfa name="home" value="home" />
    <xfa name="page" value="page" />
    <include template="dsp_nav" />
  </fuseaction>

</circuit>

Yes, I understand that it wouldn't actually execute in real life (there are a number of missing attributes), but that's not the point.  The generated flowcharts for the 'home' and 'nav' fuseactions are floating to the right. You can click the 'home' one to view it full size.

The UI is pretty simple, you enter the path to either a single circuit.xml file (as above), or your fusebox.xml file and hit 'Go'.  Then you can pick from the list of available fuseactions to act as your entry point, choose whether you'd like to include global pre/postprocess actions and pre/postfuseaction on the flowchart, and it'll draw it all out for you as a nice little PNG.

If you turn on the implicit fuseactions the charts can get pretty large pretty fast, but even generating some pretty gnarly charts for a sizeable app we have at Mentor didn't take more than a second or two.

If you'd just like to render a single circuit's stuff, you can point it directly at the circuit file, and you'll get an error box for any <do> verbs that point outside the circuit, so you'll still get a full chart, with the external dependencies called out explicitly.

I've made the code available in a zip archive if you'd like to run it yourself (or just poke around).  Just unzip it somewhere, and hit index.cfm in the browser.  The example circuit.xml above is included, so you can regenerate the demo charts I've shown here, or point it at your own Fusebox app and get a look at what you're doing.

The code itself is hardly an example of eloquent design, since this was just a little "screwing around" project.  The drawing stuff is pretty devoid of magic numbers, but I made no attempt to fully/properly decompose my types or to really enforce DRY throughout.  It is what it is: something to keep me from getting bored that I though might be of interest to others.

During normal execution this is irrelevant.  It's similarly irrelevant if you don't have a collision between FORM/URL parameters and custom tag attributes.  However, if you do have a collision, the FORM/URL parameter wins, which is clearly incorrect.

To fix this, I added the missing third parameter to structAppend, as well as reversing the lines (so FORM still overrides URL as it always has).  You can grab the source directly, or pull from Subversion.

CFML has implicit scope traversal, so if you have an unscoped variable, it will automatically traverse across a bunch of scopes until it finds one with the right name.  Further, you get an implicit local scope within UDFs, and you get a magic psuedo-scope within query-based CFOUTPUT and CFLOOP tags.

What I noticed was that looping over a query with a column named "template" always displayed the currently executing template, instead of the value from the query.   No worries, I thought, since prefixing it with the query name solved the issue.  "template" isn't a common query name for me, so while it surprised me I'd never noticed or heard about this magic "template" variable before, I didn't think too much of it.

Then a while later I realized it was my own fault, because of the include() UDF in FB3lite.  The argument to the UDF is named "template", and CFML places the implcit local scope at the top of the heap, including above the magic query-loop scope.  That argument was shadowing my query variable.

I've fixed FB3lite to use a prefix on all it's UDF arguments, so this problem cannot manifest itself anymore.  Well, I suppose it could, but you'd have to have a weird-ass variable name (e.g., "_fb3lite_template").  You can download the latest version, or pull it from Subversion.

<cfimport prefix="myapp" taglib="/path/to/fb3lite/app" />
<myapp:index do="myFuseaction" />

and you'll only get a single execution of the app, instead of one for each half of the custom tag.  This is a piece of functionality that real Fusebox has always had, but which I'd never used and so hadn't incorporated.

As always, the latest is available in Subversion at https://ssl.barneyb.com/svn/barneyb/fb3lite/trunk.

Each "page" of the app was actually a real page (a CFM).  Data access at the top, then a CFOUTPUT block below for the "view" pages, and just simple processing with a CFLOCATION for the action pages.  I built the forms so the same page would accept both create and edit requests, switching on the presence of an ID in the request parameters, so I got a little reuse that way, but nothing else.

For initial development, this worked swimmingly.  Each page was totally separate, pick a page, build it, move on to the next.   In a couple hours I was done, and most of that was spent on getting all the JS interactions tuned for inline editing, sorting, the slideshow, etc.  The app was simple enough that I didn't even do much copy and paste.  Maybe five or six blocks total, and two of those were form skeletons so I didn't have to start from scratch (i.e. not candidates for "real" reuse).

So then I wanted to add zip upload to streamline a bit.  Make a zip, upload it, and have individual items created for all the contained jpegs.  Sounds simple, right?  Except that all the logic was inside savePhoto.cfm.  I briefly considered setting up the attributes scope for each photo and then CFINCLUDEing that file for each jpeg in the zip, but it wouldn't have worked with the CFFILE ACTION="UPLOAD" in there, so that was out.  Time to refactor.

Still wanting to avoid any sort of framework-ish-ness, I opted for a UDF library instead of a CFC.  Mostly to resist the temptation to slap ColdSpring on it so I could stop thinking about those fu$@*ng CFTRANSACTION tags.  I split the logic from savePhoto.cfm into four UDFs, sliced appropriately for either "uploading" with CFFILE or sourcing from the local filesystem.  This actually worked pretty well, and I didn't have to duplicate any logic anywhere to support zip upload, create new photo, and replace existing photo.

So here I am at the end of my journey.  I actually had a pretty good time not thinking about the infrastructure and just diving right into the code.  No messing with getting ColdSpring and FB3Lite into the project, setting up mappings for them, etc.  That said, I do NOT recommend the shortcut to anyone unless they have a similar experimental interest.

As of right now, I'm probably slightly ahead in terms of time expended compared to doing the FB3Lite-on-ColdSpring way, but only slightly.  And I have manually managed transactions, no good way to apply security, layouts managed with Application.cfm and OnRequestEnd.cfm, no ability to reuse view code other than more UDFs, and a fair amount of duplicated SQL and error handling.  In short, a mess.

I'd imagine that the next enhancement made will push me over the brink to reduced productivity from the initial decision to monkey-code it, and it's downhill from there.  Fortunately the app is small enough that doing a wholesale conversion won't be too much work (and yes, that was one of the considerations for undertaking the experiment).   So that'll probably happen at the same time for the cost of an hour or so.

All in all, a good experiement, I'd say.  Completely confirmed my beliefs that spending half an hour setting up a good project framework is worth every second, and the "lost" time is made up within the first few hours of development.   And this was a very small project with a single developer, the rewards only get more significant as projects grow in size.

The basic idea is that your app generates the page body, as a full HTML document, and then it gets passed down the stream and manipulated.  Maybe it gets some LINK and SCRIPT tags added to the HEAD, or a footer to the end of the BODY.  Contrast this with the "content variable" assembly process, where your app generates a bodyContent variable which is handed to a layout to render into a full page.

What invariable ends up happening with the latter approach is a whole pile of variable along with bodyContent (headContent, pageTitle, footerContent, aboveFooterContent, belowFooterContent, etc.).  A huge mess, especially if you're using Fusebox or something like it, where you typically put your HTML in a dsp_ file and include it into a content variable, because you end up with a massive number of one-line includes, most of which are all bound to rendering a single page (i.e. aren't reused).

Contrast that with SiteMesh or Genshi, where you can package all those separate pieces up in a single packet, and let them stream out of your app to the layout engine that takes care of everything.  It might be combining your content with another app (think a portal), might be wraping it with header/nav/footer, might be restructuring it for an iPhone vs. a PC.

This doesn't come without a downside, of course.  For example your navigation isn't controlled by your application anymore, so if you're addicted to XFAs (as I am), you're kind of stuck.  For websites it's not as big a deal because you don't want your URL-space changing, but for applications it's a bit more troublesome.  This is straightforward to deal with in the opposite direction, however.  There are also some performance implications, though they're pretty trivial.

I'm trying to figure out a good way to integrate SiteMesh with CFML.  CF is just a huge burden to try and drag into the JEE way of doing things, but Railo should be far simpler.  I really don't want to use JSP for the layout engine, and while I like using Velocity, keeping to a single templating language is certainly beneficial.  Whether I'll actually have time to implement something remains to be seen, but it sure would be nice.