There are a couple of bugs in encoder/decoder still in 3.1 (I've submitted patches, one has been merged in but too late for 3.1, the other not yet) but in my experience nearly every time we have a problem regarding web services it's because Flex is doing the right thing (complaining, ignoring invalid data, or trying its best to parse something that's not valid) and that Oracle SOA / Xfire / whatever is spitting out rubbish.
Either way, I'm glad you found a solution :) FWIW, I think the original definition (that gave you trouble) is kinda iffy. When there's no accounts, should you have an empty paymentAccounts node, or no paymentAccounts node? Unfortunately XSD gives you a lot of freedom to do stuff that doesn't make much sense to a standard OO object graph. The automated unmarshalling to objects is pretty damned good given all the various different ways to define things that mean something rather different to a schema interpreter, but end up generating the same XML. -Josh On Thu, Sep 4, 2008 at 10:45 AM, Todd <[EMAIL PROTECTED]> 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 > > > > -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." http://flex.joshmcdonald.info/ :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
