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.
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.
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.