Ok, As a base thinking, and taking into account I didn't gave the cycles you all invested in it, I should notice that FlexJS is not Flash anymore. Is something that could output various things. One of them are SWF, and other is HTML, but we could output more some day. Maybe even FlexJS is not an accurate name for the future, since right not our priority in HTML (and SWF but not as important as the first), but maybe in 5 years we could think in other important output by that time. So, I think make sense to make FlexJS not subclassing Flash Objects in particular, but more than that, I should see some of the code to understand the approach.
thanks Carlos 2016-10-27 10:11 GMT+02:00 Harbs <harbs.li...@gmail.com>: > Hi Carlos, > > The refactor was already done, and I’ve been working off the > sprite-refactor branch for a few months already. I’ve been regularly > merging the changes from develop into that branch. There is however, a lot > of work done on the sprite-refactor branch which has not made it into > develop. > > The reason for the refactor was because I ran into lots of issues related > to the fact that FlexJS components are subclassing Flash objects rather > than wrapping them. How many of these issues can be resolved by tooling > remain to be seen. > > All the samples currently run on both branches, and the impact to client > code will hopefully be minimal (if impacted at all). > > I will do what I can to merge your MDL branch into the refactored code if > there are conflicts. I doubt there will be any though. > > Alex and I will probably be doing most of the flipping between the two > options until we settle on a permanent strategy for the two approaches. > > HTH, > Harbs > > On Oct 27, 2016, at 10:56 AM, Carlos Rovira <carlos.rov...@codeoscopic.com> > wrote: > > > 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. > > -- 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.
