Just under twenty bucks gets you 110 pages containing sample applications that illustrate each of the new approaches possible in Fusebox 5.5.

I love the cover art - especially the freeway sign showing the five possible styles of application!

As the announcement on the Fusebox website states, my work commitments have gradually taken me further and further away from Fusebox over the last year. Although I managed to get Fusebox 5.5 out the door in December followed by a maintenance release in March of this year, I have not been able to make any headway on my plans for 5.6, which was supposed to have been in public alpha around CFUNITED.

Adam has been a dedicated Fusebox user for four years and has closely followed the development of Fusebox 5.x. He's an experienced architect and I'm very pleased to have someone of his caliber step up and carry the torch for the Fusebox community.

I will stay on the Fusebox 5 mailing list (on Yahoo! Groups) for a while to answer questions about the transition and I will drop into the forums about once a week but I expect to drop off Team Fusebox and all Fusebox-related mailing lists and forums by early September.

Adam and I are in constant IM contact so the transition should be very smooth (and he already has full access to Trac and SVN).

Here's what I said in response:

[More]

If you're using the new no-XML style of Fusebox development, introduced in Fusebox 5.5, you should upgrade to Fusebox 5.5.1 as soon as possible. If you're using the traditional XML approach, you should read the Release Notes and decide how important this upgrade is for you.

What's changed?

[More]

This won't affect many people because the practice in the past has always been to put a copy of the error templates directory into every application - some people customize them to match their own application skin. Fusebox 5.1 added the ability to specify a mapped or root-relative path for all the configurable directories so you could have a single, central set of error templates that is used by all your applications. In Fusebox 5.5, the skeleton applications now take advantage of that and assume that there is a default set of error templates in the "/fusebox5" core file directory. Unfortunately I omitted that directory when I built the ZIP. Sorry.

If you download the core files ZIP now, you'll find it contains the error templates as it should.

The scaffolder functionality within the extensions package is currently in beta and we will be releasing updates to the extensions package throughout the coming months but the other aspects of the extensions package are final for this release, as are the core files and skeleton applications.

The skeleton has changed substantially since the Fusebox 5.1 release. The skeleton directory now contains two minimal applications: one is a reworking of the traditional Fusebox 5.x skeleton that uses XML configuration files, the other is an equivalent application that uses no XML. The circuit names are the same in both versions but in the no-XML version, the controller circuit is a CFC.

I'll be blogging plenty about the new features in Fusebox 5.5 over the next few weeks.

Thanx to everyone who has helped tested this release as well as all the ideas contributed by the community!

That means you have just one month left to download the Public Beta and take it for a test drive!

We want Fusebox 5.5 to be the greatest release ever of Fusebox so we want as many people as possible to test it and log any issues they encounter (via the Bug Tracker on the Fusebox website). The Public Beta has been available since October 1st and only two minor bugs have been found so we're fairly confident that Fusebox 5.5 is ready to go but we'd really like some more folks to test it for us!

If you're not already on the Fusebox 5 mailing list, you should join so you can discuss Fusebox 5.5 features and experiences.

If you have a blog, please spread the news about the Public Beta and the release date.

Keep your eye on Kevin Roche's blog for the very latest information about the scaffolding engine.

In Fusebox 5.1, we fixed a bug with locale-specific dates and we also speeded up the parsed file writer - both by dropping down into Java.

That means that Fusebox 5.1 and Fusebox 5.5 (Public Beta Candidate 0 and earlier) will not run on such shared hosts.

However, since the Java class usage is both fairly localized and also intended only to affect performance / accuracy of detecting when to reload in development mode, it seemed reasonable to automatically fallback to non-Java code if the sandbox prevents access to Java code.

I just committed build 5.5.0.581 which includes that fix (and one or two others since PBC0 appeared) and my friend has successfully installed Fusebox 5.5 with that build and is up and running.

Today Fusebox 5.5 reached zero bugs for the first time (by deferring the last remaining ticket).

That means we have almost reached Public Beta!

Build 5.5.0.569 is Public Beta Candidate 0 - and this site is running on it!

The core files, extensions and skeleton apps (there are two of them now: one with traditional circuits, one without XML) have all been uploaded to the files area of the Fusebox 5 mailing list (Yahoo! list membership required).

Please download and test for compatibility with Fusebox 4.x thru Fusebox 5.1 as well as exercising the new features. Between now and the end of the month, I want folks to find as many bugs as possible so that we can release an official Public Beta in time for MAX.

If anyone hits a show-stopping bug, I will fix it and release a new PBC build. Minor bugs will just be rolled into the "final" PB build.

For old school Fuseboxers, note that conditionalParse is back! If you are in development-circuit-mode and have conditionalParse set to true, the parsed files will only be overwritten if they change which will speed up execution since ColdFusion will not have to recompile them.

This build has not been tested on BlueDragon or Railo yet - volunteers please!

Items of note include: Application.cfc integration with allowImplicitFusebox and the onFuseboxApplicationStart() method, controller circuit written as a CFC (in fact, it's written entirely in <cfscript> just to make a point) with prefuseaction() and postfuseaction() methods, views relying on attributes scope (and that the event object shadows it). The model is unchanged from the classic 'ggcc3' version.

If you don't already have the database tables created, you'll want to download the original frameworks sample code and run the build tables code (in ggcc1 as I recall).

Feedback welcome, as always. One thing I'm not very happy with right now is the view / attributes scope dependence. Fusebox views have always been able to rely on variables scope but setting variables scope values, while possible, is quite ugly in a CFC controller:

I'm toying with the idea of:

which would sort of match how the event object (attributes scope) is handled:

Of course, instead of using a getter, I could just expose that scope directly like this:

which is somewhat more in keeping with the Fusebox idiom.

Fusebox 5.5 Alpha 2 is now available as a download from the files section of the Fusebox 5 mailing list on Yahoo! Groups.

There are three ZIP files:

• Core Files
• Extensions - this includes the lexicons that were previously in the skeleton application, as well as some new lexicons, plugins and the prototype of the scaffolding engine that Kevin Roche and Peter Bell are working on
• Skeleton Application

You need to be a member of the Yahoo! Group to access the file downloads but, if you are, you can download Fusebox 5.5 Alpha 2. If you're not a member and don't want to join, there will be a Public Beta available later this month (before MAX).

Regardless of membership of that group, you can read the up-to-date release notes (PDF, 188Kb) to see what's available in the new release!

The release notes cover all of the major new features (XML is optional, circuits can be CFCs, dynamic "do", Application.cfc integration) as well minor enhancements (XFA support via the event object, official support for assertions, stack traces for exceptions in the debug trace, new "shortcut" methods on myFusebox) and bug fixes.

Between now and the public beta, there are a handful of small bug fixes and some very minor enhancements to be added. You can see what's under consideration in this Trac report of open issues for Fusebox 5.5.

Please download and test, both for backward compatibility and to try out the new features!

The highlights: optional fusebox.xml, circuits can be XML or CFCs or directories, dynamic "do", Application.cfc support.

The Release Notes are a work in progress so we're still looking for your input!

I'm glad people seem so excited about the possibilities that Fusebox 5.5 opens up, making XML optional in Fusebox. Nick and a couple of others expressed interest in taking a hybrid approach, using CFCs-as-circuits in some places but using XML for circuits in other situations, to leverage lexicons, and also the option of keeping fusebox.xml to leverage plugins etc.

I expect the recording to be available shortly (and the link will be posted on the cfFrameWorks blog) but in the meantime I've added the presentation (PDF) and code (ZIP) files to the "Software" pod on my blog.

The first example is just the regular Fusebox 5.1 skeleton application but in order to run the other two examples, you'll need the latest build of Fusebox from SVN via the fusebox.org site.

I will start with a very brief overview of Fusebox so even if you don't know the framework at all, you should be able to follow the workshop.

Brian Kotek has a great post about data vs content in the context of AJAX and frameworks. He emphasizes the benefit of having your model in CFCs as the easier way to expose data-centric functionality to AJAX and notes that for data calls, you should not be trying to go through the MVC framework. It's a good read.

Scenario:

You download the Fusebox 5.1 core files and then you download the Fusebox 5.1 skeleton application and then you start to build the skeleton into a real application and you decide to convert the supplied Application.cfm file to an Application.cfc file because you're a modern CFML developer.

Symptom:

Session variables don't work in your application!

Solution:

Remove the <cfapplication> tag from the skeleton application's index.cfm file.

Problem explanation:

As supplied - and following a long, historic tradition with Fusebox - the Application.cfm file contains only logic to trap requests to non-index.cfm files and perform a redirect. That's how Fusebox applications ensure you can't request any other CFML files.

The "real" application starts with index.cfm and that begins with a <cfapplication> tag that defines the application name, session management parameters etc.

When you add Application.cfc, you're overriding Application.cfm but if you pick a different application name, e.g., this.name = "myFuseboxApp"; then index.cfm promptly resets the application name and session variables set in onSessionStart() are part of a different "application" to those within the Fusebox application.

This will be addressed in Fusebox 5.5 which will provide integration with Application.cfc out of the box.

Next up I covered the Fusebox 5.5 release which is currently in limited Alpha with a public Beta planned in July (as soon as we can get enough documentation together on the new features). I also announced publicly that providing a migration path for Fusebox 3 was on the roadmap (for Fusebox 5.7 probably).

Matt Woodward (and Peter Farrell) presented Mach II 1.5 which is in Beta right now, and the new website. He also talked about plans for their 2.0 release (but didn't go into specifics).

Next up was Chris Scott, who said that an official 1.2 release would appear within a few weeks and then they would be working toward a 1.5 release. This will be the last release of ColdSpring that will run on CFMX 7 - ColdSpring 2.0 will require CF8 because they want to take advantage of cfinterface and onMissingMethod() to make ColdSpring faster (and simplify the core files).

Last up was Doug Hughes who assured us that Reactor would hit an official 1.0 release as soon as the documentation was complete. Ah, the dreaded documentation...

Michael also mentioned that Fusebox 5.5 is currently in Alpha and has a lot of new features. I'm actively working on the documentation for those new features so that we can officially release a Beta build.

The next major release of Fusebox will be called 5.5. Accordingly, the mailing list will remain fusebox5.

Members of that mailing list now have access to a very early Alpha build of Fusebox 5.5. If you want to test for compatibility, please join the mailing list and download the A0 core files and take them for a spin. I'll be upgrading corfield.org shortly.

• Should the next major version of Fusebox be 6.0, 5.5 or 5.2?
• Should the new version get its own mailing list or should the current list be renamed to something more generic?

The voting is almost unanimous in the second poll: we will change the name of the mailing list within the next couple of months to be less "5-specific" regardless of the actual version number decided for the Summer release of Fusebox.

In the first poll, about 30% want Fusebox 6.0, 20% want Fusebox 5.2 and 50% want Fusebox 5.5. I'd like to see a clearer indication before I make a decision on numbering so please go and vote!

A semi-private Alpha of the next release will be made available to that mailing list soon - probably early May. The plan is to make a public Beta available at CFUNITED where the all-new Fusebox website will also be officially unveiled).

This is the book on Fusebox 5 / 5.1! Almost 500 pages covering Fusebox concepts, core files, the Fusebox Lifecycle Process, best practices and six appendices.

Andrew Shebanow has a good post about this tradeoff in relation to Twitter, which is powered by Ruby on Rails. Alex Payne, of Twitter, has talked about their experience with the massive scalability explosion that the site has seen and some of the "friction" that they've encountered trying to refactor the abstractions out.

I worry about this in the context of most every framework I use - and there's certainly been plenty of noise on mailing lists and blogs over the years about the performance of frameworks. One of the reasons I've settled on Fusebox for the Scazu website is that it compiles all the circuit files down to inline CFML on the first request so the abstraction is compiled out (this is one of the core messages in my "Extending the language of Fusebox" presentation - see slides and sample code under 'SOFTWARE' on my blog).

I've also been a fan of Transfer for ORM, lately because of the TQL - Transfer Query Language - component that lets me write complex database queries using an object / property abstraction. It looks much like SQL but lets you use the terminology of your application instead of the terminology of the database. It does add overhead but refactoring methods that use TQL into methods that use the underlying raw SQL is pretty straightforward and can be done on a method by method basis (and, in fact, I recently refactored one performance-critical method in exactly this way).

Going back to Andrew's post (and the underlying comments from Alex), I'd say that Transfer has a low friction coefficient that contributes to why I like it so much.

For the first role, we want someone who can create crisp, clean user interfaces that are intuitive and easy to use. You'll have good graphic design skills and the ability to take a UI vision and turn it into lightweight HTML + CSS, with slick JavaScript for interactivity. If you've got ColdFusion skills, that's a bonus.

For the second role, we want someone who can build high-performance, highly scalable ColdFusion systems. You'll have a good grasp of application frameworks and object-oriented development (preferably Fusebox + ColdSpring + Transfer since that's what we use - but experience with otherwise frameworks and a willingness to learn will count).

For both roles, you will be able to work independently (and remotely, if appropriate) but with a focus on delivery and collaboration. Familiarity with source code control (e.g., SVN) and bug tracking software (e.g., Trac) is a requirement.

It's early days for Scazu so we're looking for folks who can be creative about compensation in exchange for a stake in the company. Our collective success will mean you'll be in at the ground level and able to build your own teams over time so it's a great opportunity for the right folks!

A big thank you to all the contestants so far - there's some great work there!

• See the first five first five designs
• See the next set of designs

This said that the default value being used was not the documented default. I asked him to show me where the Fusebox 5 core files were on his system. I opened up fuseboxApplication.cfc and saw that someone had changed the underlying defaultFuseaction!

So, someone had modified the core files to create behavior that was at odds with the documentation and the result was a developer spending goodness only knows how much time trying to figure out why their basic little application didn't work - and then about another hour combined of my time and his, tracking down the problem.

Remember folks: Leave that code alone!

I've had some bad experiences with FarCry in the past, mostly because the installation is such a pain in the ass. Sandy Clark posted very detailed installations notes for the new FarCry beta and, by following those exactly, I was able to get it up and running in a pretty short space of time. The directory structure for FarCry 4 is about to change to make installation even easier - the FarCry team are working on that this week - and, whilst I still don't like the hard requirement for the web server mappings and a ColdFusion mapping, the process is definitely getting easier as FarCry matures.

So I have a new instance of ColdFusion running on my laptop with FarCry 4 Beta 1 installed and Fusebox 5.1 and a copy of the current fusebox.org website. Since Fusebox allows your application to live in a different directory to your index.cfm file, it's easy to keep the old site outside the FarCry webroot (you just set FUSEBOX_APPLICATION_PATH to the relative path from index.cfm to the directory containing fusebox.xml.cfm etc). Having the FarCry application honor the original site's URLs is as easy as editing the FarCry site's Application.cfm file to intercept fuseaction= in the URL and include the Fusebox core files.

If you're interested in playing with this yourself, you can follow Sandy's instructions and then checkout the work-in-progress from the branch in the Fusebox repository (that represents the fuseboxorg directory tree underneath the farcry folder if you've followed Sandy's instructions correctly).

Please RSVP on the BACFUG site (and it really is the February meeting on Wed, Feb 21 despite the website claiming it's January! - Jennifer just fixed this).

Here's Jennifer's announcement:

Next week at BACFUG, Sean Corfield will be lecturing on Extending the language of Fusebox.

We're used to the XML language of application frameworks being a static, fixed thing. If it doesn't let you do what you want, you're out of luck. Not so with Fusebox 5! This recent release lets you define your own verbs, which offers a much richer, more expressive way to build applications. This session will briefly walk you through the architecture of Fusebox and then dive into how to use third party custom lexicons as well as how to write your own language extensions. Enjoy the power of higher-level abstractions without the performance penalties they so often bring!

Wednesday, Feb 21, 7pm
601 Townsend St, SF

RSVP at: http://www.bacfug.org
We must give Adobe security a list of attendees based on our RSVP list, so please sign up early if you plan to go.

Also, Ben Forta will be in town in April 24 to give a Scorpio pre-release lecture! Same time and location as usual. RSVP details are still being worked out.

You can see who's who on Team Fusebox and what everyone is responsible for.

You can check out the stable Bleeding Edge Release (BER) under /framework/trunk which represents Fusebox 5.1 with some recent additions that I mentioned the other day. Or you can be really adventurous and check out the (unstable) BER under /framework/branches/dev which represents experimental code that will become Fusebox 6.

You can also check out the stable BER for Fusebox 5.0 for PHP (under /phpframework/trunk).

The code needs some cleanup but I figured it might be nice to get this out in front of people to get some feedback. This will eventually be the solution to ticket 25 as part of Fusebox 6.

Also in the repository are the Reactor and Transfer ORM lexicons that I showed at the Frameworks Conference. Again, these need code cleanup and enhancement but they should be a good starting point for people wanting to use either ORM library with Fusebox. A more comprehensive Reactor lexicon is also available.

Fusebox is a very stable, mature application framework. The basic (XML) syntax hasn't changed much since Fusebox 4 was introduced almost four years ago and pretty much every single Fusebox 4.0 and 4.1 application still runs unchanged on Fusebox 5.0 and Fusebox 5.1.

Backward compatibility is extremely important to protect everyone's investment in Fusebox so you can be assured that Fusebox 6 will also run all those existing applications.

So what can we do to make Fusebox a better framework?

We've heard a lot of calls to keep it simple (or even make it simpler) but we also hear requests to add new features. The recent Fusebox survey provided a lot of useful information and we're still analyzing that input. It's a fine line to tread to keep the framework true to it's vision while we try to address all of that input!

The Fusebox framework vision (working draft).

The two themes for Fusebox 6 are:

1. Simplify. Remove barriers. Make it easier for newbies. Make building applications faster by favoring convention over configuration.
2. Extend through extensibility. Provide new functionality outside the core. Add plugins, lexicons, even standardized circuits.

The code includes:

• The ORM lexicons which provide identical syntax for accessing both Reactor and Transfer within your circuit.xml file.
• The Cat Club task manager variant that is, essentially, the Model-Glue version (ggcc7) implemented as a Fusebox 5 lexicon.
• The simplified task manager application that uses the ORM lexicons.
• The new and as yet unannounced assertions lexicon / plugin that implements preconditions, postconditions and invariants.

I mostly followed the schedule I posted a week before the conference although after I finished my talk, I was caught in the hallways and missed both Oguz's and Matt's talks. I got caught again at lunch and missed the start of Nat's session too.

Highlights of the conference for me (in no particular order):

• Steve Nelson's "CFCs ARE the Framework"
• Peter Bell's "Application Generation - Beyond Scaffolding"
• John Paul Ashenfelter's "Rails for the Ruby-Impaired"
• The food! Did I mention the food was great?

It was great to chat to so many CFers who (for the most part) are fans of frameworks. There was also a very productive Team Fusebox meeting and we now have leaders for a number of areas where the team will focus as part of the big drive you're going to see around Fusebox - the website, the framework and the community. You'll be hearing a lot more about Fusebox from me over the coming months as I lead the development of Fusebox 6, based on community involvement!

My goal is to have Fusebox 5.1 ready for release at the Frameworks Conference so, please, download the new build and test, test, test!

I'll be speaking (you might say "of course"). About Fusebox 5 and 5.1 (you might not be surprised by that either). In particular, I'm going to be speaking about "Extending the language of Fusebox", showing the power of custom lexicons and touching on domain specific languages and expressiveness. Fusebox is the only framework that lets you extend the XML language that you use to describe the "event handlers" in your controller layer. That allows you to use a rich, expressive style of programming that makes your applications easier to maintain and much faster to develop.

I got the 8am slot on Friday which mean I'll be competing with people's hangovers and, unfortunately, Kurt Wiersma's talk about ColdSpring which I would have really liked to have attended. Given the selection of topics at the conference, it would be hard to pick a slot that didn't conflict with something I wanted to attend so that's just the luck of the draw.

See you in a couple of weeks in Washington, DC? Remember, registration is still open for the conference!

If you're not familiar with wireframing, it's a great way to sketch out the structure of a website at the beginning of the project lifecycle. Most wireframe editors generate clickable wireframes so you can get a sense of the user flow through a site or application. Some wireframe editors will also generate a skeleton application for you that supports all of the workflow. Your next step would typically be to create a static visual prototype of the site for the client (because clients usually work better with complete visuals). Once you have signoff on the prototype, you can go back to the generated skeleton and flesh it out with the HTML, CSS and graphics from the prototype.

For a really comprehensive wireframe editor for Fusebox, check out Fusebuilder, a commercial product from Mike Ritchie.

First off, let me caution that I've made some sweeping changes to how file paths are handled in the core files to enable a new feature. That means I've probably introduced a number of compatibility bugs. That's what the public beta is about - please download it and run your current Fusebox 4, Fusebox 4.1 and Fusebox 5 applications against it! I need your feedback (via the bug tracker preferably).

So, what is this new feature?

Fusebox 5 introduced the ability to run multiple Fusebox applications within a single ColdFusion application so that you could share application and session data (and do things like single signon). This increased the desire in the community for the ability to share circuits, plugins, lexicons and errortemplates between multiple Fusebox applications so that you didn't have to have a separate copy inside every single application.

Fusebox 5.1 allows absolute (or mapped) paths for circuits, plugins, lexicons and errortemplates as well as fully supporting the ability to override the default locations of the parsed/, plugins/, lexicon/ and /errortemplates using fusebox.xml parameter values (you've been able to do this partially since Fusebox 4 but it's never been officially sanctioned!).

I'll be adding documentation about the new features to the documentation wiki over the next week to explain how the absolute / mapped paths work (circuit declarations get a new relative="true|false" attribute but otherwise you should just be able to use a path that begins with "/" to indicate an absolute / mapped path that can be shared between applications).

Fusebox 4.1 introduced the <class> declaration tag as well as the <instantiate> and <invoke> verbs.

Fusebox 5.0 added the <appinit> global fuseaction and the fusebox.appinit.cfm file primarily to support CFC initialization at application startup. That release also added the <argument> child tag for the <invoke> verb to make CFC use easier.

Fusebox 5.1 provides sample lexicons for using ColdSpring and Reactor (thanx to Nathan Strutz and Qasim Rasheed). I hope the community will contribute additional lexicons for dealing with CFCs (I'd like to see a lexicon for Transfer, for example).

Fusebox 5.1 also provides an object-oriented wrapper for the Fusebox attributes "scope" (the struct that holds URL and form variables). The new event variable is a bean that encapsulates attributes and provides getValue() / setValue() / hasValue() methods which will be more natural for OO developers using Fusebox.

Fusebox 5 introduced the idea of custom attributes for the <fusebox>, <circuit>, <class> and <fuseaction> XML tags, using XML namespaces. Fusebox 5.1 extends this to <plugin> declaration tags as well. If you think other tags should also have custom attributes, let me know.

The <relocate> tag gets a couple of new types: moved and javascript. Previously you could specify client (the default, equivalent to ColdFusion's <cflocation> tag) or server (which uses server-side forwarding to a new Servlet request). client generates a 302 Moved Temporarily response but sometimes it is useful to return 301 Moved Permanently instead - moved lets you do that. The javascript option generates JavaScript code to change the location - which is useful if you've already sent HTTP headers, for example.

• attributes scope was not available in an exception handler. (140)
• "Element fusebox is undefined" exception after renaming application. (153)
• Fuseaction permissions is handled incorrectly. Fuseactions without the attribute accidentally inherited it from fuseactions that did! (155)
• Expand Boolean literals that are acceptable - Fusebox 4.1 accepted "yes" and "no" as well and "true" and "false" for attributes that were supposed to be boolean. Fusebox 5 only allowed "true" and "false". Fusebox 5.1 now allows "yes" and "no" as well. (157)
• Sequence of conditional logic in <if> block. Fusebox 5 forced you to have your <true> clause before your <false> clause. Fusebox 5.1 correctly allows either order. (160)
• Include bug. If you included a file using a variable name and said it was optional, you'd still get an exception if it was not present in Fusebox 5. Fusebox 5.1 handles this correctly. (162)
• Paths with . in the folder names fail when using