Hi Franck,
I am pretty sure this is all related to types and the fact that Flex
will serialize primitive types differently than complex ones. The C#
code that creates the WS looks like this for the correctly functioning
elements:
[XmlArray("ContainersToRetrieve")]
[XmlArrayItem("ContainerType", typeof(ContainerType))]
ContainerType[] containersToRetrieve,
and like this for the incorrect ones:
[XmlArray("SelectedPlans")]
[XmlArrayItem("PlanNumber")]
string[] SelectedPlans
I think the only way to fix this would be to have SelectedPlans be an
array of complex objects rather than an array of strings.
Unfortunately, I don't believe this is an option as there is other
code that relies on this WS.
Sigh. I really wish there was more focus on, documentation of and
support for web services in Flex. The apparent concentration on FDS
seems misguided to me as I don't see is as being a viable option for
nearly as many organizations as web services are. I suppose I
understand that FDS deployments are where the real money would be for
Adobe, but it rings of the unrealistic and arguably unsuccessful model
upon which Flex 1 and 1.5 were based on.
Ben
--- In [EMAIL PROTECTED]ups.com,
"Franck de Bruijn"
<franck.de.bruijn@...> wrote:
>
> Hi Ben,
>
>
>
> I'm not sure if I'm following you, but I'll try :).
>
>
>
> I don't have answers, just questions. Let me put them to you:
>
> * Could it maybe be the type="s:string" part? Is 's' pointing to
the
> right xsd namespace?
> * I'm curious what is exactly making the 'ContainerType' element in
> your SOAP-message. Is it the name attribute or the type attribute?
If it is
> the type attribute, then for sure in the PlanNumber element it'll
not work
> ...
> * Could the nesting be a problem? What I see from your code example,
> is that the PlanNumber elements are one level deeper than the
ContainerType
> elements. Maybe it's an idea to test a webservice operation that takes
> straight PlanNumber elements?
>
>
>
> Good luck!
>
> Franck
>
>
>
> _____
>
> From: [EMAIL PROTECTED]ups.com
[mailto:[EMAIL PROTECTED]ups.com]
On
> Behalf Of ben.clinkinbeard
> Sent: Tuesday, August 08, 2006 7:29 PM
> To: [EMAIL PROTECTED]ups.com
> Subject: [flexcoders] Re: Clarification needed on how WSDL affects
> conversion of AS objects to SOAP
>
>
>
> I meant to hit preview... here is the rest of my post.
>
> The pieces of the WSDL that correspond are:
>
> <s:element minOccurs="0" maxOccurs="unbounded"
name="ContainerType"
> type="tns:ContainerType"/> (works correctly)
>
> and
>
> <s:element minOccurs="0" maxOccurs="unbounded"
name="PlanNumber"
> nillable="true" type="s:string"/> (array is
disregarded)
>
> Is nillable="true" causing a problem here? What changes need to
be
> made to make Flex treat arrays just like objects, like it does in the
> first operation?
>
> Thanks,
> Ben
>
> --- In [EMAIL PROTECTED] <mailto:flexcoders%40yahoogroups.com>
ups.com,
> "ben.clinkinbeard"
> <ben.clinkinbeard@> wrote:
> >
> > In one part of my app, I am creating my Operation.arguments object
> > like this:
> >
> > args.ContainersToRetrieve = new Array();
> > args.ContainersToRetrieve.push("Client");
> > args.ContainersToRetrieve.push("IndustryTrends");
> >
> > which, as expected, results in a SOAP call like this:
> >
> > <ContainersToRetrieve>
> > <ContainerType>Client</ContainerType>
> > <ContainerType>IndustryTrends</ContainerType>
> >
> > In a different spot, I am constructing a call in the same manner:
> > args.RPRSelections = new Object();
> > args.RPRSelections.SelectedPlans = new Array();
> > for(var i:int = 0; i < model.arr_selectedPlans.length; i++)
> > {
> > args.RPRSelections.SelectedPlans.push(model.arr_selectedPlans[i]);
> > }
> >
> > but that produces the following output, seemingly ignoring the
> > SelectedPlans array that was created.
> >
> > <RPRSelections>
> > <item>78167</item>
> > <item>78173</item>
> >
>
