Todd, This is the exact same problem that I described in http://tech.groups.yahoo.com/group/flexcoders/message/122930 . We can't implement the fix that you mention, because you'll find that your server-side now outputs:
<paymentAccounts>fooA</paymentAccounts> <paymentAccounts>fooB</paymentAccounts> <paymentAccounts>fooC</paymentAccounts> instead of <paymentAccounts> <paymentAccount>fooA</paymentAccount> <paymentAccount>fooB</paymentAccount> <paymentAccount>fooC</paymentAccount> </paymentAccounts> which in our scenario breaks our existing non-Flex consumers. If you remove the property definiton for PaymentAccounts in FooDogVO, you'll find the 3.1 decoder will create it properly (as an ArrayCollection). In our case, we couldn't do that either, because our PaymentAccounts is a subclass of ArrayCollection. But it'd work for you. The fact that the decoder decodes it two different ways depending on whether the ArrayCollection is predeclared is probably a good indicator that its a Flex bug. -Jeff > On Thu, 04 Sep 2008 00:45:55 -0000, Todd wrote > 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] > > > > ------------------------------------ > > -- > 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 > > > > !DSPAM:48bf3202111947818312239!
