JoriDor,
nachvollzogen ich meine Schritte und stellte fest, dass eine zweite Differenz zwischen dem, was ich geschaffen und was ich aus der Probe bekam unten angeführten erscheint die wahre Ursache zu sein.
Meine ArrayCollection-Instanzvariable wurde von getter/setter-Funktionen erstellt. Als ich es in eine öffentliche Variable änderte, wie der Beispielcode, funktionierte es! Das ist sehr enttäuschend, da ich jetzt überlegen muss, meine VO-Klassen zu ändern.
Nicht zu schnell aufgeben, ich kann mir vorstellen, dass die mx.rpc.xml Klassen Reflexion verwenden (describeType()), ich kann so vielleicht sehen, was über das Ändern der Handhabung von < Accessor> im Vergleich zu < Variable getan werden kann> -Tags .
... 30 Minuten später, und danke Adobe für Open-Sourcing Flex ... Ich fand XMLDecoder.getExistingValue() verwendet BeschreibungType und berücksichtigt Getter/Setter (aka "Accessor"). Mein Konstruktor hat eine leere ArrayCollection erstellt. Nun, XMLDecoder.setValue weiß nicht, ob dieses AC ersetzt oder Elemente hinzugefügt werden sollen. Es tut das letztere. Die AC-Instanziierung wurde bis zum ersten Aufruf des Getters verschoben (natürlich auf Null), und jetzt funktioniert es!
Ich hoffe, dass es für Sie behebt. Wichtige Teile von XML Decoder, die Sie besuchen sollten, wenn Sie geneigt sind: setValue(), getExistingValue() und dann das Problem, das von promoteValueToArray() ausgeführt wird.
Retracted Teil beginnt ...
auch ich das gleiche Verhalten zu finden bin. Ich weiß nicht, ob das als eine Antwort zählt, aber ich habe Code, der funktioniert, aus this site entnommen. Der Hauptunterschied, den ich zwischen meinem Code/Daten und dem, was auf dieser Site gepostet wird, unterscheiden kann, ist die Art und Weise, in der ich meine Sammlung/das Array im Schema deklariere.
In meinem Schema, hatte ich eine Sammlung auf diese Weise erklärt:
<complexType name="Things">
<sequence>
<element name="thing" type="ids:Thing" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="ParentThing">
<complexContent>
<sequence>
<element name="things" type="Things"/>
</sequence>
<complexContent>
</complexType>
Im Code aus der oben verlinkten Seite wird die Sammlung mehr direkt erklärt:
<xs:complexType name="example">
<xs:sequence>
...
<xs:element name="items">
<xs:complexType>
<xs:sequence>
<xs:element name="item" type="item" maxOccurs="5"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
(Für den Fall, Sie werden abgeworfen, "Beispiel" ist ein Typ und ein Element im Beispielcode.Dies warf mich ab, während die Untersuchung, wie der Beispielcode funktionierte.(Ich bevorzuge die Konvention, nur Typen/Klassen zu kapitalisieren.))
Wie dem auch sei, der Beispielcode funktioniert, und der Schemaunterschied schien der einzige Unterschied zu sein, der zählte. Mit Blick auf die XML-Instanzen (seine und meins) gab es keinen Unterschied zu sehen. Jede Sammlung wird von einem Element mit einem Pluralnamen geprägt. Das ist < Things> hat < thing> Instanzen, während < items> hat < item> Instanzen.
Ich würde gerne wissen, wie Ihre Schema- und/oder XML-Instanz aussieht und ob sie geändert wird, um dem obigen Beispiel zu entsprechen (wenn Schemaänderungen in Ihrem Fall möglich sind) behebt das Problem.
JoriDor, tut mir leid. Meine Implementierung von genau dem, was Sie oben haben (bedarfsgesteuerte Instanziierung) funktioniert nicht, auch nicht mit ArrayCollection. Ich habe keinen Weg gefunden, es zum Laufen zu bringen. Entschuldige vielmals. –
Gute Trauer ... Kommentar Zeitüberschreitung. Hier ist die Balance: Public Getter/Setter funktioniert aber. Zeile 2213 von XMLDecoder (innerhalb von SetValue) verschiebt den Wert auf das vorhandene "iterable" (das heißt, TypeIterator.isIterable (existingValue) evals zu True). Dies ist der "Täter". Ich denke, die Logik sollte die Werte beschreiben, anstatt sie zu pushen. –