I'm sorry if this approach was discussed and discarded, but here it is anyway:
1. Create a new XML class type in actionscript 2. Immediately convert it into an actionscript object using the mx.rpc.xml.XMLDecoder class 3. Provide the usual public apis to the XML class 4. Internally, do all the actions on the actionscript object 5. Implement XML.xml() or XML.toString() to internally convert the actionscript object into XML using the mx.rpc.xml.XMLEncoder class. On the JS side, do the same, except use JXON? Thanks, Om On Thu, Nov 12, 2015 at 12:36 PM, Alex Harui <aha...@adobe.com> wrote: > I only read this article quickly. I’m not sure what you mean by “proxies > to XML.xmlObj”. > > My takeaway from the article is that the XML class you are writing will > need to handle > > new XML(someString) > > by implementing one of the conversions. I didn’t know about JXON until > you posted the link just now, but I was thinking along the same lines. > The attributes and children would be properties on the XML instance. Then > the delete operator would automatically do the right thing. > > I don’t think the article covered two of the issues you raised: > 1) a child tag <name /> conflicting with the name() function and other > collisions like that. > 2) how to track mutation of an XMLList back to the XML. > > I don’t think e4x-like query results was in the scope of the article. > > I was just looking at how the delete operator gets parsed. I think it > will be possible, if we know the object is XMLList, to call a > removeChild() function. > > The answer for #1 might be similar. We might try to detect function calls > on objects of type XML and XMLList and call the functions with a decorated > name. I should add that doing so wouldn’t help folks who are trying to > use your XML classes from native JS. This approach requires the class > substitutions that FalconJX executes when the SWF version (which uses the > XML and XMLList definitions in playerglobal/airglobal) gets cross-compiled. > > For #2, how bad would it be if the compiler output an error or warning if > folks write to an XMLList. Isn’t there always a way to do the same thing > by direct manipulation of the XML? Otherwise, you might have to resort to > using Object.defineProperties and maybe define one extra index that, when > written to, ands a new extra index. > > Thoughts? > -Alex > > > On 11/12/15, 12:10 PM, "Harbs" <harbs.li...@gmail.com> wrote: > > >BTW, there’s a good JXON doc on MDN here[1] > > > >Maybe there’s some way to have a dynamic object as a property of XML so > >all XML methods could get proxied to XML.xmlObj? > > > >[1]https://developer.mozilla.org/en-US/docs/JXON > > > >On Nov 12, 2015, at 10:02 PM, Harbs <harbs.li...@gmail.com> wrote: > > > >>> 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. > > > >
