quote:
Originally posted by:
GeorgeWS
I did read a post about sending 2 variables one with a null
or something. I tried that and abunch of other stuff to no avail. I
also have read a bunch a posts claiming its a bug.
What you're trying to do is simple and in general it is
supported, something just must be confused in the code - we'll have
to work out what that is.
Note that post you mention about sending 2 variables - this
technique in Flash Remoting was to avoid an issue with CFC methods
as you have to help it distinguish that you're not sending named
arguments but one argument that is a single complex object. Named
arguments are like a struct of key-value pairs... and an
ActionScript Object does represent such a struct to CF. This method
of representing arguments would be unfamiliar to a Java or AS
developer as functions typically take ordered arguments. Anyway,
named argument confusion arises if you're sending a single
ActionScript Object to a CFC method - the Flash Remoting adapter in
ColdFusion can't get access to the real API of your CFC method (due
to certain internal limitations) to check the signature or number
of arguments so it has to assume that a single ActionScript Object
is a set of named arguments rather than a single parameter. If you
send a second argument after the Object, it knows it's not a set of
named arguments but instead its a list of plain old ordered
arguments. In order to send two arguments, however, your CFC method
signature needs to have at least two arguments defined
(obviously)... the first one would be of type struct to handle the
AS Object argument and the second can be anything... you can always
just ignore the second argument and not use it in your function.
The reason you may be hitting this problem is that you're
using MXML based syntax for arguments to take advantage of
automatic binding code. If you do choose this route, you need to
understand just what the MXML compiler is generating for your code:
<mx:method name="Inventory"
result="handleQueryResult(event)"
fault="Alert.show(event.fault.message)">
<mx:arguments>
<supplierid>
{Application.application.parameters.SupplierID}
</supplierid>
</mx:arguments>
</mx:method>
Note that the child of <mx:arguments> is seen just like
an <mx:Model>... a declarative view of an object graph. The
<supplierid> is seen as a property name, and the value is a
binding expression (in your case evaluating to the value 3). This
is equivalent to the following ActionScript:
arguments = new Object();
arguments["supplierid"] = 3;
So, you may indeed be sending an Object instead of just the
number 3?
You could check this in you CFC by looking whether
"#arguments.supplierid.supplierid#" is defined.
Whenever you're dealing with data communications you should
be aware of the ways to view the data being transmitted as without
it it makes debugging very difficult. Do you know about the debug
flashplayer's ability to trace out statements to a flashlog.txt
file? Are you familiar with the <mx:TraceTarget level="0" />
technique in Flex? Do you know about the ways of turning on debug
level logging for either Flash Remoting (setting logging level to
"debug" in gateway-config.xml) or Flex Data Services (setting
logging level to "debug" in services-config.xml) and looking at the
server logs (or the console if you started the app server on the
command line)?
