Thursday, January 26, 2006
Problems with Fusebox
I liked Fusebox for about a year or so. After that, I started to catalog serious problems with the framework. As I explored the OO designs of Tartan, Model-Glue and Mach-ii, I began to be able to truly articulate my issues with this classic framework design. Of course, I am also of the thought that the problems I do have with the framework might and should be corrected in the nascent Fusebox 5, planned for release whenever the Fusebox team is done.
Enough meandering... what don't I like?
Distributed configuration files with matching names
All my Fusebox 4.x series applications have followed the MVC skeleton design. That is, all controller information is in the controller circuit, all view stuff is in the view circuit, and all model in the model circuit. Alas, all of these share the same name. Which means in every IDE in use, it can be hard to distinguish them by name alone.
Compounding that is the issue I have seen of other developers having nested circuits. All with the same name. Often called/run from the controller. Which adds complexity. Being a monkey, I don't like complexity, and now what should be a simple framework has become much more challenging.
Lack of Implicit Invocation
One thing I like about other frameworks is that you have a single event class that can be called that contains all the methods and values you need to handle business logic. This way I don't need to think much about the framework and instead can focus on the fun of business logic. Fusebox doesn't have this at all. Sure the attribute scope is handy, and you can do some fun and wonky tricks with the application.fb struct, but I can't as easily create dynamic logic to work with this sort of thing. And adding an object to any of these things is very problematic, as the attribute scope is for simple values only and the attribute.fb struct is... well... the core kernal of the application framework.
No Enforcement of Business Rules
All frameworks are guilty of this to some degree, but I think Fusebox is readily guilty of it. It is easy enough for people to stick CFINCLUDEs right into circuits, and it seems to happen all the time. I try to educate people otherwise and yet it still happens. It seems to me that people without a strong OO background fall for this trap more often than not in Fusebox, which makes me wonder if it has some weird connection with Fusebox's fundamentally OO nature.
Fusebox also has no means of enforcing naming conventions, but at least it has them. Still, someone ought to write a name checker or something.
I liked Fusebox for about a year or so. After that, I started to catalog serious problems with the framework. As I explored the OO designs of Tartan, Model-Glue and Mach-ii, I began to be able to truly articulate my issues with this classic framework design. Of course, I am also of the thought that the problems I do have with the framework might and should be corrected in the nascent Fusebox 5, planned for release whenever the Fusebox team is done.
Enough meandering... what don't I like?
Distributed configuration files with matching names
All my Fusebox 4.x series applications have followed the MVC skeleton design. That is, all controller information is in the controller circuit, all view stuff is in the view circuit, and all model in the model circuit. Alas, all of these share the same name. Which means in every IDE in use, it can be hard to distinguish them by name alone.
Compounding that is the issue I have seen of other developers having nested circuits. All with the same name. Often called/run from the controller. Which adds complexity. Being a monkey, I don't like complexity, and now what should be a simple framework has become much more challenging.
Lack of Implicit Invocation
One thing I like about other frameworks is that you have a single event class that can be called that contains all the methods and values you need to handle business logic. This way I don't need to think much about the framework and instead can focus on the fun of business logic. Fusebox doesn't have this at all. Sure the attribute scope is handy, and you can do some fun and wonky tricks with the application.fb struct, but I can't as easily create dynamic logic to work with this sort of thing. And adding an object to any of these things is very problematic, as the attribute scope is for simple values only and the attribute.fb struct is... well... the core kernal of the application framework.
No Enforcement of Business Rules
All frameworks are guilty of this to some degree, but I think Fusebox is readily guilty of it. It is easy enough for people to stick CFINCLUDEs right into circuits, and it seems to happen all the time. I try to educate people otherwise and yet it still happens. It seems to me that people without a strong OO background fall for this trap more often than not in Fusebox, which makes me wonder if it has some weird connection with Fusebox's fundamentally OO nature.
Fusebox also has no means of enforcing naming conventions, but at least it has them. Still, someone ought to write a name checker or something.
# posted by Daniel Greenfeld @ 9:47 AM 
