I don't think there's anything technically wrong with doing it that way, but I do think that you will end up paying a lot of maintenance tax further down the road.
Personally I would perfer to be able to look at the query out of context and have some idea of what it is doing. Where I draw the line on what should be dynamic and what should be hard coded is a bit grey and would normally be a trade-off between long term maintenance and short term development cost. Spike -------------------------------------------- Stephen Milligan Code poet for hire http://www.spike.org.uk Do you cfeclipse? http://cfeclipse.tigris.org >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Barry Beattie >Sent: Wednesday, May 26, 2004 3:58 PM >To: [EMAIL PROTECTED] >Subject: [CFCDev] method variations > >hi all > >not everything here is following a nice OO approach. we've got >some CFC's that are just query wrappers. they take in a struct >of arrays to build the select fields and WHERE clause and >return a query. While I've only inherited this method here, >it's similar to what I used to do in ASP (classic) - I can see >the value in decoupling this way. > ><cfif isDefined("FORM.accept_flg")><!--- accepted = "Y" >checkbox on FORM ---> > <CFSET aWhereClause[3] = StructNew()> > <CFSET aWhereClause[3].field = "r2.accept_flg"> > <CFSET aWhereClause[3].value = "#FORM.accept_flg#"> ></cfif> > ><CFSET get_donors = >eventObj.getAttendList(APPLICATION.dsnInfo,VARIABLES.selectFiel >ds,aWhereClause,FORM.sortBy)> > >and in the CFC: > > <cfquery name="getAttendList" .> > SELECT #selectList# > FROM donor AS r1, donevent AS r2 > #whereClause# > AND r1.donor_num = r2.donor_num > #andClause# > > > >can such variations of calls to CFC functions fit in to OO >design? or should multiple methods be written to cater for >every possibility, each one a wrapper to the same private >query method (passing whatever has been sent)? > >feel free to throw up your 2c worth. >cheers >barry.b > >PS: please ignore the potential security hole in directly >sending form data as CFC method arguments. They just need some >take-up time to see the light. > > > > ---------------------------------------------------------- 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]
