As the presenter in question at CFOBjective, let me be clear about the differences.
In no-xml fusebox, you lose the capabilities of plugins. As it stands now, there are no plugin points for no-xml fusebox. If you use no-xml fusebox using the cfm version, you also lose the capabilities of having parents thus not being able to do something like <prefuseaction callsuper="true">. For the cfc version, you simply extend the cfc with the parent and use super.prefuseaction() in the prefuseaction function. I happen to prefer the xml version of Fusebox. Perhaps my preference made it into my talk. Sean was there to keep me honest and I did re-do my talk at CFUNITED based on his and my discussions at CFObjective Sandra Clark From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, October 20, 2008 3:57 PM To: [email protected] Subject: [CFCDEV] Re: Mythbusters: Fusebox (was: Coldbox. What do people think?) 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. :) > > 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. > > 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. > > 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. > > 3) I don't have anything to add there. > > 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). > > Jason > > > > > On Oct 20, 2008 11:58am, Jared Rypka-Hauer [EMAIL PROTECTED]> wrote: > > > > > > I'm starting a new thread... this was supposed to be a thread about > > > > someone's interest in ColdBox... > > > > > > > > As for this subject, the only quibble I had with what was said in the > > > > original post was that ColdBox was the most developed, robust and > > > > advanced MVC choice "on the market". > > > > > > > > And really my only quibble was with the "most-developed" part, > > > > although I suppose I question the other two. > > > > > > > > And, to address a couple of other points in this thread: > > > > > > > > 1) You are in no way required to use the XML vocabulary to build an > > > > application. You are in no way required to use the lexicons to build > > > > an application (although it is possible to run a ModelGlue app > > > > against the Fusebox core by way of Lexicons... very freakin cool.) > > > > You rarely actually have a need for a plugin because most of what > > > > you're going to need to do can be done in any of the pre-request > > > > hooks that the framework provides. > > > > > > > > 2) Fusebox, from the minimalist's perspective, is a couple cfml > > > > templates with cfquery tags in some and cfoutput tags in others and > > > > XML to tie them together... think of it as nothing more than a way to > > > > build old-school inline CFML pages and yet keep logic and display > > > > separate. There's nothing to it and I wouldn't build an application > > > > that I was going to do anything with unless I was using at least > > > > Fusebox in this model. OTOH, I may choose ColdBox or ModelGlue... > > > > depends on the situation. However, what I will say is that I would > > > > not be particularly keep to release any application, even if it's > > > > only 2 pages, without seriously considering breaking my logic, my > > > > queries and my display into separate templates which I then simply > > > > stick in individual fuses and tie together with other fuses. It's not > > > > rocket science. > > > > > > > > 2.5) Using the XML vocabularly is a hotly contested and widely > > > > debated subject. Personally I like it... and to be utterly, bluntly > > > > honest I don't care if it doesn't meet with the approval of the > > > > purists out there. When I'm doing "classic Fusebox" I tend to view > > > > the controller circuit's XML AND the associated CFML templates as a > > > > comprehensive whole that form the controller layer, and knowing that > > > > it all cooks down to a CFML template I know that I'm basically using > > > > "inline includes" to build the framework's output. > > > > > > > > 3) The full functionality of the XML variant is not yet available in > > > > the no-XML variant (as with ColdBox, the more functionality you want, > > > > the more XML you have to use), but it's being looked at and worked on. > > > > > > > > 4) There continues to be a huge number of misperceptions and urban > > > > legends surrounding Fusebox. We (I, Team Fusebox, someone) needs to > > > > compile a list of them and then write up some "dispell the myths" > > > > articles on the subject. The disheartening thing about this is the > > > > fact that people who could be benefitting from the framework aren't > > > > because they "heard from someone who took over a Fusebox project what > > > > a mess it makes of things" or "had a speaker at their CFUG who hates > > > > Fusebox, so I never looked into it." > > > > > > > > Again, in the most minimal implementation, to use Fusebox is simply > > > > to reorganize your code so that you're building small, cohesive bits > > > > of CFML that are then made available to the framework via > > > > fusionactions, which, in turn, are bound together by larger > > > > fuseactions, which are then used to create execution paths thru the > > > > application from a URL to a display. It's not rocket science... it's > > > > just abstraction, encapsulation (of a sort) and cohesion in a > > > > procedural application. > > > > > > > > It's not for everyone, for sure, but if people are gonna rip on it > > > > they should at least do it from an educated perspective. > > > > > > > > Laterz, > > > > J > > > > > > > > On Oct 20, 2008, at 7:49 AM, Dan O'Keefe wrote: > > > > > > > > > > > > > > On Mon, Oct 20, 2008 at 6:50 AM, John Whish > > > > > wrote: > > > > >> I think Jared got it spot on. Coldbox probably has the best online > > > > >> documentation, but Fusebox is by far the most mature and is > > > > >> incredibly > > > > >> robust and has proved itself to be fast. Fusebox also tries hard > > > > >> not to > > > > >> force the developer into using OO, procedural or even MVC. Pretty > > > > >> much the > > > > >> only thing it does enforce is the front controller design pattern. > > > > > > > > > > I am sure it is spot on for him, but not for me - surely a > > > > > preferential selection for everyone for their own reasons. I used > > > > > Fusebox in the 3.x days, never went to 4 as it did not meet my needs > > > > > so I was using my own concoction until MG & CB came along. I have > > > > > worked on Fusebox 5.1 this year and I dislike it even more now. I > > > > > never had an issue with XML in MG, but in FB, adding logic to the XML > > > > > with Lexicons to me is ridiculous. If you are going to do that, why > > > > > not just have it all CF, a.k.a. CB. So you have CF, XML and Lexicons > > > > > in FB, all 3 you have to be aware of to follow an app. ... > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
