Basically, I'm treating this as a fail-over loop.  If the first attempt
doesn't work, then the loop iterates and tries the next server and so
on.

The cfreturn tag should throw us out of the loop, as well as the entire
method, once I get a successful ldap query.  If the first query is
successful, the successive loop iterations will never happen, therefore,
will not create a redundant connection and query.

I assume your suggestion would be best done with a "conditional" loop
rather than a counter loop such as this?

 cfloop condition="(if no error found yet)"

  cftry
    ldap query here

    cfbreak (to get out of the loop on the first successful attempt)

    cfcatch
      (set error condition variables here)
    /cfcatch
  /cftry

 /cfloop

 cfif (error condition is true)
    throw error here
 /cfif

 cfreturn ldap query results

I'm struggling with the "proper use" of when to perform a return.  Is it
acceptable to use cfreturn to break out of a loop or if statement as
well as return data to the caller?  Or, is that asking too much of the
cfreturn tag?

-----Original Message-----
From: Todd [mailto:[EMAIL PROTECTED] 
Sent: Sunday, August 10, 2003 12:17 PM
To: [EMAIL PROTECTED]
Subject: Re: Active Directory Query Service was: RE: [CFCDev] Component
Critique Wanted



Not sure I like the line 88 -> 90 specifically the:
<!--- Do nothing in order to try all ldap servers. --->

#1.) Don't you want to stop after the first successful LDAP 
server?  Currently, it's going to try them all.  Doesn't that mean that 
you're basically opening redundant connections to all servers? (if you
had 
5 of them and all of them were successful, so what? now what?)

#2.) Wouldn't it be better to create a :
result = structNew();
result.server1 = "failed";
result.server2 = "success!";

... etc - put this in the <cfcatch> block.

"Do all udfs on cflib need to be built with cfscript only or will they
also 
accept tag-based udfs?"

They accept both.

~Todd

At 12:25 PM 8/10/2003, you wrote:
>Here is my almost-ready-for-production cut of the component.  I'm 
>pretty satisfied with this code.  I have enough flexibility with the 
>methods, yet still retain many default values, in the init() method, 
>that I don't normally touch.
>
>I do have to give a lot of thanks to the "power contributors" of this 
>list.  I have learned quite a bit about CFCs and OOP (as it applies to
>CFMX) from lurking here.
>
>Is this of the caliber to post on the cfczone or cflib sites?  I 
>haven't seen too many, if any, functions that handle LDAP queries.  Do 
>all udfs on cflib need to be built with cfscript only or will they also

>accept tag-based udfs?
>
>Thanks


----------
Todd Rafferty ([EMAIL PROTECTED]) - http://www.web-rat.com/
Team Macromedia Volunteer for ColdFusion
http://www.macromedia.com/support/forums/team_macromedia/
http://www.devmx.com/

----------

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' 
in the message of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
in the message of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).

Reply via email to