|
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.selectFields,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… |
- RE: [CFCDev] method variations Barry Beattie
- RE: [CFCDev] method variations Stephen Milligan
- RE: [CFCDev] method variations Nathan Dintenfass
- [CFCDev] CFMX CFC Guru needed frederick valone
- RE: [CFCDev] method variations Barry Beattie
