0

For my application, I make an HTTPRequest, and get back some XML served from a JSP. That XML has some (yes, I'm aware this is invalid/improper XML. If I can't find a bandaid, I will try to address that internally) nodes with integers as names, say <2> for example.

When I attempt to access it, using myXMLVariable.child("2"), it returns the third (index=2) XML node instead. I understand that this behavior is "correct". Is there any way to get around this behavior?


Example

var myXML:String = "<response>" +
                    "<place1>" +
                    "   <item>1</item>" +
                    "   <stuff>1</stuff>" +
                    "</place1>" +
                    "<2>" +
                    "   <item>1</item>" +
                    "   <stuff>1</stuff>" +
                    "</2>" +
                    "<place3>" +
                    "   <item>1</item>" +
                    "   <stuff>1</stuff>" +
                    "</place3>" +
                    "</response>";

protected function getParam():void
{
    var xml:XML = new XML(myXML);
    
    Alert.show(xml.child("2"));
    //trace(xml.child("2"))
}

xml.child("2") returns

<place3>
    ...
</place3>

...when I want

<2>
    ...
</2>

NOTE

I am aware this is invalid XML. I am looking for a workaround, a short term fix. There is a near-future release date, and this workaround will be removed and replaced with proper XML for the next version.

Community
  • 1
  • 1
Sam DeHaan
  • 10,246
  • 2
  • 40
  • 48

4 Answers4

3

Use E4X search expression on XMLList.

trace(xml.children().(name() == "2").toXMLString());
  1. Get all children
  2. Search for the name() you need.
Michael Antipin
  • 3,522
  • 17
  • 32
  • It's great to come across a nice and concise question nowadays. :) – Michael Antipin May 01 '12 at 13:56
  • It works until you work with a new Flash player version that uses some internal way to check the xml input for correctness, and throws an error instead of even allowing the XML to be processed... I would not use this if I were you - it's a major bug waiting to happen. – weltraumpirat May 01 '12 at 14:10
  • Well, you a right. A band aid doesn't help, when you seriously need to get to the doctor. But it still may buy you some time to get to the hospital. – Michael Antipin May 01 '12 at 14:18
  • Well, it is still more advisable to clean the wound before putting on a band aid, is it not? – weltraumpirat May 01 '12 at 14:19
  • Whooo metaphors. I've implemented this workaround for now, but I'm also attempting to push through the XML generating fixes before next release. As to the new flash player worries, well, I have a feeling if adobe did that it might break half of the apps that run in flash player. As it is, malformed xml like this has been in use at the company I work for for as long as they've used flex/flash. – Sam DeHaan May 01 '12 at 14:26
  • 1
    My argument against it would be that once a band-aid is applied, an illusion that no more action needs to be taken is created -- its "fixed". "Why do you need to 'fix' something that has already been patched up?" The fact that you say that it has always worked that way is indicative of a culture of monkey-patching vs engineering. All I can say is this: *I wouldn't work where you work.* – J. Holmes May 01 '12 at 15:44
  • @32bitkid While I totally agree with you, in my experience there may be a quite a variety of *circumstances*, that can affect making a decision on the subject. The route to the obviously better solution may be obstructed and *sometimes* it's still better to take any possible action to get things running, then to resort to "You don't allow me to apply perfect solution right away, so I'm out of here" strategy. And, yes, you may not be proud of what you are doing at these moments. – Michael Antipin May 01 '12 at 16:02
  • And what's to that common argument "once a band aid is applied, you are unlikely to do better"... Well, some really don't, that's common indolence in action. And no one's saying this can be *good* in any way. – Michael Antipin May 01 '12 at 16:05
  • I still don't get why you wouldn't want to at least improve the XML in ActionScript before processing it. That way, at least you know that your part of the code is correct. – weltraumpirat May 01 '12 at 16:07
  • @NoxNoctis That was not a "You aren't going to play my way, so I'm going to take my ball and go home!" hissy-fit. It was a statement of philosophy: I want to write *great code* and this problem -- and the underlying *cause* -- sounds like it was fostered in an environment that does not value that. Perhaps you, and the OP for that matter, have a different philosophy. That is cool, but *I* would not work there. Period. That's all I'm saying. – J. Holmes May 01 '12 at 16:45
  • Michael Kay is suggesting the same in his answer. Sure, that is a plausible solution, but if I were to apply a kind of *temporary* fix, I would not mangle the incoming data. That would seem making bad things worse to me, as this way you get a more robust fix. :) – Michael Antipin May 01 '12 at 16:48
  • *In some ways* more robust and less transparent. – Michael Antipin May 01 '12 at 16:56
2

From the XML specification:

[Definition: A Name is an Nmtoken with a restricted set of initial characters.] 
Disallowed initial characters for Names include digits, diacritics, the full stop and the hyphen.

Your <2> tag does not have a valid name. You should not be surprised it doesn't work as expected.

EDIT

If there is no way to get around working with invalid documents like this, I would probably use a RegExp to replace the invalid tags with valid ones, prior to processing the result:

public function replaceNumericalXMLTagNames( input:String ):String {
    var reg:RegExp = /(\<\/?)([0-9]+)(\>)/g;
    return input.replace( reg, function():String {
        return arguments[1]+"num"+arguments[2]+arguments[3];
    } ) );
}
weltraumpirat
  • 22,544
  • 5
  • 40
  • 54
  • I am not surprised. I stated in the question that I am aware that it is invalid. I'm looking for a bandaid. A workaround. This is a minor app, that I only need a short term fix for. – Sam DeHaan May 01 '12 at 13:49
  • Garbage in, garbage out. It's usually a BadIdea™ to bandage up something that is inherently festering with code rot. – J. Holmes May 01 '12 at 13:54
  • Yes, it's definitely a BadIdea™, but I don't have control over the process at the moment. I can make a big deal about it, or I can short-term fix it for the current release, and push through the correct fix for the next one. – Sam DeHaan May 01 '12 at 13:59
  • I'm sorry I overlooked that, but nonetheless: Working around invalid documents like that is not something you should go for, at least not if you have even the slightest influence on how the data is generated. If you don't, consider using a RegExp to make it valid before processing the XML. See my edit. – weltraumpirat May 01 '12 at 14:04
1

I think actionscript is 'helping' you. The param for .child is an object and I'll bet that actionscript sees a number and converts it and uses it as an index. If it were me I'd fix the XML. That's going to haunt you later.

ethrbunny
  • 10,379
  • 9
  • 69
  • 131
0

If you want a short-term fix, change your non-XML with its non-standard tags to standard XML with proper named tags. Then you'll be able to use standard XML tools to manipulate it, and you'll get your code working far faster as a result.

Michael Kay
  • 156,231
  • 11
  • 92
  • 164
  • How was this necessary? Your answer says the same as other answers, with less useful contribution. I stated in the question that I'm looking for a short term fix, and the XML will be corrected in the near future. – Sam DeHaan May 01 '12 at 16:38
  • I guess I'm just advising you to avoid digging yourself deeper into the hole you find yourself in. Sorry if that's flippant advice; it's easy to be wise when you're not stuck in the mud yourself. – Michael Kay May 11 '12 at 15:12