This was the approach that I started with, but I changed to mimicking the standard XML class in JS so existing XML code can be used without modification.
I do think that approach has merit (especially because it allows us to improve on the current external API), and once I have the JS side of standard XML, I might actually do that. On Nov 12, 2015, at 10:50 PM, OmPrakash Muppirala <bigosma...@gmail.com> wrote: > 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. >>> >> >>
