I'd go with the fact once you setup whichever version of fusebox you want to play with on your machine, then deploy it onto a server. You forget the behind the scenes stuff you have setup to do some of the fusebox stuff.
Suddenly it's the host's fault that something ain't running right cos it works fine on *my* machine. Russ, I do think you should be charging for this, which I hope you are! As to fusebox and obfusctating the design. To be honest shit coder in, shit code out. Makes no difference what they do it in. Unfortunately FB does not help if somebody is doing some amazingly awful coding. It will make it worse from a maintenance point of view. Personally I like FB. Coming from a Software Engineering background (if you ever fly, I was part of the team that wrote the NERC aircraft collision detection system that covers most of the south east commercial traffic) it gave me an event driven model for web applications which lent itself to taking the product of requirements analysis all the way through to writing test harnesses. It depends on why you are using it. I do find in many cases it is overkill and I avoid like the plague, but should you get into a set of requirements that are into more than a couple of pages...it does have it's uses. Adam > -----Original Message----- > From: Kola Oyedeji [mailto:[EMAIL PROTECTED] > Sent: 04 February 2004 10:36 > To: [EMAIL PROTECTED] > Subject: RE: [ cf-dev ] cfstandards...coming soon! > > > Coming in late here... > > But just to clarify, Russ are you saying that you're finding more > bugs/errors in fusebox applications in comparison to non-fusebox > applications or just pointing out that its harder to debug a Fusebox > application than a non-fusebox application (for a non fuseboxer)? > > Kola > > -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED]
