Why I don't like Hub-and-Spoke
In my recent review of Luis Majano's ColdBox presentation, I mentioned that I don't like Hub-and-spoke. I was asked for clarification on why Hub-and-Spoke doesn't work for me.
I should first start off by explaining what I mean by Hub-and-spoke (a term for which several definitions exist). By this, I mean the technique by which all requests go through a single file. All of the major ColdFusion frameworks that I have seen (Fusebox, Mach-II, Model Glue, ColdBox) use Hub-and-Spoke. Such an approach certainly makes Front Controller functionality easy. In fact, much of what those frameworks do would be impossible without it (at least prior to the introduction of onMissingTemplate in ColdFusion 8).
In a ColdFusion environment, Hub-and-Spoke generally means that all page requests are routed through index.cfm. Here are some examples of hub-and-Spoke URLs:
- index.cfm?fusection=home.display
- index.cfm/go/features/
- /index.cfm?mode=entry&entry=FA2A2669-E081-2BAC-6979D3478AEDC219
- /go/fusebox-downloads
The last example leaves off the index.cfm, but it is still being used. As I said, this is helpful for a front controller, but can have some drawbacks. For my situations (which I will discuss as we go), these outweigh the benefits.
Messy URLS
If you look at Hub-and-Spoke sites, you will see that their URLs don't look as "clean" as sites that don't use Hub-and-Spoke. For example, Great Biz Tools uses Mach-II and MySpace was originally built with Fuxebox. My own site, on the other hand, was built without Hub-and-Spoke (except for this blog).
It used to be that this structure could affect search engine rankings. That may not be the case now, but I still prefer a cleaner looking URL. This is, admittedly, a minor issue. It is more philosophical than anything: I just don't think URL structure should be dictated by framework choice.
Traffic Reporting
Most traffic statistics software report traffic at least in part by page viewed. If you use Hub-and-Spoke, then it will report all views as being for "index.cfm". It is possible for some software packages to change the reporting so that it uses the URL variables that you use to indicate a page but that isn't always possible with every package and certainly adds extra configuration work where it is possible.
Error Reporting
ColdFusion's built in error reporting and slow-running page reports indicate which page is running slowly or has an error. If you are using Hub-and-Spoke then this will return "index.cfm" every time. Although it is advisable to have an error catching routine the reports this information to you, I have found that it is still necessary to use the ColdFusion logs from time to time (if you have an error that cannot be caught at the code level or if your error catching routine has a temporary problem).
File Editing
In my projects, I frequently work with designers who know some HTML. Although I do use a CMS in most of my projects now, I still find that there are situations where a designer will want to edit a file. On projects where I used Hub-and-Spoke, they found it very difficult to find the file that needed to be edited (even if I tried to be very consistent about the location and document it).
Now I don't use Hub-and-Spoke and I make sure that the HTML for a given page is in the file being called from the browser (if the page isn't managed by a CMS). This makes it easy for designers to edit the pages. I have gotten direct feedback about the difficulty of Hub-and-Spoke from designers, even though many programmers think that this won't add any difficulty.
Conclusion
For me, Hub-and-Spoke creates more problems than it solves. I create public facing sites wherein the site designers are generally heavily involved in the process. In most cases, the designer is my direct client so it pays for me to make their lives as easy as possible. If I were designing large, intranet applications my views on Hub-and-Spoke might certainly be different.
Messy URLs: This had been an issue for most CF MVC frameworks, but current versions of Mach-II, MG and FB all have a way to generate SES urls with some minor configuration. Even without the frameworks managing SES urls themselves, it's not too hard to configure Apache or IIS to handle the rewrite for you.
Traffic Reporting: As long as you can track query strings, you can track Hub and Spoke. For example, in Urchin just go down to the query string reports and you're good to go.
Error Reporting: I haven't used CF's slow-running page report enough to comment on it.
File Editing: M2, MG and FB all use an XML configuration file. Each page request (or "event") is defined there.
Let's say you're using Mach-II and you want to edit the Transaction History page. Find the event-handler named "transaction-history". This tells you what CFCs are used to retrieve the data for the event, as well as all the CFM files that generate the HTML displayed.
You can get as granular as you like here, so you usually won't be editing an entire page, you'd be editing the CFM file that outputs a table of data or a CFM that defines the Navigation bar.
At work, Mach-II allowed us to create a rather complex payment application in a matter of a few weeks. We also have six other large applications written in Mach-II. Once everyone was familiar with the structure of the configuration file, bug fixes and UI updates on any of them were a breeze.
I certainly didn't intend to reply that the cost of Hub-and-Spoke overwhelmed the benefits of the major frameworks for most users.
For me, however, I haven't seen benefits of the frameworks powerful enough to overcome my distaste for those extra steps.
It isn't that I haven't tried it, either. I used to be a Fuxebox zealot. It was my experience using a Hub-and-Spoke framework that turned me off the practice.
Again, I am not trying to discourage others from using any of the major frameworks. I was directly responding to a request for a blog entry on why I (personally) dislike Hub-and-Spoke.
Their opinion of the extra steps involved was such that future work with them was contingent on my *not* using Fusebox.
Designers are my clients. If they aren't happy, I don't eat.
That doesn't surprise me. It looks like a lot of thought was put into ColdBox to make sure that it provides a developer with as much useful information as possible. It really looks like a very impressive framework.
Is their any good framework without it?
Some comments. As you know, I use a pseudo page controller model where I have page stubs that feed into a front controller which gives me more granular URL control than URL rewriting, so I use a mix of the two approaches.
Some thoughts:
Traffic reporting: Back in the day when I used a front controller, I used to create my own log files which took the page title so it looked to the server like you'd gone to about-us/history.html even though it was really index.cfm?page=37.
File editing: Simple trick. Put the layout view name into the HTML source as an HTML comment. So if it is category-view.cfm in /layouts/screens, just add <!-- category-view.cfm --> to the HTML within the screen. Simple, and rather than the designer having to look through XML, they can just view source to find the file to edit. A designer suggested this to me and it works great. Benefit of this as opposed to HTML in the actual pages is for view reuse if you want to be able to use your order-detail.cfm in my account, in the administrator and in the checkout process. Also allows for view composition.
Not that I know of.
Peter,
Good advice. I think this brings up something else for me though. I am pretty happy with my current strategy. I would have to have some problem big enough to justify changing my approach and dealing with all of the issues of Hub-and-Spoke (each of which are solvable, but with some effort) in order to make the switch justifiable.
I will admit, of course, that I may be too prone to following inertia instead of making a big leap, which could be a problem.
I also really love trying to solve a lot of my issues myself. It is part of the fun of the job.
As far as file editing in FuseBox, it's not too hard to open the appropriate switch file, and find the view file associated with the fuseaction. Or, you can use a naming convention such as "view_productdetails" or the like. This might be a little hard to explain to a designer though I suppose.