Hal's been a father figure for a lot of CFers. His podcasts and blog posts have always been good listening / reading, with a lot of thought-provoking content. He was one of the early evangelists for OO in ColdFusion although more recently he's pulled back from this position and said several times that he feels certain "gurus" are pushing OO too hard and spreading misinformation (although he wouldn't name any names, which kinda created more heat than light and left a general sense of FUD around OO in some parts of the community - like we needed more of that!).
Hal listed half a dozen reasons for his shift from ColdFusion to Ruby on Rails and I'd like to talk more about those reasons in this blog post.
Fusebox 4 was a complete rewrite and not backward compatible. Fusebox 4.1 added some interesting new features and then Fusebox 4.2 (previewed in 2005) never appeared. It was a bit of a dark period for Fusebox with no progress being made and some awkward politics behind the scenes.
In 2006, I was asked to take over the project and I insisted that backward compatibility be maintained, despite another full rewrite. The result was Fusebox 5, but not without yet more political drama, mostly behind the scenes. In order to move forward, Fusebox shifted out of the control of The Fusebox Corporation and under TeraTech's benevolent guidance. I almost had to fork the project to make that happen.
Initially, TeraTech were very proactive and they organized a large survey of developers to find out what they wanted from the framework as well as supervising a complete overhaul of the website. The result of the survey was Fusebox 5.5 - and the no-XML option. The website was a huge improvement but support dwindled before the documentation could be fully overhauled.
I made a minor point release and began planning Fusebox 5.6. I wasn't using Fusebox in any of my projects, however, which made it difficult to push ahead solo, without input and guidance from the project owner, TeraTech. The community were happy with the framework and only a few enhancement requests were coming in.
Adam Haskell expressed interest in becoming more involved so I handed over the role of lead developer to him and he settled in, making small enhancements and starting to plan for the future. Like me, he found little input or guidance from TeraTech and, because of their disinterest, also found it hard to get traction on any real change.
Well, just as I almost forked Fusebox three years ago to get Fusebox 5 released and the framework moving forward, Adam is now on the brink of forking Fusebox to get things moving forward again. When this issue cropped up in 2006, lots of discussions led to the previous project owners agreeing to hand off the project to a new team. Adam has made the same request of TeraTech. I hope they take the same path and allow the framework to move on. Otherwise, what we know as Fusebox today will remain stagnant and the code will resurface under a new name and development will continue anyway, leaving TeraTech with an outdated legacy. That's one of the great things about open source: you can never close it down and you can never lock people into a single vendor.
If you have any opinions on the future of Fusebox, feel free to comment here or on Adam's blog post - and feel free to talk to either of us at CFUnited next week.
I've been using ColdFusion since 2001, back when I worked at Macromedia and my team of Java and C++ developers first encountered CFML in the form of very early builds of what went on to become CFMX (6.0). We were pretty skeptical at first.
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!
See also this book review by Niall O'Doherty.
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).
For more about the future of Fusebox, follow Adam Haskell's blog.
Here's what I said in response:
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?
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!
This site is now running the official Fusebox 5.5 core files.
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!
A scaffolding Quick Start has just been added in SVN (but is not part of the downloads).
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.
Now listed on Charlie Arehart's UGTV (Fusebox 5.5).
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).
Unfortunately, the audio of my session was not recorded - see Elliott's comment below.
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!
Updated 3/8 as eight new entries came in at the last minute!
- 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, SFRSVP 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:
- Simplify. Remove barriers. Make it easier for newbies. Make building applications faster by favoring convention over configuration.
- 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 relative paths. (163 - not fixed in SVN yet!)
I'll cover new features in a future post. Stay tuned!
I'll post more about some of the new features in this point release throughout this week...
Hal Helms just made the following announcement in the latest issue of his Occasional Newsletters (not yet posted to the site at the time of writing, only distributed by email):
In recent years, John Quarto-vonTivadar and I have been the "custodians" of Fusebox. As of today, I'm very happy to announce we're given that trust to TeraTech. Michael Smith, CEO, has been a long advocate and contributor to Fusebox and will now hold the reins. John and I will be helping as time allows, but feel certain Michael will do a great job. Special thanks are also due to Sean Corfield and his team of developers who built Fusebox 5.I'm sure we'll be seeing more details of this transition from both Hal and Michael in due course but I wanted to say that I think this is a good thing for the Fusebox community - TeraTech has the ear of a large number of developers and plenty of resources to help promote, support and drive the open community process that has built up around Fusebox!
Folks are reporting a steady (slow) stream of edge case compatibility bugs which I consider the highest priority for 5.1.
Just wanted to let people know that, yes, I'm listening to the requests and very cognizant of how important compatibility is!
If you want to review the existing open tickets and/or submit new tickets, please visit the Fusebox bug tracker.
As someone who has contributed extensively to Mach II, Model-Glue, Fusebox, ColdSpring and Reactor (phew!), I would like to step up and defend Joe's decisions - he's done a sterling job, sticking to his vision for the framework and has been very clear about what should be in the framework and what should not. As a framework developer myself, I can tell you it's a rocky road. The "community" deluge you with requests for all sorts of features and you have to stand firm and defend your vision. None of the popular frameworks are "kitchen sink" efforts - there are countless feature requests that have been denied by the framework authors.
I've requested enhancements to all these frameworks. Some of those requests have been implemented but most have been denied. Even as lead developer on one of the Mach II releases, some of my suggested enhancements were turned down (and some of the changed Peter implemented in Mach II were reverted as inappropriate for the framework).
When I built Fusebox 5, I was deliberately very conservative about what went into the framework and what didn't. I implemented a few things the community really wanted that I didn't think were great ideas but I also did not implement several things that I thought were great ideas that the community weren't very interested in.
Fusebox 5.1 will be a fairly conservative enhancement release. Fusebox 6 has more scope for adding features but, even so, backward compatibility will be maintained and the addition of features will be strictly controlled but community-driven.
I don't know how community-driven Mach II is. I don't think it has a public bug tracker (Model-Glue, Fusebox, ColdSpring and Reactor all do). I get the impression that Application.cfc support was added for coolness (the other frameworks have taken great pains to remain compatible with CFMX 6.1 and equivalent competing ColdFusion engines).
- svn.fuseboxframework.org - the SVN repository
- trac.fuseboxframework.org - the Trac bugtracker / wiki
- fuseboxframework.org - the Fusebox website
Just like Model-Glue and Reactor, the SVN repo has framework/trunk - the latest development version - framework/branches - bug fixes for prior releases - and framework/tags - various historical releases. The website is also under SVN at website/trunk.
I'll be opening up write access to the website repository shortly to certain volunteers who are helping with documentation.
Many, many thanks to Simeon Bateman for hosting all of this!
p.s. fuseboxframework.com and fuseboxframework.net also exist and should behave the same way.
Fusebox 5 was scheduled to have its general release in mid-July so where is it?
Well, first off we uncovered an interesting edge case bug that could cause corrupted parsed/ files (even in production mode) if a server was hit with a lot of traffic as it was starting up. That was a subtle thread safety issue and I think I have that fixed. My blog has been running "GR0" - General Release candidate zero - for a couple of weeks now without seeing the problem reoccur (prior to that, several folks had alerted me to corrupted parsed/ files on my blog after server restarts).
7/29: Definitely seems to be fixed so the release has begun.
Second, there turns out to be more involved with an official release than I'd originally planned for. Quite a bit of the content on the Fusebox web site needs some degree of tweaking and we have to figure out how to avoid confusing Fusebox users who opt to stay on Fusebox 4: if we update the documentation, where do they find their answers - if we don't update the documentation, what happens for people who do upgrade to Fusebox 5? I did a review of the site and opened about two dozen tickets covering changes to the web site - some of them, quite broad changes.
7/29: the core files and skeleton app are on the site now - the changes to the site will happen over the next couple of weeks.
Third, there are some philosophical issues to address about where Fusebox is and where it is going. There have been a number of different "committees" in charge of Fusebox over the years with varying degrees of success. In fact, Fusebox politics seems to be responsible for driving a number of people away from the community and even the framework itself.
7/29: we're still working through these...
Fusebox 5 has been developed in a much more public, much more community-focused way than any previous release. It's an experiment that has been very successful, in my opinion, helping to create a release that addresses genuine needs that the Fusebox developer community have.
The Fusebox web site went through a major overhaul (last year or perhaps in 2004) but still has some major holes in the content. I think we need more community involvement in contributing content but in order for that to happen, we need a more open approach to developing that content.
Using SVN and Trac, hosted by Simeon Bateman, has allowed Fusebox 5's development process to be much more transparent. Team Fusebox is having discussions about how to build on this transparency and engage the community more, going forward, but ultimately - for now, at least - the final decisions are made by The Fusebox Corporation (Hal Helms and John Quarto-vonTivadar).
I'm posting this to let folks know where things stand because whilst discussions were moving forward quite well a few weeks ago, things have gone rather quiet again.
Posting messages still requires that you join the group. The archives can be read by non-members.
First off, a general shout out to the nearly 300-strong team of Fuseboxers who joined the Fusebox 5 mailing list and risked life and limb testing alpha and beta versions of the core files. Because of their tireless work, backward compatibility with Fusebox 4.1 looks to be extremely good - one of my core goals for this completely rewritten release.
Second, a shout out to "The Fusebox Corporation" who oversee the framework, who asked me to develop this release and who have approved it for general release: Hal Helms and John Quarto-von-Tivadar.
And now some specific names who've helped - possibly in ways they didn't realize!
Barney Boisvert for comparative benchmarking and a number of excellent on-list (and off-list) suggestions; Ben Koshy, Christian Ready, Jason Daiger and Phillip Duba for being especially active contributors on the mailing list; Byron Raines, David Sparkman, Erki Esken, Jordan Clark, Qasim Rasheed, Mike Ritchie and Mike Tangorre for logging tickets directly to save me the trouble; David Epler and Ian Buzer for testing on BlueDragon and Railo; John Paul Ashenfelter and Sandy Clark for the DTDs; Mike Ritchie (again) for tireless assistance on Fusebox 4.1 compatibility issues; Nathan Strutz for a variety of contributions, including some custom verbs in the skeleton application; Patrick McElhaney for suggesting the core grammar should be implemented at custom lexicons; Roger Lancefield for being brave enough to run his public blog on a beta release; Stephen Judd for his Fusebox Reloader Firefox plugin; Terry Schmitt for working hard on isolating some thread-safety issues in the core files in development mode.
Don't feel left out if you were active on the mailing list but didn't get a specific shout out - I appreciate everyone's efforts here!
Thank you everyone - you've helped make Fusebox 5 an exciting release!
The testers focused on Fusebox 4.1 compatibility during the Alpha testing period and have been focusing on the new features during the Beta testing period. Big thanx to everyone who has taken the time to run their existing applications and log bugs!
I just updated my site to run build 200 (Beta 2 was build 192) to continue the testing.
Updated to build 205 after refactoring most of the debug / trace code and consolidating all the reserved request scope variables.
You can see what's new / fixed in Beta 2 by looking at the Beta 2 tickets on the Trac site as well as reading the updated documentation (which currently has notes on what's coming in Beta 2 - within the next day the docs will be updated some more to reflect Beta 2 itself).
I'm continuing to work on performance in development mode but we're getting closer and closer to what will be the general release of Fusebox 5.
Check out the updated documentation and join the Fusebox 5 mailing list if you want to participate in beta testing - over 200 people have already signed up, many of whom are already running Fusebox 5 in production!
Please help me make this the best release of Fusebox so far!
The last feature to be added was the ability to specify parameters for <do> and <include> verbs:
<parameter name="title" value="Home Page"/>
</do>
I'm very pleased to have reached this milestone because it means that, between now and CFUNITED, I can focus on bug fixes, performance and documentation.
I have one or two bugs to tidy up and some additional documentation to produce this week and then I will release Fusebox 5 Beta 1 to the Fusebox 5 mailing list this weekend for testing.
That build did indeed go out as Alpha 3 (5.0.0.A.3.0) and this site has been updated to the actual shipped build. Two weeks to Beta!
As the final part of testing what is almost certainly going to be the Alpha 3 build, I just upgraded my site to use build 5.0.0.A.3.X. If no problems arise, this will become the official build released to the mailing list.
Alpha 3 will be released to the Fusebox 5 mailing list in the next few days (the target is actually tomorrow but I have a pretty full day so it may be Sunday instead).
All of the changes between Alpha 2 and Alpha 3 are visible on the Fusebox 5 Trac site (courtesy of Simeon Bateman - many thanks!).
Whilst it's open, I want folks to join the Fusebox 5 mailing list if they want to get the URL so that they can be part of the discussions around features and bugs. Besides, the only way you can get on the Alpha / Beta program for Fusebox 5 is to join that list so you wouldn't have bugs to report without being on the list! :)
Again, if you want to get involved, please subscribe to the Fusebox 5 mailing list.
Stephen Judd announced on that list last night that he will update his Fusebox reloader extension for Firefox to support the new load/parse URL options that Fusebox 5 supports - thank you Stephen!
