On 8/18/16, 3:40 PM, "Harbs" wrote:
>
>On Aug 19, 2016, at 12:49 AM, Alex Harui wrote:
>
>>
>>
>> On 8/18/16, 2:15 PM, "Harbs" wrote:
>>
>>> Like I mentioned in the other thread, it’s NOT just an author-time
>>> problem.
>>>
>>> Conflicts in variables and methods will cause Flash runtime
On Aug 19, 2016, at 12:49 AM, Alex Harui wrote:
>
>
> On 8/18/16, 2:15 PM, "Harbs" wrote:
>
>> Like I mentioned in the other thread, it’s NOT just an author-time
>> problem.
>>
>> Conflicts in variables and methods will cause Flash runtime errors and
>> override can often not be done proper
On 8/18/16, 2:37 PM, "Harbs" wrote:
>React works by using a Shadow DOM and diffing the DOM to figure out if
>things need to change.
>
>Angular works by running constant checks on the DOM and updating stuff as
>needed.
>
>I think simply wrapping DOM elements by JS ones has WAY less overhead
>tha
On 8/18/16, 2:15 PM, "Harbs" wrote:
>Like I mentioned in the other thread, it’s NOT just an author-time
>problem.
>
>Conflicts in variables and methods will cause Flash runtime errors and
>override can often not be done properly.
Are you saying the override would have an incompatible signature
React works by using a Shadow DOM and diffing the DOM to figure out if things
need to change.
Angular works by running constant checks on the DOM and updating stuff as
needed.
I think simply wrapping DOM elements by JS ones has WAY less overhead than both
of these approaches.
Re. Events:
I
On 8/18/16, 1:34 PM, "Peter Ent" wrote:
>Just to play devil's advocate for moment, ReactJS duplicates the DOM for
>its own purposes and seems to do quite well. I know it has code in it to
>do optimization for what to redraw, making it more complex than just a
>duplicate tree structure.
What do
Like I mentioned in the other thread, it’s NOT just an author-time problem.
Conflicts in variables and methods will cause Flash runtime errors and override
can often not be done properly.
The only runtime workaround I can see for that would be to automatically rename
the methods and properties,
> Stepping back, IIRC, the reason we tried wrapping Sprite was to deal with
> code-hinting in the IDEs and issues with property and method names with
> low-level Flash APIs.
A bigger issue was related to defining properties and methods which collided
with Flash ones. That’s not just a tooling iss
Just to play devil's advocate for moment, ReactJS duplicates the DOM for
its own purposes and seems to do quite well. I know it has code in it to
do optimization for what to redraw, making it more complex than just a
duplicate tree structure.
That said, reducing our overhead is a worthy goal and i
On 7/27/16, 1:14 AM, "Harbs" wrote:
>I’m running into lots of issues with the fact that HTMLElementWrapper
>extends Sprite. The underlying problem is because all the native Flash
>properties and methods are being exposed to the compiler for all
>sub-classed objects.
>
>For my port this is causi
On 8/18/16, 10:42 AM, "Peter Ent" wrote:
>I think I'm leaning more toward agreeing with you, Harbs, about a Flex
>event bus. I remember changing MouseEvent because of some issue (have to
>look at the logs) with it being a subclass of Event. If we make it a rule
>that every FlexJS component only
I think I'm leaning more toward agreeing with you, Harbs, about a Flex
event bus. I remember changing MouseEvent because of some issue (have to
look at the logs) with it being a subclass of Event. If we make it a rule
that every FlexJS component only work with org.apache.flex.events.Event
(or a sub
+1.
I think now would be a good time to cut a release branch.
On Aug 18, 2016, at 6:40 PM, Christofer Dutz wrote:
> Perhaps it would be a good idea to start with release branches this time.
Hi Alex,
the source package we should vote on will be the Ant one. That's the reason for
me preparing a Maven release before the Ant. This way you can checkout the
Released version (with release versions in the poms). Perhaps it would be a
good idea to start with release branches this time.
On 8/18/16, 4:40 AM, "Christofer Dutz" wrote:
>Hi,
>
>
>as I mentioned a few days ago, I will be having a talk on FlexJS in
>Hamburg on 08.09.2016 (http://programmplaner.solutions.hamburg/#/).
>
>
>I hope we will be able to ship a new version with the Maven support till
>then? Do you think that
Hi Alex,
Can you please tell me how to unsubscribe?
Thanks,
Jack
On 8/8/16 12:55 AM, Alex Harui wrote:
On 8/7/16, 2:06 AM, "yishayw" wrote:
We have code that removes all elements in a container. It does something
like
while (container.numElements) {container.removeElementAt(0)}
The prob
IMO, the “right” way to fix this is by dispatching events from the
flexjs_wrapper and implement event bubbling up the FlexJS element chain.
Yishay did not mention them, but we were having a whole slew of problems
related to events:
1. Event targets being lost (which he mentioned here)
2. Fixin
Hi,
as I mentioned a few days ago, I will be having a talk on FlexJS in Hamburg on
08.09.2016 (http://programmplaner.solutions.hamburg/#/).
I hope we will be able to ship a new version with the Maven support till then?
Do you think that's possible? What are we missing?
I would suggest that
On 8/17/16, 11:25 PM, "yishayw" wrote:
>If I listen on a click event on the application I expect to get all click
>events bubbled up from contained elements. That works, however the target
>is
>the application rather than the element that was clicked on. This is due
>to
>ElementWrapper.forwarde
19 matches
Mail list logo
