Um, no it's not. You just read on the mailing list what feature he is interested in and he didn't submit a request for it.
Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ 888-408-0900 x901 > -----Original Message----- > From: Christian Cantrell [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 02, 2003 1:59 PM > To: CF-Talk > Subject: Re: Some idea about the Efficiency of UDFs > > Well, it's hard for us to know that you are interested in a feature if > you don't submit a request for it. I don't consider submitting feature > requests to be secretary work, so I'll be happy to take care of it. > > Christian > > On Thursday, January 2, 2003, at 12:10 PM, Li Chunshen ((Don)) wrote: > > > Christian, > > > > No, I didn't submit it (I don't like to be a > > secretary), you please, no, you are not a secretary > > either :) for that may be part of your job. > > Thanks. > > > > Don Li > > > > --- Christian Cantrell <[EMAIL PROTECTED]> > > wrote: > >> Good point. You could always call the other > >> functions using the same > >> routine that CFM pages would be expected to use, but > >> I can see where it > >> would be easier (more maintainable) to keep several > >> functions in a > >> single file. I have several functions that call > >> other functions, and > >> many of them are only one or two lines, so I'm sure > >> it would get > >> annoying having directories full of files with > >> functions containing > >> only a single line. The idea Jim proposed gets > >> around this limitation > >> nicely (dir.file.function). > >> > >> Thanks for the feedback, everyone. Li, did you > >> submit this, or shall I? > >> > >> Christian > >> > >> On Thursday, January 2, 2003, at 09:34 AM, Ben Doom > >> wrote: > >> > >>> One thing to think about: CF probably shouldn't > >> require one and only > >>> one > >>> UDF per file. Occasionally it makes sense for me > >> to write UDFs that > >>> call > >>> other UDFs (either because the functionality > >> already exists, will be > >>> needed > >>> elsewhere, or it just makes the 'main' UDF easier > >> to read) and I > >>> generally > >>> include those subroutines in the same file. If I > >> had to have a > >>> separate > >>> file for each, it would be rather confusing IMHO. > >>> > >>> > >>> -- Ben Doom > >>> Programmer & General Lackey > >>> Moonbow Software, Inc > >>> > >>> -----Original Message----- > >>> From: Christian Cantrell > >> [mailto:[EMAIL PROTECTED]] > >>> Sent: Wednesday, January 01, 2003 6:01 PM > >>> To: CF-Talk > >>> Subject: Re: Some idea about the Efficiency of > >> UDFs > >>> > >>> > >>> Interesting idea. So how exactly would this work? > >> Would ColdFusion > >>> expect one function per file, with the requirement > >> that the file and > >>> the function have the same name? Then you could > >> call any arbitrary > >>> UDF, and the CF server would look in the proper > >> directory for the right > >>> file, then execute the function in that file. How > >> else could this > >>> work? > >>> > >>> Let's flesh it out a bit here, then I invite you > >> to submit your idea to > >>> Macromedia at the following URL: > >>> > >>> > >> > > http://www.macromedia.com/support/email/wishform/?6213=3 > >>> > >>> Christian > >>> > >>> On Wednesday, January 1, 2003, at 04:40 PM, Li > >> Chunshen ((Don)) wrote: > >>> > >>>> According to Macromedia's CFMX References on > >> Using > >>>> UDFs effectively: > >>>> > >>>> "Consider the following techniques for making > >> your > >>>> functions available to your ColdFusion pages: > >>>> > >>>> If you consistently call a small number of UDFs, > >>>> consider putting their definitions on the > >>>> Application.cfm page. > >>>> If you call UDFs in only a few of your > >> application > >>>> pages, do not include their definitions in > >>>> Application.cfm. > >>>> If you use many UDFs, put their definitions on > >> one or > >>>> more ColdFusion pages that contain only UDFs. You > >> can > >>>> include the UDF definition page in any page that > >> calls > >>>> the UDFs. " > >>>> > >>>> I agree with everything it states, and I think it > >>>> might help more if CFMX predefines a UDF library > >> path > >>>> such as UDFlib under CFMX installation instead of > >> an > >>>> arbitrary directory, I can see several benefits > >> of > >>>> this approach: > >>>> consistency -- especially helpful for large > >>>> development environment; > >>>> easier for reuse -- across applications/projects > >>>> (this one is similar to CFMODULE's dot notation > >>>> method, I love it) > >>>> > >>>> And I don't see any downside of it. Thanks. > >>>> > >>>> DL > >>>> > >>>> > >>>> --- Matthew Walker <[EMAIL PROTECTED]> > >> wrote: > >>>>> These two cfmx UDFs from cflib.org may help: > >>>>> > >>>>> > >>>>> <cfscript> > >>>>> function DSNExists(DSN) { > >>>>> var factory = > >>>>> > >>>> > >> > > createObject("java","coldfusion.server.ServiceFactory"); > >>>>> var DSNs = > >>>>> factory.getDataSourceService().getNames(); > >>>>> return > >>>>> yesNoFormat(listFindNoCase(arrayToList(DSNs), > >>>>> DSN)); > >>>>> } > >>>>> </cfscript> > >>>>> > >>>>> > >>>>> <!--- > >>>>> Verifies a DSN is working. > >>>>> > >>>>> @param dsn Name of a DSN you want to verify. > >>>>> (Required) > >>>>> @return Returns a Boolean. > >>>>> @author Ben Forta ([EMAIL PROTECTED]) > >>>>> @version 1, October 15, 2002 > >>>>> ---> > >>>>> <CFFUNCTION NAME="VerifyDSN" > >> RETURNTYPE="boolean"> > >>>>> <CFARGUMENT NAME="dsn" TYPE="string" > >>>>> REQUIRED="yes"> > >>>>> > >>>>> <!--- initialize variables ---> > >>>>> <CFSET var dsService=""> > >>>>> <!--- Try/catch block, throws errors if bad > >> DSN > >>>>> ---> > >>>>> <CFSET var result="true"> > >>>>> > >>>>> > >>>>> <CFTRY> > >>>>> <!--- Get "factory" ---> > >>>>> <CFOBJECT ACTION="CREATE" > >>>>> TYPE="JAVA" > >>>>> > >>>>> CLASS="coldfusion.server.ServiceFactory" > >>>>> NAME="factory"> > >>>>> <!--- Get datasource service ---> > >>>>> <CFSET > >>>>> dsService=factory.getDataSourceService()> > >>>>> <!--- Validate DSN ---> > >>>>> <CFSET > >> result=dsService.verifyDatasource(dsn)> > >>>>> > >>>>> <!--- If any error, return FALSE ---> > >>>>> <CFCATCH TYPE="any"> > >>>>> <CFSET result="false"> > >>>>> </CFCATCH> > >>>>> </CFTRY> > >>>>> > >>>>> <CFRETURN result> > >>>>> </CFFUNCTION> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Li Chunshen (Don) > >> [mailto:[EMAIL PROTECTED]] > >>>>>> Sent: Wednesday, 1 January 2003 11:37 a.m. > >>>>>> To: CF-Talk > >>>>>> Subject: Request Time > >>>>>> > >>>>>> > >>>>>> specs: CFMX on WinXP Pro; remote datasources on > >>>>> Win2k > >>>>>> Pro. > >>>>>> > >>>>>> Requestimeout set to 40 seconds via CF admin > >>>>> (server > >>>>>> has been rebooted, my friend). Expect cf > >> server > >> > > === message truncated === > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > > http://mailplus.yahoo.com > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
