well, the way I do it (which I think is also generally frowned upon) is that I have a generic DAO cfc which expects an object that has a method which returns the fields of that object, and a structure of parameters.
It loops over the fields returned and any that it also finds in the structure of parameters get added to the sql. The field data returned is an array of structs containing the definition for each field such as name,label,primaryKey (true/false) Its certainly saved me a lot of time creating and maintaining large apps. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Merrill Sent: 22 April 2005 14:33 To: CFCDev@cfczone.org Subject: [CFCDev] To genericize parameter passing or not OO-newb here... Pre CFC/OO, I often used a custom tag to save data into a sql db, like this: <cf_save_values_to_sql table="employee" pk_col_name="employee_pk" employee_pk="#employee_pk#" last_name="#last_name#" first_name="#first_name#" [etc...] nullable_cols="email,comments" unquoted_cols="pk,num_children" id_rtn_var="employee_pk" error_rtn_var="error_message" [etc...] debug=false > It handled insert vs update depending on whether the pk value was blank, single quoting values when needed, error trapping, capturing new pk on insert, display-resulting-sql-only debug mode, etc, in a simple to use package. Sometimes, I'd pass form field values in like this: attributecollection="#form#" skip_cols="submit_btn" ...which would save any new fields just by adding them to the form, providing their names were the same as the corresponding sql column. Besides some future-proofing against modifications to the form, it also let the same code save several different veriations of the form, with different fields on them. My (oo/java-newb) impression is that something like that would be frowned upon in the java world, say, because it wasn't explicit about exactly what fields were expected to exist. Am I right about that? What's peoples' standard practice in CF? In java or other languages? Similarly, say you were implementing an object-based system, where form values updated vars in an object instance, then the object was persisted to sql. Would you call 12 explicit var-specific setters to set 12 different object vars from form fields, then 12 var-specific getters to get them back out for your persister? Or would you use more generic bulk techniques, similar to attributecollection? You're trading off enormous code economy and robustness against change in the exact fields used, vs the "tightness" of explicitly declaring which fields are expected. Thoughts? TIA, Dave Merrill ---------------------------------------------------------- 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 ---------------------------------------------------------- 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
