Parsing Element within Another element loses the value of the first Element about aexml

[tadija]

That is not a valid XML at first (you can check that on some online XML validator tool), but later after your changes it is valid. So, the AEXML is behaving correctly in this case.

[willchen]

Sorry, I missed escaping opening the in the previous comment.

Below is the XML that is valid and AEXML was not correctly taking in.

SAMPSON Aside to GREGORY Is the law of our side, if I say ay?

[tadija]

I'm not sure what's the problem, maybe it's related to NSXMLParser, maybe some other thing, but let's leave it here and whoever has time to investigate this further, and hopefully fix it, can make a pull request.

[JimBudet]

I'm seeing the same problem. The following code prints

let xmlString = "<p>Say <b>Hello</b> World</p>"
let data = xmlString.dataUsingEncoding(NSUTF8StringEncoding)!
let document = try! AEXMLDocument(xmlData: data)
print("\(document.xmlStringCompact)")

<?xml version="1.0" encoding="utf-8" standalone="no"?><p><b>Hello</b></p>

The value of the p element is lost when converting to string.

The problem is with the AEXMLElement.xmlString method. It either prints a child or a value but not both. However the "fix" isn't obvious since this example shows that there can be multiple values for an element and their order (with respect to the children) is significant.

It seems that the Element object needs to keep an ordered list of sub-objects where these sub-objects can be Strings (values) or Elements.

I'll add that I have verified that NSXMLParser parses this XML String correctly.

[FranklinYu]

@JimBudet Good point, how about a protocol ElementLike/Elementoid adopted by both AEXMLElement and String?

Sometimes user do need only the children who are AEXMLElements. My idea is to having two properties:

var richChildren: [Elementoid]
var children: [AEXMLElement] {
    richChildren.flatmap { element in
        element as? AEXMLElement
    }
}

[JimBudet]

@FranklinYu If I understand correctly, you're suggesting defining a new property (richChildren) that can contain both values (String) and elements (AEXMLElement). You apparently don't want to declare it as var richChildren: [AnyObject] so you want to create a new protocol (Elementoid, for AEXMLElement and String) so that you can declare it as var richChildren:[Elementoid] instead.

I think that I understand why you want to add the new protocol (Elementoid) but this protocol doesn't define any behavior (as far as I can tell) and it will clutter the code with empty protocol definitions and class extensions. Because of this, I'm not seeing a "real" advantage over the AnyObject approach. But there's not inherit problem with using the protocol either.

I'm curious on your thoughts on how the value, stringValue, boolValue, intValue and doubleValue properties will adapt to this change?

[FranklinYu]

@JimBudet Indeed there is no real advantage to define an empty protocol; it would be enough to simply declare richChildren of AEXMLElement as AnyObject as you stated, and in the document state "it would return an array with elements of only those two classes". It is possible to have some methods in the protocol, for example the children and richChildren properties:

extension String: Elementoid {
    var richChildren: [Elementoid] {
        return [];
    }
}

However, I admit that it does not help much. So overall, I agree with you.

Speaking of the value properties, I believe that the value property should be a calculated one:

extension AEXMLElement  {
    var value: String? {
        if richChildren.count == 1 && richChildren[0] is String {
            return richChildren[0]
        } else {
            return nil
        }
    }
}

and the other value-properties depend on this. How do you think?

I would expect this feature to change the API anyway, so it has to be at least in version 4.0.0.

[twstokes]

I've submitted a PR that may help with this: #115

[tadija]

Sorry, I think this goes a bit beyond simple XML parser, so I'll close this.