Conversation with John Sisk: The Switch
6 Dec 2002

I recently had the opportunity to talk with John Sisk, a developer who chose to move from using Struts to using Fusebox for his development projects. Intrigued by the decision, I asked John about his experience for
benefit of those who are faced with similar situations. Here is the interview. - Jeff

Jeff Peters: John, thanks for taking the time to talk with me about your experience. When Bjorn Zreloff from Synthis told me about you at this year's Fusebox conference, I was very interested to hear the whole story.
If you would, start out with a little background on your history as a developer.

John Sisk: Sure. I first became interested in HTML in 1996 when I was living in Ireland, where I grew up. By 1998 I had moved to Idaho, taught myself enough to be able to create fairly decent sites and was hired as a
tele-commuting sub-contractor for a Web Design shop based in Vermont. In 2000 I started work for a local dot com working with JSP on the frontend of a J2EE based Medical Practice Management app. 6 months later the bubble bust and I found myself working with Struts 0.5 on the front-end of a global ecommerce app in an Extreme Programming Java shop. These days I'm one of the many struggling Independent Contractors working from my home-office trying to make ends meet. I've worked with Swing, Cold Fusion, eprise CMS, created logos, site designs and anything else that comes my way. So basically, I'm just your average HTML hack who has to learn whatever is required to get the job done; learn it fast, and learn it well. :)

JP: I don't know about that history being "average", but it certainly has some characteristics with which lot of GrokFusebox friends will empathize. So you made the decision to switch from Java and Struts to ColdFusion and
Fusebox when the bubble burst and you were on your own as an independent contractor?

JS: Yes. That was really the critical point.

JP: Specifically, what drove the decision?

JS: In general Cold Fusion is a more approachable environment for creating the front-end compared to Java. Only recently is tool support for JSP and Struts beginning to catch up with CF Studio. To develop with Java you have to wade through installing the JDK, dealing with classpath issues, installing Tomcat, messing with web.xml, finding the right jars for the various add-ons you need, struggling with ant build files for the
compile-build-deploy cycle etc., etc. All this is fine once you get used to it but spend a month working on some other technology and you have to go through all the pain again just to get set up to do some work. Compare this to install Cold Fusion server, set up a data source and away you go.

JP: So the primary decision was based on rapid development speed?

JS: In part, but not entirely. Maintenance has a lot to do with it as well. I find it much easier to get the essence of the architecture when I first encounter a Fusebox application. FLiP, Fusebox and FuseDocs tell me
all I need to know, from the overview provided by wireframing, prototyping in conjunction with devnotes and the fbx_circuit and fbx_switch files, to the intricate details contained in the fusedocs for each fuse. This is
invaluable to a freelancer allowing one to get up to speed and get to work sooner. Fusebox gives me a structure I can "grok" and once one "gets it" then the method can be applied to applications built using ColdFusion, JSP, PHP, ASP.

JP: So you employ Fusebox in all of those environments?

JS: Even though I'm not an expert in all of the above technologies I'm still in known territory if they are built using Fusebox. This is another boon for a freelancer since it opens up opportunities for more work. When
I'm in the role of architect it gives me more options depending on the customers' hosting situation and the skills of the available contractors.

JP: Do you use Fusebox in a team environment, then? I thought you were mostly a one-man shop.

JS: Whether working solo or on a team, there is a more defined separation of developer roles and responsibilites when using Fusebox compared to Struts. With Struts there is a tendency for the lines between client-side
developer and server-side developer responsibilities to become clouded. As a developer I have many hats but only one head. Fusebox makes it more natural to wear the required hat for the task at hand, but with Struts I
feel as if I'm trying balance more than one hat for each task.

JP: That's a great picture of the differences in the development process. Do you have a real-world example of this that you could share?

JS: Sure.

If I'm in the role of Fusebox client-side developer I know I'm dealing with the dsp_ and lay_ fuses and if I'm in the role of Fusebox server-side developer I know I'm dealing with qry_ and act_ fuses. My feeling is that
switching roles is more intuitive when using Fusebox as it is easier to distinguish the purpose for each fuse and the shift in focus is less jarring to my brain as I'm still dealing with a familiar tag-based coding style.

With Struts client-side development I'm dealing with JSP pages for display and also having to delve into Java to create/maintain the FormBeans.

So, let's imagine we have an existing user authorization process that displays a page containing a form to capture a username and password. When the form is submitted the username and password are validated and
depending on the result the client is directed a welcome page or else redirected back to the loginForm which now shows an error message. This process is so simple that we won't delve into fbx_circuits.cfm, fbx_switch.cfm and struts-config.xml since they perform similar action mapping functions.

In Fusebox we might have:


In Struts we might have:


Let's compare the task of adding an email field:


a. Add the input field for email to dsp_LoginForm.cfm.

b. Assert #email# isn't null or empty and add to the lookup in qry_UserInfo.cfm and let's add a field for email to the UserTable in the database.

c. Add validation for in act_validateUser.cfm.


a. Add the input field for email to LoginForm.jsp.

b. Add a private String email attribute to

c. Add public getter and setter methods for the email attribute to

d. Assert email isn't null or empty validation code in If there are no errors the FormBean will be forwarded to the LoginAction.

e. If we're lucky we can simply add the email to a JDBC lookup in LoginAction and add a field for email to the UserTable in the database .

f. In some applications we might have to make changes to, and heaven help us if this app uses EJB because that would mean changes to,,, then compile, build, deploy the EJB's and bounce the server more than likely.

On most J2EE teams the client-side developer would have nothing to do with EJB but perhaps this example illustrates how it is more difficult to switch focus when developing on a Struts application. For a simple task
like this we either run the risk of messing up on the server-side code or having to co-ordinate with the EJB developer to get our task finished.

JP: That's quite a comparison; thanks. So does Fusebox work better for you than Struts in every aspect of the development cycle?

JS: Not entirely. When it comes to unit testing I feel Struts has more support for unit testing (See ).

JP: Have you checked out my Harness tool and Steve Nelson's new testing tools for Fusebox?

JS: Yes I've used Harness but I don't think Steve has released his new testing tools. I guess what I really miss is the ability to automatically run my tests using Ant ( and Junit ( in my build file. I wonder if it is possible to create a custom task for ant that would do that? I currently use Ant with Webtest ( for running my functional tests and it would be sweet to also run unit tests at the same time.

JP: So what are you doing with your projects now? Any new explorations?

JS: It'll be interesting to apply FLiP and Fusedocs to a Struts app. Having had the chance to use Fusebox, FLiP and Fusedocs I realise that many of the issues I had with Struts were not with the technology itself
but rather with the development process. I'm looking forward to exploring how Adalon can provide a bridge between Fusebox and Struts and also discovering if I can get Adalon to generate a suite of functional and unit
tests for my Fusebox and Struts projects.

JP: Now *that* I'd like to hear about. We often talk about how FLiP and Fusedocs can be applied to non-Fusebox projects, but I there's not much material available from folks who actually do so. Would you be willing to share your experiences on that front as well (once you've been there and done that)?

JS: Sure. I'd be glad to :)

JP: You mentioned earlier the strength of tools for developing in ColdFusion and Fusebox. Adalon is certainly one of the most provocative tools I've seen in a long time.

To get back to something you said earlier, though, do you see the primary advantage of CF/Fusebox to be its strength on the front end? What would you think of building a CF/Fusebox front-end and Java back end? Would you tend toward Struts for the back end?

JS: Yes I would choose CF/Fusebox over JSP/Struts for the front end but I think CF/Fusebox with a Java backend is the best of both worlds. In that situation I would probably use a CFC as the connection point. I'm thinking that a CFC could be used as a Session Facade ( Using a CFC like this would be comfortable territory for a client-side CF developer and also for a server-side Java Developer.

I recommend the following:
if anyone wants an introduction to Java server-side development and obviously
"Fusebox: Developing ColdFusion Applications" and
"Discovering ColdFusion Components (CFC's)"

for anyone moving in from the other direction :)

JP: Great thoughts, John. Thanks again for taking the time to talk with me, and to share your experience with my readers. I look forward to doing it again sometime. Specifically, I'd like to talk about Extreme Programming vs. FLiP, but we'll save that for another time.

If you'd like to see an interview with someone involved in ColdFusion or Fusebox development, let me know--I'll be happy to pursue it and post the results here. -