> >>The biggest reasons I see for using frameworks are: > -code reuse > -flexibility > -maintainability > -documented code
> Well, IMHO these are just clichés. > - code reuse? I don't see what in non framework > application makes reusing any code any more difficult. Doesn't make it more difficult, although having a framework can sometimes add clarity and ease-of-use to certain types of code reuse. Example: it's not a "framework" per se in the traditional sense, but it's possible to get a lot of OO-type functionality without using CFC's -- a number of us did so before CF MX became available. Generally speaking (and barring issues with discovery), CFC's make those features much more accessible / easy to use. Similarly many Fusebox adherents find the XML Config syntax: <postfuseaction> <include template="dsp_defaultView"/> </postfuseaction> <fuseaction name="doSomething"> <do action="model.something" /> <do action="view.something" contentvariable="request.content" /> </fuseaction> <fuseaction name="doSomethingElse"> <do action="model.somethingElse" /> <do action="view.somethingElse" contentvariable="request.content" /> </fuseaction> To be easier to read and use than for instance nested includes, or custom tags or includes for headers and footers (which would need to be coded in each base template as compared to the _ONE_ time it has to be declared in the above XML), etc. I'm not saying it's the easiest thing in the world, but you can't say that the prefuseaction and postfuseaction syntax wouldn't be helpful for code reuse in a way that raw CFML doesn't provide. Can you provide that same functionality another way or without using Fusebox? Yes. But that wasn't the question. The question was does a framework make code reuse easier? This is an example of Fusebox doing exactly that -- whether I prefer this particular method or not, I can't dispute that it _does_ satisfy that criteria. > - Flexibility? Framework means rules, how can rules add > flexibilty? See above. > - Maintainability? By someone who knows the framework, may > be, but for other (most of the time), it is like hell. It can be. But the argument that frameworks provide maintainability isn't directed at people who don't know the framework (or aren't interested in learning it). The point is that once you know the framework that knowledge makes the framework easier to maintain than random code (which is often spaghettied). Can random code be easy to maintain? Yes. But it often isn't, and in particular having a defined and commonly (amongst a team of developers) understood architecture helps the people on a team be more productive by reducing the number of hours they spend detangling random code. > - documented code? Any code should be documented, in a > framework or not. Frameworks do not create documentation. Nope, they don't. Although some frameworks do have accompanying specification for how code ought to be documented. Sometimes this is helpful. Fusedocs (although I'm not a huge fan) give you information about the current template in a very structured way, and imo having the documentation be somewhat consistent is helpful. (Having it in XML _can_ lend to its being collected and displayed or even used in ways that go beyond knowing what the current template is doing at the time you're working on it.) Hence the proliferation of documentation frameworks like JavaDoc and NaturalDoc. > Anyway, any experienced programer will end up with his > own way to design applications, this is some kind of a > framework, and it is the best one, because it is HIS. Every experienced programmer has some good ideas I'm sure... That doesn't necessarily make his ideas the best suited to a particular task. Imo the issue of using a framework is really an issue of choosing a framework and it has everything to do with the tasks at hand and the comfortability of the team in question. But as a rule I do think any team should have a common architecture to work with (whether they call it a framework or not). At my last job we had started using this custom tag <cf_customchunk id="1">...some stuff...</cf_customchunk> -- which was a "framework" for providing branding for different clients. I never much cared for it -- always thought it was too heavy handed, but I did think it was better than nothing. :) It also wasn't our only tool for branding, although I never thought any of the tools we used for that task were very good at accomplishing that task -- imo none of them were ever both granular enough and efficient enough -- which has been the case pretty much everywhere I've worked. heh... it's rather broadly responsible for a lot of the view-layer features in the onTap framework actually... Anyway... You can call them cliche if you like... Most cliches have some source even if it's tenuous. I don't think the source for these is particularly tenuous. s. isaac dealey 434.293.6201 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.fusiontap.com http://coldfusion.sys-con.com/author/4806Dealey.htm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234344 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
