HTTPServiceWrapper konvertiert fälschlicherweise einen String zu Number

[HarpoMarx]

Ich habe in FlashBuilder 4 einen XMLservice erstellt, der von HTTPServiceWrapper erbt. Dieser soll eine XML-Datei holen und die darin enthaltenen Daten in ein ValueObject packen. Die Daten im XML sehen so aus:

PHP-Code:

<medium id="1050662256262775">
    <label><![CDATA[Acetone]]></label>
.
.
.
</medium> 


Die id ist im daraus generierten ValueObject ein String, was auch bei dem Datensatz oben funktioniert, obwohl die id nur aus Ziffern besteht.
Im Falle eines anderen Datensatzes mit der id '1050662328e65175' macht der von FlashBuilder generierte Code nun jedoch eine Zahl daraus, so dass ich bei der Abfrage der id des ValueObjects Medium 'Infinity' zurückerhalte.
Da dieses Fehlverhalten tief im von FB generierten Code zu liegen scheint, bin ich nun überfragt, wie ich dem beikommen könnte.
Die XML-Datei selber zu parsen scheint mir derzeit das einzige Mittel zu sein, das mir zur Verfügung steht, aber es muss doch auch eleganter gehen. Kann man den Wrapper nicht irgendwie dazu zwingen den Datentyp String anzuwenden?

Viele Grüße

Klaus

[Omega Psi]

Was ist an selbst parsen nicht elegant? Ausserdem wird der Memory Footprint arg reduziert.

[HarpoMarx]

Ok. Ertappt. Ich suche nicht nach dem elegantesten Weg, sondern nach schnellsten, weil die Serviceklasse schon weit gediehen ist, für mich alles erledigt und jetzt im Nachhinein aufgefallen ist, dass bei 3 von 200 Datensätzen dieser Fehler auftritt.
Auch andere XMLs hole ich darüber. Alles hübsch bis auf die kleinen Ausreißer.
Für mich wäre das jetzt ein (großer) Mehraufwand, das alles zu trennen und nur für die Medien-XML einen Extraparsing zu coden.

[Omega Psi]

Hm, hat das VO eine ID Eigenschaft die als String deklariert ist?

[HarpoMarx]

Japp:

PHP-Code:

private var _internal_id : String;
.
.
.
    public function set id(value:String) : void 
    {        
        MonsterDebugger.trace(this, value, MonsterDebugger.LEVEL_DEBUG, "", "value"); //<-- Schmeißt 'Infinity'
        var recalcValid:Boolean = false;
        if (value == null || _internal_id == null)
        {
            recalcValid = true;
        }    
        
        
        var oldValue:String = _internal_id;               
        if (oldValue !== value)
        {
            _internal_id = value;
            this.dispatchEvent(mx.events.PropertyChangeEvent.createUpdateEvent(this, "id", oldValue, _internal_id));
        }             
        
        if (recalcValid && model_internal::_cacheInitialized_isValid)
        {
            model_internal::isValid_der = model_internal::calculateIsValid();
        }  
    } 


[Omega Psi]

Da wäre natürlich der Wert in der XML interessant.

[thomas_E]

ich vermute durch das e in '1050662328e65175' versucht er das als Hex-Wert zu interpretieren 0x1050662328e65175 == 1175551803939770741, nur sprengt das den Rahmen für int.

eine einfache (aber imo nicht ganz saubere) Lösung:

PHP-Code:

<medium id="#1050662256262775"> ... </medium> 


durch die Raute am Anfang sollte HTTPServiceWrapper das eindeutig als String erkennen, und auch nicht auf die Idee kommen nur einen Teil davon zu parsen (wie es parseInt ja macht, wenn nach der Zahl noch "Text" steht)

PHP-Code:

public function set id(value:String) : void 
{        
    MonsterDebugger.trace(this, value, MonsterDebugger.LEVEL_DEBUG, "", "value"); //<-- Schmeißt 'Infinity'
    var recalcValid:Boolean = false;
    if (value == null || _internal_id == null)
    {
        recalcValid = true;
    }    
    
    if(value.charAt(0) == "#") value = value.substr(1);        //<--
    
    var oldValue:String = _internal_id;
    if (oldValue !== value)
    {
        _internal_id = value;
        this.dispatchEvent(mx.events.PropertyChangeEvent.createUpdateEvent(this, "id", oldValue, _internal_id));
    }             
    
    if (recalcValid && model_internal::_cacheInitialized_isValid)
    {
        model_internal::isValid_der = model_internal::calculateIsValid();
    }  
} 


[Omega Psi]

Ja, eine Umbenennung der IDs dürfte am schnellsten gehen, sonst musst du an den entsprechenden Stellen halt Hand anlegen.

[HarpoMarx]

Die XMLs werden leider fremdgeliefert und auch für anderes verwendet. Deswegen kann der Hebel leider nicht an dieser Stelle angesetzt werden.

[HarpoMarx]

Eine ID mit dem Wert '1050662ece5b1175' funktioniert auch. Es werden nur die IDs, die nur genau ein 'e' enthalten, falsch konvertiert. Ich nehme an, dass das als Exponentialwert eingeordnet wird.