1. It seems very switch-statement intensive, in a way that does not appeal to my taste.
Fusebox is more or less an MVC (Model-View-Controller) framework, and the fbx_switch file is the controller. The very nature of a controller in MVC is to wire other components together. In actual fact one of the greatest _features_ of Fusebox is that it centralizes the control logic, and you can deduce the flow of control from looking at the fbx_switch files alone, rather than having to follow a thread of control through little bits of code here and there.
For example, the model that control is always passed to the index.* file, and then dispatched from there, seems to be adding an additional layer of indirection pointlessly.
This model is actually the prevalent model in the non-web software world today: it's called the event dispatcher. Effectively you are posting events to a dispatcher which then takes care of dispatching the event to the target circuit event handler, which looks at the event and figures out what to do. This is the model UI frameworks such as PowerPlant on the Mac or MFC on Windows use. It's nothing new. It's analogous to a form method in the 4D world.
The fbx_Switch file, in particular, looks messy to my eye.
That's because you were looking at sample code in Cold Fusion tag syntax, which is incredibly hard for the eye to parse. If you were to translate it into Active4D and format it better, it would actually be extremely simple, clean, and extremely easy to follow.
2. There appear to be two camps as far as URLs go: Those who feel that they are, mostly, machine-readable cookies that humans should not care about, and those who feel they are part of the UI. I'm in the "part of the UI" camp, and I prefer very clean, short, readable URLs. I realize that it is possible to have such URLs in Fusebox, but there is no question that you are swimming against the stream in that case.
I disagree entirely! With my new On Request event handler you can make the URLs anything you want them to be externally and then translate them internally into a fuseaction call. It is not swimming against the tide at all, in fact it is quite prevalent within the Fusebox community for URLs to be expressed externally in a totally different fashion that they are internally.
3. Along those lines, it does seem to make you express your... well, OK, I'll just called it inheritance structure in a directory structure, and since this directory structure is under the web root, it becomes a visible directory structure. That seems unpleasant to me; I don't want to make my inheritance structures part of the UI.
You don't yet understand Fusebox. The directory structure is most definetly NOT visible as part of the UI! In fact, in Fusebox it is totally hidden behind index.a4d and a fuseaction. The fbx_circuits file _flattens_ the hierarchy totally. The actual directory structure is NEVER visible.
4. This is, perhaps, petty, but I find the terminology of "fuse," "fuseaction," "circuit," etc., maddeningly opaque. Those just don't map to anything reasonable in my brain.
Geez, so call them something else! The terminology is not important -- the methodology is.
5. The actual leverage that Fusebox appears to provide, considered as a code library, is relatively small.
It was never designed to be nor does it pretend to be a code library. It is a framework, pure and simple.
Most of the gain seems to be from the discipline it imposes on how you structure your application. Call me immodest, but after 20-odd years of being a technology architect, I think I have a reasonable understanding on how to create an implementation discipline. Given that, the basic code that it provides seems like a long afternoon's worth of implementation, and I'm not sure I'm willing to learn the new jargon, etc., etc. for something I could do myself in a long > afternoon.
Do I sense a little NIH? ;-)
Okay, if you say you could have done Fusebox yourself in a long afternoon, after 20 years of being a technology architect, why hadn't you? I have also been a technology architect for 20 years, and I have been doing web programming for three years, and I was nowhere near the ideas in Fusebox.
Forgive me for saying so, but I think the ideas expressed in Fusebox required a whole lot more than an afternoon. It is precisely because the authors spent so much time thinking about the architecture and honing the code that it appears to be trivially simple.
Please don't do a disservice to the other technology architects of the world by trivializing their work!
All in all, though, it just comes down this: Fusebox doesn't really react entertainingly with my brain chemistry.
All I can tell you is that Fusebox is one of those things where you have to "grok" it.
GROK -- To understand, usually in a global sense. Connotes intimate and exhaustive knowledge.
It took me several days of trying to wrap my head around it -- or more precisely, to put my head inside of it -- until I grokked Fusebox. Once I did, I had an "aha!" moment where it all became clear and the beauty of its architecture became apparent and I could see a whole raft of problems it solved in a simple and elegant way.
Object-oriented programming is a similar case. You have to grok it. It is not something that reacts entertainingly with most people's brain chemistry in the space of a few days. Does that mean it never will, or that it isn't a valid methodology? I hope not.
I have no interest in forcing anyone to use Fusebox. I would only encourage you (and everyone else using Active4D) to try to understand it.
Of course you are free to create your own framework. By my watch it is now 12:30pm in London (where I think you are). You have until 6pm (a long afternoon) to _complete_ your framework -- with no bugs, clean code, a well thought out API, an elegant design, solving most web programming problems.
I look forward to seeing it! ;-)
P.S. No matter what else I may say, I am truly grateful that you are using Active4D.
Regards,
Aparajita Victory-Heart Productions [EMAIL PROTECTED] www.aparajitaworld.com
"If you dare to fail, you are bound to succeed." - Sri Chinmoy | www.srichinmoylibrary.com
