Title: Message
Something I just learned and to keep in mind when using evaluate():
 
The use of Evaluate, DE or SetVariable will run the CFML compiler creating a new class for each request. 
 
I could see this becoming a bottleneck as load increases.
 
Thanks,
Mike
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jerry Ela
Sent: Wednesday, March 16, 2005 10:18 AM
To: [email protected]
Subject: Re: [CFCDev] Calling a cfc method whose name is in a variable

You can use

structappend(attributes, url);
structappend(attributes, form);

note that if a variable exists in both form and url the form value will overwrite the url value.  Switch the order if you want the url val to take precedence.


Bill Rawlinson wrote:
as a matter of consistency we move all URL and FORM parameters into
the Attributes scope and to do that we use evaluate - I would love to
know if there is a faster/better way of doing this - and likewise I am
defiately open to hearing why moving these variables into the
attributes scope might be a bad idea.

We move them there so that we reference everything in the same fashion
and the person working on the receiving end doesn't have to worry if
the data coming to them is via  URL or a FORM - they get a consistent
source, Attributes, for their passed data.

	<cftry>
	
		<cfset urlKeys = structKeyList(url)>

		<cfloop list="#urlKeys#" index="thisKey">
			<cfif NOT IsDefined("Attributes.#thisKey#")>
				<CFSET SetVariable("Attributes.#thisKey#", Evaluate("url.#thisKey#"))>
			</cfif>
		</cfloop>


		<cfif IsDefined("form.fieldNames")>	
			<cfloop List="#form.fieldNames#" Index="field">
				<cfif not IsDefined("attributes.#field#")>
					<cfset SetVariable("attributes.#field#", Evaluate("form.#field#"))>
				</cfif>
			</cfloop>
		</cfif>
		
		<cfcatch type="any"></cfcatch>
	</cftry>





On Wed, 16 Mar 2005 14:22:14 -0000, Robertson-Ravo, Neil (RX)
<[EMAIL PROTECTED]> wrote:
  
Cool,

Would love to see alternative ways that I don't know about or haven't used.

OK, say we have this

#trim(evaluate("query.#ColumnName#"))#

Or

#Evaluate("query.column#request.stAvailableLanguages[i]["language"]#")

Cheers

N

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of Sean Corfield
Sent: 16 March 2005 14:01
To: [email protected]
Subject: Re: [CFCDev] Calling a cfc method whose name is in a variable

On Wed, 16 Mar 2005 13:21:10 -0000, Robertson-Ravo, Neil (RX)
<[EMAIL PROTECTED]> wrote:
    
Sean, can you give a case where it is a) unnecessary and b) required with
regards to dynamic processing - I think this would help clarify the
situation.
      
No, every case I've seen can be coded without evaluate().

    
I used to avoid it like the plague on advice of others but really I
      
haven't
    
really found any huge performance hit with it and in some cases you have
      
to
    
used it when evaluating data - is there some hidden way to avoid using
Evaluate?
      
Show me a case where you think you really need it.

    
If its not required or not advised when it comes to use - why is it still
      
in
    
the CF dictionary and not deprecated and been replaced with a faster more
efficient means of dynamic evaluation.
      
I think a lot of code relies on evaluate() - pre-MX you couldn't just
mess with scopes as if they were structs so you needed it back then.
>From MX onward, there is already a "faster more efficient" way to
avoid evaluate(). I would like to see it deprecated but it isn't my
choice to make.
--
Sean A Corfield -- http://www.corfield.org/
Team Fusebox -- http://www.fusebox.org/
Got Gmail? -- I have 50, yes 50, invites to give away!

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] 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/[email protected]
This e-mail is from Reed Exhibitions (Oriel House, 26 The Quadrant,
Richmond, Surrey, TW9 1DL, United Kingdom), a division of Reed Business,
Registered in England, Number 678540.  It contains information which is
confidential and may also be privileged.  It is for the exclusive use of the
intended recipient(s).  If you are not the intended recipient(s) please note
that any form of distribution, copying or use of this communication or the
information in it is strictly prohibited and may be unlawful.  If you have
received this communication in error please return it to the sender or call
our switchboard on +44 (0) 20 89107910.  The opinions expressed within this
communication are not necessarily those expressed by Reed Exhibitions.
Visit our website at http://www.reedexpo.com

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected]


    


  
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected]

Reply via email to