>Where does the info about the object's fields come from? Is it returned by
a
>method of each persistable object?
Yep. The method returns the fields array, which can be populated by
hardcoding the properties in the cfc, which I have done for the static, core
elements of the framework, or can come from a database/xml, which is done
for the objects which the system creates.
>Are there different cf objects for each form
No, there is only one. There is an interface.cfc which works on the same
field array to generate forms and validate them. There are some methods e.g.
setFieldControl("user_id","hidden"), that can be used to modify the behviour
of the forms, and I have toyed with creating a "do everything possible"
interface method, but the variations on what needs to be displayed /
editable seem endless. So I simply have a standard form and if that needs to
be varied, I cut and paste the html generated into a cfm, modify it to suit
my needs and change the fuseaction. I would like to do this in a better way,
but so far my efforts to create display methods this flexible have simply
resulted in large, messy chunks of code that still never cover every
scenario.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Dave Merrill
Sent: 23 April 2005 17:57
To: [email protected]
Subject: RE: [CFCDev] To genericize parameter passing or not
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]
----------------------------------------------------------
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]
