RE: [CFCDev] cfc check

[Paul]

> If it fails, you could just throw an error and have the code that called this function catch it and do what it wants with it.  … hint="I authenticate against LDAP and return a populated query object.<br/>Throws: ldap.missing if no records found”   If I were to adopt this idea, I would just cfthrow type="ldap.missing" within the CFC’s cfcatch block, yes?  I would also need to surround my calling code with <cftry> in order to handle the exception I throw…  And on that topic do most of you use some sort of error cfc to handle caught exceptions?   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter J. Farrell Sent: Wednesday, March 30, 2005 4:30 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] cfc check Hi Paul, Looks pretty good - however, I'm no OO guru - I'm sure others will chime in.  For the sake of clarity, I'd recommend grouping your getters/setters not by setting and getting but by variables - just make changes to a specific variables without hunting for the other half (i.e. a getter or setter). <cffunction name="getServer"....> <cffunction name="setServer"...> You don't really need to have a psuedo-constructor (the block outside the init()) since you already have an init() - the psuedo constructor can cause problems.  Just move the variables.instance = structNew() to the init() and forget about explicitly setting "null" values for the rest of the variables.instance since you have getters and setters for that. I don't really want to bring this up because it's been a hot topic before.  You mentioned that if the authenticate fails, it will return an empty query obj.  If it fails, you could just throw an error and have the code that called this function catch it and do what it wants with it.  This brings up the whole qryObj = "" or qyrObj = newQuery(...) argument that is in the archives.  Personally, I'd rather deal with the error than an empty query.  However, it's all personal preference.  I guess to me - if a method is supposed to return a query...it should return a full blown query to use and I shouldn't have to check to see if there is data in it.  It's all semantics... ;-) [ducks, runs and hides under the table]         <cffunction name="authenticate" access="public" returntype="query"                hint="I authenticate against LDAP and return a populated query object.<br/>Throws: ldap.missing if no records found">                <cfargument name="username" required="true" type="string">                <cfargument name="password" required="true" type="string">                <cfset var qLDAP = "">                <cftry>                        <cfldap action="">                                name="qLDAP"                                start="cn=users, dc=mydomain, dc=com"                                scope="oneLevel"                                server="#getServer()#"                                filter="sAMAccountName=#arguments.username#"                                attributes="#getAttributes()#"                                username="#getDomain()#\#arguments.username#"                                password="#arguments.password#"                                port="389">                        <cfcatch type="Any"><!--- do nothing ---></cfcatch>                </cftry>                <cfif NOT qLAP.recordcount>                        <cfthrow type="ldap.missing" message="No records found" />                </cfif>                <cfreturn qLDAP>         </cffunction> Otherwise, everything else looks pretty good.  Bare with me, this message has gotten side tracked a few times while writting and others have answered - I don't mean to be copying other people's suggestions. ;-) .pjf -- Peter J. Farrell :: Maestro Publishing blog    :: http://blog.maestropublishing.comemail   :: [EMAIL PROTECTED]phone   :: 651-204-0513 On Stardate 9567.39 which is Tuesday, I saw the light.-- ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org