Interesting that you can set a function to a 'var' scoped variable,
and that it will resolve!

That is pretty cool actually.

However, you do run the risk of losing the context of the calling CFC
in relation to the method you wish to call - which may well be an
issue for you!

I'll have a play with the technique, it's an interesting one.

Mark

On 10/23/07, Baz <[EMAIL PROTECTED]> wrote:
> Mark, in my case I am calling it from a parent CFC that is being extended by
> another CFC which may or may not be defining a custom function that needs to
> run. So the specific code in the parent CFC looks like this:
>
>  <!--- generic set --->
> <cffunction name="set" access="public">
>     <cfargument name="Name" type="string" />
>     <cfargument name="Value" />
>
>     <cfset var ReturnValue="" />
>
>     <cfset var CustomFunctionName="set#arguments.Name#" />
>     <cfset var CustomFunction="" />
>
>     <!--- if a real function exists, use it --->
>     <cfif existsFunction(CustomFunctionName)>
>         <cfset CustomFunction=variables[CustomFunctionName]
> />
>         <cfset ReturnValue=CustomFunction(arguments.Value) />
>
>     <!--- if property is defined in PropertyList, set it --->
>     <cfelseif listFindNoCase(getPropertyList(),
> arguments.Name)>
>         <cfset ReturnValue=setValue(arguments.Name, arguments.Value) />
>
>     </cfif>
>
>     <cfreturn ReturnValue />
> </cffunction>
>
> I'm var'ing the appropriate variables and it looks thread-safe to me, am I
> mistaken?
>
> Baz
>
>
>
>  On 10/22/07, Mark Mandel <[EMAIL PROTECTED]> wrote:
> >
> >
> > Baz,
> >
> > That has some pretty severe limitations however -
> >
> > - It can't be thread safe, as you are overwriting the same variable name
> > - If you wish to invoke that method from another CFC, you must
> > maintain the context of that method on that CFC, otherwise the context
> > of the method you are invoking is lost, and could quite possibly cause
> > an error
> >
> > Mark
> >
> > On 10/23/07, Baz <[EMAIL PROTECTED]> wrote:
> > > @Brian, there is a reason and method to the madness!
> > >
> > > @Matt, that solution won't work for this particular case because I know
> > > functionOne() will certainly define 1 named argument, but what that
> argument
> > > name is I won't know. So to adjust the test case:
> > >
> > >  How can I rewrite this code:
> > >
> > > <cfinvoke method="functionOne" argument1="123"
> returnvariable="ReturnValue"
> > > />
> > >
> > >  So that ReturnValue equals 123 regardless of whether functionOne is
> written
> > > like this:
> > >
> > > <cffunction name="functionOne">
> > >         <cfargument
> name="SomeRandomNameThatICanNeverKnow"
> > > />
> > >         <cfreturn
> arguments.SomeRandomNameThatICanNeverKnow
> > > />
> > > </cffunction>
> > > or like this:
> > >
> > > <cffunction name="functionOne">
> > >         <cfargument name="XYZ" />
> > >         <cfreturn arguments.XYZ />
> > > </cffunction>
> > > Another way of phrasing the question would be:
> > >
> > >  Is there a way to pass unnamed arguments using cfinvoke?
> > >
> > > For the record, Dan Wilson ( http://nodans.com) helped me come up with a
> > > solution without using cfinvoke, but by dynamically invoking a function
> > > using script:
> > >
> > > // dynamic function name
> > > FunctionName='FunctionOne';
> > >
> > > // save the function object itself to a variable
> > > FunctionObject=variables[ FunctionName ];
> > >
> > >  // invoke it
> > > FunctionObject('123');
> > >
> > > You will notice that if I invoke the function using the preceding
> syntax, I
> > > get the same result regardless of how functionOne() is defined (of the
> two
> > > options I specified earlier).
> > >
> > > Cheers,
> > > Baz
> > >
> > >
> > >
> > > On 10/22/07, Brian Kotek < [EMAIL PROTECTED]> wrote:
> > > > I'd argue that the better solution would be just to add a cfargument
> tag
> > > to the target method(s).
> > > >
> > > >
> > > > On 10/22/07, Baz < [EMAIL PROTECTED]> wrote:
> > > >
> > > > > Hi gang,
> > > > >
> > > > > I was wondering if it were possible to pass an un-named argument to
> a
> > > dynamic function. For example, I have this call:
> > > > >
> > > > >
> > > > > <cfinvoke method="get#arguments.Name#" returnvariable="ReturnValue"
> > > value="#arguments.Value#" /> - It is a CFINVOKE because to my knowledge,
> in
> > > CF8, you still can't invoke a dynamic function using script, i.e.
> > > set#DynamicFunction#(arguments) The attribute "value" in the cfinvoke
> call
> > > basically passes the invoked function an argument named "Value". Is it
> > > possible to pass in an un-named argument in position 1 instead?
> Basically
> > > the equivalent of set#DynamicFunction#(Value)??
> > > > >
> > > > > Cheers,
> > > > > Baz
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >  >
> > >
> >
> >
> > --
> > E: [EMAIL PROTECTED]
> > W: www.compoundtheory.com
> >
> >
>
>
>  >
>


-- 
E: [EMAIL PROTECTED]
W: www.compoundtheory.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"CFCDev" 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/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to