function getScope(scopeName)
{
switch(arguments.scopeName)
{
case "application":
return application;
break;
case "request":
return request;
break;
//and on as required.
}
var scope = getScope("request");
return scope[key];
See - not so hard :D
Mark
On 12/7/06, Kym Kovan <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I just noticed the "evaluate is bad" vibe in an email and it reminded me
> that I was going to post first thing today asking a question about
> evaluate() (its been that sort of a day). I spent too large a chunk of
> last night and early this morning trying to get round using evaluate and
> failed, so I then sought out why so many folk consider it to be "a bad
> thing" to try and justify having to use it :-)
>
> I have a tool that writes forms to a page, basically it creates the html
> from a big structure, and to put content/values into the form you need
> to be able to specify the variable name in the structure. The writing
> code then has an evaluate() to get the actual value to write to the
> page. I tried to use a structure but discovered that there is a
> limitation to the associative array style of notation. If I use
> something like: request[name_of_variable_in_request_scope] it works fine
> but if I want to specify the name of the scope in the structure as well,
> ie [name_of_scope][name_of_variable_in_scope], then I get a nice syntax
> error message. Doing the same with evaluate() pops out the value nicely
> so that is what I have been using.
>
> So flowing on from that I discovered a few blogs that directly
> contradict "evaluate() is bad" or, to be more precise, put that message
> into a sensible context. The standard story from way back is that CF has
> to invoke the parser at runtime to actually get the result of the
> evaluation, it is effectively a double parsing, one to work out the
> variable, done on the first compilation pass, and then again to get the
> value from that variable in the second pass at runtime. All of that is
> true but it seems that CF will compile the first result and save it to
> its own little class file so that if that result does not change then
> the second pass is run from compiled code not freshly parsed code This
> means that in a case such as indicated above where the variable names
> are not changing then using evaluate() gives virtually no performance
> hit at all.
>
>
> Kym K
>
>
> >
>
--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"cfaussie" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfaussie?hl=en
-~----------~----~----~----~------~----~------~--~---
