I noticed all the praise for Joseph's work on this list, and haven't had a chance to jump in. I have known Joseph several years now, and he is true programmer's programmer. I have used his tool from its earliest available inception (and other tools before that), and it ROX. It has cut development time down by orders of magnitude. I have told him at CFUG meetings, but never publicly in a forum like this one. Thanks much Joseph, keep it coming!
-----Original Message----- From: Joseph Flanigan [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] CFC Code generator - Question I understand your point now. "I don't want to beat this to death" - not at all. I asked the question, you gave constructive points. I wrote the UDF RequestInOut() that is now posted on CFLIB after many discussions with Ray Camden. Because I use Request.IN/.OUT, my focus for the tool was not as broad as a scenario as you stated. So that is very helpful. For the tool. How about this? Add an input text field that will allow any structure name. So it can default to Request.IN or be changed. One comment. CFSQLTool is really a namespace tool. While it goes quite a way to generating run-time code, the target for its code is build-time programming. I tried to make the variable names and code layout easy to edit change. Joseph At 09:45 PM 3/10/2004, you wrote: >I don't want to beat this to death, but I can't help but point out that if >someone were to drop your code into an existing application (a likely >scenario), they would have to be sure not use the variables request.in and >request.out -- both of which are quite generic and potentially common. This >in one of the main reasons mixing external variables inside of CFC's is a >bad idea in the long run. If you decide using request variables is really >the only way to make what you want work then you should at least create a >more specific name space to mitigate the risk of name conflicts. Perhaps >request.sqltool.in and request.sqltool.out would work? > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Joseph Flanigan > > Sent: Wednesday, March 10, 2004 2:42 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] CFC Code generator - Question > > > > > > > In HTML INPUT tags there are no spaces -- good eyes. Fixed. > > > > > init() for DSN - good idea > > > > >Request variables in the CFC. > > > > Indeed some my find uncomfortable. Here is my approach. > > All actor messages either to or from exist in a common namespace, > > Request.IN or Request.OUT. Once a variable has space, use the space. > > Case - ActorIn and ActorOUT - These are basic library functions and > > just replace hand coding the same in the application. > > Case - Request.OUT in query function. This is a generation > > option so > > it can be selected. When used with ActorOUT, the form will have variable > > value for input tags. > > > > Example of using wrapper function calls to add a contact: > > <cfscript> > > create contact component object > > contact.actorin > > contact.create > > contact.form > > contact.actorout > > contact.endform > > </cfscript> > > > > > > Joseph > > > > At 08:58 AM 3/10/2004, you wrote: > > >One obvious thing for the init() method is to pass in the DSN > > and store it > > >as an instance variable -- that would prevent you from having to > > pass it on > > >the other methods (though, you could keep it as an optional argument, > > >perhaps). > > > > > >A random comment -- I bristled a bit at your use of the Request > > scope inside > > >the CFC. Admittedly, it's a reflexive reaction to any reference > > of external > > >variables. But, why not use private instance data there? Another minor > > >thing -- I also notice in the generated HTML INPUT tags there > > are no spaces > > >between tag attributes, but you do have spaces for attributes in > > the rest of > > >the generated code. > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > Behalf Of Joseph Flanigan > > > > Sent: Wednesday, March 10, 2004 7:20 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [CFCDev] CFC Code generator - Question > > > > > > > > > > > > The Table Wrapper CRUD Wizard generates a CFC but with no > > init() function. > > > > > > > > Should I add an init() function? > > > > If so, in the case of the table wrapper, what should be in the init()? > > > > > > > > Joseph > > > > >---------------------------------------------------------- >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 >www.mail-archive.com/[EMAIL PROTECTED] ------------------------------------------ Switch_box www.Switch-box.org MediaFirm, Inc. PO Box 2171 Loveland, CO 80539 [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 www.mail-archive.com/[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 www.mail-archive.com/[EMAIL PROTECTED]
