Thanks for the response. I have a few comments, but there's one thing I want to say first:
Fusebox takes a whole different approach to development than any of the other frameworks out there. The whole point of developing with Fusebox is the dual notion of having a compiler and that "it all boils down to parsed, inline CFML" and if that's OK with you, then great. If it's not, you're not going to like it. If nothing else, though, Fusebox has enabled me to help people who are hung up on using a framework at all by showing them that all they have to do is reorganize their code a bit, abstract a couple things, and move their inline CFML applications into a framework in short order. You do, however, have to accept certain ideas that seem unpopular, and while I don't agree that they're bad things, I can see people's point. From that perspective, Fusebox is almost a language and a platform of it's own... and I can see why that would be a cause for concern for people. On Oct 20, 2008, at 2:57 PM, [EMAIL PROTECTED] wrote: > Oops... may have replied directly to Jared. Sorry for the > confusion. Read comments below. > > On Oct 20, 2008 2:55pm, [EMAIL PROTECTED] wrote: > > I fear this topic may turn into a 'bash Fusebox' discussion. In > no way do I mean to imply that Fusebox is poorly engineered. > However, I have a different opinion on the topics you presented. > I'll respond by number. :) Feh, no worries. The only thing I feel bad for is originally hijacking someone else's valid thread and turning it into a Fusebox thread. As for it becoming a "bash Fusebox" discussion, it wouldn't surprise me, nor would it be unusual. Because Fusebox takes such a different approach to solving the problem of creating and maintaining cohesive bits of functionality, and because it provides a mechanism to create purely inline CFML applications as well as CFC-based applications, it's one of the most hated and most loved tools out there. Since it imposes almost nothing in terms of application structure or architecture on the developer, it makes it really easy to be horrible... I mean, it doesn't impose MVC, it doesn't mandate CFCs, and it has no integrated concept of the difference between a service, the model, or the controller layer. So lots of bad work has been done with Fusebox over the years and Fusebox has taken a lot of the blame for it. Consider this, though: It's really no different than ColdFusion, which makes web development really easy, imposes nothing in terms of architecture on the developer and makes it really easy to make something work and be really sucky at the same time... so for both Fusebox and ColdFusion, one of the core problems is the same: perception. They both make great power available with little skill, and at various times they both have been the subject of very wide adoption... and that creates a problem for both of them. Fortunately ColdFusion's perception has been turning around of late. Maybe with the no-XML variant and with some skilled developers using Fusebox for more than just sample code, the same can be done for Fusebox. > > 1) I have not attempted to build a no-XML version of FB 5.5. I > attended CF.Objective() last year, where a presenter (and co- > author?) of FB 5.5 both said that the no-XML flavor of FB had some > shortcomings when compared to the traditional XML Fusebox. Also, > Sean (IIRC) said that FB 5.5 required quite a bit of re-tooling to > work without XML. I wouldn't argue that FB XML is immature, but I > might say that no-XML FB has a trial and maturity period to > undertake. If you want CFML based controllers, why not choose a > framework _built_ around CFC conventions? Don't get me wrong. I > don't intend to discredit the efforts of the Fusebox Team. Yeah, the no XML variant has some shortcomings. Adam (the new core lead for FB) has already implemented some feature improvements for FB 5's no-XML variant with more to come. Adam just confirmed that plugins are on that list, and the core team is cognizant of the no- XML shortcomings: http://cfrant.blogspot.com/2008/08/hello-team-fusebox.html http://cfrant.blogspot.com/2008/09/fusebox-status.html > 2) As I mentioned in the other discussion, everyone has 'what > matters most' to them. The extra steps it takes to build a Fusebox > app (or Coldbox, for that matter) sometimes outweighs the benefits. > For many of us, we are paid based upon productivity. If it's a > small site, I can navigation, header, footer and a couple of > queries faster than I can with a framework. Arguably, it's less > complex and easier to manage when it's time for pages X + 1 and X + > 2. If it starts to get out of control, it's pretty easy to extract > into multiple layers. Done that already. Fair enough. One thing I like best about Fusebox is the fact that you can build a totally procedural app with it, only using circuit files to stitch the logic together where the pieces touch. I find the amount of time that it adds to a simple app is negligible, but again, it's a "to each their own" sort of a thing. > > 2.5) It's personal preference, just as you said. I like all of > the CFML in my controller. I also like all of the tools that Luis > Majano has developed (code hints, snippets, etc.). I didn't find > any of that stuff for Fusebox. Fair enough, on both counts... although CFEclipse maintains support for several frameworks by including the CF Frameworks plugin goes a ways to offset the lack of tooling, ColdBox does have an advantage in the tools arena. OTOH, using a decent XML editor and the Fusebox DTDs, getting tag insight support is a non-issue. Either way, it doesn't really matter. You like something else better.... cool. I'm just sayin, Fusebox isn't entirely without those things. > 3) I don't have anything to add there. See item 1... > > 4) That may be true. However, in the previous thread, there > seemed to be some people who had first-hand experience with > Fusebox. Everyone is certainly entitled to their own opinion. I'm > sure I don't use Fusebox to its full capacity (nor Coldbox). I guess first-hand experience supporting someone else's application isn't really the same as knowing the framework and the difference between a well-done Fusebox application and a poorly-done Fusebox application. We've heard from people who hate Fusebox because of someone else's poor work or simply for lack of interest or because they found the Fusebox community hard to interact with. My whole (and only) real objective was (and continues to be) dispelling some of the myths, or mistaken impressions, that folks seem to be promulgating regarding Fusebox. It's not fair to Fusebox, it's not fair to those who don't know and would be left with an incorrect impression, and it's not fair to those who wrote the stuff in the first place. I guess, like I said earlier, I was seeing it like people saying "ColdFusion is dead!" So many people have an idea of Fusebox based on someone else's horrible application or without a thorough understanding of what it is and how it works except what they need to know based on the demands of their jobs. In the long run it probably makes no difference. People will like what they like because it works for them, it makes the most sense, it puts the power back in their hands, etc. etc. If nothing else, this conversation proves one thing: The ColdFusion community is evolving and things like frameworks and architecture are moving into the mainstream thought process of more CFers than ever before... and that's a Good Thing(tm). ;) Laterz, J --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
