I've sort of figured out new WSDL syntax that works as expected.  

If I change the WSDL declaration of paymentAccounts from:
<xsd:element maxOccurs="1" minOccurs="0" name="paymentAccounts">
  <xsd:complexType>
    <xsd:sequence>
      xsd:element maxOccurs="unbounded" minOccurs="0"
       name="paymentAccount" type="FooDogType"/>
         </xsd:sequence>
   </xsd:complexType>
</xsd:element>

TO:
<xsd:element maxOccurs="unbounded" minOccurs="0"
name="paymentAccounts" type="FooDogVO" />

It all seems to work.  This gets rid of some nested complexTypes and
sequence.

However, my bigger concern is changing all this code that worked
perfectly in 3.0 (10 services, 20 calls per service) and was probably
a workaround to make it work in 3.0..  What it does for the stability
of our code base.  

It seems that the backward compatibility of Flex and Web Services is a
bit sketchy, at best...especially because I don't know of other
situations that will need to be changed, too.   (This could be the
first of other problems that I've unleashed.)


--- In [email protected], "Josh McDonald" <[EMAIL PROTECTED]> wrote:
>
> Todd, if you can mail me off-list with a .zip of failing code, I'll
be able
> to poke around and (probably) figure it out for you when I get home this
> afternoon.
> 
> Cheers,
> -Josh
> 
> On Thu, Sep 4, 2008 at 4:24 AM, Todd <[EMAIL PROTECTED]> wrote:
> 
> > The only real changes (those that aren't ASDoc comments to the core
> > Flex code) I see in the the mx.rpc.soap package is in the
> > SOAPArrayType.as.
> >
> > FYI, I was happily using the 3.0.676 framework (which was post 3.0
> > release).
> >
> >
> > --- In [email protected], "Todd" <tprekaski@> wrote:
> > >
> > > Hello All,
> > >
> > >    If have some existing web services that were broken when I
upgraded
> > > to the 3.1 flex SDK.  I believe it has to do with the SOAP
Decoder.  I
> > > needed to get the newest SDK because there were other fixes I was
> > > awaiting.
> > >
> > > I have an Actionscript type that I'm decoding through the
> > > SchemaTypeRegistry:
> > > public class FooDogVO implements IValueObject
> > > {
> > >   public var quantityBasedFunding : Boolean;
> > >   public var numRecordsOrdered : int;
> > >   public var numRecordsForPurchase : int;
> > >   public var invoiceItems : ArrayCollection = new ArrayCollection();
> > >   public var fundedQuantityAccounts : ArrayCollection = new
> > > ArrayCollection();
> > >   public var paymentAccounts : ArrayCollection = new
ArrayCollection();
> > >   ...
> > >  }
> > >
> > > I'm calling a WebService that is returning the following SOAP Type,
> > > that is mapped via the SchemaTypeRegister to FooDogVO:
> > >
> > > <xsd:complexType name="FooDogType">
> > > <xsd:sequence>
> > >   <xsd:element name="numRecordsOrdered" type="xsd:int"/>
> > >   <xsd:element name="quantityBasedFunding" type="xsd:boolean"/>
> > >   <xsd:element maxOccurs="1" minOccurs="0"
> > name="fundedQuantityAccounts">
> > >       <xsd:complexType>
> > >           <xsd:sequence>
> > >               <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > name="fundedQuantityAccount" type="PaymentOptionType"/>
> > >           </xsd:sequence>
> > >       </xsd:complexType>
> > >   </xsd:element>
> > >   <xsd:element name="numRecordsForPurchase" type="xsd:int"/>
> > >   <xsd:element maxOccurs="1" minOccurs="0" name="invoiceItems">
> > >       <xsd:complexType>
> > >           <xsd:sequence>
> > >               <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > name="invoiceItem" type="InvoiceItemType"/>
> > >           </xsd:sequence>
> > >       </xsd:complexType>
> > >   </xsd:element>
> > >   <xsd:element name="total" type="xsd:double"/>
> > >   <xsd:element maxOccurs="1" minOccurs="0" name="paymentAccounts">
> > >       <xsd:complexType>
> > >           <xsd:sequence>
> > >               <xsd:element maxOccurs="unbounded" minOccurs="0"
> > > name="paymentAccount" type="PaymentOptionType"/>
> > >           </xsd:sequence>
> > >       </xsd:complexType>
> > >   </xsd:element>
> > >   <xsd:element name="applied" type="xsd:double"/>
> > >   <xsd:element name="remaining" type="xsd:double"/>
> > >   <xsd:element name="allowNewCreditCard" type="xsd:boolean"/>
> > >     <xsd:element maxOccurs="1" minOccurs="0" name="newCreditCard"
> > > type="PaymentOptionType"/>
> > > </xsd:sequence>
> > > </xsd:complexType>
> > >
> > > Before the Flex 3.1 update, The SOAP decoder properly made the
> > > FooDogVO.paymentAccounts property an ArrayCollection of
> > > PaymentOptionTypes.
> > >
> > > Now, however, with the Flex 3.1 SDK update, the
FoDogVO.paymentAccouns
> > > is an ArrayCollection to an ArrayCollection of PaymentOptionTypes.
> > > It's now FooDogVO.paymentAccounts.[ArrayCollection of
> > PaymentOptionTypes]
> > >
> > > So, I'm looking at the list of Bug fixes for Flex SDK 3.1 and I find
> > > the following two bugs:
> > > https://bugs.adobe.com/jira/browse/SDK-14321
> > > https://bugs.adobe.com/jira/browse/SDK-14871
> > >
> > > But I'm not really sure what's going on with the new Soap Decoder
> > > stuff.  It seems like I was inadvertently performing a workaround
> > > before, but what really should be the proper mapping of elements of
> > > completTypes to ArrayCollections?
> > >
> > > Thanks for any input on a) what's going on b) how I should
properly be
> > > handling this, whether on the Web Service side, or the Flex client.
> > > Naturally, I can always manually remap the properties when the Soap
> > > result completes, keeping my VOs (which the application is coded
> > > against) the same, but ideally, I'd just do "the right thing"
with the
> > > SOAP Decoder/Schema Type registry.
> > >
> > > Thanks,
> > > Todd
> > >
> >
> >
> >
> > ------------------------------------
> >
> > --
> > Flexcoders Mailing List
> > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
> > Search Archives:
> > http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups
> > Links
> >
> >
> >
> >
> 
> 
> -- 
> "Therefore, send not to know For whom the bell tolls. It tolls for
thee."
> 
> :: Josh 'G-Funk' McDonald
> :: 0437 221 380 :: [EMAIL PROTECTED]
>


Reply via email to