> > Also, I think you might be missing the point of fusedocs. You > > stated that CFCs document for you. While this may be true if > > you've already written and tested the CFC, it is not the point of > > Fusedocs. Fusedocs are like blueprints, when you're building a > > house, you don't build the house THEN draw the blueprints. It's > > the other way around. Fusedocs tell the programmer what variables > > they have so they know what their fuse needs to do. This has been > > a major flaw for 50 years in the concept of software > > documentation. > > That's a very interesting point, one which I hadn't considered. However, > would it be better to continue to use Fusebox and Fusedocs or to adapt > Fusedocs to CFCs? Obviously that is an over generalized question, but > you probably get the point. >
Well it's really going to be a personal preference. Personally for me, Fusebox 3 still solves MUCH more than CFCs do. The web services in CFCs seem great, but I have only needed a web service 2 times in the last year, whereas I've needed nested layouts in EVERY project. As far as Fusedocs go, I don't think one way is preferable over the other, because regardless of the technology used, the concept of Fusedocs is still useful. It's a simple concept. Don't document your code, code your documentation. So whether you're doing Fusebox, CFCs, JSP, PHP, CF, ASP yada yada, fusedocs would still work. They might need to be slightly changed for each technology but the concept is the same. Steve ==^================================================================ 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 ==^================================================================
