You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2016/10/27 06:57:35 UTC
Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
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
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by Alex Harui <ah...@adobe.com>.
On 10/27/16, 12:15 AM, "Harbs" <ha...@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?
Actually, it appears that we can have two SWCs with the same namespaces.
The most recently compiled one will win unless we start specifying each
SWC in flex-config.xml. Currently we only specify a folder so all SWCs
are considered. IMO, specifying a folder makes life easier for IDE and
Ant users and I can manage working with a list of specific SWCs.
>
>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)
Maybe, but I would think that would make the source code hard to read with
so many options.
>#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.
I want the existing code in Basic to work with out an additional
variables. IMO, that's the only way to know if we have an issue from the
subclassing that the compiler can't solve. But where the wrapping leaked
into other SWCS like Chart and Graphics, I'm thinking of adding the
$displayObject variable in the Basic UIBase so we don't have to duplicate
the other SWCs as well.
-Alex
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
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 <ha...@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 <ca...@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 <ha...@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 <ha...@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 <ah...@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.
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)
Posted by Harbs <ha...@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 <ca...@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 <ha...@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 <ha...@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 <ah...@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.
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by yishayw <yi...@hotmail.com>.
Done.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Getting-ready-for-the-refactor-sprite-merge-was-Re-FlexJS-HTMLElementWrapper-extending-Sprite-tp56053p56330.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by Yishay Weiss <yi...@hotmail.com>.
Encountered another issue I found when trying to compile on the swf side. I’ve added a ‘sprite-refactor’ label to JIRA issues. Here’s a filtered search
https://issues.apache.org/jira/browse/FLEX-35168?jql=labels%20%3D%20sprite-refactor
From: Alex Harui<ma...@adobe.com>
Sent: Monday, November 7, 2016 7:19 AM
To: dev@flex.apache.org<ma...@flex.apache.org>
Subject: Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)
On 11/6/16, 9:33 AM, "yishayw" <yi...@hotmail.com> wrote:
>I don't see it here
><https://github.com/apache/flex-asjs/commits/develop/frameworks/projects/H
>TML/src/main/flex/org/apache/flex/core/Application.as>
>, or even locally when following renames. Do you remember where it was
>implemented?
Hmm. I could swear I did it, but I don't see it in the logs either.
There were other times I felt like stuff I did disappeared when merging.
Anyway, yes, it should be added to Application.as
-Alex
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by Alex Harui <ah...@adobe.com>.
On 11/6/16, 9:33 AM, "yishayw" <yi...@hotmail.com> wrote:
>I don't see it here
><https://github.com/apache/flex-asjs/commits/develop/frameworks/projects/H
>TML/src/main/flex/org/apache/flex/core/Application.as>
>, or even locally when following renames. Do you remember where it was
>implemented?
Hmm. I could swear I did it, but I don't see it in the logs either.
There were other times I felt like stuff I did disappeared when merging.
Anyway, yes, it should be added to Application.as
-Alex
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by yishayw <yi...@hotmail.com>.
I don't see it here
<https://github.com/apache/flex-asjs/commits/develop/frameworks/projects/HTML/src/main/flex/org/apache/flex/core/Application.as>
, or even locally when following renames. Do you remember where it was
implemented?
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Getting-ready-for-the-refactor-sprite-merge-was-Re-FlexJS-HTMLElementWrapper-extending-Sprite-tp56053p56305.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by Alex Harui <ah...@adobe.com>.
The log should show that application implements that interface
Sent from my LG G3, an AT&T 4G LTE smartphone
------ Original message------
From: yishayw
Date: Sun, Nov 6, 2016 7:28 AM
To: dev@flex.apache.org;
Subject:Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)
I just did a smoke test on our using the merged branch. On the JS side it
looks good, but the swf side fails because <BrowserResizeHandler> now
expects the strand to be an IInitialViewApplication. Looking at the asjs
files, I can't see any IInitialViewApplication implementers. Do you think
Application.as should be such an implementer?
On refactor-sprite, we've seen all sorts of issues on the swf side due to
event target confusions, and other issues that result from UIBases not being
sprites. I hope to have time to open JIRA tickets with a dedicated tag so we
have an idea of what fixing these entails.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Getting-ready-for-the-refactor-sprite-merge-was-Re-FlexJS-HTMLElementWrapper-extending-Sprite-tp56053p56299.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by yishayw <yi...@hotmail.com>.
I just did a smoke test on our using the merged branch. On the JS side it
looks good, but the swf side fails because <BrowserResizeHandler> now
expects the strand to be an IInitialViewApplication. Looking at the asjs
files, I can't see any IInitialViewApplication implementers. Do you think
Application.as should be such an implementer?
On refactor-sprite, we've seen all sorts of issues on the swf side due to
event target confusions, and other issues that result from UIBases not being
sprites. I hope to have time to open JIRA tickets with a dedicated tag so we
have an idea of what fixing these entails.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Getting-ready-for-the-refactor-sprite-merge-was-Re-FlexJS-HTMLElementWrapper-extending-Sprite-tp56053p56299.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by Alex Harui <ah...@adobe.com>.
One more thing. I found out that, due to a compiler bug on the JS side,
we've gotten away with having the element() and createElement() calls be
of type IFlexJSElement in UIBase but WrappedHTMLElement in the subclasses.
Yes, I plan to allow this kind of overloading someday, but in theory, it
shouldn't work today. Does anybody care if we switch from
WrappedHTMLElement to IFlexJSElement in the subclasses?
Thanks,
-Alex
On 11/2/16, 8:20 AM, "Alex Harui" <ah...@adobe.com> wrote:
>OK. Cross your fingers. Let me know if you run into issues. The HTML
>folder should now contain wrapped Sprites.
>
>Note that several files got moved from Core and Graphics to HTML because
>we had to move UIBase to HTML and Basic so there would be a wrapped and
>unwrapped version and once you move UIBase out, lots of other things have
>to move as well, so be careful if you are working on concrete base classes
>that you think were in Core, or working on the SVG classes in Graphics.
>
>The Basic folder is the unwrapped code and is not part of the build right
>now. That's because I have to try to solve some of the API collision
>issues in the compiler first. It will be a good test of whether we can
>get the compiler to allow certain kinds of overloading in a SWF. I have a
>few other things in the my queue before I get to that.
>
>Thanks,
>-Alex
>
>On 11/2/16, 12:00 AM, "Harbs" <ha...@gmail.com> wrote:
>
>>Sounds good.
>>
>>Looking forward!
>>
>>On Nov 2, 2016, at 8:44 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>>> Update:
>>>
>>> Maven and Ant builds work locally for me. DataBindingExample runs.
>>>
>>> I will push it tomorrow unless someone comes up with a good reason not
>>>to.
>>>
>>> Thanks,
>>> -Alex
>>>
>>
>
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by Alex Harui <ah...@adobe.com>.
OK. Cross your fingers. Let me know if you run into issues. The HTML
folder should now contain wrapped Sprites.
Note that several files got moved from Core and Graphics to HTML because
we had to move UIBase to HTML and Basic so there would be a wrapped and
unwrapped version and once you move UIBase out, lots of other things have
to move as well, so be careful if you are working on concrete base classes
that you think were in Core, or working on the SVG classes in Graphics.
The Basic folder is the unwrapped code and is not part of the build right
now. That's because I have to try to solve some of the API collision
issues in the compiler first. It will be a good test of whether we can
get the compiler to allow certain kinds of overloading in a SWF. I have a
few other things in the my queue before I get to that.
Thanks,
-Alex
On 11/2/16, 12:00 AM, "Harbs" <ha...@gmail.com> wrote:
>Sounds good.
>
>Looking forward!
>
>On Nov 2, 2016, at 8:44 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> Update:
>>
>> Maven and Ant builds work locally for me. DataBindingExample runs.
>>
>> I will push it tomorrow unless someone comes up with a good reason not
>>to.
>>
>> Thanks,
>> -Alex
>>
>
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)
Posted by Harbs <ha...@gmail.com>.
Sounds good.
Looking forward!
On Nov 2, 2016, at 8:44 AM, Alex Harui <ah...@adobe.com> wrote:
> Update:
>
> Maven and Ant builds work locally for me. DataBindingExample runs.
>
> I will push it tomorrow unless someone comes up with a good reason not to.
>
> Thanks,
> -Alex
>
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by Alex Harui <ah...@adobe.com>.
Update:
Maven and Ant builds work locally for me. DataBindingExample runs.
I will push it tomorrow unless someone comes up with a good reason not to.
Thanks,
-Alex
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Alex,
thanks for the explanation.
regarding integration branches, the main concept it *not break develop*
(and of course master ;)).
So before Harbs response, I was worried that this merge could cause some
days of broken builds (maven, ant, etc...)
for that reason is important to make this kind of laborious merges a side
the branches so when you have it running nice in your local you could merge
with original branch with no effort and secure that all would be ok. That's
the main purpose of doing anything you want in branches.
More over, is normal for all people working in projects with GIt and using
JIRA or other system, to open a branch per ticket so you can solve the
ticket and merge it back to develop, and then remove the ticket branch.
So I think Harbs and you are managing in other way, as Harbs is integrating
changes from develop as they happen so deltas are controlled and the branch
is never to far from develop state.
Regarding the refactor, I can see the points here, but have not opinion (as
I said I'd need to check code of the work done) at this point so I'm
confident you both will do the best
Thanks
2016-10-27 18:26 GMT+02:00 Alex Harui <ah...@adobe.com>:
>
>
> On 10/27/16, 12:56 AM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira" <carlos.rovira@gmail.com on behalf of
> carlos.rovira@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.
>
> I thought about having a separate branch, but didn't do it (yet). How
> does having an integration branch help? Seems like it would just mean two
> merges instead of one. I already have other working copies of flex-asjs
> on my computer so I can handle other requests for changes while the merge
> is in progress.
>
> >
> >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)
>
> I saw Harbs summed it up, but my take is this:
>
> I am a code minimalist, so I am hopeful that we can implement some sort of
> overloading in the compiler such that we can make it look like we have
> nice clean no-flash API signature in the FlexJS APIs. IMO, we have to
> provide some sort of overloading some day anyway since otherwise,
> ActionScript will fall behind other languages that do support overloading.
>
> I believe if we can allow overloading, then you don't need pay the runtime
> cost of wrapping the platform implementations. You can just make sure the
> subclasses of the platform implementations have a common API. That means
> that app developers may trip over the platform implementations more often,
> but you will be glad we offered you this option if your app becomes too
> big or too slow.
>
> IMO, it is just more efficient to talk to someone who has a different
> native language but understands enough English (the common API) than to
> have to use another person as a translator (which effectively wraps the
> person you want to talk to). But yes, you have to be careful in your
> choice of words (adding new APIs or using old Flash APIs) since those
> words might have meaning to the non-English speaker. (I was working with
> folks from Japan once and mentioned how I liked Tacos for lunch. They
> were surprised at first because Tako means Octopus in Japanese which isn't
> nearly as well liked).
>
> Here are some scenarios:
>
> If you are porting existing Flash-based code to FlexJS, you want to get a
> good idea of how many changes you have to make. At the time Harbs started
> on the port, the workflow was to look for "import flash" in your code and
> replace those imports with FlexJS imports (if they existed) and then just
> try compiling against the FlexJS SWCs for SWF, since compiling a SWF is
> what the IDE knows how to do. The problem with that is that a simple
> reference to, for example, the "scaleX" property is not caught by this
> workflow. Clearly, if you take the time to create wrappers for the
> components that only implement the FlexJS APIs that work on both
> platforms, then the compiler would catch that you are using "scaleX".
>
> But we are looking into upgrading the compiler so that you can run the JS
> cross-compile directly as well as the SWF compile from the IDE, so the
> problems panel should show that "scaleX" is missing in the cross-compile,
> and then you don't need to wrap.
>
> Similarly, if someday someone wanted to implement a "buttonMode" property
> on a Button and didn't know the Flash implementation already used it, you
> will get an error and have to use a different property name. You wouldn't
> if you are working against wrapped components.
>
> Really, there is no right or wrong way. I am just certain that we "must"
> have a component set that does not have any extra code spent on wrapping
> implementations if we can implement overloading propertly, or on parameter
> validation, or anything else you don't need in production. It is totally
> fine to have other component sets that wrap things, aggregate beads, etc
> to make development or migration easier, but the low-level must truly be
> low-level if you are trying to fit your production version into some
> metric of code size, download size, startup time performance. The
> framework should not be to blame if you can't fit. The smaller and faster
> we make it, the better off our customers will be. Even an additional line
> of code adds up over time.
>
> HTH,
> -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.
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by Alex Harui <ah...@adobe.com>.
On 10/27/16, 12:56 AM, "carlos.rovira@gmail.com on behalf of Carlos
Rovira" <carlos.rovira@gmail.com on behalf of
carlos.rovira@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.
I thought about having a separate branch, but didn't do it (yet). How
does having an integration branch help? Seems like it would just mean two
merges instead of one. I already have other working copies of flex-asjs
on my computer so I can handle other requests for changes while the merge
is in progress.
>
>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)
I saw Harbs summed it up, but my take is this:
I am a code minimalist, so I am hopeful that we can implement some sort of
overloading in the compiler such that we can make it look like we have
nice clean no-flash API signature in the FlexJS APIs. IMO, we have to
provide some sort of overloading some day anyway since otherwise,
ActionScript will fall behind other languages that do support overloading.
I believe if we can allow overloading, then you don't need pay the runtime
cost of wrapping the platform implementations. You can just make sure the
subclasses of the platform implementations have a common API. That means
that app developers may trip over the platform implementations more often,
but you will be glad we offered you this option if your app becomes too
big or too slow.
IMO, it is just more efficient to talk to someone who has a different
native language but understands enough English (the common API) than to
have to use another person as a translator (which effectively wraps the
person you want to talk to). But yes, you have to be careful in your
choice of words (adding new APIs or using old Flash APIs) since those
words might have meaning to the non-English speaker. (I was working with
folks from Japan once and mentioned how I liked Tacos for lunch. They
were surprised at first because Tako means Octopus in Japanese which isn't
nearly as well liked).
Here are some scenarios:
If you are porting existing Flash-based code to FlexJS, you want to get a
good idea of how many changes you have to make. At the time Harbs started
on the port, the workflow was to look for "import flash" in your code and
replace those imports with FlexJS imports (if they existed) and then just
try compiling against the FlexJS SWCs for SWF, since compiling a SWF is
what the IDE knows how to do. The problem with that is that a simple
reference to, for example, the "scaleX" property is not caught by this
workflow. Clearly, if you take the time to create wrappers for the
components that only implement the FlexJS APIs that work on both
platforms, then the compiler would catch that you are using "scaleX".
But we are looking into upgrading the compiler so that you can run the JS
cross-compile directly as well as the SWF compile from the IDE, so the
problems panel should show that "scaleX" is missing in the cross-compile,
and then you don't need to wrap.
Similarly, if someday someone wanted to implement a "buttonMode" property
on a Button and didn't know the Flash implementation already used it, you
will get an error and have to use a different property name. You wouldn't
if you are working against wrapped components.
Really, there is no right or wrong way. I am just certain that we "must"
have a component set that does not have any extra code spent on wrapping
implementations if we can implement overloading propertly, or on parameter
validation, or anything else you don't need in production. It is totally
fine to have other component sets that wrap things, aggregate beads, etc
to make development or migration easier, but the low-level must truly be
low-level if you are trying to fit your production version into some
metric of code size, download size, startup time performance. The
framework should not be to blame if you can't fit. The smaller and faster
we make it, the better off our customers will be. Even an additional line
of code adds up over time.
HTH,
-Alex
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS]
HTMLElementWrapper extending Sprite)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
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 <ha...@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 <ha...@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 <ah...@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.
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)
Posted by Harbs <ha...@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 <ha...@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 <ah...@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
>>
>
Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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
>