Click here to close now.




















Welcome!

You will be redirected in 30 seconds or close now.

ColdFusion Authors: Yakov Fain, Maureen O'Gara, Nancy Y. Nee, Tad Anderson, Daniel Kaar

Related Topics: ColdFusion

ColdFusion: Article

A Fusebox How-To

A Fusebox How-To

I recently received an inquiry from a developer about my Guru-on-Call service (www.TeamAllaire.com/hal). He requested help in identifying the fuses he would need for his application.

After reading my first two Fusebox articles in last year's CFDJ (Vol. 1, issues 3 and 4), he wrote, "I understand what you are explaining but implementing it is a little harder than I thought."

I wonder if others may be having this same problem - understanding the theory but a little hung up on the details. In this article I'm going to walk through developing a Fusebox application so you can see the theory put into reality. I'm assuming you've already read enough about the Fusebox methodology to understand how it works. If you need a refresher on this, check out the back issues of CFDJ online for the two articles I wrote with Steve Nelson and Gabe Roffman, or see the sidebar for a quick recap of Fusebox rules.

I find the hardest part of a large Web application is not the actual coding - thanks to Fusebox - but determining what the actual job requirements are. I'm not alone in this; it's a common complaint of developers. Over the years I've tried, in a variety of ways, to nail down customers so they wouldn't keep changing their minds. One day it occurred to me that the reason customers wouldn't stop making changes is because they couldn't. They couldn't tell me the "requirements" until they saw them reflected in the application.

If this is true, it's my job to make sure the users can see the application - and prod, poke and punch it - until they're sure that what they see is what they want. Only then do I begin the actual coding. I place great emphasis on a simulated application that looks like the real thing to the users. When they click buttons, things happen. Links are live. Forms accept inputs. And while it looks like a real application, it's a completely different matter under the hood. There's no database hooked up to the application. There are no persistent variables, perhaps no variables at all. Any use of code (CFML or otherwise) is there only to present a convincing simulation. We haven't begun coding yet; we're doing this because experience has shown that it's the only way to find out what kind of application we should build.

This methodology takes some of the stress off skilled programmers. In practice I find that over half the work required in developing an application can be done without involving programmers - a welcome discovery as they're hard to find. This prototype is handled by people skilled in interface design and graphical arts who create essentially static Web pages that mimic their real counterparts.

It's during this process that questions, comments and concerns surface. I needed a way to capture and contain this information in a central location where all those involved in the development of the application could communicate and contribute. Over time we've developed a method that effectively lets us define and refine what the application should be, do and look like.

This method relies on some ColdFusion code running alongside the designer's prototype work. Since designers typically aren't coders, we ask only that they save the Web files with a .cfm extension and append the following code onto each of these pages:

<cfinclude template="devnotes/index.cfm"> At runtime this code calls a small Fusebox application at the bottom of the page that produces something similar to Figure 1.

This allows us to preserve the history of the development of the application while providing a map for its continued evolution. I'm going to show you how I approached building this Fusebox-based mini-app, which I hope will make the process of creating a Fusebox application clearer than a mere reading of the rules.

I start off application development - even of small apps - by creating "use cases" to identify requirements for the application. These are natural language statements that require no technical background and are ideal for communicating between client and developer. At this point, use cases form the basis of our understanding of what the application should do. A sample use case might look like this:

"User should be able to log onto the system and be validated as either a user or administrator."

While use cases are wonderful for determining requirements for the application and for communicating with clients, they're too general to be of much use to developers. For this I rely on the skill of interface designers who understand how to translate the client's requirements into actual pages that show how they'll do it. This is the prototype I spoke of above. It's an iterative process; at each step we hopefully come closer to finding exactly what the client needs. Once all participants have agreed that the application is fully defined, we arrive at a prototype freeze. Now it's my job to match the use cases (as interpreted in the prototype) with one or more fuseactions.

Fuseactions, remember, define what the application is actively involved in; at any point there's only one fuseaction operating. A fuseaction is a request for action that's sent only to the fusebox (usually named index.cfm). It's fundamental to Fusebox that all requests for action go through the fusebox, not to individual fuses. Without this we're on a slippery slope where one fuse calls another and that fuse calls yet another until we end up with a tangled mess of intricate dependencies between fuses, defeating our goals of readability and reusability.

Once the request for action (the fuseaction) is sent to the fusebox, the fusebox calls on fuses to carry out the action. So the development process goes like this: use case ...> prototype ...> fuseaction(s) ...> fuse(s). By creating a table that shows the associations between use cases, fuses and fuseactions, I can see how complete my application architecture is. Table 1 is the table for this application.

As Dennis Miller says, "I don't want to get off on a rant here...," but let me say a word about naming fuses. The Fusebox.org site suggests naming prefixes for fuses based on the fuse's job: dsp_fusename for display-type fuses and so forth. I've heard heated debate over the "correct" naming scheme and I think this misses the key point - Fusebox is a development methodology, not a naming convention. My position is, if you find the naming scheme to be helpful, by all means use it. If you have another naming scheme - possibly already a standard within your company - then use that. The power of Fusebox doesn't depend on how a fuse is named, but on its clarity, conciseness and precision.

This method relies on some ColdFusion code running alongside the designer's prototype work. Since designers typically aren't coders, we ask only that they save the Web files with a .cfm extension and append the following code onto each of these pages:

<cfinclude template="devnotes/index.cfm">

At runtime this code calls a small Fusebox application at the bottom of the page that produces something similar to Figure 1.

This allows us to preserve the history of the development of the application while providing a map for its continued evolution. I'm going to show you how I approached building this Fusebox-based mini-app, which I hope will make the process of creating a Fusebox application clearer than a mere reading of the rules.

I start off application development - even of small apps - by creating "use cases" to identify requirements for the application. These are natural language statements that require no technical background and are ideal for communicating between client and developer. At this point, use cases form the basis of our understanding of what the application should do. A sample use case might look like this:

"User should be able to log onto the system and be validated as either a user or administrator."

While use cases are wonderful for determining requirements for the application and for communicating with clients, they're too general to be of much use to developers. For this I rely on the skill of interface designers who understand how to translate the client's requirements into actual pages that show how they'll do it. This is the prototype I spoke of above. It's an iterative process; at each step we hopefully come closer to finding exactly what the client needs. Once all participants have agreed that the application is fully defined, we arrive at a prototype freeze. Now it's my job to match the use cases (as interpreted in the prototype) with one or more fuseactions.

Fuseactions, remember, define what the application is actively involved in; at any point there's only one fuseaction operating. A fuseaction is a request for action that's sent only to the fusebox (usually named index.cfm). It's fundamental to Fusebox that all requests for action go through the fusebox, not to individual fuses. Without this we're on a slippery slope where one fuse calls another and that fuse calls yet another until we end up with a tangled mess of intricate dependencies between fuses, defeating our goals of readability and reusability.

Once the request for action (the fuseaction) is sent to the fusebox, the fusebox calls on fuses to carry out the action. So the development process goes like this: use case ...> prototype ...> fuseaction(s) ...> fuse(s). By creating a table that shows the associations between use cases, fuses and fuseactions, I can see how complete my application architecture is. Table 1 is the table for this application.

As Dennis Miller says, "I don't want to get off on a rant here...," but let me say a word about naming fuses. The Fusebox.org site suggests naming prefixes for fuses based on the fuse's job: dsp_fusename for display-type fuses and so forth. I've heard heated debate over the "correct" naming scheme and I think this misses the key point - Fusebox is a development methodology, not a naming convention. My position is, if you find the naming scheme to be helpful, by all means use it. If you have another naming scheme - possibly already a standard within your company - then use that. The power of Fusebox doesn't depend on how a fuse is named, but on its clarity, conciseness and precision.

More Stories By Hal Helms

Hal Helms is a well-known speaker/writer/strategist on software development issues. He holds training sessions on Java, ColdFusion, and software development processes. He authors a popular monthly newsletter series. For more information, contact him at hal (at) halhelms.com or see his website, www.halhelms.com.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


@ThingsExpo Stories
SYS-CON Events announced today that HPM Networks will exhibit at the 17th International Cloud Expo®, which will take place on November 3–5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. For 20 years, HPM Networks has been integrating technology solutions that solve complex business challenges. HPM Networks has designed solutions for both SMB and enterprise customers throughout the San Francisco Bay Area.
For IoT to grow as quickly as analyst firms’ project, a lot is going to fall on developers to quickly bring applications to market. But the lack of a standard development platform threatens to slow growth and make application development more time consuming and costly, much like we’ve seen in the mobile space. In his session at @ThingsExpo, Mike Weiner, Product Manager of the Omega DevCloud with KORE Telematics Inc., discussed the evolving requirements for developers as IoT matures and conducted a live demonstration of how quickly application development can happen when the need to comply wit...
The Internet of Everything (IoE) brings together people, process, data and things to make networked connections more relevant and valuable than ever before – transforming information into knowledge and knowledge into wisdom. IoE creates new capabilities, richer experiences, and unprecedented opportunities to improve business and government operations, decision making and mission support capabilities.
Explosive growth in connected devices. Enormous amounts of data for collection and analysis. Critical use of data for split-second decision making and actionable information. All three are factors in making the Internet of Things a reality. Yet, any one factor would have an IT organization pondering its infrastructure strategy. How should your organization enhance its IT framework to enable an Internet of Things implementation? In his session at @ThingsExpo, James Kirkland, Red Hat's Chief Architect for the Internet of Things and Intelligent Systems, described how to revolutionize your archit...
MuleSoft has announced the findings of its 2015 Connectivity Benchmark Report on the adoption and business impact of APIs. The findings suggest traditional businesses are quickly evolving into "composable enterprises" built out of hundreds of connected software services, applications and devices. Most are embracing the Internet of Things (IoT) and microservices technologies like Docker. A majority are integrating wearables, like smart watches, and more than half plan to generate revenue with APIs within the next year.
Growth hacking is common for startups to make unheard-of progress in building their business. Career Hacks can help Geek Girls and those who support them (yes, that's you too, Dad!) to excel in this typically male-dominated world. Get ready to learn the facts: Is there a bias against women in the tech / developer communities? Why are women 50% of the workforce, but hold only 24% of the STEM or IT positions? Some beginnings of what to do about it! In her Opening Keynote at 16th Cloud Expo, Sandy Carter, IBM General Manager Cloud Ecosystem and Developers, and a Social Business Evangelist, d...
In his keynote at 16th Cloud Expo, Rodney Rogers, CEO of Virtustream, discussed the evolution of the company from inception to its recent acquisition by EMC – including personal insights, lessons learned (and some WTF moments) along the way. Learn how Virtustream’s unique approach of combining the economics and elasticity of the consumer cloud model with proper performance, application automation and security into a platform became a breakout success with enterprise customers and a natural fit for the EMC Federation.
The Internet of Things is not only adding billions of sensors and billions of terabytes to the Internet. It is also forcing a fundamental change in the way we envision Information Technology. For the first time, more data is being created by devices at the edge of the Internet rather than from centralized systems. What does this mean for today's IT professional? In this Power Panel at @ThingsExpo, moderated by Conference Chair Roger Strukhoff, panelists addressed this very serious issue of profound change in the industry.
Discussions about cloud computing are evolving into discussions about enterprise IT in general. As enterprises increasingly migrate toward their own unique clouds, new issues such as the use of containers and microservices emerge to keep things interesting. In this Power Panel at 16th Cloud Expo, moderated by Conference Chair Roger Strukhoff, panelists addressed the state of cloud computing today, and what enterprise IT professionals need to know about how the latest topics and trends affect their organization.
It is one thing to build single industrial IoT applications, but what will it take to build the Smart Cities and truly society-changing applications of the future? The technology won’t be the problem, it will be the number of parties that need to work together and be aligned in their motivation to succeed. In his session at @ThingsExpo, Jason Mondanaro, Director, Product Management at Metanga, discussed how you can plan to cooperate, partner, and form lasting all-star teams to change the world and it starts with business models and monetization strategies.
Converging digital disruptions is creating a major sea change - Cisco calls this the Internet of Everything (IoE). IoE is the network connection of People, Process, Data and Things, fueled by Cloud, Mobile, Social, Analytics and Security, and it represents a $19Trillion value-at-stake over the next 10 years. In her keynote at @ThingsExpo, Manjula Talreja, VP of Cisco Consulting Services, discussed IoE and the enormous opportunities it provides to public and private firms alike. She will share what businesses must do to thrive in the IoE economy, citing examples from several industry sectors.
There will be 150 billion connected devices by 2020. New digital businesses have already disrupted value chains across every industry. APIs are at the center of the digital business. You need to understand what assets you have that can be exposed digitally, what their digital value chain is, and how to create an effective business model around that value chain to compete in this economy. No enterprise can be complacent and not engage in the digital economy. Learn how to be the disruptor and not the disruptee.
Akana has released Envision, an enhanced API analytics platform that helps enterprises mine critical insights across their digital eco-systems, understand their customers and partners and offer value-added personalized services. “In today’s digital economy, data-driven insights are proving to be a key differentiator for businesses. Understanding the data that is being tunneled through their APIs and how it can be used to optimize their business and operations is of paramount importance,” said Alistair Farquharson, CTO of Akana.
Business as usual for IT is evolving into a "Make or Buy" decision on a service-by-service conversation with input from the LOBs. How does your organization move forward with cloud? In his general session at 16th Cloud Expo, Paul Maravei, Regional Sales Manager, Hybrid Cloud and Managed Services at Cisco, discusses how Cisco and its partners offer a market-leading portfolio and ecosystem of cloud infrastructure and application services that allow you to uniquely and securely combine cloud business applications and services across multiple cloud delivery models.
The enterprise market will drive IoT device adoption over the next five years. In his session at @ThingsExpo, John Greenough, an analyst at BI Intelligence, division of Business Insider, analyzed how companies will adopt IoT products and the associated cost of adopting those products. John Greenough is the lead analyst covering the Internet of Things for BI Intelligence- Business Insider’s paid research service. Numerous IoT companies have cited his analysis of the IoT. Prior to joining BI Intelligence, he worked analyzing bank technology for Corporate Insight and The Clearing House Payment...
"Optimal Design is a technology integration and product development firm that specializes in connecting devices to the cloud," stated Joe Wascow, Co-Founder & CMO of Optimal Design, in this SYS-CON.tv interview at @ThingsExpo, held June 9-11, 2015, at the Javits Center in New York City.
SYS-CON Events announced today that CommVault has been named “Bronze Sponsor” of SYS-CON's 17th International Cloud Expo®, which will take place on November 3–5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. A singular vision – a belief in a better way to address current and future data management needs – guides CommVault in the development of Singular Information Management® solutions for high-performance data protection, universal availability and simplified management of data on complex storage networks. CommVault's exclusive single-platform architecture gives companies unp...
Electric Cloud and Arynga have announced a product integration partnership that will bring Continuous Delivery solutions to the automotive Internet-of-Things (IoT) market. The joint solution will help automotive manufacturers, OEMs and system integrators adopt DevOps automation and Continuous Delivery practices that reduce software build and release cycle times within the complex and specific parameters of embedded and IoT software systems.
"ciqada is a combined platform of hardware modules and server products that lets people take their existing devices or new devices and lets them be accessible over the Internet for their users," noted Geoff Engelstein of ciqada, a division of Mars International, in this SYS-CON.tv interview at @ThingsExpo, held June 9-11, 2015, at the Javits Center in New York City.
Internet of Things is moving from being a hype to a reality. Experts estimate that internet connected cars will grow to 152 million, while over 100 million internet connected wireless light bulbs and lamps will be operational by 2020. These and many other intriguing statistics highlight the importance of Internet powered devices and how market penetration is going to multiply many times over in the next few years.