>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
I would probably abstract *Data Manipulation to Java/PL-SQL/T-SQL to Stored Procedures* and preferably use just a Call Statement. All the data validation/business logic/other can be done within CFC's. 1. Read Data (using SQL CFC Methods) 2. Manipulate data (CFC Validator Methods) 3. Update Data (Using a Struct--all data being updated) No need to write multiple SQL Statements to update multiple fields or write if Conditions checking for Structs or Data. >And you're suggesting I should run with 4000 lines of code (90% of which Every Method within CFC are compiled to its own Classes... so if you have 20 methods(4000 lines) within a CFC and you call 2 Methods... How are you executing 4000 Lines Code? Joe Eugene >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Behalf Of Adam Cameron >Sent: Tuesday, July 06, 2004 8:07 PM >To: [EMAIL PROTECTED] >Subject: RE: [CFCDev] Serialization of CFCs > > >>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] ---------------------------------------------------------- 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]
