There’s also differences related to events and the like, but we can add blocks for that as well.
On Oct 27, 2016, at 10:15 AM, Harbs <harbs.li...@gmail.com> wrote: > I had an idea last night: > > Instead of having two different namespaces for wrapped and unwrapped > components, what about making it a compiler option? > > The primary difference between the two is: > 1. The base class is different. > 2. References in platform-specific code to the platform-specific > implementation when needed. > > #1 can be resolved by conditional compilation blocks (such as > COMPILE::OPTIMIZE_PERFORMANCE and COMPILE::OPTIMIZE_COMPATIBILITY) > #2 can be resolved by having a variable which points to the implementation > (and typed as an Object) So for wrapped components, myComponents.impl (or > whatever we’d call it) would be HTMLElementWrapper.$displayObject and for > subclassed components it would be “this”. For HTML, it would be element, etc. > > Thoughts? > > On Oct 27, 2016, at 9:57 AM, Alex Harui <aha...@adobe.com> wrote: > >> I've been looking at the differences between develop and refactor-sprite >> and how to manage the fork of the Basic set into both a wrapped and >> unwrapped set. >> >> I found that I can just copy the HTML folder to a Basic folder and you can >> use --follow on the copies to follow history in the fork. >> >> In looking at the examples, they often import org.apache.flex.html.*, so >> I'm tempted to not rename the packaging in the Basic folder so it is >> easier to switch from wrapped to unwrapped. It appears that the compiler >> doesn't care that both Basic.swc and HTML.swc have the same classes. >> Because the HTML.swc is compiled later, it has a newer timestamp and its >> classes are used by default in IDE and Ant builds. I think for Maven you >> just specify one or the other in the pom.xml. I think that should be ok >> since I'll be the primary person switching between the two and I can >> control which classes I am using. >> >> I think the next move is to move-and-fork many classes from Core to both >> Basic and HTML so each folder can have its own fork of UIBase, >> Application, View, etc. >> >> This should leave org.apache.flex.core with mostly interfaces. Which is >> probably a good thing. There might need to be some move-and-forking for a >> few org.apache.flex.utils. >> >> I think I do these steps in develop, then merge them into refactor-sprite, >> then try to merge refactor-sprite into develop. >> >> Anybody have a better plan or see big holes in this one? I'm done for >> tonight and will check in the AM. >> >> Thanks, >> -Alex >> >
