>Sharing code across CFCs is one place that I refuse to agree that CFINCLUDE is a good thing.
For the most part I agree. Here's a situation we have (and I'm not saying it's a good approach, but it's a live instance of <cfinclude> in a CFC... I'm all ears as to how better to do it!) We have database abstraction CFC... They handle the differences between MS-SQL, Oracle, MySQL and what-have-you, as well as removing the need to know *how* we're doing stuff under the hood. Each DB table has a CFC that relates to it, and might have methods like get(), add(), update(), delete(). The get() function will take an argument for each field of the table, to allow filtering (basically chucking it in a where statement), as well as an additional 'whereClause' argument for stuff that ain't a direct col=value filter. Now the resultant SQL-building logic for all these arguments is identical for the get() and the delete() functions, basically a series of "if an argument exists for this field, add the where filter for it in". I guess this *might* work as a separate function, but having a bunch of <cfqueryparam> tags in function strikes me as a bit weird... Even if you could even do that (haven't tried... Maybe I should?). [tried it: no, can't do it] So my approach here is to have that same code dumped in a separate CFM file,. Which I <cfinclude> as and when I need it. Second situation. We have a cfml.cfc, which ahsd a bunch of function versions of CFML tags (cfAbort(), cfDump() and such like: we've all done this). We've also got a cfQuery() function, which maps as closely to <cfquery> as I can get it, including the <cfqueryparam> support. Now it turns out that there are 30 (I think... Going from memory here) mutulaly exclusive combinations of attributes for <cfquery>. And thanks to CF rocking so much, each of these combos has to be reflected in a hunge sequence of conditional statements identifying which attributes have been passed in, and accordingly put together a separate <cfquery /> block for each of them. And within each of those thirty <cfquery> blocks, there is the <cfqueryparam>0-handling code. And the <cfqueryparam> handling code is itself another series of conditonals to determine which attributes have been passed to each query param. I <cfinclude> the queryparam code within each <cfquery> block. Well I <cfmodule> it now, actually, go get around this stupid variables bug. Using the <cfmodule> include, the function is about 200 lines line. If I was to replicate the param handling code in situ, the function is now close to 4000 lines long. Whether or not this is good OO practice... It's not, it's not attempting to be: OO is irrelevant to this task... It's a perfectly valid (and bloody useful!) thing to be undertaking. And you're suggesting I should run with 4000 lines of code (90% of which is the same 100-odd lines of code, repeated 30-odd times), rather than abstract it out with an include? Because some OO monkeys say it's a good idea? Cool. Don't get me wrong, I think OO is a great concept which I try to stick with. And I spend a lot of time wishing I wasn't stuck with CF for that very reason. But horses for courses... CF ain't an OO language. And working with this fact sometimes means OO best practices are best placed out the window. Adam ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
