> Fusebox will never just be ColdFusion. Fusebox is made of a bunch > of ideas creating a powerful framework. We started with CF, but > there have been Fusebox ports to PHP and JSP.
To be honest, I was leaving that out of the scope of this conversation. I'm really not terrible familiar with PHP or JSP so I don't feel qualified to discuss them. Regardless, I would imagine changes to ColdFusion don't directly affect Fusebox as far as those languages are concerned. > CFCs are proprietary to CF, and will most likely remain > proprietary. Which is one reason I'm not personally bending over > backwards for CFCs. What happens when you realize CFCs don't do > something you want in your framework? Are you going to decompile > CFMX? Probably not. What if a CFInclude file doesn't do what you want it to? Decompile ColdFusion? :) I'm joking of course, but really, your argument is one against using ColdFusion altogether, not against migrating from Fusebox to a framework that may make better use of the language. > A goal of Fusebox is to create an open framework across > technologies. Along with create an open development methodology > based on the framework (FLiP). Combining the framework and the > methodology and you've got a killer solution to many common > development problems. In all honesty, I hadn't considered the "cross technology" argument in regards to CFCs. Personally, though, I wouldn't imagine that what makes sense in one language makes sense in another. Without knowing anything about Fusebox in other languages, it would seem that you end up with a lowest common denominator framework. As you add languages, the framework gets "dumbed down" to compensate for functionality that is missing in other languages. I assume that this is not the case, because Fusebox would not be as popular as it is, but I don't know how you manage this. Or do you make certain sacrifices in the Fusebox framework for the FLiP methodology? I could certainly understand this. As I mentioned, my primary ambition when coding a site is to make it easy to maintain in the future without increasing my development time. Consequently, I don't think my applications scale well, relatively speaking. It's a sacrifice I make. > CFCs may end up being just another implementation of Fusebox. As > long as the implementation can achieve what the Fusebox spec > states, then great, let's give it a shot. Until then, CFCs will > plug in perfectly with Fusebox without changing Fusebox at all. Where can I find the specifications? I think I have rough idea of what these are from experience, but I would like to know more. The Fusebox.org site lists tools, tags, example apps and help files, but there aren't really any "specifications" so to speak. I'm looking for something that says "An implementation of Fusebox architecture in any language must have...." > Fusebox is not trying to create the end all be all syntax for > writing web software. We're trying to reduce the awful 70% > software failure rate. For many, many, many people Fusebox has > succeeded in doing this, it definitely has for me. It has for me as well. :) Benjamin S. Rogers http://www.c4.net/ v.508.240.0051 f.508.240.0057 ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
