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? On Nov 12, 2015, at 6:38 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 11/12/15, 3:16 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> While working on XML, I have a situation where I’d like to use an >> internal namespace for some functions (like mx_internal and tlf_internal >> scattered around the classic Flex SDK). I do not see internal used in >> FlexJS. Was this a conscious decision, or nothing came up where internal >> was desirable? Any preferences on an internal name if I do use one? > > Well, I wouldn’t make a rule against it, but here are some reasons why I’m > trying not to do it in FlexJS: > > 1) No such thing as namespaces in JS. > 2) We can fake them by decorating names of methods, but I find that a bit > messy. > 3) Only public functions can be in interfaces. I want FlexJS to use lots > of interfaces so that implementations can be swapped out, unit tested with > mocks, etc. > 4) At Adobe, we used mx_internal for APIs we weren’t sure we wanted to > document. In FlexJS, because we supposedly will have swappable > implementations, it doesn’t matter if you have an API you don’t like, you > can always swap in an implementation with a better API. > > The use of interfaces has exposed a lot more APIs as public APIs. I am > pondering the idea of a doc viewer. Instead of a pile of HTML pages like > ASDoc is now, an AIR app that is a bit smarter and can handle different > categories of public APIs. So far, it appears that there are public APIs > most likely to be used by app developers, and other public APIs used by > the various beads to talk to each other. > > None of this is set in stone, so alternative viewpoints are most welcome. > -Alex >
