On 11/12/15, 8:52 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>Here’s where I am (and why I’m asking): > >I figured out how to use Document and Element as the underlying structure >for JS XML. But to use them correctly, I need to manipulate the internal >structure of one XML object from another. > >One example: in ActionScript XML you can call appendChild to move the >child of one XML object to another. In JS, appendChild only works if both >elements belong to the same document. So if the XML object belongs to a >different document, I need to call removeChild on its parent (why in the >world does ActionScript XML not have removeChild()???) in addition to >importNode(). Also, for appendChild() I need to get the delegate of the >new child to call appendChild() on that. > >So there need to be public methods which expose some of the internals, >but they really should not be full public APIs. > >Any ideas on a good way to structure this? There are going to be plenty of public APIs that we don’t want to expose to certain sets of consumers. But to me, the advantages of abstracting implementations with Interfaces outweighs the effort to “fake” namespaces in the JS side. That’s why I’m considering a more elaborate ASDoc viewer that can filter public APIs based on tags. IMO, that would give us the usability benefits of namespaces. I’ve seen plenty of folks hack into mx_internal APIs anyway, so why not just make them all public and make it easier to document which ones are provided for application developers vs implementation details? I figure we can decide on some @developer or @application tag (and maybe more) that the doc viewer could filter on. Maybe even @common and @advanced. -Alex
