Interesting strategy. Where does the info about the object's fields come from? Is it returned by a method of each persistable object?
How does that relate to form fields? Are there different cf objects for each form, even if the underlying data object is the same (user and admin views of an employee record, say, with different parts editable)? Are you using that same object metadata in building your forms? Dave Merrill > 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. =================================== > 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 > [email protected] 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/[email protected] > > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] 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/[email protected] > > > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected]
