FUSEBOX CONFERENCE

CF Conf Central


August 30th - September 1st, 2003 Las Vegas, NV
Sean's Blog Report on Fusebox 2003 Conference September 01, 2003 Fusebox / Mach II Conference - Report Coming Soon A full report will be posted in the next few days as I catch up on my notes. Sorry I didn't blog live from the conference but the room only had WebTV instead of a proper Internet connection so I wasn't going to pay $10 a day for that! In summary, it was a great conference - really good to hear about Fusebox 4 and Mach II - really good to meet all the 'names' and talk turkey about frameworks etc. I've posted some more Mach II bug fixes and an updated MachWiki sample application. Ben Edwards is busy integrating these code changes along with several other fixes and enhancements. Right now, I think MachWiki relies on some core file changes that haven't been made public yet - a new code drop is coming soon - and I'm in the process of making a slew of other changes. I'll blog more on this once everything has stabilized. September 02, 2003 Introduction to Fusebox 4 (Fusebox Conference) Hal gave a good overview of Fusebox 4, starting out by saying that although acceptance of Fusebox has increased over the last two years there had been no updates to the framework. He outlined the big changes (XML configuration files, plugins, content variables - instead of layouts, code parsing) but also said that many things don't change: fuseactions, circuits, fuses. Hal explained how the XML to CFML compilation mechanism (which will also be able to target PHP etc) is the key to the performance improvements in FB4. Instead of the core files dynamically pulling together all the files needed to satisfy a request as happens in FB3, the XML in FB4 is translated to a single include file for each fuseaction that contains all the code needed to execute that fuseaction. The result is much less processing and much more speed. Then he walked through the process of building a typical FB4 app: write the Fusedocs (same as for FB3), write the fuses (same as for FB3), write test harnesses (same), write `circuit.xml` for each circuit (new in FB4, replaces the `fbx_switch.cfm` files), write `fusebox.xml` for the application (new in FB4, replaces the `fbx_settings.cfm` and `fbx_circuits.cfm` files). Migration from FB3 shouldn't be too hard and it brings many benefits, including better performance, better extensibility (plugins), more flexible layout (content variables), multiple fuseactions per request (like FuseQ which FB4 totally obsoletes)... Fusebox Conference - Overview I figured I'd do an overview first and then blog detailed entries about the sessions. Saturday night was the foosball ('Fuseball') tournament and networking evening. I didn't play (too wary of RSI) but it was good to hang out and chat with folks I'd only 'met' through email before. A fun 'Fusetag' game was organized for the weekend too - everyone got a sheet with everyone's name and a CF / Fusebox tag next to each; you also got name tags with your own <tag> on; the goal was to get as many folks to initial your sheet as possible. A good way to encourage networking! Sunday was Fusebox 4 day. Hal gave a great overview across two sessions, followed by John Q talking about plugins (another two sessions). After lunch, Sandy Clark gave two sessions on layouts and writing standards compliant, accessible code (excellent stuff!). Then a session from Jeff Peters on Fusedocs followed by a session from Charlie Arehart about Blue Dragon (and he mostly managed to stay out of 'sales' mode!). After dinner, Michael Smith ran an interactive workshop on FLiP then we had an open Q&A session - the Fusepanel. Monday morning was Mach II with a three-hour introduction to the architecture and framework, along with some live coding demos. The highlights of the conference for me were Sandy's sessions on layouts (and, particularly, standards and accessibility) and the Fusepanel (because it was so interesting to hear from, and interact with, the Fusebox community for really the first time for me). It was also great to chat with Ben Edwards about Mach II and discuss possible enhancements and bug fixes. I'll write up all the sessions, in order, over the next couple of days. September 04, 2003 Fusebox 4 Layouts (Fusebox Conference) For me, this was probably the best session: not only did it cover the whole layout mechanism in detail but it also talked about standards compliance and accessibility. Very important topics! Sandy Clark started out with an overview of layouts in general and drew a distinction between the application level (global navigation, site consistency) and the circuit level (side navigation etc). She showed how these can be implemented in Fusebox 4: application level layout can use global fuseactions (preprocess / postprocess) that invoke fuseactions in a layout circuit; circuit level layout can either use a plugin (which must check which circuit is active) or a circuit's prefuseaction (which requires clearly separating fuseactions into public and private circuits). Her presentation was very clear, with good code examples as well as good screen examples to illustrate each type of layout. In the second half of her session, she focused on accessibility and standards compliance and used a free 'screen reader' application to dramatic effect to show how a site that uses HTML for layout (tables) instead of just for structural markup can be almost impossible to navigate for disabled users. She said we should use XHTML and CSS to separate structural markup from positioning and visual styling - to assist the "15-30% of the general population that have functional limtations that can affect their ability to use technology products" (from the Internet Society briefing on design). Having gotten our attention with this, she showed how Fusebox 4's 'content variables' help us keep content separate from presentation, allowing us to produce accessible websites much more easily. As a final example, Sandy worked through the entire process of implementing a breadcrumb trail navigation element in Fusebox 4. All in all, a high-content, high-value presentation and the highlight of the conference for me! Fusebox 4 Plugins (Fusebox Conference) One of the problems that has plagued Fusebox in the past is that people tended to modify the core files of the framework to add various extensions like security etc. This undermines the whole purpose of a framework of course - a framework is supposed to provide a standard way of doing things! Fusebox 4 comes to the rescue by providing a plugin framework so that you can add your own code to the framework without touching the core files! John Quarto-Tividar talked about how FB4 plugins work and gave some really good guidelines as to what should be a plugin: Is your extension applicable to all Fusebox applications? If so, consider submitting it for inclusion in the framework. Very few extensions are likely to fall into this category! Is your extension applicable just to a single action or maybe a few actions? If so, you can just implement it as a fuseaction and invoke it from the XML control file `<do action="...">`. Is your extension somewhere in between - applicable to a class of applications? If so, it's a good candidate for a plugin. Security is a good example of a class of plugins. John also emphasized that each plugin should be atomic and cohesive, i.e., it should do a single job and do it well, independent of other code. He demonstrated a security plugin based on a list of access keys in the context of an office building and securing access to different rooms. It was an engaging demo and clearly showed the benefits of being able to easily extend the framework. It should be noted that in Fusebox 4, each plugin is somewhat like a fuse - a simple `.cfm` file - that is called at a certain point in the processing of a fuseaction request. By contrast, in Mach II a plugin is a CFC which extends the framework's base `Plugin.cfc` and overrides the necessary methods - all of which are called by the framework for every plugin object registered. I prefer Mach II's approach but for folks comfortable with earlier Fusebox versions, the simple procedural approach of Fusebox 4 will be very natural. September 06, 2003 Fusedocs (Fusebox Conference) Fusedocs are an XML-based documentation standard for fuses that several automated tools have grown up around. Jeff Peters talked about how and why you should use them when writing Fusebox applications. The basic idea is that, before you start coding but after you have identified all your fuses, you write a structured comment at the top of each fuse file that explains to the programmer exactly what they need to know to write the code of the fuse - the "responsibilities" of the fuse (written in the first person singular - "I retrieve all the users in the system"), the properties of the fuse and the input / output parameters of the fuse (i.e., which variables it expects to be set on entry and what it sets on exit). As Jeff points out, this level of documentation "takes practice and discipline" but, as Steve Nelson has shown with his SecretAgents.com company, if you follow the process well enough then you can hand the Fusedocs out to 100 random programmers and have all your fuses written in parallel. Steve reckons that his 'agents' write a fuse in around ten minutes for the most part but I can't help feeling it would take at least that long to write a decent Fusedoc so it's a tradeoff between the benefits of distributed "Software Done In A Day" (the SecretAgents.com tag line) and getting much of the code written in the time it would take to write the Fusedocs in the first place! Personally, I feel that by the time you've broken your application down into such small bite-size pieces as fuses, you might as well just write the code and put a simple comment at the head of each file... but... well... there is also the tempting benefits of many of the Fusedocs related tools, such as the one that generates CF test harnesses for your fuses based solely on the Fusedocs. So I'm in two minds about that, when it comes to Fusebox. Of course, I mostly program in an OO style, using MVC as the basis for my applications - hence my interest in and enthusiasm for Mach II - so Fusedocs in their current form simply don't apply to what I do. If a similar system grows up around Mach II, I'll have to re-evaluate whether I'd find it valuable. I lean much more toward 'self-documenting' code with well-chosen names for components and methods and variables - if it reads like English it can be its own documentation and it never gets out of sync with the code (because it is the code). September 12, 2003 Fusebox Conference Again I got somewhat overtaken by work and then I was off sick for a couple of days so I didn't get around to blogging the rest of the sessions. Sorry. I'd got as far as Jeff Peters' "Fusedocs" session so next up was Charlie Arehart of New Atlanta touting the upcoming BlueDragon 3.1 release as an alternative platform for Fusebox 4. BlueDragon 3.1 will add the XML functions (already present in CFMX) that are necessary to support FB4. After dinner, Michael Smith ran an interactive workshop on FLiP - the Fusebox Lifecycle Process. It was interesting to hear people talking about what didn't work for them in the real world and hearing suggestions for how to overcome these problems. That's always more productive than simply hearing why something is so great! I sat at the back and watched, mostly because I'm not very familiar with FLiP beyond what I've read in Nat & Jeff's book (about Fusebox 3, which includes a chapter on FLiP). After that, it was the Fusepanel, which I was honored to be asked to join. The audience asked a lot of questions ranging from very Fusebox-related issues (which I deferred to Sandy Clark, Michael Smith and Steve Nelson) to more general design-related issues (where I found myself more in agreement with Steve than I would have expected!). There were also some specific Macromedia-related questions for me... I talked a little about how the product team had made a specific effort to optimize CFMX 6.1 for Fusebox applications (both existing Fusebox 3 applications and the then-nascent Fusebox 4 and Fusebox MX sample applications). I also encouraged the audience to submit articles about Fusebox to the Developer Center since Fusebox was currently unrepresented on macromedia.com. I also acknowledged that we're using Mach II on some projects at Macromedia but couldn't say much about those yet... watch this space! September 14, 2003 Mach II - Fusebox Conference Monday morning at the conference was dedicated to Mach II. Hal Helms and Ben Edwards presented a three hour session on the new framework with theory as well as practical applications. Hal started with a background on why object-orientation is important and why, even if you're not planning to jump into OO today, you should be thinking about learning OO techniques. He focused on encapsulation as the most important of OO's PIE techniques (Polymorphism, Inheritance and Encapsulation). He also explained the concepts of tight cohesion and loose coupling (cohesion means a class does one job well which is a good thing; coupling means the dependence between classes which is a bad thing). It was a very compelling introduction to OO and I was pleased to hear him focus so heavily on good practice in design rather than any specific nuts and bolts issues. He quoted Buckminster Fuller at one point on the importance of elegance in design - if it isn't beautiful, it's wrong. He also focused on why inheritance should be used with caution: novices see inheritance "everywhere" and overuse it; composition is more common and more flexible (and more likely to be the correct design choice). One of the hardest parts of moving to OO is learning to develop a good object model. Hal said you need to think in terms telling a story with a coherent narrative - write down the way your system works (at a business level). This will help you identify good candidates for classes (the 'nouns' in the story - and the methods on those classes are the 'verbs' in the story). In more formal OO design work, this story telling would be called Use Case Analysis. Finally, on to the framework itself where they kept the nuts and bolts to a minimum except where they needed to explain code structure to support their examples. If you want more information, you can always read the Mach II website and my Mach II resources page. The framework is based on Implicit Invocation which can be a bit of a hard concept to swallow so I liked Hal's simple analogy: a website announces an event and people sign up for it (register interest in it) - when the event occurs, they all get notified and can process the information however they want. It was very gratifying for me to see the 'buzz' that Mach II created amongst the Fuseboxers at the conference, with many keen to learn more about OO and expand their skills 'toolbox'. We should see a near-final code drop of the core files pretty soon. Source Courtesy of Sean's Blog If you have any questions, contact [email protected] \| HOME \| DIRECTIONS \| HOTEL \| SCHEDULE \| \| TOPICS \| SPEAKERS \| REGISTER \| CF CONF CENTRAL \|