RE: [CFCDev] Ad-hoc queries using Data Gateway objects

[Jason Daiger]

Title: Spam:RE: [CFCDev] Ad-hoc queries using Data Gateway objects

I agree w/ the convention approach over configuration as it adds too many layers.  Also I just reread an earlier post and realized I should have added that each Gateway I use does accept a specialized Filter, e.g. ContactsFilter, which for me is part of the contract b/w the Filter and the Gateway. If the Gateway method chooses to ignore or use only a specific item w/in the Filter I'll add this to the hint for the method so the contract b/w the two is clear.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Johnson (KW) Sent: Wednesday, January 11, 2006 12:25 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Ad-hoc queries using Data Gateway objects > At some point yes a Filter must get mapped to a db column  or column in > order to be used but... It's the DAO or Gateway's job to do the mapping.    I firmly agree,  but there also needs to be a declaration somewhere or what fields or properties the Gateway will accept as a part of a filter.  Otherwise, how do clients know how to construct the filter?   This *could* be done using a mapping file, but the mapping file would be mapping a filter property name (like "name") to the object property it relates to ("firstName"), not the database field holding that data.  As you said, its the Gateway's job to map that object property to its database field (or XML tag or whatever data source the Gateway interfaces with).   I still think I'd choose convention over configuration in this case. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org