Yep. That's exactly what it does. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Short Sent: Wednesday, November 17, 2004 5:15 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Process for Updating Database Records
I'm not familiar with the argumentcollection attribute. Would it basically map the argument names to the form names? So if I had FORM.txtFirstName and FORM.txtLastName, I could reference them as Arguments.txtFirstName and Arguments.txtLastName. Dan > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Roland Collins > Sent: Wednesday, November 17, 2004 2:05 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Process for Updating Database Records > > I personally use named parameters - I've never had a function > with more than > 10, so I've never seen a need to pass things any differently. > However, one > neat trick is to pass the form object in as the argument > collection, like > so: > > <CFINVOKE COMPONENT="MyComponent" METHOD="MyMethod" > ARGUMENTCOLLECTION="#form#"/> > > As long as your form items are named the same as the > arguments, this works > splendidly and avoids having to create DTO-like objects just > to pass form > data. > > Roland > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Daniel Short > Sent: Wednesday, November 17, 2004 4:01 PM > To: [EMAIL PROTECTED] > Subject: [CFCDev] Process for Updating Database Records > > Hi everyone, > > I'm working on making my database layers a bit more abstract, > and I'm just > curious how you all handle inserting and updating to tables > through your > CFCs. I've gotten quite good at breaking out the SELECT pieces via > getMyRecordset type functions, but can't quite figure out the > best way to > abstract INSERT and UPDATE statements. My biggest question is > how to get all > of the FORM data into the CFC without relying on > FORM.whatever. The only > thing I can think of at the moment is to actually pass each > form variable in > as an argument, but I can imagine how that could quickly get > out of hand > with some of the rather large tables I need to maintain (I > don't really want > to define 30 or more arguments in my CFCs). > > Any ideas would be greatly appreciated. > > > Regards, > > Daniel Short > Lead Developer > Cartweaver Development Team > Application Dynamics, Inc. > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > [EMAIL PROTECTED] > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > [EMAIL PROTECTED] > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED]
