RE: Cons to Fusebox
No dork, I was responding to your weird remark: What does that say about FuseBox? I don't understand nor do I wish to understand your goofy situation and why you have to work so hard to upload files. I think you may have made a logistical error or 2 designing this cluster-f*** of a site, but it doesn't reflect at all on the merits of fuesbox so I'm not sure why you made that remark. You're just further supporting my theory about nay-sayers not understanding something about using fusebox. You know, if a requirement of using FuseBox was to have an attitude like yours, then I'm glad that I don't use it I thought that the whole ColdFusion Community was about sharing opinions, not of personal insults - never did I make a personal attack on you, but you feel the need to personally insult me If you're the average FuseBox user, then I'm sure that there are a lot of people out there who will be turned away from FuseBox because of your chip on my shoulder attitude ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
He is obviouslay a twat Phil. ;-) step back and let his brain cell fight with his ego for who gets more oxygen. -Original Message- From: Philip Arnold [mailto:[EMAIL PROTECTED] Sent: 21 July 2003 10:42 To: CF-Talk Subject: RE: Cons to Fusebox No dork, I was responding to your weird remark: What does that say about FuseBox? I don't understand nor do I wish to understand your goofy situation and why you have to work so hard to upload files. I think you may have made a logistical error or 2 designing this cluster-f*** of a site, but it doesn't reflect at all on the merits of fuesbox so I'm not sure why you made that remark. You're just further supporting my theory about nay-sayers not understanding something about using fusebox. You know, if a requirement of using FuseBox was to have an attitude like yours, then I'm glad that I don't use it I thought that the whole ColdFusion Community was about sharing opinions, not of personal insults - never did I make a personal attack on you, but you feel the need to personally insult me If you're the average FuseBox user, then I'm sure that there are a lot of people out there who will be turned away from FuseBox because of your chip on my shoulder attitude ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Twat? That's nice. You think Phil's remark what does that say about fusebox was intelligent? Him blaming fusebox for his inability to organize his code properly is rediculous. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 5:07 AM To: CF-Talk Subject: RE: Cons to Fusebox He is obviouslay a twat Phil. ;-) step back and let his brain cell fight with his ego for who gets more oxygen. -Original Message- From: Philip Arnold [mailto:[EMAIL PROTECTED] Sent: 21 July 2003 10:42 To: CF-Talk Subject: RE: Cons to Fusebox No dork, I was responding to your weird remark: What does that say about FuseBox? I don't understand nor do I wish to understand your goofy situation and why you have to work so hard to upload files. I think you may have made a logistical error or 2 designing this cluster-f*** of a site, but it doesn't reflect at all on the merits of fuesbox so I'm not sure why you made that remark. You're just further supporting my theory about nay-sayers not understanding something about using fusebox. You know, if a requirement of using FuseBox was to have an attitude like yours, then I'm glad that I don't use it I thought that the whole ColdFusion Community was about sharing opinions, not of personal insults - never did I make a personal attack on you, but you feel the need to personally insult me If you're the average FuseBox user, then I'm sure that there are a lot of people out there who will be turned away from FuseBox because of your chip on my shoulder attitude ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
On Fri, 18 Jul 2003 17:39:19 -0400, in cf-talk you wrote: Out of curiosity, Jamie, is this typical of all of your projects or just this particular one? This is the first CF project that I foresaw being complicated by multiple developers. However, I have the feeling that I'll be inclined to use one of the FB variants for all but the smallest future CF projects. Additionally, how do you (and all other appropriate developers on your project(s)) respond to changes in requirement that necessitate a change in display, logic, and data? With a changing requirement, the architect or I have told the other developer that I needed a new variable from their fuse, etc. Are the changes made by one person or three? If three, have you found it difficult to coordinate everyone's time and effort? I can't think a time when this has been an issue (yet). If necessary, I could always go into their fuse and make the mod myself, but we've been happy staying out of each others' code so far. Thanks, Jamie ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Mosh Teitelbaum wrote: Are the changes made by one person or three? If three, have you found it difficult to coordinate everyone's time and effort? Jamie Jackson wrote: I can't think a time when this has been an issue (yet). If necessary, I could always go into their fuse and make the mod myself, but we've been happy staying out of each others' code so far. This is pretty much the point I was getting at when I asked In your experience, how often do you have one developer working on the form and another working on the action file? My point was that, when you have different developers working on different aspects of a single functional unit (i.e., display, logic, data for a single action), it can become difficult to respond to changes in the requirements without having to cross those borders. It sounds as if, so far, you've been able to succeed in that regard, and I congratulate you on that. I just wonder how successful it will be come crunch time, or when a developer gets moved to another project, or any number of other problems that are unfortunately common. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
We too work in such a manneri.e. multiple developers on the same fuses etc, the reason we seem to have it working is that we have a very strict set of code guidelines which outline : style, variable names etc At present what tends to happen is one developer works on the display page which can automatically be used across mutiple fuses etc and one developer writes the actions pages as stored procedures. When it comes to crunch time, they all link together sweetly.. -Original Message- From: Mosh Teitelbaum [mailto:[EMAIL PROTECTED] Sent: 21 July 2003 16:06 To: CF-Talk Subject: RE: Cons to Fusebox Mosh Teitelbaum wrote: Are the changes made by one person or three? If three, have you found it difficult to coordinate everyone's time and effort? Jamie Jackson wrote: I can't think a time when this has been an issue (yet). If necessary, I could always go into their fuse and make the mod myself, but we've been happy staying out of each others' code so far. This is pretty much the point I was getting at when I asked In your experience, how often do you have one developer working on the form and another working on the action file? My point was that, when you have different developers working on different aspects of a single functional unit (i.e., display, logic, data for a single action), it can become difficult to respond to changes in the requirements without having to cross those borders. It sounds as if, so far, you've been able to succeed in that regard, and I congratulate you on that. I just wonder how successful it will be come crunch time, or when a developer gets moved to another project, or any number of other problems that are unfortunately common. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
I'm not sure that there was, but in case there was some misunderstanding, by crunch time I meant when things start getting hectic, time is running out, last minute changes, etc. In my own experience, and this is from having been a code grunt to an architect to a project manager to just about every other aspect of a project you can think of, a team is better able to handle any challenge when all (or as many as possible) members of the team have a solid understanding of the overall architecture. I've found that requiring and enforcing strict ownership of individual files can become a nightmare when new requirements, bug fixes, or unforeseeables occur. It's always been better when any number of available (key word that) developers can step up and resolve any number of problems. This is not to say that other approaches can't work, but I'd rather be able to use any resource I have for any problem occurs rather than having to wait on a single resource becoming available. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 11:10 AM To: CF-Talk Subject: RE: Cons to Fusebox We too work in such a manneri.e. multiple developers on the same fuses etc, the reason we seem to have it working is that we have a very strict set of code guidelines which outline : style, variable names etc At present what tends to happen is one developer works on the display page which can automatically be used across mutiple fuses etc and one developer writes the actions pages as stored procedures. When it comes to crunch time, they all link together sweetly.. -Original Message- From: Mosh Teitelbaum [mailto:[EMAIL PROTECTED] Sent: 21 July 2003 16:06 To: CF-Talk Subject: RE: Cons to Fusebox Mosh Teitelbaum wrote: Are the changes made by one person or three? If three, have you found it difficult to coordinate everyone's time and effort? Jamie Jackson wrote: I can't think a time when this has been an issue (yet). If necessary, I could always go into their fuse and make the mod myself, but we've been happy staying out of each others' code so far. This is pretty much the point I was getting at when I asked In your experience, how often do you have one developer working on the form and another working on the action file? My point was that, when you have different developers working on different aspects of a single functional unit (i.e., display, logic, data for a single action), it can become difficult to respond to changes in the requirements without having to cross those borders. It sounds as if, so far, you've been able to succeed in that regard, and I congratulate you on that. I just wonder how successful it will be come crunch time, or when a developer gets moved to another project, or any number of other problems that are unfortunately common. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
No-one here is in control of any particular file...we just ensure that when people do work on individual files : they can always be pieced together without error., -Original Message- From: Mosh Teitelbaum [mailto:[EMAIL PROTECTED] Sent: 21 July 2003 16:27 To: CF-Talk Subject: RE: Cons to Fusebox I'm not sure that there was, but in case there was some misunderstanding, by crunch time I meant when things start getting hectic, time is running out, last minute changes, etc. In my own experience, and this is from having been a code grunt to an architect to a project manager to just about every other aspect of a project you can think of, a team is better able to handle any challenge when all (or as many as possible) members of the team have a solid understanding of the overall architecture. I've found that requiring and enforcing strict ownership of individual files can become a nightmare when new requirements, bug fixes, or unforeseeables occur. It's always been better when any number of available (key word that) developers can step up and resolve any number of problems. This is not to say that other approaches can't work, but I'd rather be able to use any resource I have for any problem occurs rather than having to wait on a single resource becoming available. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 11:10 AM To: CF-Talk Subject: RE: Cons to Fusebox We too work in such a manneri.e. multiple developers on the same fuses etc, the reason we seem to have it working is that we have a very strict set of code guidelines which outline : style, variable names etc At present what tends to happen is one developer works on the display page which can automatically be used across mutiple fuses etc and one developer writes the actions pages as stored procedures. When it comes to crunch time, they all link together sweetly.. -Original Message- From: Mosh Teitelbaum [mailto:[EMAIL PROTECTED] Sent: 21 July 2003 16:06 To: CF-Talk Subject: RE: Cons to Fusebox Mosh Teitelbaum wrote: Are the changes made by one person or three? If three, have you found it difficult to coordinate everyone's time and effort? Jamie Jackson wrote: I can't think a time when this has been an issue (yet). If necessary, I could always go into their fuse and make the mod myself, but we've been happy staying out of each others' code so far. This is pretty much the point I was getting at when I asked In your experience, how often do you have one developer working on the form and another working on the action file? My point was that, when you have different developers working on different aspects of a single functional unit (i.e., display, logic, data for a single action), it can become difficult to respond to changes in the requirements without having to cross those borders. It sounds as if, so far, you've been able to succeed in that regard, and I congratulate you on that. I just wonder how successful it will be come crunch time, or when a developer gets moved to another project, or any number of other problems that are unfortunately common. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Ah... then I think this is a different issue than what I was discussing with Jamie. Jamie had been saying that one developer works on the front end of a single action, another works on the middle, and a third works on the back end, without crossing those borders (except, perhaps, in extreme situations). What you're saying, though, pretty much enforces what I said in a different branch of this thread: The fact that a project is successful is in only small part due to the framework being used (if any). It's much more dependant on planning and documentation prior to actual coding. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 11:43 AM To: CF-Talk Subject: RE: Cons to Fusebox No-one here is in control of any particular file...we just ensure that when people do work on individual files : they can always be pieced together without error., -Original Message- From: Mosh Teitelbaum [mailto:[EMAIL PROTECTED] Sent: 21 July 2003 16:27 To: CF-Talk Subject: RE: Cons to Fusebox I'm not sure that there was, but in case there was some misunderstanding, by crunch time I meant when things start getting hectic, time is running out, last minute changes, etc. In my own experience, and this is from having been a code grunt to an architect to a project manager to just about every other aspect of a project you can think of, a team is better able to handle any challenge when all (or as many as possible) members of the team have a solid understanding of the overall architecture. I've found that requiring and enforcing strict ownership of individual files can become a nightmare when new requirements, bug fixes, or unforeseeables occur. It's always been better when any number of available (key word that) developers can step up and resolve any number of problems. This is not to say that other approaches can't work, but I'd rather be able to use any resource I have for any problem occurs rather than having to wait on a single resource becoming available. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 11:10 AM To: CF-Talk Subject: RE: Cons to Fusebox We too work in such a manneri.e. multiple developers on the same fuses etc, the reason we seem to have it working is that we have a very strict set of code guidelines which outline : style, variable names etc At present what tends to happen is one developer works on the display page which can automatically be used across mutiple fuses etc and one developer writes the actions pages as stored procedures. When it comes to crunch time, they all link together sweetly.. -Original Message- From: Mosh Teitelbaum [mailto:[EMAIL PROTECTED] Sent: 21 July 2003 16:06 To: CF-Talk Subject: RE: Cons to Fusebox Mosh Teitelbaum wrote: Are the changes made by one person or three? If three, have you found it difficult to coordinate everyone's time and effort? Jamie Jackson wrote: I can't think a time when this has been an issue (yet). If necessary, I could always go into their fuse and make the mod myself, but we've been happy staying out of each others' code so far. This is pretty much the point I was getting at when I asked In your experience, how often do you have one developer working on the form and another working on the action file? My point was that, when you have different developers working on different aspects of a single functional unit (i.e., display, logic, data for a single action), it can become difficult to respond to changes in the requirements without having to cross those borders. It sounds as if, so far, you've been able to succeed in that regard, and I congratulate you on that. I just wonder how successful it will be come crunch time, or when a developer gets moved to another project, or any number of other problems that are unfortunately common. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm
Re: Cons to Fusebox
Brain, I appreciate that, however, I've already had experience with Fusebox, and decided it wasn't worth the additional overhead of complexity 'for me' ;) - Calvin - Original Message - From: Brian Kotek [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:54 PM Subject: Cons to Fusebox Calvin, I could see how you might think that, but in reality, this is the list of arcane terms that Fusebox brings with it: Fuse - an individual, atomic code file in a Fusebox application. Fuseaction - a request handler, usually responds by running fuses. Circuit - a group of related fuseactions. XFA - an Exit Point of a fuse which causes a new reqeust to the Fusebox. That's it. It's really not very daunting. Hope that helps. Brian Exactly so... Just an odd opinion. ColdFusion seems to shield the developer from the more arcane phraseology and syntax used by lower level languages, and Fusebox seems to introduce the arcane right back on top of it... - Calvin ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
Matt, I'm with you on that, I even incorporated a good portion of Sean's guidelines into our guidelines :) They be good stuff! - Calvin - Original Message - From: Matt Robertson [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 3:00 PM Subject: RE: Cons to Fusebox Calvin Ward said: ColdFusion seems to shield the developer from the more arcane phraseology and syntax used by lower level languages, and Fusebox seems to introduce the arcane right back on top of it... Calvin, in one sentence you articulated what I was unable to in, what... 100 across this thread? Nail on the head. I don't think CF needs to be complex to be understandable by coders other than the original one. CF is simple to follow and this is a benefit to be preserved, not thrown away in the interest of standardization, regardless of the fact it does have some inarguable benefits, the KISS principle should rule. Do I have a better solution? No, but this lack doesn't invalidate the right to make the observation, as some have suggested. If everyone just read Sean Corfield's code guidelines and took them to heart that'd be most of the battle won right there. Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc. http://mysecretbase.com -Original Message- From: Calvin Ward [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 11:39 AM To: CF-Talk Subject: Re: Cons to Fusebox Exactly so... Just an odd opinion. ColdFusion seems to shield the developer from the more arcane phraseology and syntax used by lower level languages, and Fusebox seems to introduce the arcane right back on top of it... - Calvin - Original Message - From: Michael T. Tangorre [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 1:38 PM Subject: Re: Cons to Fusebox X(exit) F(fuse) A(actions) - Original Message - From: Calvin Ward [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 1:37 PM Subject: Re: Cons to Fusebox XFA? - Original Message - From: Mosh Teitelbaum [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 1:39 AM Subject: RE: Cons to Fusebox snip Yes, but the earlier comments I was responding to were suggesting that Fusebox allows individual developers to know Fusebox but not have to know the specific details of the current FB implementation. For example, the developer can know to read the FuseDoc at the top of the file and can know to plugin FORM ACTION=#someXFA# but not have to know that sometimes this form targets foo.add and other times targets foo.edit. As an example of why this is problematic, if the developer doesn't know about both targets, he can't know to test his code against both targets. It also makes it more difficult to debug any problem that crop up. Adding some code to fix one problem may unknowingly cause another problem when going to a different target. snip ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Oh, in that case fusebox sucks. I'm not going to use it anymore! You're the smartest guy ever! Hey, you said I've never heard a developer who's actually architected and developed a project with FB say I wish I hadn't used FB I told you that I had a situation where I HAD said that I wished I hand't used FuseBox So, because you've been proven wrong, you come back with a smart-ass remark? Sorry, I'd better go back in time and decide that FuseBox 2 was the greatest thing ever, even though it added 20 minutes to my upload time because of how many locations I had to FTP to... cf_Shakes Head ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
No dork, I was responding to your weird remark: What does that say about FuseBox? I don't understand nor do I wish to understand your goofy situation and why you have to work so hard to upload files. I think you may have made a logistical error or 2 designing this cluster-f*** of a site, but it doesn't reflect at all on the merits of fuesbox so I'm not sure why you made that remark. You're just further supporting my theory about nay-sayers not understanding something about using fusebox. -Original Message- From: Philip Arnold [mailto:[EMAIL PROTECTED] Sent: Sunday, July 20, 2003 2:08 AM To: CF-Talk Subject: RE: Cons to Fusebox Oh, in that case fusebox sucks. I'm not going to use it anymore! You're the smartest guy ever! Hey, you said I've never heard a developer who's actually architected and developed a project with FB say I wish I hadn't used FB I told you that I had a situation where I HAD said that I wished I hand't used FuseBox So, because you've been proven wrong, you come back with a smart-ass remark? Sorry, I'd better go back in time and decide that FuseBox 2 was the greatest thing ever, even though it added 20 minutes to my upload time because of how many locations I had to FTP to... cf_Shakes Head ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
I tried to build an app on FB2, then another client wanted a site with exactly the same technology - this meant duplicating the files over the ? 2 folders - whenever I did updates, I had to upload to 2 locations Philip, I'm no FB evangelist... people should use whatever works for them, IMO. But there are a couple things in your comment that don't make sense to me. (1) FB2 places no particular limits on the locations of your individual fuses. In my case, each JournURL community is an independent instance of an FB2-ish app, but all instances share dsp_s, act_s, qry_s, custom tags, and CFCs that are stored in centralized locations. (2) Ignoring any potential architectural issues, the problem you're describing could have been solved with an automation app like AutoMate (http://www.unisyn.com/automate/). One click (or a scheduler) will copy files across directories and FTP them to the appropriate remote locations. Would have been a whole lot simpler than scrapping most of the code and starting from scratch. -- Roger Benningfield JournURL blog: http://admin.support.journurl.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
This is almost rediculous. I've seen complete newbies with little or no CF experience pick up fusebox in a week. There's nothing ridiculous about the FB learning curve... FB makes instant sense to many people, and is completely impenetrable to many others. Anyone who has watched the various FB mailing lists over the years has seen newbies struggle with simple tasks like framing a Fusebox'd site, not because such things are actually hard to do, but because FB can be conceptually confusing to folks who are accustomed to EPIAI (Each Page Is An Island) web development. Folks have different backgrounds and make different intuitive leaps. That's just the way it is. -- Roger JournURL blog: http://admin.support.journurl.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
The anonymous GL said, No dork, I was responding to snip If you can't be a grownup here then get out. Around here that attitude just discounts your opinion as noise. Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc. http://mysecretbase.com ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
...and you further support their point that people who use Fusebox are idiots. You do nothing to further this thread with these comments and you do nothing to show that Fusebox is beneficial to developers. Michael Wilson -Original Message- From: GL [mailto:[EMAIL PROTECTED] Sent: Sunday, July 20, 2003 7:25 AM To: CF-Talk Subject: RE: Cons to Fusebox You're just further supporting my theory about nay-sayers not understanding something about using fusebox. ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
It's not really a campaign to convert stubborn cowboy-coders to use Fusebox is it? I don't care if these guys are too smart to use fusebox. Those of us that efficiently produce reusable, maintainable code are just becomming more valued in the industry. Clients/Investors are quickly learning that it's not practical to invest hundreds of thousands of dollars into disposal software. It all comes out in the wash. -Original Message- From: Michael Wilson [mailto:[EMAIL PROTECTED] Sent: Sunday, July 20, 2003 12:24 PM To: CF-Talk Subject: RE: Cons to Fusebox ...and you further support their point that people who use Fusebox are idiots. You do nothing to further this thread with these comments and you do nothing to show that Fusebox is beneficial to developers. Michael Wilson -Original Message- From: GL [mailto:[EMAIL PROTECTED] Sent: Sunday, July 20, 2003 7:25 AM To: CF-Talk Subject: RE: Cons to Fusebox You're just further supporting my theory about nay-sayers not understanding something about using fusebox. ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Your statements assume the apps in multiple locations all belong to one client. If I had 3 clients who each required a shopping cart app (for instance), I doubt very much if they would want their system to be even partially located on server's outside their domains. In this case (which is common among software shops) one would need to copy the common code to each of the domains. Then, if a fix is done for one site (to the common code), then it is very likely that fix needs to be applied to the other sites as well. I don't see how FB helps with this situation any, nor makes it any worse. This issue would exist regardless of what architecture or methodology was implemented. But yes, I agree that there are tools available to synchronize remote folders which would make this issue easier to deal with. rant on The next comment is directed at GL. It's people like you who make a mailing list frustrating. I'm here to gather information, and stay current with the issues that affect my trade. To hear someone like you spout off that you are oh so superior because I don't do it like you makes me want to puke. You have a different way of doing the job - that's fine. But to hear you cut down people who don't do it your way is just stupid. Grow up. I've seen too many people - programmers, techs, or otherwise - with this attitude, and everyone of them runs into a situation where they are put in their spot. A little knowledge does not make you an expert. (And notice I did not even for a second attack your skills as a programmer? Isn't that how it's supposed to be done? A general discussion - not a bashing without cause.) /rant off snip Roger Benningfield said: (1) FB2 places no particular limits on the locations of your individual fuses. In my case, each JournURL community is an independent instance of an FB2-ish app, but all instances share dsp_s, act_s, qry_s, custom tags, and CFCs that are stored in centralized locations. (2) Ignoring any potential architectural issues, the problem you're describing could have been solved with an automation app like AutoMate (http://www.unisyn.com/automate/). One click (or a scheduler) will copy files across directories and FTP them to the appropriate remote locations. Would have been a whole lot simpler than scrapping most of the code and starting from scratch. /snip ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Just to set the record straight since you weren't paying attention to the whole thread. I was using dork to describe the obvious latency in brain function on the part of the guy when he said: So, because you've been proven wrong, you come back with a smart-ass remark?. My smart-ass remark was about What does that say about FuseBox?. That's a dorky statement when all he just explained is why he couldn't figure out a good way to do something so he blames it on fusebox. -Original Message- From: Shawn Grover [mailto:[EMAIL PROTECTED] Sent: Sunday, July 20, 2003 2:40 PM To: CF-Talk Subject: RE: Cons to Fusebox Your statements assume the apps in multiple locations all belong to one client. If I had 3 clients who each required a shopping cart app (for instance), I doubt very much if they would want their system to be even partially located on server's outside their domains. In this case (which is common among software shops) one would need to copy the common code to each of the domains. Then, if a fix is done for one site (to the common code), then it is very likely that fix needs to be applied to the other sites as well. I don't see how FB helps with this situation any, nor makes it any worse. This issue would exist regardless of what architecture or methodology was implemented. But yes, I agree that there are tools available to synchronize remote folders which would make this issue easier to deal with. rant on The next comment is directed at GL. It's people like you who make a mailing list frustrating. I'm here to gather information, and stay current with the issues that affect my trade. To hear someone like you spout off that you are oh so superior because I don't do it like you makes me want to puke. You have a different way of doing the job - that's fine. But to hear you cut down people who don't do it your way is just stupid. Grow up. I've seen too many people - programmers, techs, or otherwise - with this attitude, and everyone of them runs into a situation where they are put in their spot. A little knowledge does not make you an expert. (And notice I did not even for a second attack your skills as a programmer? Isn't that how it's supposed to be done? A general discussion - not a bashing without cause.) /rant off snip Roger Benningfield said: (1) FB2 places no particular limits on the locations of your individual fuses. In my case, each JournURL community is an independent instance of an FB2-ish app, but all instances share dsp_s, act_s, qry_s, custom tags, and CFCs that are stored in centralized locations. (2) Ignoring any potential architectural issues, the problem you're describing could have been solved with an automation app like AutoMate (http://www.unisyn.com/automate/). One click (or a scheduler) will copy files across directories and FTP them to the appropriate remote locations. Would have been a whole lot simpler than scrapping most of the code and starting from scratch. /snip ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Brian Kotek wrote: I mean, I could say the best methodology is the build the best application methodology. There are no repeatable steps to this methodology, no way to document it in a way that someone else can use. But when you use it and you do it right, whooeee the results are amazing! Brian: Not to try and get you back into the thread here 8^), but there are numerous methodologies/frameworks/paradigms/etc. out there, for any number of languages, that consistently produce successful products. Of course, those same methodologies/frameworks/paradigms/etc. can also consistently create dreck. I think the key is not so much in the methodologies/frameworks/paradigms/etc. as it is in the preparations made prior to the actual development of the code. In my experience, which includes long stretches of time at programming shops as well as technology consultancies, the most successful projects and products have been those in which a significant amount of time was spent, prior to actual coding, in developing the concept of the final product, the details of inner and outer workings, the documents supporting these details, solid planning (including time for unforeseeables), solid programming, peer review/oversight/auditing/whatever, testing, and more. Whether or not all of this was wrapped into Framework X, Methodology Y, or Paradigm Z was of very little import if all of the other factors were not there. I think that, in general, any standard, whether standardized at the individual; organization, or community at large, can be beneficial. But it tends to be only a small part of the larger process. Frameworks are great for taking care of core functionalities, methodologies are great for explaining how things should be done, and paradigm is a horrible word that should never have found its way into our lexicon but no matter what you use, or even if you don't use anything at all, if you don't have a solid pre- and post- coding process, you're still not going to produce a successful product. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Mosh Teitelbaum wrote: 4) Fusebox does have a learning curve (IMO, a pretty steep one if you want to truly and properly use all that FB offers) but once learned, you're in pretty good company (until the next release and then there usually seems to be another learning curve). GL drew on a cave wall: This is almost rediculous. I've seen complete newbies with little or no CF experience pick up fusebox in a week. Although I haven't been into FB4 yet, the transition from FB2 to FB3 took about a half hour. In less than the time it took me to read the Techspedition book, I had picked up Fusebox. But did I know it well enough to architect a perfect, completely Fusebox-compatible and -compliant system taking full advantage of all it offers? No. That takes experience. I picked up ColdFusion in about 4 hours. But was I as good with it 8 years ago as I am now? No. Because now I have 8 years of experience with it that I didn't have back then. The fact that someone can pick something up in a short amount of time says absolutely nothing about their ability to turn it around and make something useful. As a purely hypothetical example (with no offense intended to Fuseboxers or the newbies in question), I have to assume that your newbies were used as coders and not architects. Given that Fusebox is advertised as being able to separate coders from having to actually know anything about the system that they're developing, it doesn't say much for people who require a week to learn how to code individual files each of which perform a single task and are fully documented and spec'ed out. Now I suspect that your newbies were something of an exaggeration. And my example was intended to bring that to the fore, but my point remains... something as (relatively) complex as Fusebox cannot be fully learned in that short a time frame. And every time it changes, it needs to be relearned. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
This is almost rediculous. I've seen complete newbies with little or no CF experience pick up fusebox in a week. Although I haven't been into FB4 yet, the transition from FB2 to FB3 took about a half hour. 4) Fusebox does have a learning curve (IMO, a pretty steep one if you want to truly and properly use all that FB offers) but once learned, you're in pretty good company (until the next release and then there usually seems to be another learning curve). -Original Message- From: Mosh Teitelbaum [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:27 PM To: CF-Talk Subject: RE: Cons to Fusebox Brian: I appreciate all the effort you've been pouring into this thread. That said, allow *me* to back up a bit 8^). I am familiar with FB3 and have had opportunities to use it and its various features. I've also spent some (but not enough) time going over FB4 and I'm fairly well aware of what new features it brings to the table. All that said, I was never actually interested in discussing the pros/cons of Fusebox (despite the unfortunate email subject). I was really interested (and still am) in the pros/cons of one aspect of Fusebox... the controller. The central index.cfm file that all requests must pass through. That said, this thread has become interesting to me in its own right. To date, the main and generic points that I've noticed being made in this thread are, in no particular order: 1) Some people love FB, others hate it, still others don't care, and everyone seems to be very passionate about it all (except maybe for those who don't care). 2) Fusebox doesn't offer anything that can't otherwise be accomplished, however, it essentially prepackages it for you so you don't have to worry about it. 3) Fusebox offers its own set of advantages and disadvantages (perceived or actual) and it's up to the individual developer/architect to determine whether or not the tradeoffs make sense for that developer or project. 4) Fusebox does have a learning curve (IMO, a pretty steep one if you want to truly and properly use all that FB offers) but once learned, you're in pretty good company (until the next release and then there usually seems to be another learning curve). 5) While I wouldn't call Fusebox the de facto ColdFusion framework (there are too many people/sites not using it for that) it is certainly the most popular and used ColdFusion framework out there. 6) Fusebox is not a panacea. It's just as easy to write crappy code in FB as it is to write crappy code without FB. From my own perspective, and arguably for my own personal reasons, Fusebox tends to be too much for me. It doesn't overwhelm me, it just offers too much stuff that I don't feel I need, and doesn't offer other stuff that I do want. It also requires a style of managing/writing code that I don't find beneficial. I'm willing to be flexible and change my coding style and mannerisms when I see benefit in doing so but, again for my own reasons, I don't find FB's way of doing things to be beneficial to what I do. Finally, FB tends to restrict how projects can be organized. I don't know much about FLiP but what I do seems to be impractical for how my own experiences suggest most projects succeed. I recognize that any framework will restrict to some extent how you do what you do, but I find FB's restrictions to be too restrictive/impractical. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ -Original Message- From: Brian Kotek [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 10:26 AM To: CF-Talk Subject: Cons to Fusebox Mosh, I think we're getting wrapped up too much in specifics. Let me back up for a moment. First, XFA's are not required, only suggested. You can write an entire FB app without a single XFA. They just offer some nice benefits, like: keeping decisions about application flow in the realm of the architect. keeping decisions about application flow out of any individual code file. allowing you to change at runtime how the application behaves. allowing for components that respond differently in different situations. So, the decision on whether or not to use XFA's is a personal one. If you think this is not worth the effort (though in reality the effort required is neglegible), then you aren't required to use it. Regarding reuse and the question of building up end content from smaller pieces, this too is a decision, not a requirement. But having the ability to do this by adding a single attribute to an XML element is pretty impressive, at least to me. Let me give a more realistic example: Someone calls the controller to execute the fuseaction store.productDetails. The store circuit is targeted, and the action productDetails is executed. productDetails is a controller-level action so it doesn't do anything itself. Instead it invokes
RE: Cons to Fusebox
This debate has been informative, but not really about pros or cons of Fusebox. I didn't realize there were so many developers out there that dislike a proven tool because they don't have the time/energy to understand it. I've never heard a developer who's actually architected and developed a project with FB say I wish I hadn't used FB. Just developers that adopt code and don't understand how it works, or it's done differently then they do it. There is a principle which is a bar against all information, which is proof against all arguments and which cannot fail to keep a man in everlasting ignorance - that principle is contempt prior to investigation. Greg -Original Message- From: Michael Wilson [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 11:55 PM To: CF-Talk Subject: RE: Cons to Fusebox Hi, I'm sorry that you feel this is personally directed at you. I don't feel that way and never said that I did feel that way. I realize you aren't attacking any individual, much less me. This has actually been the best most informative Fusebox debate I have ever witnessed. I am glad I had the opportunity to speak during it. I reserve the right to answer honestly and fully. Of course you do. I would just like to hear a response with some meat to it; not necessarily from you, but in general. I would like to see examples that support views. Most of all I would like to see an unbiased opinion that is not based on trivial issues. Even though I don't speak out much, I have always respected your opinions. And I have always tried to keep an open mind, especially when it comes to frameworks and the like. I agree with some of the issues you raised; however others are, imo, minor obstacles with simple solutions and really don't reflect the bigger picture of the framework. These same types of obstacles also exist outside the realm of Fusebox. if kiss my ass is the best argument you can find, well, good luck with that Kiss my ass isn't my reply; sorry it seemed that way, I had intended it as a joke not as a direct comment towards you. I was commenting on your point about emoticons and certain remarks. Just because one smiles doesn't mean they think it is going to make you feel better or hope that their comments sit better with you. If I told you to kiss my ass and smiled about it, I would likely be smiling because it made me feel better; however childish it might be. :) I don't take offense to any of your comments; although, I disagree with many of them and as I said earlier I am not trying to convert you. I apologize if my comments were too blunt; I posted too hastily on my way out of the office, which was irresponsible on my part. I think we all agree Fusebox isn't for everyone or every situation, but for me--at the moment--it is. Although I have nothing to gain personally, I hope it continues to grow as it has and that it becomes more useful to more people. I think Fb4 is a great stride in that direction. Best regards, Michael Wilson ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
This debate has been informative, but not really about pros or cons of Fusebox. I didn't realize there were so many developers out there that dislike a proven tool because they don't have the time/energy to understand it. I've never heard a developer who's actually architected and developed a project with FB say I wish I hadn't used FB. Just developers that adopt code and don't understand how it works, or it's done differently then they do it. Prior to FuseBox 4, there was a HUGE issue which meant that I couldn't/wouldn't use it; All of the FB files had to be held in folders under each website/application that it was running on When you run 30-40 sites on the same technology, spread over 3-4 servers, this was completely unusable With FB4 allowing centralised files, this helped an awful lot, but there are still restrictions I tried to build an app on FB2, then another client wanted a site with exactly the same technology - this meant duplicating the files over the 2 folders - whenever I did updates, I had to upload to 2 locations Over time it went to several more sites, thus more uploads At that point, I thought I REALLY wish I hadn't used FuseBox for this - I had to scrap most of the code and start again It would have been easier to have started with a centralised system - at the time, FuseBox was fine for individual sites, but as soon as you wanted the same technology on multiple sites, it became unmanageable... At this point, I'm too far away from anything FuseBox to convert to it, and I'm happy developing my way - although the current FuseBox architecture is VERY similar to the system I designed for myself about 4 years ago, and am still using something very similar What does that say about FuseBox? ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Oh, in that case fusebox sucks. I'm not going to use it anymore! You're the smartest guy ever! Greg -Original Message- From: Philip Arnold [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2003 11:46 AM To: CF-Talk Subject: RE: Cons to Fusebox This debate has been informative, but not really about pros or cons of Fusebox. I didn't realize there were so many developers out there that dislike a proven tool because they don't have the time/energy to understand it. I've never heard a developer who's actually architected and developed a project with FB say I wish I hadn't used FB. Just developers that adopt code and don't understand how it works, or it's done differently then they do it. Prior to FuseBox 4, there was a HUGE issue which meant that I couldn't/wouldn't use it; All of the FB files had to be held in folders under each website/application that it was running on When you run 30-40 sites on the same technology, spread over 3-4 servers, this was completely unusable With FB4 allowing centralised files, this helped an awful lot, but there are still restrictions I tried to build an app on FB2, then another client wanted a site with exactly the same technology - this meant duplicating the files over the 2 folders - whenever I did updates, I had to upload to 2 locations Over time it went to several more sites, thus more uploads At that point, I thought I REALLY wish I hadn't used FuseBox for this - I had to scrap most of the code and start again It would have been easier to have started with a centralised system - at the time, FuseBox was fine for individual sites, but as soon as you wanted the same technology on multiple sites, it became unmanageable... At this point, I'm too far away from anything FuseBox to convert to it, and I'm happy developing my way - although the current FuseBox architecture is VERY similar to the system I designed for myself about 4 years ago, and am still using something very similar What does that say about FuseBox? ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
On Thursday, Jul 17, 2003, at 21:41 US/Pacific, Mosh Teitelbaum wrote: So first, as has been stated to death in this thread, there are tons of different ways of accomplishing the same thing. I recognize this, agree with it, respect it. What I'm really asking is, why is *this* a better way of obtaining these benefits then any other way? Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... Concerning the points you mentioned, other than point (a), all of this can be accomplished via constructive use of Application.cfm and OnRequestEnd.cfm. True, and for some folks, that will be the right choice. In general, I hear folks saying that HTML / layout should not be handled by those two special files tho'... As far as hiding the file structure goes, I'm not sure I find it a truly useful benefit given what I perceive to be its downsides. Your mileage may vary, as they say. Your instance in which you had to merge your blogs shows it can be useful but -- and no offense intended here, Sean -- it sounds like more of a short term hack than a long term solution. I'd be only too happy for someone to figure out why, after upgrading my Hurricane Electric account to new software revs, I can no longer access the old blog database files. It's true that creating a new blog is a 'hack' but it was either that or stay 'off the air' for longer while I try to migrate the old data. I, personally, don't care how the problem is resolved... My point was that I can wrap the blog in standardized URLs and provide a more consistent user experience no matter what happens under the hood. I would think it'd be a better idea to simply merge the old data with the new (preferably via automation if available). Yes, it would. You're welcome to help me. So far my ISP has not provided any feedback on why the blog broke. Otherwise, you have to maintain 2 separate systems, regardless of how similar they look. Nope. The old stuff is a static archive now. No maintenance needed. But the downsides of hiding the file system by way of a Request controller are pretty hefty, IMO: 1) Some search engines will not be able to index your site, or more than a few pages of your site. For example, if I recall correctly, Google will only index dynamic pages that are linked to from a static page. How does it do with a site that is so obviously dynamic vs. site's where dynamic pages get non-assuming, unique URLs (/blog/index.cfm - /blog/entry.cfm?ID=5)? Er, rubbish! Google, along with most other search engines these days, has NO PROBLEM WHATSOEVER with 'dynamic URLs'... I'm surprised this old chestnut is still being trotted out! Google has no problems searching and indexing my Fusebox-based site. Sorry, but I really think this is a myth based on how things used to be... 2) Static sounding URLs are easier to remember. They shouldn't be, but they are. Most likely, this is because people are used to seeing a URL like /Products/SuperApp.cfm instead of index.cfm?go=Products.SuperApp. OK, I'll buy that. But that's why Macromedia (for example) has go URLs and some server-side redirects for 'obvious' URLs. It's also why, for example, my site has these URLs: http://www.corfield.org/coldfusion/ http://www.corfield.org/cplusplus/ http://www.corfield.org/weddings/ http://www.corfield.org/sean/ http://www.corfield.org/java/ etc Adding shortcut URLs is perfectly reasonable. 3) Additional overhead from the architect's perspective. I had mentioned this earlier in the thread; basically, the architect(s) must now define 2 hierarchical structures, the physical file system, and the virtual file system (regardless of you agree with the specific terminology). Sorry but I think this is a perfectly acceptable overhead - it reflects the real-world difference between the URL API structure (the public face of the site) and the file system structure (the private implementation of the site). The bigger the site, the more important this issue is and the more important the distinction is. I deal with a 45,000 page website every day that has thousands of go URLs and thousands of server-side redirects that support the public URL API - juggling the contrasting requirements of the public interface and the implementation is a necessary part of my job. Concerning a single source for controlling a site's presentation, this (a) can be done any number of other ways (obviously) and (b) can have it's own issues. Trade offs. You can accomplish this by including header/footer files from App.cfm ...which a lot of people seem to consider bad practice... However, what if you want to display the common header/footer but only on certain pages Sure, what ifs always complicate matters and there are a number of options and solutions. As soon as you get into 'custom' solutions, you start to stray from a
RE: Cons to Fusebox
Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... This for me (being a small shop) is why I've extensively adopted a framework like Fusebox. Most of my projects are not going to become an Amazon.com anytime soon, while this doesn't mean I should write sloppy code - it does allow the flexibility of allowing a bit of a processing overhead in lieu of manageability and the ability to bring in external talent to easily assist me in changes (if needed) by providing a good set of standards and the Fusebox docs. I don't have to spend precious time educating another developer on the intricacies of a custom framework. Despite what organizations like Rational think (in the sense that there is no such thing as RAD development) - I mean, come on now, how many developers out there have had the I needed it yesterday conversation with a client? I find having the ability to quickly find and make changes to medium sized projects, forced structuring of code and application processes to be a boon. Erik Yowell [EMAIL PROTECTED] http://www.shortfusemedia.com ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: URLs and abstraction (was: RE: Cons to Fusebox)
2) Static sounding URLs are easier to remember. They shouldn't be, but they are. Most likely, this is because people are used to seeing a URL like /Products/SuperApp.cfm instead of index.cfm?go=Products.SuperApp. OK, I'll buy that. But that's why Macromedia (for example) has go URLs and some server-side redirects for 'obvious' URLs. It's also why, for example, my site has these URLs: http://www.corfield.org/coldfusion/ http://www.corfield.org/cplusplus/ http://www.corfield.org/weddings/ http://www.corfield.org/sean/ http://www.corfield.org/java/ etc Adding shortcut URLs is perfectly reasonable. So, you're fixing the problem caused by one layer of abstraction by applying another? It seems easier to forego the abstraction entirely. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
XFA? - Original Message - From: Mosh Teitelbaum [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 1:39 AM Subject: RE: Cons to Fusebox snip Yes, but the earlier comments I was responding to were suggesting that Fusebox allows individual developers to know Fusebox but not have to know the specific details of the current FB implementation. For example, the developer can know to read the FuseDoc at the top of the file and can know to plugin FORM ACTION=#someXFA# but not have to know that sometimes this form targets foo.add and other times targets foo.edit. As an example of why this is problematic, if the developer doesn't know about both targets, he can't know to test his code against both targets. It also makes it more difficult to debug any problem that crop up. Adding some code to fix one problem may unknowingly cause another problem when going to a different target. snip ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Mosh Teitelbaum wrote: Concerning the points you mentioned, other than point (a), all of this can be accomplished via constructive use of Application.cfm and OnRequestEnd.cfm. Sean A Corfield wrote: True, and for some folks, that will be the right choice. In general, I hear folks saying that HTML / layout should not be handled by those two special files tho'... I was think more in terms of including the appropriate display file from App.cfm rather than actually embedding the HTML code directly in the file. But, as you said, personal preference. I would think it'd be a better idea to simply merge the old data with the new (preferably via automation if available). Yes, it would. You're welcome to help me. So far my ISP has not provided any feedback on why the blog broke. If I only had the time 8^). Otherwise, you have to maintain 2 separate systems, regardless of how similar they look. Nope. The old stuff is a static archive now. No maintenance needed. No plans to add features and functionality? No plans to change the look and feel? etc. 1) Some search engines will not be able to index your site, or more than a few pages of your site. For example, if I recall correctly, Google will only index dynamic pages that are linked to from a static page. How does it do with a site that is so obviously dynamic vs. site's where dynamic pages get non-assuming, unique URLs (/blog/index.cfm - /blog/entry.cfm?ID=5)? Er, rubbish! Google, along with most other search engines these days, has NO PROBLEM WHATSOEVER with 'dynamic URLs'... I'm surprised this old chestnut is still being trotted out! Google has no problems searching and indexing my Fusebox-based site. Sorry, but I really think this is a myth based on how things used to be... I didn't say that Google has problems with dynamic URLs, only that it will not index dynamic URLs beyond a certain point. This, at least, is my understanding of the situation. I did a quick search on Google (http://www.google.com/search?hl=enlr=ie=UTF-8oe=UTF-8q=google+index+dyn amic+pages+site%3Agoogle.com) and got the following: http://www.google.com/webmasters/2.html 1. Reasons your site may not be included. * Your pages are dynamically generated. We are able to index dynamically generated pages. However, because our web crawler can easily overwhelm and crash sites serving dynamic content, we limit the amount of dynamic pages we index. and http://www.google.com/webmasters/guidelines.html Design and Content Guidelines: ... * If you decide to use dynamic pages (i.e., the URL contains a '?' character), be aware that not every search engine spider crawls dynamic pages as well as static pages. It helps to keep the parameters short and the number of them small. I'd love to hear that I'm wrong. And, in fact, Google doesn't prove me correct, but it does seem to somewhat validate my concern. Sorry but I think this is a perfectly acceptable overhead - it reflects the real-world difference between the URL API structure (the public face of the site) and the file system structure (the private implementation of the site). The bigger the site, the more important this issue is and the more important the distinction is. I deal with a 45,000 page website every day that has thousands of go URLs and thousands of server-side redirects that support the public URL API - juggling the contrasting requirements of the public interface and the implementation is a necessary part of my job. So, as you said earlier, it's really a trade-off. You can go the non-controller route and save yourself the added work of managing public and private file systems. Or you can go the controller route and enjoy the benefits if you find them worthwhile. You can accomplish this by including header/footer files from App.cfm ...which a lot of people seem to consider bad practice... Yeah, I've never understood that, but we can save that for another thread. I'm still recovering from this one 8^). However, what if you want to display the common header/footer but only on certain pages Sure, what ifs always complicate matters and there are a number of options and solutions. As soon as you get into 'custom' solutions, you start to stray from a framework and more into bespoke development. I was simply pointing out a downside of using the controller to apply global design elements. I would think that any good framework modeled around controllers would allow for exceptions since, in practice, many sites have this kind of need. And finally, concerning the central controller, I actually prefer using a central controller for logic. But I'm questioning the usefulness for a *REQUEST* controller. The difference is that the request controller receives all HTTP requests and passes control to another file or files. But you
Re: Cons to Fusebox
X(exit) F(fuse) A(actions) - Original Message - From: Calvin Ward [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 1:37 PM Subject: Re: Cons to Fusebox XFA? - Original Message - From: Mosh Teitelbaum [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 1:39 AM Subject: RE: Cons to Fusebox snip Yes, but the earlier comments I was responding to were suggesting that Fusebox allows individual developers to know Fusebox but not have to know the specific details of the current FB implementation. For example, the developer can know to read the FuseDoc at the top of the file and can know to plugin FORM ACTION=#someXFA# but not have to know that sometimes this form targets foo.add and other times targets foo.edit. As an example of why this is problematic, if the developer doesn't know about both targets, he can't know to test his code against both targets. It also makes it more difficult to debug any problem that crop up. Adding some code to fix one problem may unknowingly cause another problem when going to a different target. snip ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: URLs and abstraction (was: RE: Cons to Fusebox)
One is for administration and maintenance, and one is for usabilty. Is www.macromedia.com/software/coldfusion hard to remember? No, but it might change to www.macromedia.com/software/servers/coldfusion next week. www.macromedia.com/go/coldfusion, on the other hand, will NEVER change, and gives MM the ability to muck with their URLs as they need to. That level of abstraction should be used for all application that intend for people to jump into the middle, regardless of what their URLs actually look like. If you have controlled access (a login form) then it's probably irrelevant, since people will have to start at the homepage, but for anything else, it's a really good idea, especially content-heavy sites. barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 7:23 AM To: CF-Talk Subject: RE: URLs and abstraction (was: RE: Cons to Fusebox) 2) Static sounding URLs are easier to remember. They shouldn't be, but they are. Most likely, this is because people are used to seeing a URL like /Products/SuperApp.cfm instead of index.cfm?go=Products.SuperApp. OK, I'll buy that. But that's why Macromedia (for example) has go URLs and some server-side redirects for 'obvious' URLs. It's also why, for example, my site has these URLs: http://www.corfield.org/coldfusion/ http://www.corfield.org/cplusplus/ http://www.corfield.org/weddings/ http://www.corfield.org/sean/ http://www.corfield.org/java/ etc Adding shortcut URLs is perfectly reasonable. So, you're fixing the problem caused by one layer of abstraction by applying another? It seems easier to forego the abstraction entirely. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common sense in lieu of a framework. I think frameworks are extremely valuable and can make an enormous difference in the success of web applications especially where more than 3 people on working on them. Of course, picking the wrong framework for an application can lead to all sorts of problems, so the notion of one framework being the correct one in every case should be abandoned. Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I like to put that into perspective a bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure where that number comes from, but let's apply that to the number of CF developers, which is supposed to be about 300,000. That would mean about 6% of CF developers are using Fusebox. Now then, let's assume that 6% of Java developers are using Struts. Since there is supposed to be about 3,000,000 Java developers that would mean there would be 180,000 Java developers using Struts. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. BTW, if you don't buy the above numbers; take a look at the Amazon.com sales rankings for the 10+ struts books vs. the Fusebox books. -Matt On Friday, July 18, 2003, at 12:27 PM, Erik Yowell wrote: Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... This for me (being a small shop) is why I've extensively adopted a framework like Fusebox. Most of my projects are not going to become an Amazon.com anytime soon, while this doesn't mean I should write sloppy code - it does allow the flexibility of allowing a bit of a processing overhead in lieu of manageability and the ability to bring in external talent to easily assist me in changes (if needed) by providing a good set of standards and the Fusebox docs. I don't have to spend precious time educating another developer on the intricacies of a custom framework. Despite what organizations like Rational think (in the sense that there is no such thing as RAD development) - I mean, come on now, how many developers out there have had the I needed it yesterday conversation with a client? I find having the ability to quickly find and make changes to medium sized projects, forced structuring of code and application processes to be a boon. Erik Yowell [EMAIL PROTECTED] http://www.shortfusemedia.com ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
I think the most important thing with web applications is that you write your projects in ways that make it easy for other developers to come in and start working on it. You can either use an industry standard, or cowboy code it (http://c2.com/cgi/wiki?CowboyCoding) and hope that you are the only one who will use it AND have to rewrite aspects of your project that are already available in frameworks. If we all used the same framework, you could work on anyone else's project as if you were the original developer. Thats very beneficial. If you were a client and understood the difference, you would ask that your project is coded to an industry standard rather than the way a given developer happens to thinks is the best way they could code it. I'm sure there are some really great developers out there that can probably find reasons not to use industry standard frameworks for their own special reasons, but for the greater good of all of us and our work, standard coding methods will work to our advantage. Just my two cents! Jon -Original Message- From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 2:20 PM To: CF-Talk Subject: Cons to Fusebox Hey everyone, Some co-workers have asked me for some pros and cons to Fusebox 4 or Fusebox in general. I polled the Fusebox list awhile back and obviously got some biased results... anyone care to chime in I guess im really looking for some cons as I have a decent list of pros. Thanks, Mike ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Hi Mosh, I was think more in terms of including the appropriate display file from App.cfm You can most certainly do this (I used to), but it isn't much different than building the switch file and may or may not (I can't say for sure) offer the same level of control you get with Fusebox. I'd love to hear that I'm wrong. And, in fact, Google doesn't prove me correct, but it does seem to somewhat validate my concern. I don't think it is a huge issue any longer; however, you could always use Fusebox SES to overcome this issue. It is a painless implementation that produces search engine safe and friendly urls. This was an issue that was addressed a couple of years ago, when dynamic urls of any type had an impact on site rankings. SES will convert index.cfm?fuseaction=myApp.MainPage to index.cfm/fuseaction/myApp.MainPage.cfm I was simply pointing out a downside of using the controller to apply global design elements. The upside is, at least with Fusebox, you have circuit level control of the design elements along with the new content variables. Fusebox offers a great deal of control over layout and circuit navigation. The ability to offer skins or custom views is quite a simple process. Best regards, Michael Wilson ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
Exactly so... Just an odd opinion. ColdFusion seems to shield the developer from the more arcane phraseology and syntax used by lower level languages, and Fusebox seems to introduce the arcane right back on top of it... - Calvin - Original Message - From: Michael T. Tangorre [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 1:38 PM Subject: Re: Cons to Fusebox X(exit) F(fuse) A(actions) - Original Message - From: Calvin Ward [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 1:37 PM Subject: Re: Cons to Fusebox XFA? - Original Message - From: Mosh Teitelbaum [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 1:39 AM Subject: RE: Cons to Fusebox snip Yes, but the earlier comments I was responding to were suggesting that Fusebox allows individual developers to know Fusebox but not have to know the specific details of the current FB implementation. For example, the developer can know to read the FuseDoc at the top of the file and can know to plugin FORM ACTION=#someXFA# but not have to know that sometimes this form targets foo.add and other times targets foo.edit. As an example of why this is problematic, if the developer doesn't know about both targets, he can't know to test his code against both targets. It also makes it more difficult to debug any problem that crop up. Adding some code to fix one problem may unknowingly cause another problem when going to a different target. snip ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Michael Wilson wrote: Hi Mosh, Howdy 8^) I was think more in terms of including the appropriate display file from App.cfm You can most certainly do this (I used to), but it isn't much different than building the switch file and may or may not (I can't say for sure) offer the same level of control you get with Fusebox. As it turns out, I don't include global headers/footers in App.cfm, etc. I was just pointing out alternative methods that provide a method of supporting global layouts. I believe the above was associated with appropriate layout mechanisms for a smallish website. I'd love to hear that I'm wrong. And, in fact, Google doesn't prove me correct, but it does seem to somewhat validate my concern. I don't think it is a huge issue any longer; however, you could always use Fusebox SES to overcome this issue. It is a painless implementation that produces search engine safe and friendly urls. This was an issue that was addressed a couple of years ago, when dynamic urls of any type had an impact on site rankings. SES will convert index.cfm?fuseaction=myApp.MainPage to index.cfm/fuseaction/myApp.MainPage.cfm Yup, I'm aware of SES and have used it quite often (not via Fusebox). Again, the above was my response explaining why Fusebox style URLs can/might be problematic. This whole thread began because I asked about pros and cons, not of using Fusebox, bit in using a controller (hub and spoke, what have you) for all requests just like Fusebox does. I wasn't actually interested in talking about Fusebox, but this thread has been fairly educational and entertaining to boot 8^). -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Calvin Ward said: ColdFusion seems to shield the developer from the more arcane phraseology and syntax used by lower level languages, and Fusebox seems to introduce the arcane right back on top of it... Calvin, in one sentence you articulated what I was unable to in, what... 100 across this thread? Nail on the head. I don't think CF needs to be complex to be understandable by coders other than the original one. CF is simple to follow and this is a benefit to be preserved, not thrown away in the interest of standardization, regardless of the fact it does have some inarguable benefits, the KISS principle should rule. Do I have a better solution? No, but this lack doesn't invalidate the right to make the observation, as some have suggested. If everyone just read Sean Corfield's code guidelines and took them to heart that'd be most of the battle won right there. Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc. http://mysecretbase.com -Original Message- From: Calvin Ward [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 11:39 AM To: CF-Talk Subject: Re: Cons to Fusebox Exactly so... Just an odd opinion. ColdFusion seems to shield the developer from the more arcane phraseology and syntax used by lower level languages, and Fusebox seems to introduce the arcane right back on top of it... - Calvin - Original Message - From: Michael T. Tangorre [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 1:38 PM Subject: Re: Cons to Fusebox X(exit) F(fuse) A(actions) - Original Message - From: Calvin Ward [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 1:37 PM Subject: Re: Cons to Fusebox XFA? - Original Message - From: Mosh Teitelbaum [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, July 18, 2003 1:39 AM Subject: RE: Cons to Fusebox snip Yes, but the earlier comments I was responding to were suggesting that Fusebox allows individual developers to know Fusebox but not have to know the specific details of the current FB implementation. For example, the developer can know to read the FuseDoc at the top of the file and can know to plugin FORM ACTION=#someXFA# but not have to know that sometimes this form targets foo.add and other times targets foo.edit. As an example of why this is problematic, if the developer doesn't know about both targets, he can't know to test his code against both targets. It also makes it more difficult to debug any problem that crop up. Adding some code to fix one problem may unknowingly cause another problem when going to a different target. snip ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Brian: I appreciate all the effort you've been pouring into this thread. That said, allow *me* to back up a bit 8^). I am familiar with FB3 and have had opportunities to use it and its various features. I've also spent some (but not enough) time going over FB4 and I'm fairly well aware of what new features it brings to the table. All that said, I was never actually interested in discussing the pros/cons of Fusebox (despite the unfortunate email subject). I was really interested (and still am) in the pros/cons of one aspect of Fusebox... the controller. The central index.cfm file that all requests must pass through. That said, this thread has become interesting to me in its own right. To date, the main and generic points that I've noticed being made in this thread are, in no particular order: 1) Some people love FB, others hate it, still others don't care, and everyone seems to be very passionate about it all (except maybe for those who don't care). 2) Fusebox doesn't offer anything that can't otherwise be accomplished, however, it essentially prepackages it for you so you don't have to worry about it. 3) Fusebox offers its own set of advantages and disadvantages (perceived or actual) and it's up to the individual developer/architect to determine whether or not the tradeoffs make sense for that developer or project. 4) Fusebox does have a learning curve (IMO, a pretty steep one if you want to truly and properly use all that FB offers) but once learned, you're in pretty good company (until the next release and then there usually seems to be another learning curve). 5) While I wouldn't call Fusebox the de facto ColdFusion framework (there are too many people/sites not using it for that) it is certainly the most popular and used ColdFusion framework out there. 6) Fusebox is not a panacea. It's just as easy to write crappy code in FB as it is to write crappy code without FB. From my own perspective, and arguably for my own personal reasons, Fusebox tends to be too much for me. It doesn't overwhelm me, it just offers too much stuff that I don't feel I need, and doesn't offer other stuff that I do want. It also requires a style of managing/writing code that I don't find beneficial. I'm willing to be flexible and change my coding style and mannerisms when I see benefit in doing so but, again for my own reasons, I don't find FB's way of doing things to be beneficial to what I do. Finally, FB tends to restrict how projects can be organized. I don't know much about FLiP but what I do seems to be impractical for how my own experiences suggest most projects succeed. I recognize that any framework will restrict to some extent how you do what you do, but I find FB's restrictions to be too restrictive/impractical. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ -Original Message- From: Brian Kotek [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 10:26 AM To: CF-Talk Subject: Cons to Fusebox Mosh, I think we're getting wrapped up too much in specifics. Let me back up for a moment. First, XFA's are not required, only suggested. You can write an entire FB app without a single XFA. They just offer some nice benefits, like: keeping decisions about application flow in the realm of the architect. keeping decisions about application flow out of any individual code file. allowing you to change at runtime how the application behaves. allowing for components that respond differently in different situations. So, the decision on whether or not to use XFA's is a personal one. If you think this is not worth the effort (though in reality the effort required is neglegible), then you aren't required to use it. Regarding reuse and the question of building up end content from smaller pieces, this too is a decision, not a requirement. But having the ability to do this by adding a single attribute to an XML element is pretty impressive, at least to me. Let me give a more realistic example: Someone calls the controller to execute the fuseaction store.productDetails. The store circuit is targeted, and the action productDetails is executed. productDetails is a controller-level action so it doesn't do anything itself. Instead it invokes a series of actions in the Model and the View to complete the user's request. In this case, it might call the model to query for product details, and the view to output those product details. Simple enough so far. But now... We take the resulting formatted output and capture it in a variable called a content component. So we have the formatted product details wrapped up in a variable. But why stop there? The controller can call more fuseactions in the Model and View, maybe to get recently viewed items, items similar to the current item being viewed, daily specials, etc. All of these are called separately, each one is
RE: Cons to Fusebox
Why are you comparing the numbers using a Java Framework to the numbers using a ColdFusion framework? Isn't that like comparing Appes to Oranges? It has no meaning. Does this mean that because there are more Java Programmers, we should all just stop using CF and move to Java?? Struts is the most popular framework for Java. It doesn't mean that Struts can be used in C++ Development, nor does it mean that it can be used in ColdFusion development (I did read the article on DevNet), but not everyone is doing cross Java/CFMX development. Instead compare Apples to Apples. Compare Struts to something like JADE (IBM) or Barracuda. Compare Fusebox to things like BlackBox or SmartObjects. Those are true comparisons I would like to see. -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:00 PM To: CF-Talk Subject: Re: Cons to Fusebox I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common sense in lieu of a framework. I think frameworks are extremely valuable and can make an enormous difference in the success of web applications especially where more than 3 people on working on them. Of course, picking the wrong framework for an application can lead to all sorts of problems, so the notion of one framework being the correct one in every case should be abandoned. Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I like to put that into perspective a bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure where that number comes from, but let's apply that to the number of CF developers, which is supposed to be about 300,000. That would mean about 6% of CF developers are using Fusebox. Now then, let's assume that 6% of Java developers are using Struts. Since there is supposed to be about 3,000,000 Java developers that would mean there would be 180,000 Java developers using Struts. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. BTW, if you don't buy the above numbers; take a look at the Amazon.com sales rankings for the 10+ struts books vs. the Fusebox books. -Matt On Friday, July 18, 2003, at 12:27 PM, Erik Yowell wrote: Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... This for me (being a small shop) is why I've extensively adopted a framework like Fusebox. Most of my projects are not going to become an Amazon.com anytime soon, while this doesn't mean I should write sloppy code - it does allow the flexibility of allowing a bit of a processing overhead in lieu of manageability and the ability to bring in external talent to easily assist me in changes (if needed) by providing a good set of standards and the Fusebox docs. I don't have to spend precious time educating another developer on the intricacies of a custom framework. Despite what organizations like Rational think (in the sense that there is no such thing as RAD development) - I mean, come on now, how many developers out there have had the I needed it yesterday conversation with a client? I find having the ability to quickly find and make changes to medium sized projects, forced structuring of code and application processes to be a boon. Erik Yowell [EMAIL PROTECTED] http://www.shortfusemedia.com ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox (sorry for the double post)
Sorry for the double post, I tried posting to the list from the HOF web site and then came home and didn't see it and figured it never got posted. So I rewrote and posted again. Wouldn't you know both of them came through at the same time. lol -Original Message- From: Sandy Clark [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 3:30 PM To: CF-Talk Subject: RE: Cons to Fusebox Why are you comparing the numbers using a Java Framework to the numbers using a ColdFusion framework? Isn't that like comparing Appes to Oranges? It has no meaning. Does this mean that because there are more Java Programmers, we should all just stop using CF and move to Java?? Struts is the most popular framework for Java. It doesn't mean that Struts can be used in C++ Development, nor does it mean that it can be used in ColdFusion development (I did read the article on DevNet), but not everyone is doing cross Java/CFMX development. Instead compare Apples to Apples. Compare Struts to something like JADE (IBM) or Barracuda. Compare Fusebox to things like BlackBox or SmartObjects. Those are true comparisons I would like to see. -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:00 PM To: CF-Talk Subject: Re: Cons to Fusebox I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common sense in lieu of a framework. I think frameworks are extremely valuable and can make an enormous difference in the success of web applications especially where more than 3 people on working on them. Of course, picking the wrong framework for an application can lead to all sorts of problems, so the notion of one framework being the correct one in every case should be abandoned. Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I like to put that into perspective a bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure where that number comes from, but let's apply that to the number of CF developers, which is supposed to be about 300,000. That would mean about 6% of CF developers are using Fusebox. Now then, let's assume that 6% of Java developers are using Struts. Since there is supposed to be about 3,000,000 Java developers that would mean there would be 180,000 Java developers using Struts. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. BTW, if you don't buy the above numbers; take a look at the Amazon.com sales rankings for the 10+ struts books vs. the Fusebox books. -Matt On Friday, July 18, 2003, at 12:27 PM, Erik Yowell wrote: Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... This for me (being a small shop) is why I've extensively adopted a framework like Fusebox. Most of my projects are not going to become an Amazon.com anytime soon, while this doesn't mean I should write sloppy code - it does allow the flexibility of allowing a bit of a processing overhead in lieu of manageability and the ability to bring in external talent to easily assist me in changes (if needed) by providing a good set of standards and the Fusebox docs. I don't have to spend precious time educating another developer on the intricacies of a custom framework. Despite what organizations like Rational think (in the sense that there is no such thing as RAD development) - I mean, come on now, how many developers out there have had the I needed it yesterday conversation with a client? I find having the ability to quickly find and make changes to medium sized projects, forced structuring of code and application processes to be a boon. Erik Yowell [EMAIL PROTECTED] http://www.shortfusemedia.com ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
Don't fight this people! This is not comparing oranges with apples this is just the right thing! 6% of Jave user use Strute, 6% of CF Developer use Fusebox! Struts compared to Fusebox...! That doesn't say much about Struts, but it tells a lot about Fusebox! Is has come a long way and it finally made it into the league where it receives serious considerations from a lot of high class programmers, that have been all time opponents! Congrats to Steve, Hal, Nat, John, Eric, Jeff and others that worked on it so faithfully and persistent.! This is a great! Made my day! And if you are out there Buddies, I hope it made your day as well! Matt thank you! Birgit Pauli-Haack PS: hey it's Friday chuckle Friday, July 18, 2003, 3:29:46 PM, you wrote: SC From: Matt Liotta [mailto:[EMAIL PROTECTED] SC Sent: Friday, July 18, 2003 2:00 PM SC To: CF-Talk SC Subject: Re: Cons to Fusebox SC I saw this thread mentioned on Sean's blog and I was thinking about SC rejoining this list before reading his blog, so here I am. I'm not SC interested in trying to rehash much of the debate since I am late to SC this thread, but I feel like it is important to make at least a couple SC of points. SC First, I largely agree with Dave's position in this debate, but I don't SC agree with him in regards to his application of common sense in lieu of SC a framework. I think frameworks are extremely valuable and can make an SC enormous difference in the success of web applications especially where SC more than 3 people on working on them. Of course, picking the wrong SC framework for an application can lead to all sorts of problems, so the SC notion of one framework being the correct one in every case should be SC abandoned. SC Second, I have seen numerous references by Fusebox people both in and SC out of this thread in regards to how the sheer number of people using SC Fusebox is an important point. I like to put that into perspective a SC bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure SC where that number comes from, but let's apply that to the number of CF SC developers, which is supposed to be about 300,000. That would mean SC about 6% of CF developers are using Fusebox. Now then, let's assume SC that 6% of Java developers are using Struts. Since there is supposed to SC be about 3,000,000 Java developers that would mean there would be SC 180,000 Java developers using Struts. SC There are a lot of reasons why one would use Struts over Fusebox and SC vice versa, but if sheer numbers matter to people than Struts is the SC way to go since it is used by a lot more people. BTW, if you don't buy SC the above numbers; take a look at the Amazon.com sales rankings for the SC 10+ struts books vs. the Fusebox books. SC -Matt SC On Friday, July 18, 2003, at 12:27 PM, Erik Yowell wrote: Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... This for me (being a small shop) is why I've extensively adopted a framework like Fusebox. Most of my projects are not going to become an Amazon.com anytime soon, while this doesn't mean I should write sloppy code - it does allow the flexibility of allowing a bit of a processing overhead in lieu of manageability and the ability to bring in external talent to easily assist me in changes (if needed) by providing a good set of standards and the Fusebox docs. I don't have to spend precious time educating another developer on the intricacies of a custom framework. Despite what organizations like Rational think (in the sense that there is no such thing as RAD development) - I mean, come on now, how many developers out there have had the I needed it yesterday conversation with a client? I find having the ability to quickly find and make changes to medium sized projects, forced structuring of code and application processes to be a boon. Erik Yowell [EMAIL PROTECTED] http://www.shortfusemedia.com SC ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Brian Kotek wrote: Mosh, you are probably the most even-headed person here. The observations you list here are pretty accurrate. And thanks for the kudos, I really am just trying to help. I really like Fusebox, but I do try hard not to be the zealot that some people think all Fuseboxers are. Personally I haven't run into anything that Fusebox couldn't handle, and I work on very large and complex applications with tens of thousands of lines of CF code. But if some folks do have challenges that Fusebox can't solve in an efficient way for them, then they shouldn't use Fusebox, it's just that simple. I appreciate your views on the subject as well. Sorry to spoil your thread by going beyond just talking about hub-and-spoke, but ya start answering questions and it just snowballs. It sure brought everyone out of the woodwork, didn't it? ;-) Indeed, it seems to have done just that. I wouldn't go so far as to say it spoiled it. The thread was well worth reading. Heck Sean found it interesting enough to stick in his blog 8^). So... anyone want to explain to me the pros/cons of... eh, nevermind 8^). -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
I don't see why comparing different kinds of framework is an issue if you limit your comparison to specifics that are shared by both. As I pointed out in my first email, there is no one framework that is best for all applications, so what the framework is or what it does is irrelevant to my point, which was in regards to sheer numbers. And since both frameworks have a following it is perfectly acceptable to compare that following. -Matt On Friday, July 18, 2003, at 03:07 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Interesting that you are comparing a Java Framework to a ColdFusion framework. Don't you think that is comparing Apples to Oranges? Within the Java World, Struts is by far the most adapted Framework of its kind. Within the ColdFusion world (and I am not just referring to CFMX here). Fusebox is the most adapted Framework of its kind. So don't compare Fusebox with Struts, compare it to BlackBox and SmartObjects. Those are the items within the same realm, just as you would compare Struts to Jade rather than comparing Struts to Zope. I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common sense in lieu of a framework. I think frameworks are extremely valuable and can make an enormous difference in the success of web applications especially where more than 3 people on working on them. Of course, picking the wrong framework for an application can lead to all sorts of problems, so the notion of one framework being the correct one in every case should be abandoned. Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I like to put that into perspective a bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure where that number comes from, but let's apply that to the number of CF developers, which is supposed to be about 300,000. That would mean about 6% of CF developers are using Fusebox. Now then, let's assume that 6% of Java developers are using Struts. Since there is supposed to be about 3,000,000 Java developers that would mean there would be 180,000 Java developers using Struts. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. BTW, if you don't buy the above numbers; take a look at the Amazon.com sales rankings for the 10+ struts books vs. the Fusebox books. -Matt On Friday, July 18, 2003, at 12:27 PM, Erik Yowell wrote: Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... This for me (being a small shop) is why I've extensively adopted a framework like Fusebox. Most of my projects are not going to become an Amazon.com anytime soon, while this doesn't mean I should write sloppy code - it does allow the flexibility of allowing a bit of a processing overhead in lieu of manageability and the ability to bring in external talent to easily assist me in changes (if needed) by providing a good set of standards and the Fusebox docs. I don't have to spend precious time educating another developer on the intricacies of a custom framework. Despite what organizations like Rational think (in the sense that there is no such thing as RAD development) - I mean, come on now, how many developers out there have had the I needed it yesterday conversation with a client? I find having the ability to quickly find and make changes to medium sized projects, forced structuring of code and application processes to be a boon. Erik Yowell [EMAIL PROTECTED] http://www.shortfusemedia.com ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
See my response to another email along similar lines. However, I'd to respond to your email a little differently. Based on my earlier message it could be said that there is 10 times as many Java developers as CF developers, so why would one use CF over Java? There are tons of answers to that question that I think most of us know. In fact, we know these answers so well that we disregard the number of Java developers as irrelevant. Now then... with so many more people using Struts as opposed to Fusebox (both of which can be used in Java and CF), why would one use Fusebox over Struts? The answers to that question aren't as important as realizing that most CF developers don't know them. Thus, whenever someone tries to sell Fusebox based on the number of people using it the obvious question remains, why not use something with a greater following? I don't use Struts or Fusebox, so I don't care. I only point this out to show how silly the whole 17,000 people use Fusebox and you should too line is. -Matt On Friday, July 18, 2003, at 03:29 PM, Sandy Clark wrote: Why are you comparing the numbers using a Java Framework to the numbers using a ColdFusion framework? Isn't that like comparing Appes to Oranges? It has no meaning. Does this mean that because there are more Java Programmers, we should all just stop using CF and move to Java?? Struts is the most popular framework for Java. It doesn't mean that Struts can be used in C++ Development, nor does it mean that it can be used in ColdFusion development (I did read the article on DevNet), but not everyone is doing cross Java/CFMX development. Instead compare Apples to Apples. Compare Struts to something like JADE (IBM) or Barracuda. Compare Fusebox to things like BlackBox or SmartObjects. Those are true comparisons I would like to see. -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:00 PM To: CF-Talk Subject: Re: Cons to Fusebox I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common sense in lieu of a framework. I think frameworks are extremely valuable and can make an enormous difference in the success of web applications especially where more than 3 people on working on them. Of course, picking the wrong framework for an application can lead to all sorts of problems, so the notion of one framework being the correct one in every case should be abandoned. Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I like to put that into perspective a bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure where that number comes from, but let's apply that to the number of CF developers, which is supposed to be about 300,000. That would mean about 6% of CF developers are using Fusebox. Now then, let's assume that 6% of Java developers are using Struts. Since there is supposed to be about 3,000,000 Java developers that would mean there would be 180,000 Java developers using Struts. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. BTW, if you don't buy the above numbers; take a look at the Amazon.com sales rankings for the 10+ struts books vs. the Fusebox books. -Matt On Friday, July 18, 2003, at 12:27 PM, Erik Yowell wrote: Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... This for me (being a small shop) is why I've extensively adopted a framework like Fusebox. Most of my projects are not going to become an Amazon.com anytime soon, while this doesn't mean I should write sloppy code - it does allow the flexibility of allowing a bit of a processing overhead in lieu of manageability and the ability to bring in external talent to easily assist me in changes (if needed) by providing a good set of standards and the Fusebox docs. I don't have to spend precious time educating another developer on the intricacies of a custom framework. Despite what organizations like Rational think (in the sense that there is no such thing as RAD development) - I mean, come on now, how many developers out there have had the I needed it yesterday conversation with a client? I find having the ability to quickly find and make changes to medium sized projects, forced structuring of code and application processes to be a boon. Erik Yowell [EMAIL
Re: Cons to Fusebox
On Thu, 17 Jul 2003 16:36:20 -0400, in cf-talk you wrote: In your experience, how often do you have one developer working on the form and another working on the action file? Answer: As I type. I know the form, and he knows what he's doing with XML storage and retrieval. Do I feel like learning his XML model, etc.? Do I care about developer number 3's DB model? No, she just feeds me result sets. I don't have time to know the entire app right now... eventually, but not right now, I've got work to do. This project would be a mess without Fusebox. Yes, I've run into problems using FB3 (FB4 promises remedies for my issues), but I haven't regretted FB for this project. Jamie ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
I didn't claim 6% of Java users use Struts nor did I claim that 6% of CF developers use Fusebox. I simply threw out anecdotal numbers for the sake a comparison. -Matt On Friday, July 18, 2003, at 03:45 PM, Birgit Pauli-Haack wrote: Don't fight this people! This is not comparing oranges with apples this is just the right thing! 6% of Jave user use Strute, 6% of CF Developer use Fusebox! Struts compared to Fusebox...! That doesn't say much about Struts, but it tells a lot about Fusebox! Is has come a long way and it finally made it into the league where it receives serious considerations from a lot of high class programmers, that have been all time opponents! Congrats to Steve, Hal, Nat, John, Eric, Jeff and others that worked on it so faithfully and persistent.! This is a great! Made my day! And if you are out there Buddies, I hope it made your day as well! Matt thank you! Birgit Pauli-Haack PS: hey it's Friday chuckle Friday, July 18, 2003, 3:29:46 PM, you wrote: SC From: Matt Liotta [mailto:[EMAIL PROTECTED] SC Sent: Friday, July 18, 2003 2:00 PM SC To: CF-Talk SC Subject: Re: Cons to Fusebox SC I saw this thread mentioned on Sean's blog and I was thinking about SC rejoining this list before reading his blog, so here I am. I'm not SC interested in trying to rehash much of the debate since I am late to SC this thread, but I feel like it is important to make at least a couple SC of points. SC First, I largely agree with Dave's position in this debate, but I don't SC agree with him in regards to his application of common sense in lieu of SC a framework. I think frameworks are extremely valuable and can make an SC enormous difference in the success of web applications especially where SC more than 3 people on working on them. Of course, picking the wrong SC framework for an application can lead to all sorts of problems, so the SC notion of one framework being the correct one in every case should be SC abandoned. SC Second, I have seen numerous references by Fusebox people both in and SC out of this thread in regards to how the sheer number of people using SC Fusebox is an important point. I like to put that into perspective a SC bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure SC where that number comes from, but let's apply that to the number of CF SC developers, which is supposed to be about 300,000. That would mean SC about 6% of CF developers are using Fusebox. Now then, let's assume SC that 6% of Java developers are using Struts. Since there is supposed to SC be about 3,000,000 Java developers that would mean there would be SC 180,000 Java developers using Struts. SC There are a lot of reasons why one would use Struts over Fusebox and SC vice versa, but if sheer numbers matter to people than Struts is the SC way to go since it is used by a lot more people. BTW, if you don't buy SC the above numbers; take a look at the Amazon.com sales rankings for the SC 10+ struts books vs. the Fusebox books. SC -Matt SC On Friday, July 18, 2003, at 12:27 PM, Erik Yowell wrote: Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... This for me (being a small shop) is why I've extensively adopted a framework like Fusebox. Most of my projects are not going to become an Amazon.com anytime soon, while this doesn't mean I should write sloppy code - it does allow the flexibility of allowing a bit of a processing overhead in lieu of manageability and the ability to bring in external talent to easily assist me in changes (if needed) by providing a good set of standards and the Fusebox docs. I don't have to spend precious time educating another developer on the intricacies of a custom framework. Despite what organizations like Rational think (in the sense that there is no such thing as RAD development) - I mean, come on now, how many developers out there have had the I needed it yesterday conversation with a client? I find having the ability to quickly find and make changes to medium sized projects, forced structuring of code and application processes to be a boon. Erik Yowell [EMAIL PROTECTED] http://www.shortfusemedia.com SC ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Hi, I don't see why You never do, Matt. :) is perfectly acceptable to compare that following Had you confined your comparison to ColdFusion frameworks your point would have much more validity. I do however agree with you that no framework is best for all situations and that the number of developers using a specific framework does not make it any more, or less, the right framework for the job at hand. By the way, shouldn't you be busy writing your next enlightening article or something? Just kidding... Just kidding. :) Best regards, Michael Wilson ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: RE: Cons to Fusebox
Don't prod Matt. He's really easy to goad :) - Original Message - From: Michael Wilson [EMAIL PROTECTED] Date: Friday, July 18, 2003 2:38 pm Subject: RE: Cons to Fusebox Hi, I don't see why You never do, Matt. :) is perfectly acceptable to compare that following Had you confined your comparison to ColdFusion frameworks your point would have much more validity. I do however agree with you that no framework is best for all situations and that the number of developers using a specificframework does not make it any more, or less, the right framework for the job at hand. By the way, shouldn't you be busy writing your next enlightening article or something? Just kidding... Just kidding. :) Best regards, Michael Wilson ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
I don't think the Fusebox people are using that X number to say that because there are so many X people using FB, so should you. Rather, it's there for informational purposes, and to say that, yeah, people are using it. Maybe not a lot in comparison to some other framework, but the only winner in a comparison like that is the most popular item in it's class. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 2:34 pm Subject: Re: Cons to Fusebox See my response to another email along similar lines. However, I'd to respond to your email a little differently. Based on my earlier message it could be said that there is 10 times as many Java developers as CF developers, so why would one use CF over Java? There are tons of answers to that question that I think most of us know. In fact, we know these answers so well that we disregard the number of Java developers as irrelevant. Now then... with so many more people using Struts as opposed to Fusebox (both of which can be used in Java and CF), why would one use Fusebox over Struts? The answers to that question aren't as important as realizing that most CF developers don't know them. Thus, whenever someone tries to sell Fusebox based on the number of people using it the obvious question remains, why not use something with a greater following? I don't use Struts or Fusebox, so I don't care. I only point this out to show how silly the whole 17,000 people use Fusebox and you should too line is. -Matt On Friday, July 18, 2003, at 03:29 PM, Sandy Clark wrote: Why are you comparing the numbers using a Java Framework to the numbers using a ColdFusion framework? Isn't that like comparing Appes to Oranges? It has no meaning. Does this mean that because there are more Java Programmers, we should all just stop using CF and move to Java?? Struts is the most popular framework for Java. It doesn't mean that Struts can be used in C++ Development, nor does it mean that it can be used in ColdFusion development (I did read the article on DevNet), but not everyone is doing cross Java/CFMX development. Instead compare Apples to Apples. Compare Struts to something like JADE (IBM) or Barracuda. Compare Fusebox to things like BlackBox or SmartObjects. Those are true comparisons I would like to see. -Original Message- From: Matt Liotta [EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:00 PM To: CF-Talk Subject: Re: Cons to Fusebox I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common sense in lieu of a framework. I think frameworks are extremely valuable and can make an enormous difference in the success of web applications especially where more than 3 people on working on them. Of course, picking the wrong framework for an application can lead to all sorts of problems, so the notion of one framework being the correct one in every case should be abandoned. Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I like to put that into perspective a bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure where that number comes from, but let's apply that to the number of CF developers, which is supposed to be about 300,000. That would mean about 6% of CF developers are using Fusebox. Now then, let's assume that 6% of Java developers are using Struts. Since there is supposed to be about 3,000,000 Java developers that would mean there would be 180,000 Java developers using Struts. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. BTW, if you don't buy the above numbers; take a look at the Amazon.com sales rankings for the 10+ struts books vs. the Fusebox books. -Matt On Friday, July 18, 2003, at 12:27 PM, Erik Yowell wrote: Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... This for me (being a small shop) is why I've extensively adopted a framework like Fusebox. Most of my projects are not going to become an Amazon.com anytime soon, while this doesn't mean I should write sloppy code - it does allow the flexibility of allowing a bit of a processing overhead in lieu of manageability
RE: Cons to Fusebox
Again, I don't think anyone can say they will use Fusebox in a Java World or Struts in a CF5 world. There is no comparison. If you are talking numbers as a way to go by your own supposition, there are 10 times the number of Java Developers. You can't compare the frameworks like that. There is no commonality in terms of ability to use them in the areas for which they are not designed. So I don't think that comparing Struts to Fusebox is a reasonable comparison. Its like saying there are more people in the world who drive cars rather than boats, cars sell better, therefore regardless of whether you are on land or water, you should be in a car. Cars are for land, boats are for water. Struts is for Java, Fusebox is for CFML. Personally I don't care how many people use something. To me that isn't a valid argument. What I am concerned about is what will work for me and the people who work with me in developing web applications quickly and cleanly. I have yet to be introduced to a framework that will work in both CF5 or CFMX that will help me structure my code and not have to worry about all the housekeeping, other than Fusebox. I've looked at BlackBox, I've looked at SmartObjects. Neither of them come close. If you have a framework that will work better in ColdFusion, then please introduce it to me. I have always said that I will be more then happy to drop Fusebox if something better comes along. I've always said it's a framework not a religion. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 4:24 PM To: CF-Talk Subject: Re: Cons to Fusebox I don't see why comparing different kinds of framework is an issue if you limit your comparison to specifics that are shared by both. As I pointed out in my first email, there is no one framework that is best for all applications, so what the framework is or what it does is irrelevant to my point, which was in regards to sheer numbers. And since both frameworks have a following it is perfectly acceptable to compare that following. -Matt On Friday, July 18, 2003, at 03:07 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Interesting that you are comparing a Java Framework to a ColdFusion framework. Don't you think that is comparing Apples to Oranges? Within the Java World, Struts is by far the most adapted Framework of its kind. Within the ColdFusion world (and I am not just referring to CFMX here). Fusebox is the most adapted Framework of its kind. So don't compare Fusebox with Struts, compare it to BlackBox and SmartObjects. Those are the items within the same realm, just as you would compare Struts to Jade rather than comparing Struts to Zope. I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common sense in lieu of a framework. I think frameworks are extremely valuable and can make an enormous difference in the success of web applications especially where more than 3 people on working on them. Of course, picking the wrong framework for an application can lead to all sorts of problems, so the notion of one framework being the correct one in every case should be abandoned. Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I like to put that into perspective a bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure where that number comes from, but let's apply that to the number of CF developers, which is supposed to be about 300,000. That would mean about 6% of CF developers are using Fusebox. Now then, let's assume that 6% of Java developers are using Struts. Since there is supposed to be about 3,000,000 Java developers that would mean there would be 180,000 Java developers using Struts. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. BTW, if you don't buy the above numbers; take a look at the Amazon.com sales rankings for the 10+ struts books vs. the Fusebox books. -Matt On Friday, July 18, 2003, at 12:27 PM, Erik Yowell wrote: Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... This for me (being a small shop) is why I've extensively adopted
Re: Cons to Fusebox
didn't say you did:-)) Anecdotally I am just having fun B. Friday, July 18, 2003, 4:37:41 PM, you wrote: ML I didn't claim 6% of Java users use Struts nor did I claim that 6% of ML CF developers use Fusebox. I simply threw out anecdotal numbers for the ML sake a comparison. ML -Matt ML On Friday, July 18, 2003, at 03:45 PM, Birgit Pauli-Haack wrote: Don't fight this people! This is not comparing oranges with apples this is just the right thing! 6% of Jave user use Strute, 6% of CF Developer use Fusebox! Struts compared to Fusebox...! That doesn't say much about Struts, but it tells a lot about Fusebox! Is has come a long way and it finally made it into the league where it receives serious considerations from a lot of high class programmers, that have been all time opponents! Congrats to Steve, Hal, Nat, John, Eric, Jeff and others that worked on it so faithfully and persistent.! This is a great! Made my day! And if you are out there Buddies, I hope it made your day as well! Matt thank you! Birgit Pauli-Haack PS: hey it's Friday chuckle Friday, July 18, 2003, 3:29:46 PM, you wrote: SC From: Matt Liotta [mailto:[EMAIL PROTECTED] SC Sent: Friday, July 18, 2003 2:00 PM SC To: CF-Talk SC Subject: Re: Cons to Fusebox SC I saw this thread mentioned on Sean's blog and I was thinking about SC rejoining this list before reading his blog, so here I am. I'm not SC interested in trying to rehash much of the debate since I am late to SC this thread, but I feel like it is important to make at least a couple SC of points. SC First, I largely agree with Dave's position in this debate, but I don't SC agree with him in regards to his application of common sense in lieu of SC a framework. I think frameworks are extremely valuable and can make an SC enormous difference in the success of web applications especially where SC more than 3 people on working on them. Of course, picking the wrong SC framework for an application can lead to all sorts of problems, so the SC notion of one framework being the correct one in every case should be SC abandoned. SC Second, I have seen numerous references by Fusebox people both in and SC out of this thread in regards to how the sheer number of people using SC Fusebox is an important point. I like to put that into perspective a SC bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure SC where that number comes from, but let's apply that to the number of CF SC developers, which is supposed to be about 300,000. That would mean SC about 6% of CF developers are using Fusebox. Now then, let's assume SC that 6% of Java developers are using Struts. Since there is supposed to SC be about 3,000,000 Java developers that would mean there would be SC 180,000 Java developers using Struts. SC There are a lot of reasons why one would use Struts over Fusebox and SC vice versa, but if sheer numbers matter to people than Struts is the SC way to go since it is used by a lot more people. BTW, if you don't buy SC the above numbers; take a look at the Amazon.com sales rankings for the SC 10+ struts books vs. the Fusebox books. SC -Matt SC On Friday, July 18, 2003, at 12:27 PM, Erik Yowell wrote: Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... This for me (being a small shop) is why I've extensively adopted a framework like Fusebox. Most of my projects are not going to become an Amazon.com anytime soon, while this doesn't mean I should write sloppy code - it does allow the flexibility of allowing a bit of a processing overhead in lieu of manageability and the ability to bring in external talent to easily assist me in changes (if needed) by providing a good set of standards and the Fusebox docs. I don't have to spend precious time educating another developer on the intricacies of a custom framework. Despite what organizations like Rational think (in the sense that there is no such thing as RAD development) - I mean, come on now, how many developers out there have had the I needed it yesterday conversation with a client? I find having the ability to quickly find and make changes to medium sized projects, forced structuring of code and application processes to be a boon. Erik Yowell [EMAIL PROTECTED] http://www.shortfusemedia.com SC ML ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
How about the following quote from this thread for example. When compared to the alternatives (no structure at all, someone's personal best guess at something, or some superior approach that conspicuously manages to never actually be revealed) it is the best thing I've found so far. And about 17,000 other people agree. -Matt On Friday, July 18, 2003, at 04:43 PM, [EMAIL PROTECTED] wrote: I don't think the Fusebox people are using that X number to say that because there are so many X people using FB, so should you. Rather, it's there for informational purposes, and to say that, yeah, people are using it. Maybe not a lot in comparison to some other framework, but the only winner in a comparison like that is the most popular item in it's class. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 2:34 pm Subject: Re: Cons to Fusebox See my response to another email along similar lines. However, I'd to respond to your email a little differently. Based on my earlier message it could be said that there is 10 times as many Java developers as CF developers, so why would one use CF over Java? There are tons of answers to that question that I think most of us know. In fact, we know these answers so well that we disregard the number of Java developers as irrelevant. Now then... with so many more people using Struts as opposed to Fusebox (both of which can be used in Java and CF), why would one use Fusebox over Struts? The answers to that question aren't as important as realizing that most CF developers don't know them. Thus, whenever someone tries to sell Fusebox based on the number of people using it the obvious question remains, why not use something with a greater following? I don't use Struts or Fusebox, so I don't care. I only point this out to show how silly the whole 17,000 people use Fusebox and you should too line is. -Matt On Friday, July 18, 2003, at 03:29 PM, Sandy Clark wrote: Why are you comparing the numbers using a Java Framework to the numbers using a ColdFusion framework? Isn't that like comparing Appes to Oranges? It has no meaning. Does this mean that because there are more Java Programmers, we should all just stop using CF and move to Java?? Struts is the most popular framework for Java. It doesn't mean that Struts can be used in C++ Development, nor does it mean that it can be used in ColdFusion development (I did read the article on DevNet), but not everyone is doing cross Java/CFMX development. Instead compare Apples to Apples. Compare Struts to something like JADE (IBM) or Barracuda. Compare Fusebox to things like BlackBox or SmartObjects. Those are true comparisons I would like to see. -Original Message- From: Matt Liotta [EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:00 PM To: CF-Talk Subject: Re: Cons to Fusebox I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common sense in lieu of a framework. I think frameworks are extremely valuable and can make an enormous difference in the success of web applications especially where more than 3 people on working on them. Of course, picking the wrong framework for an application can lead to all sorts of problems, so the notion of one framework being the correct one in every case should be abandoned. Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I like to put that into perspective a bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure where that number comes from, but let's apply that to the number of CF developers, which is supposed to be about 300,000. That would mean about 6% of CF developers are using Fusebox. Now then, let's assume that 6% of Java developers are using Struts. Since there is supposed to be about 3,000,000 Java developers that would mean there would be 180,000 Java developers using Struts. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. BTW, if you don't buy the above numbers; take a look at the Amazon.com sales rankings for the 10+ struts books vs. the Fusebox books. -Matt On Friday, July 18, 2003, at 12:27 PM, Erik Yowell wrote: Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... This for me (being a small shop) is why I've extensively
RE: Cons to Fusebox
If you wanna have fun,anecdotally or totally ,you should join us on the CF-Community list. ;-) Happy Friday! -Gel -Original Message- From: Birgit Pauli-Haack [mailto:[EMAIL PROTECTED] didn't say you did:-)) Anecdotally I am just having fun B. ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
I could have sworn the other I saw a demo of Struts running on CF and for that matter I seem to recall Fusebox on J2EE as well. Anyway... on to the rest of your email. Why do you want a framework from me that will work better than Fusebox for your needs? Wouldn't you be the best person to create such a framework. A better question is, why haven't you created a better framework for your needs? -Matt On Friday, July 18, 2003, at 04:46 PM, Sandy Clark wrote: Again, I don't think anyone can say they will use Fusebox in a Java World or Struts in a CF5 world. There is no comparison. If you are talking numbers as a way to go by your own supposition, there are 10 times the number of Java Developers. You can't compare the frameworks like that. There is no commonality in terms of ability to use them in the areas for which they are not designed. So I don't think that comparing Struts to Fusebox is a reasonable comparison. Its like saying there are more people in the world who drive cars rather than boats, cars sell better, therefore regardless of whether you are on land or water, you should be in a car. Cars are for land, boats are for water. Struts is for Java, Fusebox is for CFML. Personally I don't care how many people use something. To me that isn't a valid argument. What I am concerned about is what will work for me and the people who work with me in developing web applications quickly and cleanly. I have yet to be introduced to a framework that will work in both CF5 or CFMX that will help me structure my code and not have to worry about all the housekeeping, other than Fusebox. I've looked at BlackBox, I've looked at SmartObjects. Neither of them come close. If you have a framework that will work better in ColdFusion, then please introduce it to me. I have always said that I will be more then happy to drop Fusebox if something better comes along. I've always said it's a framework not a religion. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 4:24 PM To: CF-Talk Subject: Re: Cons to Fusebox I don't see why comparing different kinds of framework is an issue if you limit your comparison to specifics that are shared by both. As I pointed out in my first email, there is no one framework that is best for all applications, so what the framework is or what it does is irrelevant to my point, which was in regards to sheer numbers. And since both frameworks have a following it is perfectly acceptable to compare that following. -Matt On Friday, July 18, 2003, at 03:07 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Interesting that you are comparing a Java Framework to a ColdFusion framework. Don't you think that is comparing Apples to Oranges? Within the Java World, Struts is by far the most adapted Framework of its kind. Within the ColdFusion world (and I am not just referring to CFMX here). Fusebox is the most adapted Framework of its kind. So don't compare Fusebox with Struts, compare it to BlackBox and SmartObjects. Those are the items within the same realm, just as you would compare Struts to Jade rather than comparing Struts to Zope. I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common sense in lieu of a framework. I think frameworks are extremely valuable and can make an enormous difference in the success of web applications especially where more than 3 people on working on them. Of course, picking the wrong framework for an application can lead to all sorts of problems, so the notion of one framework being the correct one in every case should be abandoned. Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I like to put that into perspective a bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure where that number comes from, but let's apply that to the number of CF developers, which is supposed to be about 300,000. That would mean about 6% of CF developers are using Fusebox. Now then, let's assume that 6% of Java developers are using Struts. Since there is supposed to be about 3,000,000 Java developers that would mean there would be 180,000 Java developers using Struts. There are a lot of reasons why one would use
Re: Cons to Fusebox
That's Brian's own opinion. He is not a member of the Fusebox team. On Fusebox.org's web page: Fusebox is a standard framework and methodology for building web-based applications. Currently used by well over 17762 people from around the world, Fusebox attempts to reduce the 70% software failure rate (download 105KB) by creating a standard framework and methodology for writing web applications and managing web development projects. Nothing special there. Certainly doesn't sound like they're tooting their own horn. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 3:00 pm Subject: Re: Cons to Fusebox How about the following quote from this thread for example. When compared to the alternatives (no structure at all, someone's personal best guess at something, or some superior approach that conspicuously manages to never actually be revealed) it is the best thing I've found so far. And about 17,000 other people agree. -Matt On Friday, July 18, 2003, at 04:43 PM, [EMAIL PROTECTED] wrote: I don't think the Fusebox people are using that X number to say that because there are so many X people using FB, so should you. Rather, it's there for informational purposes, and to say that, yeah, people are using it. Maybe not a lot in comparison to some other framework, but the only winner in a comparison like that is the most popular item in it's class. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 2:34 pm Subject: Re: Cons to Fusebox See my response to another email along similar lines. However, I'd to respond to your email a little differently. Based on my earlier message it could be said that there is 10 times as many Java developers as CF developers, so why would one use CF over Java? There are tons of answers to that question that I think most of us know. In fact, we know these answers so well that we disregard the number of Java developers as irrelevant. Now then... with so many more people using Struts as opposed to Fusebox (both of which can be used in Java and CF), why would one use Fusebox over Struts? The answers to that question aren't as important as realizing that most CF developers don't know them. Thus, whenever someone tries to sell Fusebox based on the number of people using it the obvious question remains, why not use something with a greater following? I don't use Struts or Fusebox, so I don't care. I only point this out to show how silly the whole 17,000 people use Fusebox and you should too line is. -Matt On Friday, July 18, 2003, at 03:29 PM, Sandy Clark wrote: Why are you comparing the numbers using a Java Framework to the numbers using a ColdFusion framework? Isn't that like comparing Appes to Oranges? It has no meaning. Does this mean that because there are more Java Programmers, we should all just stop using CF and move to Java?? Struts is the most popular framework for Java. It doesn't mean that Struts can be used in C++ Development, nor does it mean that it can be used in ColdFusion development (I did read the article on DevNet), but not everyone is doing cross Java/CFMX development. Instead compare Apples to Apples. Compare Struts to something like JADE (IBM) or Barracuda. Compare Fusebox to things like BlackBox or SmartObjects. Those are true comparisons I would like to see. -Original Message- From: Matt Liotta [EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:00 PM To: CF-Talk Subject: Re: Cons to Fusebox I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common sense in lieu of a framework. I think frameworks are extremely valuable and can make an enormous difference in the success of web applications especially where more than 3 people on working on them. Of course, picking the wrong framework for an application can lead to all sorts of problems, so the notion of one framework being the correct one in every case should be abandoned. Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I like to put that into perspective a bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure where that number comes from, but let's apply that to the number of CF developers, which is supposed to be about 300,000. That would mean about 6% of CF
RE: Cons to Fusebox
And there, Matt, is the crux of the issue. There is a fairly substantial benefit to using a generic framework, even if it's not exactly what would be considered 'ideal'. First, you don't have to spend the time developing it, and second, you won't have to train every single person that comes in the door to work on your project. If I were to start a new project tomorrow, I could either grab Fusebox (or Struts, or whatever) and start architecting and coding, or I could start building a framework, and refine it and test it, and then start architecting and coding, once the framework is complete. Fusebox4 has been months in development; Struts 1.1 was much longer than that, and both have both been years from the initial get-go to now. I can get the majority of the functionality I want immediately by using an existing framework, and start the actual app (what I get paid for), or I can spend a long time making a custom framework that provides all the functionality I want first (and not get paid for it), and then develope the app. I'd have to make one hell of an improvement over existing frameworks for rolling my own to be an economical decision, even over the course of numerous applications developed with it. barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:03 PM To: CF-Talk Subject: Re: Cons to Fusebox I could have sworn the other I saw a demo of Struts running on CF and for that matter I seem to recall Fusebox on J2EE as well. Anyway... on to the rest of your email. Why do you want a framework from me that will work better than Fusebox for your needs? Wouldn't you be the best person to create such a framework. A better question is, why haven't you created a better framework for your needs? -Matt On Friday, July 18, 2003, at 04:46 PM, Sandy Clark wrote: Again, I don't think anyone can say they will use Fusebox in a Java World or Struts in a CF5 world. There is no comparison. If you are talking numbers as a way to go by your own supposition, there are 10 times the number of Java Developers. You can't compare the frameworks like that. There is no commonality in terms of ability to use them in the areas for which they are not designed. So I don't think that comparing Struts to Fusebox is a reasonable comparison. Its like saying there are more people in the world who drive cars rather than boats, cars sell better, therefore regardless of whether you are on land or water, you should be in a car. Cars are for land, boats are for water. Struts is for Java, Fusebox is for CFML. Personally I don't care how many people use something. To me that isn't a valid argument. What I am concerned about is what will work for me and the people who work with me in developing web applications quickly and cleanly. I have yet to be introduced to a framework that will work in both CF5 or CFMX that will help me structure my code and not have to worry about all the housekeeping, other than Fusebox. I've looked at BlackBox, I've looked at SmartObjects. Neither of them come close. If you have a framework that will work better in ColdFusion, then please introduce it to me. I have always said that I will be more then happy to drop Fusebox if something better comes along. I've always said it's a framework not a religion. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 4:24 PM To: CF-Talk Subject: Re: Cons to Fusebox I don't see why comparing different kinds of framework is an issue if you limit your comparison to specifics that are shared by both. As I pointed out in my first email, there is no one framework that is best for all applications, so what the framework is or what it does is irrelevant to my point, which was in regards to sheer numbers. And since both frameworks have a following it is perfectly acceptable to compare that following. -Matt On Friday, July 18, 2003, at 03:07 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Interesting that you are comparing a Java Framework to a ColdFusion framework. Don't you think that is comparing Apples to Oranges? Within the Java World, Struts is by far the most adapted Framework of its kind. Within the ColdFusion world (and I am not just referring to CFMX here). Fusebox is the most adapted Framework of its kind. So don't compare Fusebox with Struts, compare it to BlackBox and SmartObjects. Those are the items within the same realm, just as you would compare
RE: Cons to Fusebox
Since you are starting to misquote me, I think that I will stop posting lest it degenerate further. Thanks Matt, I think you made my point abundantly clear for me. ML Why do you want a framework from me that will work better than Fusebox for your needs? Wouldn't you be the best person to create such a framework. A better question is, why haven't you created a better framework for your needs? SC I have yet to be introduced to a framework that will work in both CF5 or CFMX that will help me structure my code and not have to worry about all the housekeeping, other than Fusebox. I've looked at BlackBox, I've looked at SmartObjects. Neither of them come close. If you have a framework that will work better in ColdFusion, then please introduce it to me. -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 5:03 PM To: CF-Talk Subject: Re: Cons to Fusebox I could have sworn the other I saw a demo of Struts running on CF and for that matter I seem to recall Fusebox on J2EE as well. Anyway... on to the rest of your email. Why do you want a framework from me that will work better than Fusebox for your needs? Wouldn't you be the best person to create such a framework. A better question is, why haven't you created a better framework for your needs? -Matt On Friday, July 18, 2003, at 04:46 PM, Sandy Clark wrote: Again, I don't think anyone can say they will use Fusebox in a Java World or Struts in a CF5 world. There is no comparison. If you are talking numbers as a way to go by your own supposition, there are 10 times the number of Java Developers. You can't compare the frameworks like that. There is no commonality in terms of ability to use them in the areas for which they are not designed. So I don't think that comparing Struts to Fusebox is a reasonable comparison. Its like saying there are more people in the world who drive cars rather than boats, cars sell better, therefore regardless of whether you are on land or water, you should be in a car. Cars are for land, boats are for water. Struts is for Java, Fusebox is for CFML. Personally I don't care how many people use something. To me that isn't a valid argument. What I am concerned about is what will work for me and the people who work with me in developing web applications quickly and cleanly. I have yet to be introduced to a framework that will work in both CF5 or CFMX that will help me structure my code and not have to worry about all the housekeeping, other than Fusebox. I've looked at BlackBox, I've looked at SmartObjects. Neither of them come close. If you have a framework that will work better in ColdFusion, then please introduce it to me. I have always said that I will be more then happy to drop Fusebox if something better comes along. I've always said it's a framework not a religion. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 4:24 PM To: CF-Talk Subject: Re: Cons to Fusebox I don't see why comparing different kinds of framework is an issue if you limit your comparison to specifics that are shared by both. As I pointed out in my first email, there is no one framework that is best for all applications, so what the framework is or what it does is irrelevant to my point, which was in regards to sheer numbers. And since both frameworks have a following it is perfectly acceptable to compare that following. -Matt On Friday, July 18, 2003, at 03:07 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Interesting that you are comparing a Java Framework to a ColdFusion framework. Don't you think that is comparing Apples to Oranges? Within the Java World, Struts is by far the most adapted Framework of its kind. Within the ColdFusion world (and I am not just referring to CFMX here). Fusebox is the most adapted Framework of its kind. So don't compare Fusebox with Struts, compare it to BlackBox and SmartObjects. Those are the items within the same realm, just as you would compare Struts to Jade rather than comparing Struts to Zope. I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common sense in lieu of a framework. I think frameworks are extremely valuable and can make an enormous difference in the success
RE: Cons to Fusebox
Dave, clearly we disagree on a fundamental level on many topics. I don't know you, but I can tell you are an intelligent person (maybe minus the sarcasm), so clearly you must have reasons for not liking Fusebox. All I can do is disagree. I tried to do it before, but now I'll make it more decisive: I'm bowing out of this discussion. I really don't like getting into exchanges like this, and it could go on for days, and I feel that the point (to get folks to examine Fusebox as an approach with many benefits) has been made. Honestly, I have better things to do. I've said my piece. Fusebox is there and ready for open consideration by anyone who has the interest in looking at it. I'll leave it to the individual reader to make their own comparisons between your common sense methodology (with all the detailed and helpful techniques you provided along with it) and Fusebox. ... Stace, while we wait for Dave's example apps and documentation of his development approach, I thought I'd let you know that lots of examples and framework code is available at www.fusebox.org for anyone to look at and try out. ;-) And why beholdest thou the mote that is in thy brother's eye, but considerest not the beam that is in thine own eye? I find it amusing that people think the use of an emoticon lets them say whatever they like without reproach. Maybe you should check your own sarcasm before pointing out mine. I think that my criticisms of Fusebox have been written clearly enough that you can understand them if you have a basic grasp of English. That doesn't mean that you have to agree with them, of course. But it does appear that you do not, in fact, have better things to do. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
I am aware that it is Brian's own opinion and that of anyone else who has made a statement like that. Whether Brian is associated with Fusebox officially is irrelevant. I shared the quote from this thread simply as an example in regards to the statement I made. -Matt On Friday, July 18, 2003, at 05:15 PM, [EMAIL PROTECTED] wrote: That's Brian's own opinion. He is not a member of the Fusebox team. On Fusebox.org's web page: Fusebox is a standard framework and methodology for building web-based applications. Currently used by well over 17762 people from around the world, Fusebox attempts to reduce the 70% software failure rate (download 105KB) by creating a standard framework and methodology for writing web applications and managing web development projects. Nothing special there. Certainly doesn't sound like they're tooting their own horn. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 3:00 pm Subject: Re: Cons to Fusebox How about the following quote from this thread for example. When compared to the alternatives (no structure at all, someone's personal best guess at something, or some superior approach that conspicuously manages to never actually be revealed) it is the best thing I've found so far. And about 17,000 other people agree. -Matt On Friday, July 18, 2003, at 04:43 PM, [EMAIL PROTECTED] wrote: I don't think the Fusebox people are using that X number to say that because there are so many X people using FB, so should you. Rather, it's there for informational purposes, and to say that, yeah, people are using it. Maybe not a lot in comparison to some other framework, but the only winner in a comparison like that is the most popular item in it's class. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 2:34 pm Subject: Re: Cons to Fusebox See my response to another email along similar lines. However, I'd to respond to your email a little differently. Based on my earlier message it could be said that there is 10 times as many Java developers as CF developers, so why would one use CF over Java? There are tons of answers to that question that I think most of us know. In fact, we know these answers so well that we disregard the number of Java developers as irrelevant. Now then... with so many more people using Struts as opposed to Fusebox (both of which can be used in Java and CF), why would one use Fusebox over Struts? The answers to that question aren't as important as realizing that most CF developers don't know them. Thus, whenever someone tries to sell Fusebox based on the number of people using it the obvious question remains, why not use something with a greater following? I don't use Struts or Fusebox, so I don't care. I only point this out to show how silly the whole 17,000 people use Fusebox and you should too line is. -Matt On Friday, July 18, 2003, at 03:29 PM, Sandy Clark wrote: Why are you comparing the numbers using a Java Framework to the numbers using a ColdFusion framework? Isn't that like comparing Appes to Oranges? It has no meaning. Does this mean that because there are more Java Programmers, we should all just stop using CF and move to Java?? Struts is the most popular framework for Java. It doesn't mean that Struts can be used in C++ Development, nor does it mean that it can be used in ColdFusion development (I did read the article on DevNet), but not everyone is doing cross Java/CFMX development. Instead compare Apples to Apples. Compare Struts to something like JADE (IBM) or Barracuda. Compare Fusebox to things like BlackBox or SmartObjects. Those are true comparisons I would like to see. -Original Message- From: Matt Liotta [EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:00 PM To: CF-Talk Subject: Re: Cons to Fusebox I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common sense in lieu of a framework. I think frameworks are extremely valuable and can make an enormous difference in the success of web applications especially where more than 3 people on working on them. Of course, picking the wrong framework for an application can lead to all sorts of problems, so the notion of one framework being the correct one in every case should be abandoned. Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I like to put that into perspective a bit
Re: Cons to Fusebox
From your original messsage: Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I'm saying that the official FB people do not do this. So, tell me again why Brian's comment somehow refutes this statement. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 3:25 pm Subject: Re: Cons to Fusebox I am aware that it is Brian's own opinion and that of anyone else who has made a statement like that. Whether Brian is associated with Fusebox officially is irrelevant. I shared the quote from this thread simply as an example in regards to the statement I made. -Matt On Friday, July 18, 2003, at 05:15 PM, [EMAIL PROTECTED] wrote: That's Brian's own opinion. He is not a member of the Fusebox team. On Fusebox.org's web page: Fusebox is a standard framework and methodology for building web-based applications. Currently used by well over 17762 people from around the world, Fusebox attempts to reduce the 70% software failure rate (download 105KB) by creating a standard framework and methodology for writing web applications and managing web development projects. Nothing special there. Certainly doesn't sound like they're tooting their own horn. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 3:00 pm Subject: Re: Cons to Fusebox How about the following quote from this thread for example. When compared to the alternatives (no structure at all, someone's personal best guess at something, or some superior approach that conspicuously manages to never actually be revealed) it is the best thing I've found so far. And about 17,000 other people agree. -Matt On Friday, July 18, 2003, at 04:43 PM, [EMAIL PROTECTED] wrote: I don't think the Fusebox people are using that X number to say that because there are so many X people using FB, so should you. Rather, it's there for informational purposes, and to say that, yeah, people are using it. Maybe not a lot in comparison to some other framework, but the only winner in a comparison like that is the most popular item in it's class. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 2:34 pm Subject: Re: Cons to Fusebox See my response to another email along similar lines. However, I'd to respond to your email a little differently. Based on my earlier message it could be said that there is 10 times as many Java developers as CF developers, so why would one use CF over Java? There are tons of answers to that question that I think most of us know. In fact, we know these answers so well that we disregard the number of Java developers as irrelevant. Now then... with so many more people using Struts as opposed to Fusebox (both of which can be used in Java and CF), why would one use Fusebox over Struts? The answers to that question aren't as important as realizing that most CF developers don't know them. Thus, whenever someone tries to sell Fusebox based on the number of people using it the obvious question remains, why not use something with a greater following? I don't use Struts or Fusebox, so I don't care. I only point this out to show how silly the whole 17,000 people use Fusebox and you should too line is. -Matt On Friday, July 18, 2003, at 03:29 PM, Sandy Clark wrote: Why are you comparing the numbers using a Java Framework to the numbers using a ColdFusion framework? Isn't that like comparing Appes to Oranges? It has no meaning. Does this mean that because there are more Java Programmers, we should all just stop using CF and move to Java?? Struts is the most popular framework for Java. It doesn't mean that Struts can be used in C++ Development, nor does it mean that it can be used in ColdFusion development (I did read the article on DevNet), but not everyone is doing cross Java/CFMX development. Instead compare Apples to Apples. Compare Struts to something like JADE (IBM) or Barracuda. Compare Fusebox to things like BlackBox or SmartObjects. Those are true comparisons I would like to see. -Original Message- From: Matt Liotta [EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:00 PM To: CF-Talk Subject: Re: Cons to Fusebox I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common
RE: Cons to Fusebox
Out of curiosity, Jamie, is this typical of all of your projects or just this particular one? Additionally, how do you (and all other appropriate developers on your project(s)) respond to changes in requirement that necessitate a change in display, logic, and data? Are the changes made by one person or three? If three, have you found it difficult to coordinate everyone's time and effort? -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ -Original Message- From: Jamie Jackson [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 4:35 PM To: CF-Talk Subject: Re: Cons to Fusebox On Thu, 17 Jul 2003 16:36:20 -0400, in cf-talk you wrote: In your experience, how often do you have one developer working on the form and another working on the action file? Answer: As I type. I know the form, and he knows what he's doing with XML storage and retrieval. Do I feel like learning his XML model, etc.? Do I care about developer number 3's DB model? No, she just feeds me result sets. I don't have time to know the entire app right now... eventually, but not right now, I've got work to do. This project would be a mess without Fusebox. Yes, I've run into problems using FB3 (FB4 promises remedies for my issues), but I haven't regretted FB for this project. Jamie ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
I am aware of what you are saying and I do NOT refute it with or without Brian's comment. However, since my original email never specified official Fusebox people I don't see the relevance. -Matt On Friday, July 18, 2003, at 05:31 PM, [EMAIL PROTECTED] wrote: From your original messsage: Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I'm saying that the official FB people do not do this. So, tell me again why Brian's comment somehow refutes this statement. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 3:25 pm Subject: Re: Cons to Fusebox I am aware that it is Brian's own opinion and that of anyone else who has made a statement like that. Whether Brian is associated with Fusebox officially is irrelevant. I shared the quote from this thread simply as an example in regards to the statement I made. -Matt On Friday, July 18, 2003, at 05:15 PM, [EMAIL PROTECTED] wrote: That's Brian's own opinion. He is not a member of the Fusebox team. On Fusebox.org's web page: Fusebox is a standard framework and methodology for building web-based applications. Currently used by well over 17762 people from around the world, Fusebox attempts to reduce the 70% software failure rate (download 105KB) by creating a standard framework and methodology for writing web applications and managing web development projects. Nothing special there. Certainly doesn't sound like they're tooting their own horn. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 3:00 pm Subject: Re: Cons to Fusebox How about the following quote from this thread for example. When compared to the alternatives (no structure at all, someone's personal best guess at something, or some superior approach that conspicuously manages to never actually be revealed) it is the best thing I've found so far. And about 17,000 other people agree. -Matt On Friday, July 18, 2003, at 04:43 PM, [EMAIL PROTECTED] wrote: I don't think the Fusebox people are using that X number to say that because there are so many X people using FB, so should you. Rather, it's there for informational purposes, and to say that, yeah, people are using it. Maybe not a lot in comparison to some other framework, but the only winner in a comparison like that is the most popular item in it's class. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 2:34 pm Subject: Re: Cons to Fusebox See my response to another email along similar lines. However, I'd to respond to your email a little differently. Based on my earlier message it could be said that there is 10 times as many Java developers as CF developers, so why would one use CF over Java? There are tons of answers to that question that I think most of us know. In fact, we know these answers so well that we disregard the number of Java developers as irrelevant. Now then... with so many more people using Struts as opposed to Fusebox (both of which can be used in Java and CF), why would one use Fusebox over Struts? The answers to that question aren't as important as realizing that most CF developers don't know them. Thus, whenever someone tries to sell Fusebox based on the number of people using it the obvious question remains, why not use something with a greater following? I don't use Struts or Fusebox, so I don't care. I only point this out to show how silly the whole 17,000 people use Fusebox and you should too line is. -Matt On Friday, July 18, 2003, at 03:29 PM, Sandy Clark wrote: Why are you comparing the numbers using a Java Framework to the numbers using a ColdFusion framework? Isn't that like comparing Appes to Oranges? It has no meaning. Does this mean that because there are more Java Programmers, we should all just stop using CF and move to Java?? Struts is the most popular framework for Java. It doesn't mean that Struts can be used in C++ Development, nor does it mean that it can be used in ColdFusion development (I did read the article on DevNet), but not everyone is doing cross Java/CFMX development. Instead compare Apples to Apples. Compare Struts to something like JADE (IBM) or Barracuda. Compare Fusebox to things like BlackBox or SmartObjects. Those are true comparisons I would like to see. -Original Message- From: Matt Liotta [EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:00 PM To: CF-Talk Subject: Re: Cons to Fusebox I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I
Re: Cons to Fusebox
I understand why it is desirable to have an existing framework as opposed to creating a new one. There is always a build or buy decision that needs to be made when it comes to new development and I trust everyone has a good handle on how to evaluate these decisions for themselves. In my previous life as a developer, the various organizations I worked for and applications I helped create benefitted greatly from a custom framework even when you include the cost in time and money it took to develop the framework. Further, I can say that in all cases, new hires were able to come up-to-speed immediately. Even though I no longer work at any of these companies my frameworks are still in place and the employees are developing quite fine without the original architect. I don't think that has anything to do with the framework; it's more a function of CFML being so easy to understand. -Matt On Friday, July 18, 2003, at 05:21 PM, Barney Boisvert wrote: And there, Matt, is the crux of the issue. There is a fairly substantial benefit to using a generic framework, even if it's not exactly what would be considered 'ideal'. First, you don't have to spend the time developing it, and second, you won't have to train every single person that comes in the door to work on your project. If I were to start a new project tomorrow, I could either grab Fusebox (or Struts, or whatever) and start architecting and coding, or I could start building a framework, and refine it and test it, and then start architecting and coding, once the framework is complete. Fusebox4 has been months in development; Struts 1.1 was much longer than that, and both have both been years from the initial get-go to now. I can get the majority of the functionality I want immediately by using an existing framework, and start the actual app (what I get paid for), or I can spend a long time making a custom framework that provides all the functionality I want first (and not get paid for it), and then develope the app. I'd have to make one hell of an improvement over existing frameworks for rolling my own to be an economical decision, even over the course of numerous applications developed with it. barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:03 PM To: CF-Talk Subject: Re: Cons to Fusebox I could have sworn the other I saw a demo of Struts running on CF and for that matter I seem to recall Fusebox on J2EE as well. Anyway... on to the rest of your email. Why do you want a framework from me that will work better than Fusebox for your needs? Wouldn't you be the best person to create such a framework. A better question is, why haven't you created a better framework for your needs? -Matt On Friday, July 18, 2003, at 04:46 PM, Sandy Clark wrote: Again, I don't think anyone can say they will use Fusebox in a Java World or Struts in a CF5 world. There is no comparison. If you are talking numbers as a way to go by your own supposition, there are 10 times the number of Java Developers. You can't compare the frameworks like that. There is no commonality in terms of ability to use them in the areas for which they are not designed. So I don't think that comparing Struts to Fusebox is a reasonable comparison. Its like saying there are more people in the world who drive cars rather than boats, cars sell better, therefore regardless of whether you are on land or water, you should be in a car. Cars are for land, boats are for water. Struts is for Java, Fusebox is for CFML. Personally I don't care how many people use something. To me that isn't a valid argument. What I am concerned about is what will work for me and the people who work with me in developing web applications quickly and cleanly. I have yet to be introduced to a framework that will work in both CF5 or CFMX that will help me structure my code and not have to worry about all the housekeeping, other than Fusebox. I've looked at BlackBox, I've looked at SmartObjects. Neither of them come close. If you have a framework that will work better in ColdFusion, then please introduce it to me. I have always said that I will be more then happy to drop Fusebox if something better comes along. I've always said it's a framework not a religion. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 4:24 PM To: CF-Talk Subject: Re: Cons to Fusebox I don't see why comparing different kinds
RE: Cons to Fusebox
-Original Message- From: Barney Boisvert [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 3:21 PM To: CF-Talk Subject: RE: Cons to Fusebox If I were to start a new project tomorrow, I could either grab Fusebox (or Struts, or whatever) and start architecting and coding, or I could start building a framework, and refine it and test it, and then start architecting and coding, once the framework is complete. Fusebox4 has been months in development; Struts 1.1 was much longer than that, and both have both been years from the initial get-go to now. I'm going to take this statement at face value for a moment, even though I suspect you mean differently. So, what I'm hearing is that your client says they want X, and you begin coding X immediately. But I do not see in you statement where the requirements gathering and planning process has taken place to determine if the client really wants X, or maybe X and Y and Z. If this is the case, then yes, FB may make it easy for you to backtrack and add Y and Z afterwards. But if you've done the requirements gathering beforehand (I'll assume you normally do Barney - this is simply for discussion puposes), then you would have planned for X Y and Z from the start, before any code was written. In which case, FB still doesn't really buy you anything that simply following good practices would. Yes, it makes things easier in some ways, however, so does Object Oriented Programming, and so does Struts, or any other methodology - even some home grown ones. As near as I can tell from this discussion, it comes down to a matter of coding style. If you prefer the FB style of coding, then do it. If you prefer a custom style of programming, then do it. There is no right way to do the code - other than making the application do what it's supposed to. My thoughts, not yours... Shawn ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Hi, Dave, you have been antagonistic since you started commenting on this thread. Fusebox will not cease to exist because you don't like it. It will, however, continue to grow as long as those of us who do use it present its benefits to others. Along with that growth will come improvements and enhancements that will make Fusebox even more useful and practical. I think your criticisms of Fusebox have been weak; hell Matt's observations made more sense. I have heard this same song and dance since Fusebox first came to be, but it is still rolling right along. It's not better it's not bigger it's just free, easy, and works. And, just because someone smiles when they tell you to kiss their ass, :), doesn't mean they hope you feel better about it. Best regards, Michael Wilson -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 5:24 PM To: CF-Talk Subject: RE: Cons to Fusebox And why beholdest thou the mote that is in thy brother's eye, but considerest not the beam that is in thine own eye? I find it amusing that people think the use of an emoticon lets them say whatever they like without reproach. Maybe you should check your own sarcasm before pointing out mine. I think that my criticisms of Fusebox have been written clearly enough that you can understand them if you have a basic grasp of English. That doesn't mean that you have to agree with them, of course. But it does appear that you do not, in fact, have better things to do. ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
I am aware of what you are saying and I do NOT refute it with or without Brian's comment. However, since my original email never specified official Fusebox people I don't see the relevance. My point was that although FB users like to spout off, the official FB people don't like to advocate FB in such a manner. I mean really, who cares if Brian said something like that? It's just his opinion about a product he uses. Big deal. -Matt On Friday, July 18, 2003, at 05:31 PM, [EMAIL PROTECTED] wrote: From your original messsage: Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I'm saying that the official FB people do not do this. So, tell me again why Brian's comment somehow refutes this statement. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 3:25 pm Subject: Re: Cons to Fusebox I am aware that it is Brian's own opinion and that of anyone else who has made a statement like that. Whether Brian is associated with Fusebox officially is irrelevant. I shared the quote from this thread simply as an example in regards to the statement I made. -Matt On Friday, July 18, 2003, at 05:15 PM, [EMAIL PROTECTED] wrote: That's Brian's own opinion. He is not a member of the Fusebox team. On Fusebox.org's web page: Fusebox is a standard framework and methodology for building web-based applications. Currently used by well over 17762 people from around the world, Fusebox attempts to reduce the 70% software failure rate (download 105KB) by creating a standard framework and methodology for writing web applications and managing web development projects. Nothing special there. Certainly doesn't sound like they're tooting their own horn. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 3:00 pm Subject: Re: Cons to Fusebox How about the following quote from this thread for example. When compared to the alternatives (no structure at all, someone's personal best guess at something, or some superior approach that conspicuously manages to never actually be revealed) it is the best thing I've found so far. And about 17,000 other people agree. -Matt On Friday, July 18, 2003, at 04:43 PM, [EMAIL PROTECTED] wrote: I don't think the Fusebox people are using that X number to say that because there are so many X people using FB, so should you. Rather, it's there for informational purposes, and to say that, yeah, people are using it. Maybe not a lot in comparison to some other framework, but the only winner in a comparison like that is the most popular item in it's class. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 2:34 pm Subject: Re: Cons to Fusebox See my response to another email along similar lines. However, I'd to respond to your email a little differently. Based on my earlier message it could be said that there is 10 times as many Java developers as CF developers, so why would one use CF over Java? There are tons of answers to that question that I think most of us know. In fact, we know these answers so well that we disregard the number of Java developers as irrelevant. Now then... with so many more people using Struts as opposed to Fusebox (both of which can be used in Java and CF), why would one use Fusebox over Struts? The answers to that question aren't as important as realizing that most CF developers don't know them. Thus, whenever someone tries to sell Fusebox based on the number of people using it the obvious question remains, why not use something with a greater following? I don't use Struts or Fusebox, so I don't care. I only point this out to show how silly the whole 17,000 people use Fusebox and you should too line is. -Matt On Friday, July 18, 2003, at 03:29 PM, Sandy Clark wrote: Why are you comparing the numbers using a Java Framework to the numbers using a ColdFusion framework? Isn't that like comparing Appes to Oranges? It has no meaning. Does this mean that because there are more Java Programmers, we should all just stop using CF and move to Java?? Struts is the most popular framework for Java. It doesn't mean that Struts can be used in C++ Development, nor does it mean that it can be used in ColdFusion development (I did read the article on DevNet), but not everyone is doing cross Java/CFMX development. Instead compare Apples to Apples. Compare Struts to something like JADE (IBM) or Barracuda. Compare Fusebox to things like BlackBox or SmartObjects. Those are true comparisons I would like to see. -Original Message- From
Re: RE: Cons to Fusebox
But if you've done the requirements gathering beforehand (I'll assume you normally do Barney - this is simply for discussion puposes), then you would have planned for X Y and Z from the start, before any code was written. As anyone who gathers requirements can attest to, getting every single requirement up front is impossible. ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Matt's here, party's over. LOL ;) -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:00 PM To: CF-Talk Subject: Re: Cons to Fusebox I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not interested in trying to rehash much of the debate since I am late to this thread, but I feel like it is important to make at least a couple of points. First, I largely agree with Dave's position in this debate, but I don't agree with him in regards to his application of common sense in lieu of a framework. I think frameworks are extremely valuable and can make an enormous difference in the success of web applications especially where more than 3 people on working on them. Of course, picking the wrong framework for an application can lead to all sorts of problems, so the notion of one framework being the correct one in every case should be abandoned. Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I like to put that into perspective a bit. According to Fusebox.org, there are 17756 using Fusebox. Not sure where that number comes from, but let's apply that to the number of CF developers, which is supposed to be about 300,000. That would mean about 6% of CF developers are using Fusebox. Now then, let's assume that 6% of Java developers are using Struts. Since there is supposed to be about 3,000,000 Java developers that would mean there would be 180,000 Java developers using Struts. There are a lot of reasons why one would use Struts over Fusebox and vice versa, but if sheer numbers matter to people than Struts is the way to go since it is used by a lot more people. BTW, if you don't buy the above numbers; take a look at the Amazon.com sales rankings for the 10+ struts books vs. the Fusebox books. -Matt On Friday, July 18, 2003, at 12:27 PM, Erik Yowell wrote: Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... This for me (being a small shop) is why I've extensively adopted a framework like Fusebox. Most of my projects are not going to become an Amazon.com anytime soon, while this doesn't mean I should write sloppy code - it does allow the flexibility of allowing a bit of a processing overhead in lieu of manageability and the ability to bring in external talent to easily assist me in changes (if needed) by providing a good set of standards and the Fusebox docs. I don't have to spend precious time educating another developer on the intricacies of a custom framework. Despite what organizations like Rational think (in the sense that there is no such thing as RAD development) - I mean, come on now, how many developers out there have had the I needed it yesterday conversation with a client? I find having the ability to quickly find and make changes to medium sized projects, forced structuring of code and application processes to be a boon. Erik Yowell [EMAIL PROTECTED] http://www.shortfusemedia.com ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
I was just giving Stace something to do while he waits for the small sample app he asked about, Dave. Ah, I see. At least now, you're omitting the emoticon. If I say that no particular structure is needed solely to organize your CF code, why would you expect me to provide one? Why would I have a sample application to demonstrate this? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
It may not be a big deal to you, but many people are on this list because they care about the opinions of others. In fact, I believe this thread started with one developer asking for the opinions of others. If there weren't any opinions to debate in this thread then there wouldn't be any substance either. -Matt On Friday, July 18, 2003, at 06:01 PM, [EMAIL PROTECTED] wrote: I am aware of what you are saying and I do NOT refute it with or without Brian's comment. However, since my original email never specified official Fusebox people I don't see the relevance. My point was that although FB users like to spout off, the official FB people don't like to advocate FB in such a manner. I mean really, who cares if Brian said something like that? It's just his opinion about a product he uses. Big deal. -Matt On Friday, July 18, 2003, at 05:31 PM, [EMAIL PROTECTED] wrote: From your original messsage: Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I'm saying that the official FB people do not do this. So, tell me again why Brian's comment somehow refutes this statement. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 3:25 pm Subject: Re: Cons to Fusebox I am aware that it is Brian's own opinion and that of anyone else who has made a statement like that. Whether Brian is associated with Fusebox officially is irrelevant. I shared the quote from this thread simply as an example in regards to the statement I made. -Matt On Friday, July 18, 2003, at 05:15 PM, [EMAIL PROTECTED] wrote: That's Brian's own opinion. He is not a member of the Fusebox team. On Fusebox.org's web page: Fusebox is a standard framework and methodology for building web-based applications. Currently used by well over 17762 people from around the world, Fusebox attempts to reduce the 70% software failure rate (download 105KB) by creating a standard framework and methodology for writing web applications and managing web development projects. Nothing special there. Certainly doesn't sound like they're tooting their own horn. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 3:00 pm Subject: Re: Cons to Fusebox How about the following quote from this thread for example. When compared to the alternatives (no structure at all, someone's personal best guess at something, or some superior approach that conspicuously manages to never actually be revealed) it is the best thing I've found so far. And about 17,000 other people agree. -Matt On Friday, July 18, 2003, at 04:43 PM, [EMAIL PROTECTED] wrote: I don't think the Fusebox people are using that X number to say that because there are so many X people using FB, so should you. Rather, it's there for informational purposes, and to say that, yeah, people are using it. Maybe not a lot in comparison to some other framework, but the only winner in a comparison like that is the most popular item in it's class. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 2:34 pm Subject: Re: Cons to Fusebox See my response to another email along similar lines. However, I'd to respond to your email a little differently. Based on my earlier message it could be said that there is 10 times as many Java developers as CF developers, so why would one use CF over Java? There are tons of answers to that question that I think most of us know. In fact, we know these answers so well that we disregard the number of Java developers as irrelevant. Now then... with so many more people using Struts as opposed to Fusebox (both of which can be used in Java and CF), why would one use Fusebox over Struts? The answers to that question aren't as important as realizing that most CF developers don't know them. Thus, whenever someone tries to sell Fusebox based on the number of people using it the obvious question remains, why not use something with a greater following? I don't use Struts or Fusebox, so I don't care. I only point this out to show how silly the whole 17,000 people use Fusebox and you should too line is. -Matt On Friday, July 18, 2003, at 03:29 PM, Sandy Clark wrote: Why are you comparing the numbers using a Java Framework to the numbers using a ColdFusion framework? Isn't that like comparing Appes to Oranges? It has no meaning. Does this mean that because there are more Java Programmers, we should all just stop using CF and move to Java?? Struts is the most popular framework for Java. It doesn't mean that Struts can be used in C++ Development, nor does it mean that it can be used in ColdFusion development (I did read the article on DevNet), but not everyone is doing cross Java/CFMX development. Instead
RE: Cons to Fusebox
Dave, you have been antagonistic since you started commenting on this thread. I think it's unfortunate that you confuse criticism with antagonism. Fusebox will not cease to exist because you don't like it. I should hope not. Frankly, it doesn't bother me that people use Fusebox, or that people like it. I wouldn't be surprised if I'd worked with as many Fusebox applications as you have. When I am asked to fix an application, I don't ever suggest that they avoid using Fusebox if they're already using it - and that question actually comes up a lot. You'll notice that not once, in this thread or others, have I said that people shouldn't use it - things like this are decisions that people should make for themselves. But, when asked how I feel about it myself, I reserve the right to answer honestly and fully. Especially when the thread is called Cons to Fusebox. I'm sorry that you feel this is personally directed at you. It isn't. But you may find it useful to understand that adults can disagree about things, and provide arguments to justify their positions, without feeling personal animus. It'll help you get through life. It will, however, continue to grow as long as those of us who do use it present its benefits to others. Well, that's good. Maybe it'll grow into something that I'll like, too. Who knows? I'm actually interested in the Mach II stuff, although I haven't spent very long looking into it so far. And, just because someone smiles when they tell you to kiss their ass, :), doesn't mean they hope you feel better about it. No, but it does point out that person's own thin skin and hypocrisy. And if kiss my ass is the best argument you can find, well, good luck with that. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Dave, the argument that Fusebox doesn't solve any real problems is a very interesting perspective, and one I haven't really heard before. I can't say I agree with it, but I certainly see it's validity. In fact, it's probably one of the more valid arguments against Fusebox that I've heard, and certainly one that can't be relegated to the he/she just doesn't know enough about Fusebox category. Well, it's certainly possible that I don't know enough about it. I don't write Fusebox applications from scratch, although I do work on other people's Fusebox applications very often. I suspect that a lot of my distaste for Fusebox stems from that. The problem that I run into, simply stated, is that Fusebox developers spend too much time organizing their CF code, and not enough time figuring out what should be in CF and what shouldn't, or what should be done at runtime and what shouldn't. For example, I can't count the times that I've seen code like this in Fusebox (and non-Fusebox) applications: cfquery name=foo ... SELECT a bunch of records /cfquery cfloop query=foo ... ... do a bunch of calculations, and/or execute other queries /cfloop When I see something like that, I'm inclined to think that the developers should spend less time learning Fusebox, and more time learning SQL. This is a long email, and I've taken way more time than I should have to carefully craft a cohesive response. I've attempted to keep my pro-Fusebox bias out of the picture, with purely objective references to it. I suspect that both sides could use this effectively as an argument for themselves, but hopefully intelligence will overcome petty differences, and this will provide a solid description of Fusebox from one who intimately understands it's inner workings, but isn't trying to push it on the world. I think you've done a very good job with this response, for what that's worth. In any Fusebox app, if you see a file that starts with dsp_ you instantly know that it has very little logic, if any, and outputs something to the client, usually HTML. You might use d_ prefixes, maybe it's a directory for display template, I don't know, so I'd have to learn them if I took over your app. If we're both using Fusebox, that bump, however inconsequential it is, would not exist. I submit that this bump is inconsequential, and that the bump in moving to Fusebox may be greater. But I don't think it makes much difference either way. My experience has been that the CF code itself tends to be easy to figure out. The framework also provides a very raw form of documentation for the application. ... Now, you can certainly say that the roadmap aspect of Fusebox could easily be duplicated with a non-Fusebox framework, or no framework at all. But if there is already a tool that takes care of all the administrative bookkeeping in dealing with making that roadmap also the functional driver for your app, why not use it? That strikes me as something that could be a compelling argument, at least if you don't already have some documentation process for this already. Do you find yourself going beyond this raw form of documentation anyway, though? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
Very true. However, Brian's statement really has nothing to do with what Fusebox offers. You decided to reply to it. I responded by merely saying that the official FB do not promote FB in such a manner, lest people get the wrong message from your post. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 4:13 pm Subject: Re: Cons to Fusebox It may not be a big deal to you, but many people are on this list because they care about the opinions of others. In fact, I believe this thread started with one developer asking for the opinions of others. If there weren't any opinions to debate in this thread then there wouldn't be any substance either. -Matt On Friday, July 18, 2003, at 06:01 PM, [EMAIL PROTECTED] wrote: I am aware of what you are saying and I do NOT refute it with or without Brian's comment. However, since my original email never specified official Fusebox people I don't see the relevance. My point was that although FB users like to spout off, the official FB people don't like to advocate FB in such a manner. I mean really, who cares if Brian said something like that? It's just his opinion about a product he uses. Big deal. -Matt On Friday, July 18, 2003, at 05:31 PM, [EMAIL PROTECTED] wrote: From your original messsage: Second, I have seen numerous references by Fusebox people both in and out of this thread in regards to how the sheer number of people using Fusebox is an important point. I'm saying that the official FB people do not do this. So, tell me again why Brian's comment somehow refutes this statement. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 3:25 pm Subject: Re: Cons to Fusebox I am aware that it is Brian's own opinion and that of anyone else who has made a statement like that. Whether Brian is associated with Fusebox officially is irrelevant. I shared the quote from this thread simply as an example in regards to the statement I made. -Matt On Friday, July 18, 2003, at 05:15 PM, [EMAIL PROTECTED] wrote: That's Brian's own opinion. He is not a member of the Fusebox team. On Fusebox.org's web page: Fusebox is a standard framework and methodology for building web-based applications. Currently used by well over 17762 people from around the world, Fusebox attempts to reduce the 70% software failure rate (download 105KB) by creating a standard framework and methodology for writing web applications and managing web development projects. Nothing special there. Certainly doesn't sound like they're tooting their own horn. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 3:00 pm Subject: Re: Cons to Fusebox How about the following quote from this thread for example. When compared to the alternatives (no structure at all, someone's personal best guess at something, or some superior approach that conspicuously manages to never actually be revealed) it is the best thing I've found so far. And about 17,000 other people agree. -Matt On Friday, July 18, 2003, at 04:43 PM, [EMAIL PROTECTED] wrote: I don't think the Fusebox people are using that X number to say that because there are so many X people using FB, so should you. Rather, it's there for informational purposes, and to say that, yeah, people are using it. Maybe not a lot in comparison to some other framework, but the only winner in a comparison like that is the most popular item in it's class. - Original Message - From: Matt Liotta [EMAIL PROTECTED] Date: Friday, July 18, 2003 2:34 pm Subject: Re: Cons to Fusebox See my response to another email along similar lines. However, I'd to respond to your email a little differently. Based on my earlier message it could be said that there is 10 times as many Java developers as CF developers, so why would one use CF over Java? There are tons of answers to that question that I think most of us know. In fact, we know these answers so well that we disregard the number of Java developers as irrelevant. Now then... with so many more people using Struts as opposed to Fusebox (both of which can be used in Java and CF), why would one use Fusebox over Struts? The answers to that question aren't as important as realizing that most CF developers don't know them. Thus, whenever someone tries to sell Fusebox based on the number of people using it the obvious question remains, why not use something with a greater following? I don't use Struts or Fusebox, so I don't care. I only point this out to show how silly the whole 17,000 people use Fusebox and you should too line is. -Matt On Friday, July 18, 2003, at 03:29 PM, Sandy Clark wrote: Why are you
Re: Cons to Fusebox
But regarding the quote about 17,000 people, I'll say this. As with anything, looking at ONLY the number of people doing something is a poor gauge of the worth of that thing. However, the fact that far, far more people use Fusebox than any other ColdFusion methodology DOES indeed carry meaning. Why is this? What is it about Fusebox that makes it the most successful development framework among ColdFusion developers? I'd actually say the most successful framework in CF, and every other web development language, is the page-centric model. ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
I'm not going to get involved much further in this thread because just about everything has been said. I think you're already involved as deeply as possible. Folks who don't like Fusebox still don't like it. While I still don't like it, I do have a better understanding of why others might like it, and perhaps would even agree that it may help some people with their development process. Without this thread, I probably wouldn't have that understanding. Folks that like Fusebox still like it. Folks who don't know about Fusebox, or haven't looked at it lately, might have reason to investigate it further. And it is to those people, not the detractors or the evangalists, that my effort has truly been directed. And in that case, your participation was certainly a good thing. I would strongly recommend that people take a look at anything they think might help them be better developers, with the caveat that they shouldn't believe everything anyone says, and judge for themselves. Part of the answer is that Fusebox just works. Seriously, how do you measure that? But the majority of folks using it clearly are not having failures; they are having successes. Perhaps. I doubt that either of us have access to useful statistics on that point. But let's say that you're right about this. In that case, are they successful because of Fusebox? Or are they successful because they're the kind of people more likely to think about how their application is structured? Or are they successful because any rigid framework is better than no rigid framework? You may not think these questions are important, but I do. In my experience, the successful projects I've seen (Fusebox and non-Fusebox) tended to be successful in my estimation because the people on those projects were more thoughtful about them, before they started writing code. But the real benefit to having a huge, and ever growing, base of Fusebox developers, is the speed at which these developers can understand, maintain, and contribute to existing Fusebox applications. The more people who use it, the more widespread the standard becomes and the more likely development projects are to adopt it. It's a symbiotic relationship; a cycle. While some may claim that new developers can come into an existing project and instantly pick up whatever custom framework or architecture is used, I believe that in reality this happens extremely rarely. I think everyone will agree that just because ColdFusion is an easy language to understand does not necessarily mean that all ColdFusion applications are easy to understand. Again, in my experience, I've run into two things which make me doubt this. First, I've seen plenty of competent developers who were easily able to figure out what's going on in a current project, without it using Fusebox or any other framework as formal. Second, I've seen plenty of Fusebox code where no one (including other experienced Fusebox developers on the same project) could make heads or tails out of it. Of course, that's just my anecdotal experience, and yours may differ. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: URLs and abstraction (was: RE: Cons to Fusebox)
One is for administration and maintenance, and one is for usabilty. Is www.macromedia.com/software/coldfusion hard to remember? No, but it might change to www.macromedia.com/software/servers/coldfusion next week. www.macromedia.com/go/coldfusion, on the other hand, will NEVER change, and gives MM the ability to muck with their URLs as they need to. That level of abstraction should be used for all application that intend for people to jump into the middle, regardless of what their URLs actually look like. If you have controlled access (a login form) then it's probably irrelevant, since people will have to start at the homepage, but for anything else, it's a really good idea, especially content-heavy sites. That's a good argument, I suppose. I don't run into this very often; most everything I get to work on is more of an application with a highly structured path, or if it's a content-heavy site, it's using a CMS anyway. Also, two levels of abstraction in this case require additional setup/migration steps, so that if an application is put in a new environment, someone has to remember to create the redirects, unless they're done in CF rather than in the web server configuration. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
I didn't mean to spark controversy, I was actually just curious as to how Dave would approach any given app...but as he pointed out afterwards...I don't think many folks make example apps of their own customized frameworks hehe ;-) As for FB...I've used variations of it since xfb days...and over the past year I've been absorbed into RIA with Flash/J2EE development so I'm a little out of the loop in the FB realm. As for mach-ii, I liked what I've seen so far...my initial response is that using this pre-built machinery is icky but I think I can get over my ego to try it out...hell, Ben's a smart cookie, I'm sure there's some good stuff in there to learn. ;) As for the more experienced folks on this list, I find Sean has the best attitude in that he approaches everything openly even if he doesn't like the initial vibe. Others, jump into these types of conversations just for the opportunity to belittle other people IMO. To each his own I guess...lol But if ya don't have something constructive to say then why not pipe it? If you're gonna challenge something then offer an alternative...otherwise all your doing is a disservice to list folks climbing the ranks in the development world trying to figure out which is the best road to take... Cheers all, Stace -Original Message- From: Brian Kotek [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 5:57 PM To: CF-Talk Subject: Cons to Fusebox I was just giving Stace something to do while he waits for the small sample app he asked about, Dave. Dave, clearly we disagree on a fundamental level on many topics. I don't know you, but I can tell you are an intelligent person (maybe minus the sarcasm), so clearly you must have reasons for not liking Fusebox. All I can do is disagree. I tried to do it before, but now I'll make it more decisive: I'm bowing out of this discussion. I really don't like getting into exchanges like this, and it could go on for days, and I feel that the point (to get folks to examine Fusebox as an approach with many benefits) has been made. Honestly, I have better things to do. I've said my piece. Fusebox is there and ready for open consideration by anyone who has the interest in looking at it. I'll leave it to the individual reader to make their own comparisons between your common sense methodology (with all the detailed and helpful techniques you provided along with it) and Fusebox. ... Stace, while we wait for Dave's example apps and documentation of his development approach, I thought I'd let you know that lots of examples and framework code is available at www.fusebox.org for anyone to look at and try out. ;-) And why beholdest thou the mote that is in thy brother's eye, but considerest not the beam that is in thine own eye? I find it amusing that people think the use of an emoticon lets them say whatever they like without reproach. Maybe you should check your own sarcasm before pointing out mine. I think that my criticisms of Fusebox have been written clearly enough that you can understand them if you have a basic grasp of English. That doesn't mean that you have to agree with them, of course. But it does appear that you do not, in fact, have better things to do. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Yes, I meant differently. I left out the entire fact-finding and prototyping, assuming that everyone does it via whatever means they deem appropriate, and all are reasonably successful. That process is a separate discussion altogether. I agree with your final paragraph completely. Meeting the spec is the foremost concern. However, you stated in your second paragragh that FB may make it easy for your to backtrack and add Y and Z afterwards. I've never seen a project that didn't evolve and grow over time (excepting the ones that were stillborn). It doesn't matter how well you do the initial development, 6 months or a year down the road, things will need to change. If they don't, either no one uses the app, or the planners/architects/developers were friggin' omnicient. cheers, barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com -Original Message- From: Shawn Grover [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 2:59 PM To: CF-Talk Subject: RE: Cons to Fusebox -Original Message- From: Barney Boisvert [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 3:21 PM To: CF-Talk Subject: RE: Cons to Fusebox If I were to start a new project tomorrow, I could either grab Fusebox (or Struts, or whatever) and start architecting and coding, or I could start building a framework, and refine it and test it, and then start architecting and coding, once the framework is complete. Fusebox4 has been months in development; Struts 1.1 was much longer than that, and both have both been years from the initial get-go to now. I'm going to take this statement at face value for a moment, even though I suspect you mean differently. So, what I'm hearing is that your client says they want X, and you begin coding X immediately. But I do not see in you statement where the requirements gathering and planning process has taken place to determine if the client really wants X, or maybe X and Y and Z. If this is the case, then yes, FB may make it easy for you to backtrack and add Y and Z afterwards. But if you've done the requirements gathering beforehand (I'll assume you normally do Barney - this is simply for discussion puposes), then you would have planned for X Y and Z from the start, before any code was written. In which case, FB still doesn't really buy you anything that simply following good practices would. Yes, it makes things easier in some ways, however, so does Object Oriented Programming, and so does Struts, or any other methodology - even some home grown ones. As near as I can tell from this discussion, it comes down to a matter of coding style. If you prefer the FB style of coding, then do it. If you prefer a custom style of programming, then do it. There is no right way to do the code - other than making the application do what it's supposed to. My thoughts, not yours... Shawn ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: RE: Cons to Fusebox
I think it's time from a group hug. Come on over Matt! :) - Original Message - From: Dave Watts [EMAIL PROTECTED] Date: Friday, July 18, 2003 5:02 pm Subject: RE: Cons to Fusebox I'm not going to get involved much further in this thread because just about everything has been said. I think you're already involved as deeply as possible. Folks who don't like Fusebox still don't like it. While I still don't like it, I do have a better understanding of why others might like it, and perhaps would even agree that it may help some peoplewith their development process. Without this thread, I probably wouldn't have that understanding. Folks that like Fusebox still like it. Folks who don't know about Fusebox, or haven't looked at it lately, might have reason to investigate it further. And it is to those people, not the detractors or the evangalists, that my effort has truly been directed. And in that case, your participation was certainly a good thing. I wouldstrongly recommend that people take a look at anything they think might help them be better developers, with the caveat that they shouldn't believe everything anyone says, and judge for themselves. Part of the answer is that Fusebox just works. Seriously, how do you measure that? But the majority of folks using it clearly are not having failures; they are having successes. Perhaps. I doubt that either of us have access to useful statistics on that point. But let's say that you're right about this. In that case, are they successful because of Fusebox? Or are they successful because they're the kind of people more likely to think about how their application is structured? Or are they successful because any rigid framework is betterthan no rigid framework? You may not think these questions are important, but I do. In my experience, the successful projects I've seen (Fusebox and non-Fusebox) tended to be successful in my estimation because the people on those projects were more thoughtful about them, before they started writing code. But the real benefit to having a huge, and ever growing, base of Fusebox developers, is the speed at which these developers can understand, maintain, and contribute to existing Fusebox applications. The more people who use it, the more widespread the standard becomes and the more likely development projects are to adopt it. It's a symbiotic relationship; a cycle. While some may claim that new developers can come into an existing project and instantly pick up whatever custom framework or architecture is used, I believe that in reality this happens extremely rarely. I think everyone will agree that just because ColdFusion is an easy language to understand does not necessarily mean that all ColdFusion applications are easy to understand. Again, in my experience, I've run into two things which make me doubt this. First, I've seen plenty of competent developers who were easily able to figure out what's going on in a current project, without it using Fusebox or any other framework as formal. Second, I've seen plenty of Fusebox codewhere no one (including other experienced Fusebox developers on the same project) could make heads or tails out of it. Of course, that's just my anecdotal experience, and yours may differ. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
Everyone enjoys discussing with Dave because he's so even keeled. Makes it so much easier to discuss a topic. - Original Message - From: Brian Kotek [EMAIL PROTECTED] Date: Friday, July 18, 2003 5:12 pm Subject: Cons to Fusebox Dave, I must admit that this is the nicest and most well-formed post I've seen from you on this thread. Honestly I don't mean to seem like I'm calling you out when I support people asking for sample code from you. It's just hard for me to accept arguments from people who say there is a better way, but then won't demonstrate it. I mean, I could say the best methodology is the build the best application methodology. There are no repeatable steps to this methodology, no way to document it in a way that someone else can use. But when you use it and you do it right, whooeee the results are amazing! I'm not going to get involved much further in this thread because just about everything has been said. I think you're already involved as deeply as possible. Actually I'm serious. I'm about to bail out just out of exhaustion...have you seen how many posts I've written? ;-) (that emoticon WAS meant to be humorous) And in that case, your participation was certainly a good thing. I would strongly recommend that people take a look at anything they think might help them be better developers, with the caveat that they shouldn't believeeverything anyone says, and judge for themselves. This is what I mean, thank you for that and I must admit that, in some ways, I have found it interesting, if not occasionally frustrating, to read your thoughts as well. Of course, that's just my anecdotal experience, and yours may differ. Yes, mine does. But that's OK. Anyway, sorry for the occasional heat...I can be a passionate guy. Regards, Brian ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: RE: Cons to Fusebox
Very true, as we both well know. However, if the requirement gathering is done, then the proper planning, the system you've built can normally handle these situations - regardless of what framework/architecture/methodology you've chosen. Shawn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 4:05 PM To: CF-Talk Subject: Re: RE: Cons to Fusebox But if you've done the requirements gathering beforehand (I'll assume you normally do Barney - this is simply for discussion puposes), then you would have planned for X Y and Z from the start, before any code was written. As anyone who gathers requirements can attest to, getting every single requirement up front is impossible. ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: URLs and abstraction (was: RE: Cons to Fusebox)
Oh, it's definitely an administrative hassle, but that's the job of the developer, make things easier on what are invariably idiot users. ;) Most of my apps are also very constrained on their flow, but I've written a couple where this kind of abstraction was essential. One of them, in particular greatly benefited from it. Subdomains (usually a better choise in my opinion) were out for some reason, so we had to do directory paths. Did a complete fuseboxing of the app without much in the way of visible changes (as a precursor to a substantial refactoring) and it was installed and running for a week before anyone noticed that the URLs were all different. Once it was fuseboxed, we were able to move stuff all around without changing many of the URLs from the initial fuseboxing, which was very nice. Those that did change were again protected by the extra URL abstraction for another URL-indifferent upgrade. There were major interface changes, but the access points were still the same from the user perspective. barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 4:14 PM To: CF-Talk Subject: RE: URLs and abstraction (was: RE: Cons to Fusebox) One is for administration and maintenance, and one is for usabilty. Is www.macromedia.com/software/coldfusion hard to remember? No, but it might change to www.macromedia.com/software/servers/coldfusion next week. www.macromedia.com/go/coldfusion, on the other hand, will NEVER change, and gives MM the ability to muck with their URLs as they need to. That level of abstraction should be used for all application that intend for people to jump into the middle, regardless of what their URLs actually look like. If you have controlled access (a login form) then it's probably irrelevant, since people will have to start at the homepage, but for anything else, it's a really good idea, especially content-heavy sites. That's a good argument, I suppose. I don't run into this very often; most everything I get to work on is more of an application with a highly structured path, or if it's a content-heavy site, it's using a CMS anyway. Also, two levels of abstraction in this case require additional setup/migration steps, so that if an application is put in a new environment, someone has to remember to create the redirects, unless they're done in CF rather than in the web server configuration. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Bravo, Judith! Exactly the proper perspective to have, in my opinion. Given an choice, I'll almost invariably choose to go my prefered framework for initial development. The exceptions would be if it's both simple and not going to be around long enough for the maintenance benefits a framework provides to matter much. If I take over an app that's not in my framework of choice, I'm certainly not going to rewrite it from scratch to use that framework. That's just foolish. However, as I make changes, I do incorporate what elements I can from my framework into the changes I make, with the hope that at some point in the future, enough of those elements will be present that tying it all together into a full implementation of the framework will be trvial enough to justify the wasted time. I've been doing this very thing with an app I inherited March 2002. It was about 60,000 lines of code, with a lot (probably 6-8,000 lines) of that being duplicated, rather than abstracted into a common include. It's now about 70,000 lines (because of enhancements), with very little code duplication. As it stands, there are about 10 separate fuseboxes that comprise the entire app. 97 or 98% of it is using fuseactions, with 12-15% of them using a single monolithic include, rather than a series of atomic fuses. If I wanted to, I could probably sit down and convert the whole thing to a single cohesive FB3 application in 10 or 15 hours. It still wouldn't be fully up to snuff (those big fuseactions, missing fusedocs, etc.), but it'd technically be an FB3 application. At some point in the near future I'll probably make that final conversion (after our current release cycle concludes), but even with 10 separate fuseboxes, it's enormously easier to find my way around the codebase and remove the seemingly random cross-dependancies which plagued me like nothing else when I first took over. This is undoubtedly an atypical scenario, but it's a success that's almost entirely because of the flexibility and standardization that my framework of choice (which happens to be Fusebox) provided to me. There's certainly no reason that I had to use Fusebox to get where I've gotten, it just the one I prefer. cheers, barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com -Original Message- From: Judith Dinowitz [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 4:25 PM To: CF-Talk Subject: Cons to Fusebox While I still don't like it, I do have a better understanding of why others might like it, and perhaps would even agree that it may help some people with their development process. Without this thread, I probably wouldn't have that understanding. I find myself very much agreeing with you, Dave, in that I think this thread has been very educational. I do wish people would not react so personally when someone says they dislike a particular methodology or framework. I personally don't think one framework can solve all problems in web development, and that each application should be viewed on its own merits and the first question that should be asked is: What's the best tool for this job? For example: Let's say you've inherited a ColdFusion application that's not in Fusebox, and you've got to work on it/enhance it in some way within a short time period. Is it better to sit and recode that app to be a Fusebox app, or is it better to take the app as is and recode where needed? I've never coded in Fusebox (or in ColdFusion, for that matter, though I can edit articles on both), but I would imagine that there are times when you'd want to use Fusebox and there are times when time constraints/other issues might cause you to decide to use some other methodology/framework or your own coding guidelines for a more generic ColdFusion app. Thoughts from people who are actually in the trenches here? Judith ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox - From the trenches
You might be interested in Mach-II (www.mach-ii.com). Its an implicit invocation framework that Hal Helms and a couple other guys have been working on. It's 100% OO, entirely in CFCs. I haven't played with it myself, but it looks pretty hot. I believe it's in beta now (it was alpha until recently). cheers, barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com -Original Message- From: Shawn Grover [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 4:55 PM To: CF-Talk Subject: Cons to Fusebox - From the trenches I undertook a project which was partially completed before I became involed. The project up to that point had been done in a modified form of FB2 on CF5. I ran into large number of problems simply because the code was not a full FB implementation. Had it been, a number of things would have been easier. However, it was not in the best interests of the project to start from scratch and rewrite the code in full FB implementation, or some other archeticture. So, I had to work with what was there, and follow the FB'ness of the application as closely as possible. Looking back on the project, I think it was a good example of where FB was not well suited. This was an very complex application (basically rewriting a desktop app to the web, but in such a way that there was no difference between the two - either in functionality or interface). Some of the pages did so many different things given so many different conditions - the FB approach hindered the process I think. I'm sure some would argue that FB is very good at this type of application (sorry I can't give more details - NDA), but in my eyes, even had FB2 been implemented correctly, it would have made debugging and maintenance of the application extremely difficult. Now that CFMX can support components and most of the object oriented approach to programming, I'm finding this to be a much better, and more robust solution. If I can figure out how to simulate events serverside (but within the CFC framework), I wouldn't see a need for any other language on the web. On the otherhand, I know FB3 and FB4 have improved significantly, and may be as robust as applying OOP concepts. Shawn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 5:25 PM To: CF-Talk Subject: Cons to Fusebox While I still don't like it, I do have a better understanding of why others might like it, and perhaps would even agree that it may help some people with their development process. Without this thread, I probably wouldn't have that understanding. I find myself very much agreeing with you, Dave, in that I think this thread has been very educational. I do wish people would not react so personally when someone says they dislike a particular methodology or framework. I personally don't think one framework can solve all problems in web development, and that each application should be viewed on its own merits and the first question that should be asked is: What's the best tool for this job? For example: Let's say you've inherited a ColdFusion application that's not in Fusebox, and you've got to work on it/enhance it in some way within a short time period. Is it better to sit and recode that app to be a Fusebox app, or is it better to take the app as is and recode where needed? I've never coded in Fusebox (or in ColdFusion, for that matter, though I can edit articles on both), but I would imagine that there are times when you'd want to use Fusebox and there are times when time constraints/other issues might cause you to decide to use some other methodology/framework or your own coding guidelines for a more generic ColdFusion app. Thoughts from people who are actually in the trenches here? Judith ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: URLs and abstraction (was: RE: Cons to Fusebox)
On Friday, Jul 18, 2003, at 10:49 US/Pacific, Barney Boisvert wrote: Is www.macromedia.com/software/coldfusion hard to remember? No, but it might change to www.macromedia.com/software/servers/coldfusion next week. A better example is probably: http://www.macromedia.com/exchange/coldfusion/ That's a public API URL. We effectively promise not to change it. At one time, it redirected to http://devex.macromedia.com/developer/gallery/ (I think) which in turn invoked a CF page. Now it redirects to http://www.macromedia.com/cfusion/exchange/index.cfm?view=sn110 (I think it's sn110 - I'm doing this from memory). We have a whole set of high-level, memorable URLs that will never change. In fact, we've supported some API URLs for many years that have *never* been real filesystem URLs. They're a convenience for users. URL abstractions can be a really good thing. Sean A Corfield -- http://www.corfield.org/blog/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
On Friday, Jul 18, 2003, at 10:59 US/Pacific, Matt Liotta wrote: I saw this thread mentioned on Sean's blog and I was thinking about rejoining this list before reading his blog, so here I am. I'm not sure whether to be flattered that I was the final encouragement you needed or whether you joined the list despite reading my blog? *grin* I think frameworks are extremely valuable and can make an enormous difference in the success of web applications especially where more than 3 people on working on them. Agreed. Of course, picking the wrong framework for an application can lead to all sorts of problems, so the notion of one framework being the correct one in every case should be abandoned. Agreed. See my articles about BroadVision's web framework: http://www.corfield.org/index.php?fuseaction=broadvision.articles Frameworks, like standards, are great because you have so many to choose from... ;) Sean A Corfield -- http://www.corfield.org/blog/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Hi, I'm sorry that you feel this is personally directed at you. I don't feel that way and never said that I did feel that way. I realize you aren't attacking any individual, much less me. This has actually been the best most informative Fusebox debate I have ever witnessed. I am glad I had the opportunity to speak during it. I reserve the right to answer honestly and fully. Of course you do. I would just like to hear a response with some meat to it; not necessarily from you, but in general. I would like to see examples that support views. Most of all I would like to see an unbiased opinion that is not based on trivial issues. Even though I don't speak out much, I have always respected your opinions. And I have always tried to keep an open mind, especially when it comes to frameworks and the like. I agree with some of the issues you raised; however others are, imo, minor obstacles with simple solutions and really don't reflect the bigger picture of the framework. These same types of obstacles also exist outside the realm of Fusebox. if kiss my ass is the best argument you can find, well, good luck with that Kiss my ass isn't my reply; sorry it seemed that way, I had intended it as a joke not as a direct comment towards you. I was commenting on your point about emoticons and certain remarks. Just because one smiles doesn't mean they think it is going to make you feel better or hope that their comments sit better with you. If I told you to kiss my ass and smiled about it, I would likely be smiling because it made me feel better; however childish it might be. :) I don't take offense to any of your comments; although, I disagree with many of them and as I said earlier I am not trying to convert you. I apologize if my comments were too blunt; I posted too hastily on my way out of the office, which was irresponsible on my part. I think we all agree Fusebox isn't for everyone or every situation, but for me--at the moment--it is. Although I have nothing to gain personally, I hope it continues to grow as it has and that it becomes more useful to more people. I think Fb4 is a great stride in that direction. Best regards, Michael Wilson ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Hi, too much time organizing their CF code, and not enough time figuring out what should be in CF I use Fusebox almost daily, so I tend to have this under control. I spend most of my time making sure I write the best CF code I am capable of. This is not to say I do everything correctly; I learn better ways of doing things all the time. I can see how someone less familiar with Fusebox could waste time due to the learning curve, but I suggest this is a part of adopting any methodology. Do you find yourself going beyond this raw form of documentation anyway, though? I rarely document outside of the Fusedocs. If I do it is more of an overview of the application rather than the code behind it. Just about anything I could comment on about a particular file (fuse) is contained in the fusedoc. I make inline comments where I feel it is prudent, but these generally deal more with a specific chunk of code within the file; e.g. why I did something, that may seem odd later, a certain way. Best regards, Michael Wilson ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Hi, Seriously, how do you measure that? I think, largely, it is measured against personal experience. If I had the opportunity to work with you directly and to learn how you do things, I may indeed find your methods to be superior--and that would be wonderful. I would then have another standard to apply to my formula. The people I have talked with that do feel Fusebox works, speak from their experiences both individually and within teams, but rarely compare Fusebox to other frameworks or methodologies. In that case, are they successful because of Fusebox? I am sure it plays a role in their success. Is Fusebox the driving force behind their success? I doubt it. The very fact that the individual took the time to learn any framework says allot about the individual's character and desires. I totally agree that the success of a project, Fusebox or otherwise, is based more on the people involved than the methods used. I have seen some really crappy Fusebox apps and some really great ones. Best regards, Michael Wilson ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Hi, I am with Dave on the fact that I would not suggest a change unless I felt it to be truly beneficial. I work on allot of non Fusebox stuff; for that matter the entire back end of one of our PDA apps is written in ASP... Ick. I would never suggest that it would be wise to get back into bed with that thing; Fusebox be damned. :) I like working in Fusebox when I can start from scratch and the situation allows for it or when the app in question is already written using Fusebox. I only convert applications when It is something small and quick or when I want to do it for my own experience. Best regards, Michael Wilson ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Clint Tredway wrote: In a nutshell, I don't like having all my files going through a switch and having a to add a case statement every time I add a section. I've been pondering the benefits and downsides of this approach for a while now. Since you bring it up, I was wondering what everyone else thought about all requests having to come in through an application spine? That is, what benefits exist and/or are perceived to exist from structuring all of your HREFs like index.cfm?fuseaction=foo.bar or index.cfm?displayPage=5 instead of /foo/bar.cfm and page5.cfm respectively? Anyone? -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
it is REALLY nice to be able to edit a few lines in your circuit definitions and be done with it, instead of having to change links all over the place. I agree with most of your points. But if you decide to change your fuseaction names and circuits structure, don't you have to change links all over the place, plus the fusebox configuration files? (fuseaction names and circuits are also harcoded all over the place, instead of file names and directories) It solves the problem by adding another one and add complexity/overhead to your app. Always the same dilemma : when to stop to add levels/layers of abstration... :) Benoit Hediard www.benorama.com -Message d'origine- De : Brian Kotek [mailto:[EMAIL PROTECTED] Envoyé : jeudi 17 juillet 2003 19:48 À : CF-Talk Objet : Cons to Fusebox First, I just want to be sure you understand what the fuseaction actually is. It's in the format circuit.targetfuseaction, where the circuit part is the alias of a Fusebox circuit, and the targetfuseaction part is the actual action within that circuit that you want to execute. I just wanted to make sure that was clear. So... Abstraction is one huge benefit of circuits. When I do index.cfm?fuseaction=store.productdetails, I don't know, or care, WHERE the store circuit is. This applies to both the logical and physical structure of the site. Using circuit aliases masks these dependencies because the core file handles translation of the alias to a directory path to be called. So as a team developer creating a link to that section of the site, I don't need to know anything about the application's directory structure or where that part of the site is located. On the other hand, using /root/store/products/productdetails.cfm in a link requires you to know EVERYTHING about the physical structure of the site for EVERY link. And if for some reason I refactor the site, and part of the change is to alter the physical location of my products directory, or break it up into more than one directory? Better open up a lot of files or break out the extended search and replace, because every link that points there is going to have to be changed. Circuits also allow for very easy dynamic links. If I have a component that creates a form, and I want to reuse that form in multiple places in the system but I want it to post to different things, this is really easy with circuits. You do: form action=index.cfm?fuseaction=#xfa.formAction#. Then at runtime, you can set xfa.formAction to be anything you need it to be. Bam...like magic the form can now post to any fuseaction you need it to...and you never need to touch the code itself, only set the xfa variable. Pretty much, your question goes right to the heart of why Fusebox uses circuits in the first place. The answer is that when related code is grouped together, that code is easier to maintain and change. Placing code into directories can do this as well, in fact Fusebox circuits are aliases for directories. But with circuits, you get that layer of abstraction between the alias of the circuit and it's actual path. I can tell you from real world experience that when you have to make significant changes to the structure of your application, it is REALLY nice to be able to edit a few lines in your circuit definitions and be done with it, instead of having to change links all over the place. Hope that helps, Brian Mosh Teitelbaum wrote: I've been pondering the benefits and downsides of this approach for a while now. Since you bring it up, I was wondering what everyone else thought about all requests having to come in through an application spine? That is, what benefits exist and/or are perceived to exist from structuring all of your HREFs like index.cfm?fuseaction=foo.bar or index.cfm?displayPage=5 instead of /foo/bar.cfm and page5.cfm respectively? Anyone? -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
You can accomplish the same thing with dynamic paths and still not have to use fusebox. There are easier ways to do this and not have all the overhead of FB. Clint - Original Message - From: Brian Kotek [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 12:48 PM Subject: Cons to Fusebox First, I just want to be sure you understand what the fuseaction actually is. It's in the format circuit.targetfuseaction, where the circuit part is the alias of a Fusebox circuit, and the targetfuseaction part is the actual action within that circuit that you want to execute. I just wanted to make sure that was clear. So... Abstraction is one huge benefit of circuits. When I do index.cfm?fuseaction=store.productdetails, I don't know, or care, WHERE the store circuit is. This applies to both the logical and physical structure of the site. Using circuit aliases masks these dependencies because the core file handles translation of the alias to a directory path to be called. So as a team developer creating a link to that section of the site, I don't need to know anything about the application's directory structure or where that part of the site is located. On the other hand, using /root/store/products/productdetails.cfm in a link requires you to know EVERYTHING about the physical structure of the site for EVERY link. And if for some reason I refactor the site, and part of the change is to alter the physical location of my products directory, or break it up into more than one directory? Better open up a lot of files or break out the extended search and replace, because every link that points there is going to have to be changed. Circuits also allow for very easy dynamic links. If I have a component that creates a form, and I want to reuse that form in multiple places in the system but I want it to post to different things, this is really easy with circuits. You do: form action=index.cfm?fuseaction=#xfa.formAction#. Then at runtime, you can set xfa.formAction to be anything you need it to be. Bam...like magic the form can now post to any fuseaction you need it to...and you never need to touch the code itself, only set the xfa variable. Pretty much, your question goes right to the heart of why Fusebox uses circuits in the first place. The answer is that when related code is grouped together, that code is easier to maintain and change. Placing code into directories can do this as well, in fact Fusebox circuits are aliases for directories. But with circuits, you get that layer of abstraction between the alias of the circuit and it's actual path. I can tell you from real world experience that when you have to make significant changes to the structure of your application, it is REALLY nice to be able to edit a few lines in your circuit definitions and be done with it, instead of having to change links all over the place. Hope that helps, Brian Mosh Teitelbaum wrote: I've been pondering the benefits and downsides of this approach for a while now. Since you bring it up, I was wondering what everyone else thought about all requests having to come in through an application spine? That is, what benefits exist and/or are perceived to exist from structuring all of your HREFs like index.cfm?fuseaction=foo.bar or index.cfm?displayPage=5 instead of /foo/bar.cfm and page5.cfm respectively? Anyone? -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Cons to Fusebox
I agree with this ;) Clint - Original Message - From: Benoit Hediard [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 1:23 PM Subject: RE: Cons to Fusebox it is REALLY nice to be able to edit a few lines in your circuit definitions and be done with it, instead of having to change links all over the place. I agree with most of your points. But if you decide to change your fuseaction names and circuits structure, don't you have to change links all over the place, plus the fusebox configuration files? (fuseaction names and circuits are also harcoded all over the place, instead of file names and directories) It solves the problem by adding another one and add complexity/overhead to your app. Always the same dilemma : when to stop to add levels/layers of abstration... :) Benoit Hediard www.benorama.com -Message d'origine- De : Brian Kotek [mailto:[EMAIL PROTECTED] Envoyé : jeudi 17 juillet 2003 19:48 À : CF-Talk Objet : Cons to Fusebox First, I just want to be sure you understand what the fuseaction actually is. It's in the format circuit.targetfuseaction, where the circuit part is the alias of a Fusebox circuit, and the targetfuseaction part is the actual action within that circuit that you want to execute. I just wanted to make sure that was clear. So... Abstraction is one huge benefit of circuits. When I do index.cfm?fuseaction=store.productdetails, I don't know, or care, WHERE the store circuit is. This applies to both the logical and physical structure of the site. Using circuit aliases masks these dependencies because the core file handles translation of the alias to a directory path to be called. So as a team developer creating a link to that section of the site, I don't need to know anything about the application's directory structure or where that part of the site is located. On the other hand, using /root/store/products/productdetails.cfm in a link requires you to know EVERYTHING about the physical structure of the site for EVERY link. And if for some reason I refactor the site, and part of the change is to alter the physical location of my products directory, or break it up into more than one directory? Better open up a lot of files or break out the extended search and replace, because every link that points there is going to have to be changed. Circuits also allow for very easy dynamic links. If I have a component that creates a form, and I want to reuse that form in multiple places in the system but I want it to post to different things, this is really easy with circuits. You do: form action=index.cfm?fuseaction=#xfa.formAction#. Then at runtime, you can set xfa.formAction to be anything you need it to be. Bam...like magic the form can now post to any fuseaction you need it to...and you never need to touch the code itself, only set the xfa variable. Pretty much, your question goes right to the heart of why Fusebox uses circuits in the first place. The answer is that when related code is grouped together, that code is easier to maintain and change. Placing code into directories can do this as well, in fact Fusebox circuits are aliases for directories. But with circuits, you get that layer of abstraction between the alias of the circuit and it's actual path. I can tell you from real world experience that when you have to make significant changes to the structure of your application, it is REALLY nice to be able to edit a few lines in your circuit definitions and be done with it, instead of having to change links all over the place. Hope that helps, Brian Mosh Teitelbaum wrote: I've been pondering the benefits and downsides of this approach for a while now. Since you bring it up, I was wondering what everyone else thought about all requests having to come in through an application spine? That is, what benefits exist and/or are perceived to exist from structuring all of your HREFs like index.cfm?fuseaction=foo.bar or index.cfm?displayPage=5 instead of /foo/bar.cfm and page5.cfm respectively? Anyone? -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
With the proper use of XFAs and API variables, you can reduce that workload tremendously. For example, using XFAs means that you will only ever have to change your switch files (fbx_Switch in FB3, circuit.xml.cfm in FB4). Using the API variables (fusebox.thiscircuit and/or fusebox.targetcircuit in FB3, and myFusebox.thiscircuit and/or myFusebox.originalcircuit in FB4) lets you define XFAs that point to the current circuit (which most do) without specifying it's name, so you can rename the circuit without affecting those XFAs. Also, with XFAs, all your circuit and fuseaction names share a very consistent format, so you can easily do a global search and replace, and have great confidence that it'll get everything, and not get anything extra. Not as easy to do that with directory names that might happen to also be query string parameter names, or just in the text of a page. Take this snip from FB4: !-- this automatically adds the current circuit -- xfa name=process value=process / ... a href=#self##xfa.process#link text/a versus this snip from a non-FB app: a href=../products/processproductform.cfmlink text/a First, you wouldn't have to do a serach and replace on the FB4 one, and even if you did, the XML formatting makes it a cinch to be very precise about the replacements you make. cheers, barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com -Original Message- From: Benoit Hediard [mailto:[EMAIL PROTECTED] Sent: Thursday, July 17, 2003 11:24 AM To: CF-Talk Subject: RE: Cons to Fusebox it is REALLY nice to be able to edit a few lines in your circuit definitions and be done with it, instead of having to change links all over the place. I agree with most of your points. But if you decide to change your fuseaction names and circuits structure, don't you have to change links all over the place, plus the fusebox configuration files? (fuseaction names and circuits are also harcoded all over the place, instead of file names and directories) It solves the problem by adding another one and add complexity/overhead to your app. Always the same dilemma : when to stop to add levels/layers of abstration... :) Benoit Hediard www.benorama.com -Message d'origine- De : Brian Kotek [mailto:[EMAIL PROTECTED] Envoyé : jeudi 17 juillet 2003 19:48 À : CF-Talk Objet : Cons to Fusebox First, I just want to be sure you understand what the fuseaction actually is. It's in the format circuit.targetfuseaction, where the circuit part is the alias of a Fusebox circuit, and the targetfuseaction part is the actual action within that circuit that you want to execute. I just wanted to make sure that was clear. So... Abstraction is one huge benefit of circuits. When I do index.cfm?fuseaction=store.productdetails, I don't know, or care, WHERE the store circuit is. This applies to both the logical and physical structure of the site. Using circuit aliases masks these dependencies because the core file handles translation of the alias to a directory path to be called. So as a team developer creating a link to that section of the site, I don't need to know anything about the application's directory structure or where that part of the site is located. On the other hand, using /root/store/products/productdetails.cfm in a link requires you to know EVERYTHING about the physical structure of the site for EVERY link. And if for some reason I refactor the site, and part of the change is to alter the physical location of my products directory, or break it up into more than one directory? Better open up a lot of files or break out the extended search and replace, because every link that points there is going to have to be changed. Circuits also allow for very easy dynamic links. If I have a component that creates a form, and I want to reuse that form in multiple places in the system but I want it to post to different things, this is really easy with circuits. You do: form action=index.cfm?fuseaction=#xfa.formAction#. Then at runtime, you can set xfa.formAction to be anything you need it to be. Bam...like magic the form can now post to any fuseaction you need it to...and you never need to touch the code itself, only set the xfa variable. Pretty much, your question goes right to the heart of why Fusebox uses circuits in the first place. The answer is that when related code is grouped together, that code is easier to maintain and change. Placing code into directories can do this as well, in fact Fusebox circuits are aliases for directories. But with circuits, you get that layer of abstraction between the alias of the circuit and it's actual path. I can tell you from real world experience that when you have to make significant changes to the structure of your application
RE: Cons to Fusebox
Abstraction is one huge benefit of circuits. When I do index.cfm?fuseaction=store.productdetails, I don't know, or care, WHERE the store circuit is. This applies to both the logical and physical structure of the site. Using circuit aliases masks these dependencies because the core file handles translation of the alias to a directory path to be called. So as a team developer creating a link to that section of the site, I don't need to know anything about the application's directory structure or where that part of the site is located. On the other hand, using /root/store/products/productdetails.cfm in a link requires you to know EVERYTHING about the physical structure of the site for EVERY link. And if for some reason I refactor the site, and part of the change is to alter the physical location of my products directory, or break it up into more than one directory? Better open up a lot of files or break out the extended search and replace, because every link that points there is going to have to be changed. While that may be theoretically nice, why would you have so many duplicate links to the same thing anyway? A well-constructed site should have common, reusable (and potentially data-driven) navigation elements. In that light, this doesn't seem to be the huge benefit that you claim. Circuits also allow for very easy dynamic links. If I have a component that creates a form, and I want to reuse that form in multiple places in the system but I want it to post to different things, this is really easy with circuits. You do: form action=index.cfm?fuseaction=#xfa.formAction#. Then at runtime, you can set xfa.formAction to be anything you need it to be. Bam...like magic the form can now post to any fuseaction you need it to...and you never need to touch the code itself, only set the xfa variable. If you really wanted that, you don't need circuits. All you need to do is create a variable to store the form action attribute, right? Maybe I'm missing something, though. Pretty much, your question goes right to the heart of why Fusebox uses circuits in the first place. The answer is that when related code is grouped together, that code is easier to maintain and change. Placing code into directories can do this as well, in fact Fusebox circuits are aliases for directories. But with circuits, you get that layer of abstraction between the alias of the circuit and it's actual path. I can tell you from real world experience that when you have to make significant changes to the structure of your application, it is REALLY nice to be able to edit a few lines in your circuit definitions and be done with it, instead of having to change links all over the place. You can group related code together without Fusebox or any other controller structure. I've been doing that for years. I can tell you from real world experience that when you have to make significant changes to the structure of your application, it is REALLY nice to be able to edit a few lines in your navigation elements and be done with it, instead of having to change links all over the place. On the other hand, I can also tell you from real world experience that when you have to make significant changes to the structure of your application, that's a sign that you should've spent more time planning and less time coding. I'll close this by stating that I'm not against your using Fusebox, or anyone else for that matter, but I did think it worth pointing out that a lot of the problems solved by Fusebox have traditionally not really been significant problems for lots of people. If they are significant problems for you, then you should probably use Fusebox. Personally, since I stopped writing CGI programs in Visual Basic 3 and started writing them in CF instead, I haven't had much need for a controller structure, but that's just me. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Cons to Fusebox
Brian Kotek wrote: First, I just want to be sure you understand what the fuseaction actually is. [snip] Yup, I understand all of that. But thanks for making sure. Abstraction is one huge benefit of circuits. When I do index.cfm?fuseaction=store.productdetails, I don't know, or care, WHERE the store circuit is. This applies to both the logical and physical structure of the site. Using circuit aliases masks these dependencies because the core file handles translation of the alias to a directory path to be called. So as a team developer creating a link to that section of the site, I don't need to know anything about the application's directory structure or where that part of the site is located. I can see how abstraction of a file's location might be beneficial, but I'm not sure I would agree that it's a *HUGE* benefit. As I see it, this kind of abstraction provides 2 kinds of benefit; security and, for lack of another term, abstraction as to where a file (or in your example, a circuit) is actually located to aid in team development. It provides security because a would-be hacker doesn't necessarily know where your file or files are actually located. However, I think this is more a form of security through obscurity rather than true security. The truth is, if someone were to hack your web server, they'd very easily be able to determine the true names and locations of your files. And, they probably wouldn't care much anyway since there's more valuable loot in the database than in code file. Concerning the benefit to team development, I'm not sure I see it. You're right, the members of your development team don't need to know that the store circuit is actually a directory called MungeMe but they still need to know that they are to use the circuit named store. In essence, you're creating a virtual file system and requiring that the development team learn the virtual file system instead of the physical file system. With a well documented development plan, the benefits of this virtual file system are negligible to none to, maybe even, harmful. At least with a physical file system you can open up a file browser and see the actual structure. With a virtual file system you have to either remember it (bad), open and parse the code (bad), or read the documents (please god no 8^). And this just speaks to the development team. How does this benefit the architect(s)? The way I see it, it makes their lives more difficult because they now need to craft a physical and a virtual file system. On the other hand, using /root/store/products/productdetails.cfm in a link requires you to know EVERYTHING about the physical structure of the site for EVERY link. And if for some reason I refactor the site, and part of the change is to alter the physical location of my products directory, or break it up into more than one directory? Better open up a lot of files or break out the extended search and replace, because every link that points there is going to have to be changed. As Benoit indicated, and as I mentioned above, you're still hard coding targets, you're just targeting the virtual file system instead of the physical one. Circuits also allow for very easy dynamic links. If I have a component that creates a form, and I want to reuse that form in multiple places in the system but I want it to post to different things, this is really easy with circuits. You do: form action=index.cfm?fuseaction=#xfa.formAction#. Then at runtime, you can set xfa.formAction to be anything you need it to be. Bam...like magic the form can now post to any fuseaction you need it to...and you never need to touch the code itself, only set the xfa variable. My question was really more about the benefits of a central spine (hub and spoke pattern) than Fusebox, and I'm not trying to start a holy war (nor am I suggesting that you are), but since we're here... I'm all for reuse (actual reuse, not cut paste reuse) of code. But in practice, how often does the same one form need to be used in different situations? I can see reusing a form to add and edit a specific type of item/object but don't see reuse of a single form much beyond that. The only other time I've seen where something like this would be reusable is in a security context where you want to assign permissions or ownership to an object regardless of object type. In the case or add/edit, instead of dynamically setting the form action to addThing or editThing you could just decide in the action page whether the request is meant to add or edit (usually by detecting the presence of an ID). Pretty much, your question goes right to the heart of why Fusebox uses circuits in the first place. The answer is that when related code is grouped together, that code is easier to maintain and change. Placing code into directories can do this as well, in fact Fusebox circuits are aliases for directories. But with circuits, you get that layer of
RE: Cons to Fusebox
Barney wrote: Take this snip from FB4: !-- this automatically adds the current circuit -- xfa name=process value=process / ... a href=#self##xfa.process#link text/a versus this snip from a non-FB app: a href=../products/processproductform.cfmlink text/a Or versus this snip from a non-FB app: a href=#request.ProductsBaseHRef#processproductform.cfmlink text/a Or to stretch it a bit (too far perhaps): a href=#request.BaseHRef##request.ProductsFolder#processproductform.cfm link text/a Or this: a href=#cgi.script_name#?#client.defaultparms#blah=blahlink text/a You certainly don't need FB to standardize locations. Why would you point to something that's so simple to achieve in so simple a fashion? I can move an entire web site by a)copying the files, b)reassigning to a new dsn and c)editing a db record to change urls and physical paths. Elapsed time is maybe 5 minutes, with 3 of that being the copy process. In a simpler app this could simply go into something like application.cfm. Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc. http://mysecretbase.com ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribeforumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
