Hi, don't know how you plan to do this, but seems an important refactor and lots of files included. I suggest to do this in an "integration" branch to manage all posible colateral issues generated. And then as adjusted merge with develop.
As well, I came to the discussion too much late so I don't know about the basic thinking of this refactor. Could you share what's behind? (now that you discuss it for long time) Thanks 2016-10-27 9:17 GMT+02:00 Harbs <harbs.li...@gmail.com>: > 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 > >> > > > > -- Carlos Rovira Director General M: +34 607 22 60 05 http://www.codeoscopic.com http://www.avant2.es Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la prestación del servicio o información solicitados, teniendo usted derecho de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación necesaria.
