When is an application too small to bother with an application framework? Andy Jarrett poses that question and offers some thoughts. He was inspired to comment based on a post by Mike Rankin (see Andy's entry for the link) who is leaving Fusebox behind.

Mike criticizes Fusebox for a number of issues which I'll address here but first I'll highlight one sentence of his post:

"All three of the shops had implemented something less or different than the standardized fusebox. FuseDoc was used in only one shop, as were XFAs. None of them were even evaluating fusebox 4 yet."

It never ceases to amaze me how many people say "XYZ didn't work for us" but when you dig into it, you find out that they weren't using XYZ properly. I thought Fusedocs sucked at first but I've used them properly recently and, much to my surprise, they work. I was also resistant to XFAs but those also work. And if you're not using the standardized version of something, you ought to expect problems - standards are there for a reason.

So it's perhaps not surprising that Mike isn't a fan of Fusebox - he hasn't really been using it (it's taken me a couple of years to figure this out too, by the way!).

Now let's move onto his counterclaims about Fusebox benefits:

• Increased productivity - Mike hasn't seen big gains and feels Fusebox inhibits use of some productivity features in Dreamweaver. See his comment about how the development shops he's worked in have been set up - a recipe for failure. As for Dreamweaver, Steve Nelson has an awesome Fusebox Explorer extension for it (and, of course, CFEclipse has Mark Drew's Fusebox plugin too). The productivity benefits come from two main areas: if you use Fusedocs, you can more effectively parallelize the writing of the fuses; maintenance is easier when all your developers know how all your apps are structured (that's why frameworks are worth using).
• Increased code reuse - Mike acknowledges that Fusebox helps but thinks ColdFusion Components make it obsolete because they encourage more reuse. Well, CFCs work very nicely with Fusebox and I'd encourage Fuseboxers to learn to use those two tools together effectively. Using CFCs is no reason to stop using a framework!
• Easier code maintenance - again Mike thinks CFCs make Fusebox obsolete. Let me tell you, your developers will be able to write spaghetti CFCs just as easily as they write spaghetti CFML. In fact, I'm starting to recommend Fuseboxers moving to CFCs look at Tartan as a way of helping them structure their OO model (and use both Fusebox and Tartan together - it's a great combination).
• More productive team development - Mike says all of the development shops he's been in have "All the developers work off of a single development server using CFStudio as their editor." Well, that's just a recipe for disaster whether you're using Fusebox or not! Development shops need to grow up: use localhost development and a shared source code management system (CVS, Subversion); use a shared server for testing integration of parts. Developer Edition is free - use it! CVS and Subversion are free - use them! Stop working in the dark ages!

These are not problems with Fusebox, these are problems with the way the development shops are setup and misconceptions about CFCs being some sort of silver bullet.

He's also had problems using CSS with Fusebox (go read Sandy Clark's articles on accessibility, Fusebox layouts and CSS) and claims - without any substantiation - that "running fusebox in a shared environment can be a problem". Like what?

Finally, he says he'll "probably take a look at Mach-ii (sic), but I've heard that fuseboxers have trouble understanding it." Mach II requires a good grasp of OO which really has nothing to do with whether you're a Fuseboxer or not. Lots of people have trouble understanding Mach II and there's not really a huge amount of documentation around for it. The real issue here is more that the problems Mike cites for moving away from Fusebox will bite him even more in a Mach II environment. Swapping a metric wrench for an imperial wrench won't help one bit if no one knows how to use a wrench in the first place!

To return to your post's title topic, there is a point where even something as lightweight as FB is too much. I think it's important to recognize that fact, because it's along the same lines as the "how to use a wrench" subject. If I've got a nut that I need to remove, but it isn't tight, a wrench is only going to be a PITA, since I can use my fingers to unscrew it far more easily.

The point where FB is too much is pretty low, though it's definitely higher with FB4 than with FB3. I still find myself using FB3 for small apps, because FB4 is simply too much. And for some things, even FB3 is too much, and I use a hacked-up version of FB3 that has a lot of stuff removed (static layout, single circuit, etc.).

I think most of the points made are pretty much without merit and can be attributed to not really giving FB a legitimate chance, but the original tenet isn't baseless by any stretch.

Code structure, the fact that Fusebox implies it, is one major reason for using it, IMHO. I did a two page website (two plain display pages) and used fusebox. Why? Because it is structured, it looks the same as our other sites from a code standpoint, and thanks to things like layouts and CSS everything is broken up into its own small pieces.

Yes, simeon does have a point (in a comment on Andy Jarrett's site) that Contribute can be a great tool for managing sites, i.e. you set up a template and then let others fill in the content. Personally I'd like to see how/if it could be used with a framework like Fusebox where non-programmers could edit the display pages.

I use both Fusebox and Contribute extensively, though never on the same project. They're for different things. Fusebox is a framework for developing applications. Contribute is a CMS for allowing primary sources to contribute to static sites. Not much overlap there, IMO.

Definitely, some sites do not call for a framework. Many sites are not applications, so an application framework is pointless. You must be able to select the right tool for the job.

I agree with both the comments regarding my comment on Andy's site :)

Our new home page <http://www.businesstrans.com> is not an application. Its a static brochure with a contact us form. Anything more complicated than that and I would have had FB4 setup in a heartbeat.

And although I can see where people may feel that fb3 is more light weight than fb4 ( and it may be!) I feel the speed benifits via caching and such make it a superior choice to fb3 in any situation. but as always that IMHO ;)

A bit of a departure from the core topic, but...

Having built a few Contribute sites now, we've found that if you want to integrate it into a project to deliver CMS functionality it's best to separate out the Contribute managed parts of your website and establish a page template and directory structure framework tuned to the requirements of the product.

You can still build the web application-driven parts of your site using whatever framework you favour (FB, Mach-ii etc.); there's no issue with co-existence between Contribute and FB/Mach-ii etc., and in fact it usually makes a lot of sense to handle the Contribute and web app components separately.

Contribute is HTML page template-driven: content editors/approvers browse to, access and edit actual HTML pages (versus code snippets or includes) so it doesn't play very nicely with "pages" that are managed and assembled dynamically via a typical web application framework.

Since pages as actual document URL-access files don't really exist in Mach-ii or Fusebox, it would be very awkward to try and set up a site entirely in either framework and apply a Contribute CMS solution over top of it.

For example, you can set up Contribute to allow users to edit includes; so in theory one could try to set it up by pointing content editors to the actual view files of an MVC-based framework, but explaining the process to non-technical users can be a bit of a stretch. Even worse: getting include-based content to render properly (especially if you're using CSS and including your CSS within the head portion of your document templates) in Contribute's edit mode is not very practical at all. Plus all the paths for hyperlinking documents and embedding images would change.

In fact if you want to keep the rendering of page content in edit mode fairly consistent with how they appear in browse mode, it's best to keep your actual page template code (and include file code) fairly simple (i.e.: no dynamic variables in include paths, keeping conditional scripting logic to a minimum) and to structure your site along more traditional website lines.

When we first started experimenting with Contribute this all seemed very counter-intuitive and a bit of a throw back to old school ways of thinking, but based on how it is designed, and what problems it is trying to solve (editing static content, managing the page publishing process...), it actually makes sense.

If you design your Contribute templates and site structure within the parameters of the technology it's amazing how cool it is for a so-called basic CMS. We've played with the 800 pound gorillas of the CMS world, and compared to many of the enterprise solutions out there Contribute delivers a substantial amount of functionality for a fraction of the price and a miniscule fraction of the headaches ;-)

This is actually one of the main things that bothers e about there not being any documentation for Fusebox (aside from paying $85 for a book sight-unseen, that is frequently out of pint and takes a long time to ship). People who claim to be using Fusebox aren't.

Part of the point of a standard is for it to actually be standardized. Having to open up sample applications and interpret the code in them is not conducive to standardization. Even with documentation, people interpret things badly. Without documentation, they are even worse. Standards need guidelines.

Now, I know Sean thinks I'm beating a dead horse here, but without guidelines, it is impossible for something to be a standard. That's not my only problem with lack of documentation in Fusebox, but it is the main one. :)

PS. Imperial wrench? Is that what they call English units in England?

In addition to the $85 Techspedition book there are several books by Jeff Peters available on the Proton Arts website...

The proof of the pudding is in the eating. It works to keep to what I somehow can fully and easily understand as logical guidelines or standards if we call them that. We have used Fusebox in large enterprises since version 2.0 extended. We have brought in Fusebox developers over 50% into a project successfully. We have instigated Fusebox-Fusedocs methodologies in large organizations and seen developers successfully cross projects and teams. The days of unstructured development in web applications should be well behind us all and in some ways home-grown frameworks/methodologies are even worse than none at all. Bottom line, Fusebox is beneficial to developers to enterprises and I also believe it has helped ColdFusion to be considered as a serious programming environment in larger enterprises. So far we have not been involved in any application development in-house or for clients that is too small for Fusebox.

Sean Corfield wrote: "Let me tell you, your developers will be able to write spaghetti CFCs just as easily as they write spaghetti CFML"

I couldn't agree more and agree with most of the other comments here, especially those about the role of the framework by Barney, Jeff and Mike Brunt.

Just echoing many of the above comments really, but I find that as an app grows in complexity, Fusebox becomes less and less of an 'overhead' and increasingly becomes a welcome friend, maintaining order and structure and importantly, keeping constant the amount of knoweledge one needs to hold in one's head at any given moment when working on the app. Besides, for small apps it's a doddle to re-use an existing Fusebox app, so the 'overhead' accusation is a bit misleading in IMO.

Clearly compartmentalising the request flow is one of the things I like most about Fusebox. I've found that I can work on Fusebox apps even when I'm dog tired, because the explicit request flow combined with the loosely-coupled and cohesive nature of the app's components (especially when well-designed CFCs are used in the model) is such that I only ever need to hold relatively small amounts of 'logic' in my head at any given moment. The app never feels overwhelming in its complexity and because the request flow is 'mapped' and explicit, it's so much easier to divide the application into manageable, bite-size chunks. Procedural apps are so free-form that it takes enormous discipline, commitment, communication (where multiple developers are involved) and advanced knowledge of application structure to be able to build truly loosely coupled & cohesive app that does'nt mix logic and display. Why put yourself through it? Allow a framework to take the strain!

Roger

Rather than 'procedural apps' in my penultimate sentence above, I should have said 'no-framework' apps.

Sean, I believe Mike must be in your DNH list, right?

I really dislike (or even hate) people who argue with hundreds of non-sense reasons to resist something but they haven't ever try it.

Lately, I have an argument (again) with my PHB. And this time is on Fusedoc.

One day, he grabbed me, opened my program, and told me that he didn't like Fusedoc and would rather like tons of <cfparam /> at the top of a page. He stated three reasons: 1) CF will prompt error when people forget to define any parameters if I use <cfparam /> but Fusedoc does not 2) busy people like him could not find any spare time to write document 3) when other developers modify the code without updating the Fusedoc, Fusedoc will be misleading

I didn't argue but was only saying, "yes", "right", "hmm" , etc.

I see the top two factors of DNH person are fit into my boss perfectly: 1) continual insistence that a demonstrable falsehood is true 2) simply don't accept that someone might know more than him

Sigh...

Crab, no, Mike Rankin is not on my DNH list. Like I said (or at least intended to convey), I think most of Mike's opinions of Fusebox stem from development shops that have bad practices in general, don't use Fusebox properly (or don't use standard Fusebox) and also some misconceptions about CFCs.

Mike's latest blog post casts doubts on using getters - they get in the way of his productivity. That's a common reaction to encapsulation techniques but if you're working with folks who don't get it either, you're not going to hear the reasons why encapsulation is a Good Thing(tm).

Mike at least blogs about it to open a dialog. He just needs to get a job in a forward-looking development shop that follows best practices. I bet he'd see the light then...

Sean -

My only experience with fusebox 3/4 is maintaining an application which consisted over +100 folders (+1000 cfm files) which contained the same cfm code in these multiple folders. He had too much duplication of code. I personally use the 'AJAX' method of creating web applcations (not a static site) with the use of external css,js,cfc,cfincludes,and custom tags for presentation layer (view). This allows me to test my model before changing the view. I have multiple custom tags for the controller and the data rendering code for form elements, layers and span tags.

The first thing Mike needs to do is stop listening to Craig Rosenblum rather than people like Sean and Hal. As a general rule, the 'expert' who has to keep looking for a new job should be treated with high levels of skepticism.

A new framework is coming to solve your problems.

provides: - both procedural and OO programing - controller-centric and page-centric development - high compatibility with all MM Products - productive, easy, flexible and *scalable* infrastructure - and so on

Coming soon...

Murat, that sounds just like Fusebox. ;-) Seriously though I'll definitely take a look when it's released.

I've read Craig's posting. It's so full of ignorant comments and incoherent analysis as to be barely worth discussing. He can't even be bothered to write English properly (and what exactly is 'English logic'?). He confuses 'logical process' with 'ease of learning' and whether something is intuitive or not. His writing smacks of insecurity and lack of comprehension. I'm surprised it has generated the amount of discussion it has. For those not acquainted with Craig's razor sharp analysis, here are some exerts:

"I felt this when I had taken my first java class, I could figure out how eventually to do whatever i wanted, but no one would talk in a logical manner"

"What happened to plain old english logic?"

"Simply said, Object Orientation, requires thinking in non-logical ways, that make it hard to work with and hard to communicate about."

"Object Orientaton sounds really fascinating, but experiences like really a waste of time. "

"I am sure there can be a more logical approach to working with Java, without having to use OO language."

"I mean, I've worked in javascript, which has methods and objects, but I've had no problem doing what I needed to get done, because it's coders use logic."

Well, see ya OO suckers! No more illogicality for me. I'm off to that place where logic rules supreme and the people are nice. Planet JavaScript!

We're drifting off topic, but yes, I agree Roger. Craig's posts are a comma-infested series of nonsensical words strung together at random and trying desperately to sound important.

Murat, I'll be happy to kick the tires of a new framework. It would have to be damn good for me to think about switching though! :-D

[clarifying Sean's comment on books] ProtonArts doesn't carry the Techspedition books; my most expensive title there is $39.95.

As for Fusebox documentation, Team Fusebox is continually working on fusebox.org to provide more information and links to all kinds of resources. I'm particularly happy about the new Wegot Widgets reference apps, which will continue to expand over time.

I don't think it's fair to say there's no documentation for Fusebox, though I'll agree the site hasn't been updated very well (yet).

My rant above about Craig's article has been burning a whole in my conscience since I posted it. I don't know why I felt it necessary to ridicule his article or be sarcastic. He was only expressing an opinion. It's not like my English is perfect or that I'm an expert in OO. If you end up stumbling across it Craig. Apologies. It was unworthy of me. Roger

One last point which is key, in my opinion. Yes there are other Frameworks and Methodologies and no doubt there will others, like the one Murat mentions. The big bonus with Fusebox is it's ubiquity of use, I don't see anything else getting close to that for ColdFusion. We do however, again in my opinion, need to get some cohesiveness back into the Fusebox Community. We have lost that and I think Sean's thoughts on IRC have good merit.

Sorry I missed an emphasis in my last post, I meant to say there will be other new ones like the one Murat mentions.

You're right Jeff that there is some Fusebox documentation on the site. However, it seems to be limited to a FAQ. It's a useful FAQ, granted, but seriously, very basic concepts of the framework go completely unmentioned on the website. I realize that you guys have put a lot of work into the framework and that it's difficult for you to put the time into writing documentation. I just don't think that it will be widely adopted without easy-to-access documentation. Plus, without documentation, the people who build the sites will be doing things wrong and ruining the Fusebox name. (Like the guy who built the site that I've been working on. I'm sure he thought he was doing things correctly but he just wasn't.)

Not having documentation just seems like such a horrible business plan to me, even ignoring that it makes people irritated. I know that I keep pushing on this and it's probably irritating but I really don't want all of your work to go to waste.

My $85 book came in today but I haven't taken a look yet. :)

Jennifer, how many times do I have to point you at the documentation that DOES exist at the site? There is a lot more than the FAQ.

http://www.fusebox.org/downloads/index.cfm?method=Fusebox4.grammar

As unfathomable as this may sound, the few people who contribute to the framework and the site actually do have limits on the amount of time they can put in. And to be honest, when people like you simply overlook everything that has already been done and go up in arms about the things they think still need to be done, it actually creates LESS incentive to do additional work, NOT MORE.

However, we have been working further on new versions of the documentation that include information on the 4.1 updates. This should be available in the next week or so.

Whenever Craig's name comes up, I always feel a little thrill. He's my neighbor (or lives nearby, anyway). He's very helpful and very knowledgable about CF, and contributes to the local Yahoo group frequently. He's got strong opinions, and some of them contradict what I believe to be good sense... but, he also has his strengths, and I've seen him put a LOT of work into helping someone with a specific problem (like me ;) ).

But, it's still cool for a local up here in frigid Minneapolis, birthplace of CF, to show up in such illustrious places... even if it IS for infamy.

As far as Fusebox and CSS... What kinda crap is that? I've just deployed an all-CSS2 site done in Fusebox. No issues. As far as Fusebox and productivity... I'm going to go against the grain and proclaim my love for the vocabulary. Since the pages all compile to a FB-specific format anyway, why, oh why, does it matter if I use an IF or an INVOKE tag in my fusebox.xml or circuit.xml files? I think it makes my fuseactions more cohesive, my systems lighter, and my development faster. I can do 70% to 85% of my work within the circuit.xml file and not even HAVE to build include files. In that case... no site is too small for Fusebox 4.1, because I can create an entire MVC app and use hand-coded CF for nothing but the view.

IMO, it's fab!

Laterz, J

Jennifer, I really don't know why you keep harping on about the lack of documentation... Read this:

http://www.fusebox.org/downloads/index.cfm?method=Fusebox4.basicConcepts

From the home page, follow the link to "Learn more about the Fusebox Framework" then read "More about the Fusebox Framework >>"...

I am a complete convert to fusebox. I will cringe if I have to ever write anything without using a framework like fusebox.

Name:
Email Address:
Comments *** Please note that all comments require moderation so it may be some time before your comment posts to this blog! ***
Remember My Information: