I did not think of your case of (obj is Array). Yeah. That could be a problem.
Here’s some examples of how I’ve used XML in the past:
1. myXMLList[myXMLList.length()] = myNewXML. This adds the object to the XML
list and inserts it into the underlying XML object. Under the hood this could
be something like this:
myXMLList[myXMLList.length()-1].parent.insertChildAfter(myXMLList[myXMLList.length()-1]);
2. There’s no good way to delete nodes from XML. The only two ways I know are
a) To add the child XML to another XML object b) to use delete. delete only
works on XMLLists which have a length of 1. Otherwise you need to reference the
XML object within the list. I have no idea why there is not a removeChild()
method like there is in modern javascript.
3. I’ve used lots of E4X filters, but I generally steer away from complex
filters because I always find them confusing.
4. One common use case for XML (which does not need toXMLString()) is binding
to tree components. I’ve always found XML a more natural fit than objects
there. (not sure why)
> So, given all that, if your XML class is dynamic, and attributes are just
> added to the instance as properties with the @prefix and child nodes are
> arrays of the child node name, I think that delete will do the right thing.
Yes. attributes can be prefixed with “@“, but what about element names which
might conflict with function names? For example I could easily see someone have
some xml which looks like this:<catalog><name title=“something”/></catalog>
“name would then conflict with “name()”.
I was thinking of having one array of elements and another for properties.
Mapping delete to something like that sounds tricky.
On Nov 12, 2015, at 7:28 PM, Alex Harui <aha...@adobe.com> wrote:
> I will spend some time looking into how the compiler sees XML Literals.
>
> Regarding length(), delete, and extending Array:
>
> If you extend Array, I would worry that some code like:
>
> if (obj is Array)
> createArrayCollection(obj)
> else
> createXMLListCollection(obj)
>
> will not do what the developer would expect. And again, code hinting
> would offer up methods that probably shouldn’t be exposed.
>
> I can probably teach the compiler to map length() to length, but let’s
> first nail down scenarios so we understand where we can hack and where we
> shouldn’t. I haven’t written any production apps that use XML, so I am
> relying on input from you and others.
>
> The key thing about the XML implementation is when you will need to know a
> property (or attribute) changed, if ever. You would only need to use
> Object.defineProperties to immediately catch changes. Otherwise, it is
> reasonable to think of the APIs as queries. XML is defined in
> ActionScript as dynamic. So really, it may be that you can get quite far
> without immediate change detection.
>
> Also, I recall past conversations where folks were doing things to XMLList
> that the language guys never anticipated, like adding nodes from some
> other XML tree to ab XMLList. We have to keep in mind that we may not be
> able to replicate 100% of E4x, but if we can get even 80% there, it will
> be a major savings to folks with existing code bases.
>
> And, of course, since the implementation should be swappable, we can build
> an implementation that handles the most common cases and allow
> extensibility or full replacement to get other cases.
>
> So, given all that, if your XML class is dynamic, and attributes are just
> added to the instance as properties with the @prefix and child nodes are
> arrays of the child node name, I think that delete will do the right thing.
>
> For XMLList, how common is it to delete an index and what does it do (does
> it affect the XML the XMLList came from)? We are having the compiler map
> E4X syntax into new APIs on XML and XMLList, so maybe we do add a
> removeChild to XML and I can get delete to call it.
>
> Also, does deleting an index from an XMLList re-order the indexes or just
> set that index to undefined/null. If the latter, that should be free.
>
> My understanding of the bigger picture is that folks get some XML,
> manipulate it with E4X, and always call toXMLString() at the end. If XML
> and XMLList are dynamic, toXMLString can just walk the properties on each
> node and no immediate change detection is needed. Even length() would
> just walk each property looking for property names that map to numbers and
> return the highest number it found. That would be slow, but it would work.
>
> Thoughts?
> -Alex
>
>
> On 11/12/15, 7:10 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> Another question regarding FalconJX:
>>
>> How easy will it be to handle xml literals? The most straightforward way
>> I can think of that would be to convert:
>> var myXML:XML = <root><node name=“fred”/><node name=“John”/></root>;
>> into
>> var myXML:XML = new XML("<root><node name=\“fred\”/><node
>> name=\“John\”/></root>”);
>>
>> Right now I’m left with three open questions:
>>
>> 1. Will it be hard to convert XMLList.length() into XMLList.length
>> 2. How can we deal with “delete” in the context of XML
>> 3. How to deal with XML literals
>
