No other comments on this? I'm surprised... Dave Merrill
> 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]
