Re: [FlexJS]TileLayout

[Harbs]

Already fixed. :-)

> On Jul 25, 2017, at 12:47 AM, Alex Harui  wrote:
> 
> I thought the goal was to approximate what regular Flex TileLayout did.
> The fact that TileLayout uses flexbox under the covers is an
> implementation detail.  IMO, Flex TileLayout behavior would be the default
> TileLayout to simplify migration and other options would have longer names.
> 
> No matter what, if SWF and HTML don't currently match, we should fix it so
> they do.
> 
> My 2 cents,
> -Alex
> 
> On 7/24/17, 7:13 AM, "Peter Ent"  wrote:
> 
>> I just left things as open as possible as I recall. Thanks Harbs.
>> 
>> On 7/23/17, 6:06 AM, "Harbs"  wrote:
>> 
>>> Agreed, but I think the defaults should match Flash between and HTML.
>>> 
>>> He did not set stretch. Nothing was set. ³stretch² is the default css.
>>> 
 On Jul 23, 2017, at 12:23 PM, Alex Harui 
 wrote:
 
 There doesn't have to be one TileLayout.  There can be
 TileLayoutWithFlexStart, TileLayoutWithStretch, and
 TileLayoutWithAlignContent with a property that allows you to set it.
 
 Peter may remember why he chose "stretch".
 
 -Alex
 
 On 7/23/17, 1:28 AM, "Harbs"  wrote:
 
> I just discovered something which is worth bringing up:
> 
> The default for css flex layouts is align-content: stretch This adds
> space between elements if the total height (or width) of the elements
> are
> less than the parent. I don¹t think that¹s an appropriate default for
> a
> tile layout. The layout should be packed from the top left and only
> add
> space if there is padding/margins in the itemRenderers.
> 
> I believe the correct default css is align-content: flex-start which
> has
> the behavior that I would expect from a tile layout.
> 
> Of course, it might be interesting to have a tile layout which offers
> different spacing options. That could be alternate layouts, or even
> beads
> attached to the layout beads.
> 
> I fixed this issue in my app by just adding some align-content:
> flex-start css to my TileLayout component. This works because I don¹t
> need swf rendering, but I think it¹s something that should be
> addressed
> in the TileLayout.
> 
> Let me checkŠ
> 
> I just (fixed and) ran ContainerTest, and the swf behavior is in fact
> different than the HTML behavior. I think we can classify this as a
> bug.
> I¹m committing this change.
> 
> FWIW, there¹s lots of other differences between the swf output and the
> JS
> output in ContainerTest. It¹s probably worth looking into the rest of
> those issues as wellŠ
> 
> Harbs
 
>>> 
>> 
> 

Re: PAYG

[Greg Dove]

Josh, that was the general idea with the wiki docs:

-One section for 'definitions'

-And another section for examples/archetypes with advantages/disadvantages
of each - as a form of 'guidance', emphasis on the practical, but not a
proscriptive approach.

I'm sorry I have not had time to come back and consolidate the various
discussions on this. I still have that intention, just not the time
available right now. Please do not hesitate if you want to kick this off in
the wiki yourself.




On Tue, Jul 25, 2017 at 9:44 AM, Josh Tynjala  wrote:

> Okay, so PAYG can't have One True Definition. How you implement PAYG
> depends on context.
>
> I wonder if some kind of PAYG pattern cookbook would be helpful? I was
> thinking that our situations with PAYG remind me of software design
> patterns. Design patterns aren't really defined with an exact
> implementation, but they offer guidance for how you can solve problems of a
> certain category. With PAYG, I think we're going to have different
> categories that will need similar implementations, but not exactly the
> same. That's where PAYG patterns could help provide a framework for
> implementation.
>
> Let's find common patterns. Maybe even give them names to make them
> memorable and easy to refer to.
>
> - Josh
>
> On Thu, Jul 13, 2017 at 10:42 AM, Alex Harui 
> wrote:
>
> > Hi,
> >
> > I promised some feedback on Greg's PAYG page.  After thinking about it
> > some more, I'm proposing my take on it below.  I know past discussion
> > tried to break off component set definitions from PAYG, but I think PAYG
> > is always going to be subjective enough that the goals of the various
> > component sets will affect decisions about what goes in the default
> beads.
> >  I can't say this often enough though:  one main goal of beads is to
> avoid
> > spending energy on what is the one right way, and also, on exactly what
> > PAYG means.  If you don't agree with what PAYG means to the others
> working
> > on a component set, go start a new component set.
> >
> > So, I am going to try to discuss all of the related factors in one place
> > below.
> >
> > Thanks,
> > -Alex
> >
> > --- Pay-as-you-go (PAYG) ---
> >
> >
> > PAYG means that Download Size, Startup Time, Memory Usage, Line of Code
> > goes up and Performance goes down as new features are added to the
> > Application.
> >
> > PAYG leverages well-known computer science principles:  Re-usable code,
> > Separation of Concerns, Modularity, Abstraction.
> >
> > PAYG cannot be defined objectively.  You can be too granular or not
> > granular enough.
> > Too Much:  Put a for loop in a re-usable function.  Everybody must call
> > this function.
> > Too Little:  Regular Flex SDK.  13,000 line base classes.
> > Just Right:  Make it possible that an application has no unused code
> paths
> > in the framework code it uses.  IOW, no just-in-case code.
> >
> > FlexJS uses modules called "Beads" to implement features in a PAYG
> > fashion.  Beads are placed on Strands so composition is primary pattern.
> >
> > PAYG has no required implementation patterns.  There is no one right way.
> > Subclassing, sharing utility functions, beads sharing other beads are all
> > valid implementations.  The key is to see how it measures up against the
> > metrics of Download Size, Startup Time, Memory Usage, etc.  Other
> > computer-science principles like DRY should be considered as well.  There
> > doesn't have to be only one version of a bead.  There can be beads with
> > different implementations and tradeoffs on those metrics.
> >
> > ---Additional Guidelines for FlexJS---
> >
> > Naming:  Pick a relatively small/simple set of features that are likely
> to
> > be used in several applications.Give it a name starting with Simple,
> > or something descriptive and well-known like Panel.  Additional features
> > expand the name with prefixes (DropDownList instead of ListForDropDown)
> or
> > suffixes like PanelWithControlBar.  Reduced/inlined versions will also
> get
> > expanded names.
> >
> > Defensive Code:  Rarely needed.  Bad inputs should be found and fixed
> > before deploying the app.  Folks who take the time to do that should be
> > rewarded with smaller code and faster performance.  Use of goog.DEBUG to
> > have debug-time input checking is allowed.  There is a trade-off between
> > any performance hit of debug-time checking vs the developer productivity
> > of having those errors caught early.
> >
> > Bead Removal:  We may someday decide that beads should almost never be
> > removed.  Implementing a flag to disable a bead might be cheaper than
> > removing it.
> >
> > Component Sets:  Different component sets have different goals.
> >   Basic:  smallest SWF-equivalent implementations
> >   Express:  Pre-package Basic beads and thus SWF-equivalent
> >   MDL:  No interest in SWF equivalence.
> >
> > JS metrics are more important than SWF metrics.
> >
> >
> >
>

Re: [FlexJS]TileLayout

[Alex Harui]

I thought the goal was to approximate what regular Flex TileLayout did.
The fact that TileLayout uses flexbox under the covers is an
implementation detail.  IMO, Flex TileLayout behavior would be the default
TileLayout to simplify migration and other options would have longer names.

No matter what, if SWF and HTML don't currently match, we should fix it so
they do.

My 2 cents,
-Alex

On 7/24/17, 7:13 AM, "Peter Ent"  wrote:

>I just left things as open as possible as I recall. Thanks Harbs.
>
>On 7/23/17, 6:06 AM, "Harbs"  wrote:
>
>>Agreed, but I think the defaults should match Flash between and HTML.
>>
>>He did not set stretch. Nothing was set. ³stretch² is the default css.
>>
>>> On Jul 23, 2017, at 12:23 PM, Alex Harui 
>>>wrote:
>>> 
>>> There doesn't have to be one TileLayout.  There can be
>>> TileLayoutWithFlexStart, TileLayoutWithStretch, and
>>> TileLayoutWithAlignContent with a property that allows you to set it.
>>> 
>>> Peter may remember why he chose "stretch".
>>> 
>>> -Alex
>>> 
>>> On 7/23/17, 1:28 AM, "Harbs"  wrote:
>>> 
 I just discovered something which is worth bringing up:
 
 The default for css flex layouts is align-content: stretch This adds
 space between elements if the total height (or width) of the elements
are
 less than the parent. I don¹t think that¹s an appropriate default for
a
 tile layout. The layout should be packed from the top left and only
add
 space if there is padding/margins in the itemRenderers.
 
 I believe the correct default css is align-content: flex-start which
has
 the behavior that I would expect from a tile layout.
 
 Of course, it might be interesting to have a tile layout which offers
 different spacing options. That could be alternate layouts, or even
beads
 attached to the layout beads.
 
 I fixed this issue in my app by just adding some align-content:
 flex-start css to my TileLayout component. This works because I don¹t
 need swf rendering, but I think it¹s something that should be
addressed
 in the TileLayout.
 
 Let me checkŠ
 
 I just (fixed and) ran ContainerTest, and the swf behavior is in fact
 different than the HTML behavior. I think we can classify this as a
bug.
 I¹m committing this change.
 
 FWIW, there¹s lots of other differences between the swf output and the
JS
 output in ContainerTest. It¹s probably worth looking into the rest of
 those issues as wellŠ
 
 Harbs
>>> 
>>
>

Re: PAYG

[Josh Tynjala]

Okay, so PAYG can't have One True Definition. How you implement PAYG
depends on context.

I wonder if some kind of PAYG pattern cookbook would be helpful? I was
thinking that our situations with PAYG remind me of software design
patterns. Design patterns aren't really defined with an exact
implementation, but they offer guidance for how you can solve problems of a
certain category. With PAYG, I think we're going to have different
categories that will need similar implementations, but not exactly the
same. That's where PAYG patterns could help provide a framework for
implementation.

Let's find common patterns. Maybe even give them names to make them
memorable and easy to refer to.

- Josh

On Thu, Jul 13, 2017 at 10:42 AM, Alex Harui 
wrote:

> Hi,
>
> I promised some feedback on Greg's PAYG page.  After thinking about it
> some more, I'm proposing my take on it below.  I know past discussion
> tried to break off component set definitions from PAYG, but I think PAYG
> is always going to be subjective enough that the goals of the various
> component sets will affect decisions about what goes in the default beads.
>  I can't say this often enough though:  one main goal of beads is to avoid
> spending energy on what is the one right way, and also, on exactly what
> PAYG means.  If you don't agree with what PAYG means to the others working
> on a component set, go start a new component set.
>
> So, I am going to try to discuss all of the related factors in one place
> below.
>
> Thanks,
> -Alex
>
> --- Pay-as-you-go (PAYG) ---
>
>
> PAYG means that Download Size, Startup Time, Memory Usage, Line of Code
> goes up and Performance goes down as new features are added to the
> Application.
>
> PAYG leverages well-known computer science principles:  Re-usable code,
> Separation of Concerns, Modularity, Abstraction.
>
> PAYG cannot be defined objectively.  You can be too granular or not
> granular enough.
> Too Much:  Put a for loop in a re-usable function.  Everybody must call
> this function.
> Too Little:  Regular Flex SDK.  13,000 line base classes.
> Just Right:  Make it possible that an application has no unused code paths
> in the framework code it uses.  IOW, no just-in-case code.
>
> FlexJS uses modules called "Beads" to implement features in a PAYG
> fashion.  Beads are placed on Strands so composition is primary pattern.
>
> PAYG has no required implementation patterns.  There is no one right way.
> Subclassing, sharing utility functions, beads sharing other beads are all
> valid implementations.  The key is to see how it measures up against the
> metrics of Download Size, Startup Time, Memory Usage, etc.  Other
> computer-science principles like DRY should be considered as well.  There
> doesn't have to be only one version of a bead.  There can be beads with
> different implementations and tradeoffs on those metrics.
>
> ---Additional Guidelines for FlexJS---
>
> Naming:  Pick a relatively small/simple set of features that are likely to
> be used in several applications.Give it a name starting with Simple,
> or something descriptive and well-known like Panel.  Additional features
> expand the name with prefixes (DropDownList instead of ListForDropDown) or
> suffixes like PanelWithControlBar.  Reduced/inlined versions will also get
> expanded names.
>
> Defensive Code:  Rarely needed.  Bad inputs should be found and fixed
> before deploying the app.  Folks who take the time to do that should be
> rewarded with smaller code and faster performance.  Use of goog.DEBUG to
> have debug-time input checking is allowed.  There is a trade-off between
> any performance hit of debug-time checking vs the developer productivity
> of having those errors caught early.
>
> Bead Removal:  We may someday decide that beads should almost never be
> removed.  Implementing a flag to disable a bead might be cheaper than
> removing it.
>
> Component Sets:  Different component sets have different goals.
>   Basic:  smallest SWF-equivalent implementations
>   Express:  Pre-package Basic beads and thus SWF-equivalent
>   MDL:  No interest in SWF equivalence.
>
> JS metrics are more important than SWF metrics.
>
>
>

Re: [FlexJS] Debugging package

[Josh Tynjala]

I implemented a "debugger" statement in ActionScript that works similarly
to the JavaScript debugger statement:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/debugger

In JavaScript, it translates directly. In SWF, the compiler generates
bytecode for a call to flash.debugger.enterDebugger(). This is not an
officially documented function in the Flash runtimes, but it's been around
since AS3 was introduced, as far as I can tell. I would say that it's
unlikely to be removed in the future. While I mentioned that I was
considering using flash.system.System.pause(), it did not behave in the way
that I originally hoped. In my tests, System.pause() seemed to pause
rendering only, and code kept running without triggering the debugger.

My changes are in the feature/debugger-statement branch of flex-falcon.
I'll be happy to merge them into develop, if there's interest.

- Josh



On Tue, Jul 18, 2017 at 5:05 PM, Josh Tynjala  wrote:

> I'm working on adding support for the debugger statement to the compiler
> (FLEX-35343). I can successfully emit the debugger statement in the
> generated JS so far.
>
> I'm not yet sure if I can make it work on the SWF side. I figured out
> where I can generate bytecode instructions in ABCGeneratingReducer. If I
> can figure out how to generate bytecode to call enterDebugger() (or
> whatever the function is called), the debugger statement will work in both
> SWF and JS.
>
> - Josh
>
> On Sun, Jul 16, 2017 at 9:22 AM, Josh Tynjala 
> wrote:
>
>> If it were a variable or function, it could be defined somewhere like
>> that. It's a statement, though, so it needs to be added to where Falcon
>> creates the AST from the ActionScript code. Then, it also needs to emit the
>> statement as JS in FalconJX. On the SWF side, it should be translated to
>> appropriate bytecode to call enterDebugger().
>>
>> - Josh
>>
>> On Jul 16, 2017 8:56 AM, "Harbs"  wrote:
>>
>>> What needs to be modified? Does it need to be added to NativeJSType
>>> enums? Somewhere else?
>>>
>>> I’m really not clear on when things to be added to that and when they
>>> need to be in typedefs.
>>>
>>> > On Jul 16, 2017, at 6:51 PM, Harbs  wrote:
>>> >
>>> >> The compiler needs to be modified to support the debugger statement.
>>>
>>>
>

Re: [FlexJS]TileLayout

[Peter Ent]

I just left things as open as possible as I recall. Thanks Harbs.

On 7/23/17, 6:06 AM, "Harbs"  wrote:

>Agreed, but I think the defaults should match Flash between and HTML.
>
>He did not set stretch. Nothing was set. ³stretch² is the default css.
>
>> On Jul 23, 2017, at 12:23 PM, Alex Harui 
>>wrote:
>> 
>> There doesn't have to be one TileLayout.  There can be
>> TileLayoutWithFlexStart, TileLayoutWithStretch, and
>> TileLayoutWithAlignContent with a property that allows you to set it.
>> 
>> Peter may remember why he chose "stretch".
>> 
>> -Alex
>> 
>> On 7/23/17, 1:28 AM, "Harbs"  wrote:
>> 
>>> I just discovered something which is worth bringing up:
>>> 
>>> The default for css flex layouts is align-content: stretch This adds
>>> space between elements if the total height (or width) of the elements
>>>are
>>> less than the parent. I don¹t think that¹s an appropriate default for a
>>> tile layout. The layout should be packed from the top left and only add
>>> space if there is padding/margins in the itemRenderers.
>>> 
>>> I believe the correct default css is align-content: flex-start which
>>>has
>>> the behavior that I would expect from a tile layout.
>>> 
>>> Of course, it might be interesting to have a tile layout which offers
>>> different spacing options. That could be alternate layouts, or even
>>>beads
>>> attached to the layout beads.
>>> 
>>> I fixed this issue in my app by just adding some align-content:
>>> flex-start css to my TileLayout component. This works because I don¹t
>>> need swf rendering, but I think it¹s something that should be addressed
>>> in the TileLayout.
>>> 
>>> Let me checkŠ
>>> 
>>> I just (fixed and) ran ContainerTest, and the swf behavior is in fact
>>> different than the HTML behavior. I think we can classify this as a
>>>bug.
>>> I¹m committing this change.
>>> 
>>> FWIW, there¹s lots of other differences between the swf output and the
>>>JS
>>> output in ContainerTest. It¹s probably worth looking into the rest of
>>> those issues as wellŠ
>>> 
>>> Harbs
>> 
>

Re: [FlexJS] PAYG and dataGroups

[Harbs]

Framework convention is generally to leave out the braces and indent the line 
like this:
if (ir)
  ir.selected = true;

> On Jul 24, 2017, at 2:54 PM, piotrz  wrote:
> 
> I meant this kind of lines somewhere inside method:
> 
> ir = dataGroup.getItemRendererForIndex(listModel.selectedIndex) as
> ISelectableItemRenderer;
> if (ir != null) ir.selected = true;
> 
> I would change it to:
> 
> ir = dataGroup.getItemRendererForIndex(listModel.selectedIndex) as
> ISelectableItemRenderer;
> if (ir != null)
> {
>   ir.selected = true;
> }
> 
> But if this is framework code convention let's live it as is. I just didn't
> notice that is look like that.
> 
> Piotr
> 
> 
> 
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: 
> http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63511.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] PAYG and dataGroups

[piotrz]

I meant this kind of lines somewhere inside method:

ir = dataGroup.getItemRendererForIndex(listModel.selectedIndex) as
ISelectableItemRenderer;
if (ir != null) ir.selected = true;

I would change it to:

ir = dataGroup.getItemRendererForIndex(listModel.selectedIndex) as
ISelectableItemRenderer;
if (ir != null)
{
   ir.selected = true;
}

But if this is framework code convention let's live it as is. I just didn't
notice that is look like that.

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63511.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] PAYG and dataGroups

[Harbs]

I’m not sure what you mean.

If you mean braces for single-line statements, I actually use those in my 
personal projects, but I leave them out in Flex code because that’s alway been 
the convention in the Flex Framework.

Thanks,
Harbs

> On Jul 24, 2017, at 2:32 PM, piotrz  wrote:
> 
> Thanks! I saw your changes and it look better. 
> 
> Btw: I really would like to see in your commits more curly brackets -
> especially when you are doing some changes down into the methods. - It's lot
> easier to catch eventually bugs.
> 
> Piotr
> 
> 
> 
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: 
> http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63509.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] PAYG and dataGroups

[piotrz]

Thanks! I saw your changes and it look better. 

Btw: I really would like to see in your commits more curly brackets -
especially when you are doing some changes down into the methods. - It's lot
easier to catch eventually bugs.

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63509.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] PAYG and dataGroups

[Harbs]

I spent quite a bit of time looking into this.

I came to the conclusion that there likely needs to be beads with more interop 
for modifying data content, but I don’t think I need that for right now.

After finding my way through the classes, I realized that 
dataGroup.getItemRendererForIndex() has range checking, so there’s no reaosn 
for the view to do it’s own range checking.

A simple null check on the results is enough (which the selected handler was 
already doing).

So better safety with less code. An all-around win. :-)

> On Jul 24, 2017, at 10:12 AM, piotrz  wrote:
> 
> Hi Harbs,
> 
> In such cases where you preventing from RTE I'm thinking that having bead
> would be weird. PreventDataGroupFromRte? Cause you do not do anything more
> adding such just-in-case code. Maybe this case is one of those when we
> should have that code? 
> 
> Piotr
> 
> 
> 
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: 
> http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63502.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: git commit: [flex-asjs] [refs/heads/develop] - This appears to be inoperative. I believe this change is correct, but it really needs a test.

[Harbs]

Good call.

I noticed that I can simplify the code a bit as well.

I added this to the other notifier classes too.

> On Jul 24, 2017, at 1:37 PM, Piotr Zarzycki  wrote:
> 
> Hi Harbs,
> 
> I think this line should be outside "if":
> 
> var object:Object = document[sourceID];
> 
> Please check additionally other beads related to ChangeNotifier.
> 
> Thanks,
> Piotr
> 
> 
> 2017-07-24 12:29 GMT+02:00 :
> 
>> Repository: flex-asjs
>> Updated Branches:
>>  refs/heads/develop 2458fe559 -> 61ef18b9a
>> 
>> 
>> This appears to be inoperative. I believe this change is correct, but it
>> really needs a test.
>> 
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/61ef18b9
>> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/61ef18b9
>> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/61ef18b9
>> 
>> Branch: refs/heads/develop
>> Commit: 61ef18b9adce1b6fbc650cd07654198e90d780d5
>> Parents: 2458fe5
>> Author: Harbs 
>> Authored: Mon Jul 24 13:29:05 2017 +0300
>> Committer: Harbs 
>> Committed: Mon Jul 24 13:29:05 2017 +0300
>> 
>> --
>> .../flex/org/apache/flex/html/beads/DataProviderChangeNotifier.as | 3 +++
>> 1 file changed, 3 insertions(+)
>> --
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
>> 61ef18b9/frameworks/projects/Basic/src/main/flex/org/
>> apache/flex/html/beads/DataProviderChangeNotifier.as
>> --
>> diff --git a/frameworks/projects/Basic/src/main/flex/org/apache/flex/
>> html/beads/DataProviderChangeNotifier.as b/frameworks/projects/Basic/
>> src/main/flex/org/apache/flex/html/beads/DataProviderChangeNotifier.as
>> index e8c28bd..bab1c4a 100644
>> --- a/frameworks/projects/Basic/src/main/flex/org/apache/flex/html/beads/
>> DataProviderChangeNotifier.as
>> +++ b/frameworks/projects/Basic/src/main/flex/org/apache/flex/html/beads/
>> DataProviderChangeNotifier.as
>> @@ -56,10 +56,13 @@ package org.apache.flex.html.beads
>>}
>>else
>>{
>> +   if(object[propertyName] == dataProvider)
>> +   return;
>> dataProvider.removeEventListener("itemAdded",
>> handleDataProviderChanges);
>> dataProvider.removeEventListener("itemRemoved",
>> handleDataProviderChanges);
>> dataProvider.removeEventListener("itemUpdated",
>> handleDataProviderChanges);
>> dataProvider.removeEventListener("collectionChanged",
>> handleDataProviderChanges);
>> +   dataProvider = object[propertyName] as
>> ArrayList;
>>}
>> 
>> dataProvider.addEventListener("itemAdded",
>> handleDataProviderChanges);
>> 
>> 

Re: git commit: [flex-asjs] [refs/heads/develop] - This appears to be inoperative. I believe this change is correct, but it really needs a test.

[Piotr Zarzycki]

Hi Harbs,

I think this line should be outside "if":

var object:Object = document[sourceID];

Please check additionally other beads related to ChangeNotifier.

Thanks,
Piotr


2017-07-24 12:29 GMT+02:00 :

> Repository: flex-asjs
> Updated Branches:
>   refs/heads/develop 2458fe559 -> 61ef18b9a
>
>
> This appears to be inoperative. I believe this change is correct, but it
> really needs a test.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/61ef18b9
> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/61ef18b9
> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/61ef18b9
>
> Branch: refs/heads/develop
> Commit: 61ef18b9adce1b6fbc650cd07654198e90d780d5
> Parents: 2458fe5
> Author: Harbs 
> Authored: Mon Jul 24 13:29:05 2017 +0300
> Committer: Harbs 
> Committed: Mon Jul 24 13:29:05 2017 +0300
>
> --
>  .../flex/org/apache/flex/html/beads/DataProviderChangeNotifier.as | 3 +++
>  1 file changed, 3 insertions(+)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> 61ef18b9/frameworks/projects/Basic/src/main/flex/org/
> apache/flex/html/beads/DataProviderChangeNotifier.as
> --
> diff --git a/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> html/beads/DataProviderChangeNotifier.as b/frameworks/projects/Basic/
> src/main/flex/org/apache/flex/html/beads/DataProviderChangeNotifier.as
> index e8c28bd..bab1c4a 100644
> --- a/frameworks/projects/Basic/src/main/flex/org/apache/flex/html/beads/
> DataProviderChangeNotifier.as
> +++ b/frameworks/projects/Basic/src/main/flex/org/apache/flex/html/beads/
> DataProviderChangeNotifier.as
> @@ -56,10 +56,13 @@ package org.apache.flex.html.beads
> }
> else
> {
> +   if(object[propertyName] == dataProvider)
> +   return;
>  dataProvider.removeEventListener("itemAdded",
> handleDataProviderChanges);
>  dataProvider.removeEventListener("itemRemoved",
> handleDataProviderChanges);
>  dataProvider.removeEventListener("itemUpdated",
> handleDataProviderChanges);
>  dataProvider.removeEventListener("collectionChanged",
> handleDataProviderChanges);
> +   dataProvider = object[propertyName] as
> ArrayList;
> }
>
>  dataProvider.addEventListener("itemAdded",
> handleDataProviderChanges);
>
>

Re: git commit: [flex-asjs] [refs/heads/develop] - This appears to be inoperative. I believe this change is correct, but it really needs a test.

[Harbs]

While researching the issue I had, I noticed this code.

It appears to be removing the event handlers from the object and then adding 
them back to the same objects. I believe the change I wrote is necessary to add 
the event handlers to the new object, but I’d appreciate if we get some 
additional eyeballs on this.

I did not see any tests for this, and I don’t have the time right now to write 
one.

Thanks,
Harbs
 
> On Jul 24, 2017, at 1:29 PM, ha...@apache.org wrote:
> 
> Repository: flex-asjs
> Updated Branches:
>  refs/heads/develop 2458fe559 -> 61ef18b9a
> 
> 
> This appears to be inoperative. I believe this change is correct, but it 
> really needs a test.
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/61ef18b9
> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/61ef18b9
> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/61ef18b9
> 
> Branch: refs/heads/develop
> Commit: 61ef18b9adce1b6fbc650cd07654198e90d780d5
> Parents: 2458fe5
> Author: Harbs 
> Authored: Mon Jul 24 13:29:05 2017 +0300
> Committer: Harbs 
> Committed: Mon Jul 24 13:29:05 2017 +0300
> 
> --
> .../flex/org/apache/flex/html/beads/DataProviderChangeNotifier.as | 3 +++
> 1 file changed, 3 insertions(+)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/61ef18b9/frameworks/projects/Basic/src/main/flex/org/apache/flex/html/beads/DataProviderChangeNotifier.as
> --
> diff --git 
> a/frameworks/projects/Basic/src/main/flex/org/apache/flex/html/beads/DataProviderChangeNotifier.as
>  
> b/frameworks/projects/Basic/src/main/flex/org/apache/flex/html/beads/DataProviderChangeNotifier.as
> index e8c28bd..bab1c4a 100644
> --- 
> a/frameworks/projects/Basic/src/main/flex/org/apache/flex/html/beads/DataProviderChangeNotifier.as
> +++ 
> b/frameworks/projects/Basic/src/main/flex/org/apache/flex/html/beads/DataProviderChangeNotifier.as
> @@ -56,10 +56,13 @@ package org.apache.flex.html.beads
>   }
>   else
>   {
> + if(object[propertyName] == dataProvider)
> + return;
> dataProvider.removeEventListener("itemAdded", 
> handleDataProviderChanges);
> dataProvider.removeEventListener("itemRemoved", 
> handleDataProviderChanges);
> dataProvider.removeEventListener("itemUpdated", 
> handleDataProviderChanges);
> dataProvider.removeEventListener("collectionChanged", 
> handleDataProviderChanges);
> + dataProvider = object[propertyName] as 
> ArrayList;
>   }
> 
> dataProvider.addEventListener("itemAdded", 
> handleDataProviderChanges);
> 

Re: [FlexJS] stopImmediatePropagation

[Alex Harui]

Good to know.

I think the bubbles test also needs to test a custom event.  I think there is 
code that listens to the element for certain event names and to the wrapper.

Get Outlook for Android


From: Harbs 
Sent: Sunday, July 23, 2017 2:55:10 PM
To: dev@flex.apache.org
Subject: Re: [FlexJS] stopImmediatePropagation

Good. I confirmed that this survives minification.

> On Jul 24, 2017, at 12:41 AM, Harbs  wrote:
>
> Oh.It seems like there’s an official way to do this:
> BrowserEvent.prototpye.getBrowserEvent()
>
>> On Jul 24, 2017, at 12:34 AM, Harbs > > wrote:
>>
>> Bah!
>>
>> I just discovered another issue with this branch.
>>
>> The goog.BrowserEvent “event_” property is renamed when the code is 
>> minified. Without hacking the goog code, using that property is not gonna 
>> work…
>>
>>> On Jul 23, 2017, at 1:44 PM, Harbs >> > wrote:
>>>
>>> I feel like I went down the rabbit hole with this…
>>>
>>> I think MouseEvent needs to work much like BrowserEvent in that it proxies 
>>> to the underlying event to get properties, coordinates, etc.
>>>
>>> What I’m not really sure about is what happens if you want to dispatch a 
>>> MouseEvent on an element? (i.e. myButton.dispatchEvent(new 
>>> MouseEvent(MouseEvent.CLICK)))
>>>
>>> Is that something which currently works? How should it work? Should localX 
>>> and localY be user-settable?
>>>
>>> There’s also some code in MosueEvent in getScreenX and getScreenY which 
>>> calculates _stagePoint using localToGlobal. I’m not sure that makes sense 
>>> either. Assuming we can rely on the native event, there’s no need to do 
>>> those calculations ourselves. I can not find a single use of MouseEvent 
>>> anywhere, so I don’t have any way of confirming that this ever worked or 
>>> did anything. Was it ever used in any of the examples?
>>>
>>>
 On Jul 21, 2017, at 6:06 PM, Harbs > wrote:

 Yes. That seems to be the case:
 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-library%2Fblob%2F608e0eaaa42bb5f041a7f067f254907d47edf7d1%2Fclosure%2Fgoog%2Fevents%2Feventtarget.js%23L371=02%7C01%7C%7C763d326f33864e8a00a008d4d21584b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636364437271019556=rAs8Re5hh5fsu1%2B0RrzauKsOeLAxy9eshW%2FRxFr4U2g%3D=0
  
 

> On Jul 21, 2017, at 5:18 PM, Alex Harui  > wrote:
>
> I think other goog code updates currentTarget as needed.  They are the
> same when no capture or bubbling, IIRC.
>
> -Alex
>
> On 7/20/17, 11:52 PM, "Harbs"  > wrote:
>
>> Yes. I need to copy the code from BrowserEvent.
>>
>> Interestingly, goog.Events does not distinguish between target and
>> currentTarget. That does not seem very useful:
>>
>> * Target of the event.
>>  * @type {Object|undefined}
>>  */
>> this.target = opt_target;
>>
>> /**
>>  * Object that had the listener attached.
>>  * @type {Object|undefined}
>>  */
>> this.currentTarget = this.target;
>>
>>> On Jul 21, 2017, at 9:21 AM, piotrz >> > wrote:
>>>
>>> Ahh Sorry I missed the point in his post. Do you see some solution ?
>>>
>>> Piotr
>>>
>>>
>>>
>>> -
>>> Apache Flex PMC
>>> piotrzarzyck...@gmail.com 
>>> --
>>> View this message in context:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>>  
>>> 
>>> ex-development.247.n4.nabble.com 
>>> %2FFlexJS-stopImmediatePropagation-tp
>>> 63418p63479.html=02%7C01%7C%7C33b41ee272044f297c9208d4d005185f%7Cfa7
>>> b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636362167683568915=xo66CMSg
>>> ME%2BdFt7dg5qU6%2BYv7quJw6REm%2B5mKJbwpS0%3D=0
>>> Sent from the Apache Flex Development mailing 

Re: git commit: [flex-asjs] [refs/heads/feature/browser-event] - goog.Event assumes the getter can be called on the event. Default to the super getter if wrappedEvent is not set (yet).

[Harbs]

Good thought, but it does not work.

With the modified typedef, I get this which generates an RTE because 
“get__target” is not defined:

return this.wrappedEvent ? 
org.apache.flex.events.getTargetWrapper(this.wrappedEvent.target) : 
org.apache.flex.events.MouseEvent.superClass_.get__target.apply(this);

> On Jul 23, 2017, at 12:25 PM, Alex Harui  wrote:
> 
> It may not be a getter in goog.Event and just a var instead.  It might be
> ok to modify the typedefs to make it a getter.
> 
> HTH,
> -Alex
> 
> On 7/23/17, 1:59 AM, "Harbs"  > wrote:
> 
>> This commit should theoretically work, but it looks like there’s a weird
>> Falcon bug here.
>> 
>> When outputting the getters for target and currentTarget, the “super”
>> reference is being dropped. I’m assuming it’s because
>> org.apache.flex.events.Event does not actually declare target and
>> currentTarget. That’s defined in goog.Event. I would think that this
>> should work though.
>> 
>> org.apache.flex.events.KeyboardEvent.prototype.get__target = function() {
>> return this.wrappedEvent ?
>> org.apache.flex.events.getTargetWrapper(this.wrappedEvent.target) :
>> .target;
>> };
>> 
>> 
>> org.apache.flex.events.KeyboardEvent.prototype.get__currentTarget =
>> function() {
>> return this.wrappedEvent ?
>> org.apache.flex.events.getTargetWrapper(this.wrappedEvent.currentTarget)
>> : .currentTarget;
>> };
>> 
>> For now, I’m just going to return null if the wrappedEvent is not yet
>> defined...
>> 
>>> On Jul 23, 2017, at 11:36 AM, ha...@apache.org wrote:
>>> 
>>> Repository: flex-asjs
>>> Updated Branches:
>>> refs/heads/feature/browser-event f53e941ac -> 3b2a8feb7
>>> 
>>> 
>>> goog.Event assumes the getter can be called on the event. Default to
>>> the super getter if wrappedEvent is not set (yet).
>>> 
>>> 
>>> Project: 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip-u 
>>> 
>>> s.apache.org 
>>> %2Frepos%2Fasf%2Fflex-asjs%2Frepo=02%7C01%7C%7C6220b295f
>>> 3164be8c9b608d4d1a93840%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363
>>> 63972100230488=NnjD1v1Q0qgXCroxbCqrYJ7jZQYEIgoEF3r%2B3PgY9eE%3D
>>> erved=0
>>> Commit: 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip-u 
>>> 
>>> s.apache.org 
>>> %2Frepos%2Fasf%2Fflex-asjs%2Fcommit%2F3b2a8feb=02%7C01%7
>>> C%7C6220b295f3164be8c9b608d4d1a93840%7Cfa7b1b5a7b34438794aed2c178decee1%7
>>> C0%7C0%7C636363972100230488=dW4KyFwidrnA41bUXzqrleDUlciVmVfL1e34Wl6
>>> %2F8SM%3D=0
>>> Tree: 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip-u 
>>> 
>>> s.apache.org 
>>> %2Frepos%2Fasf%2Fflex-asjs%2Ftree%2F3b2a8feb=02%7C01%7C%
>>> 7C6220b295f3164be8c9b608d4d1a93840%7Cfa7b1b5a7b34438794aed2c178decee1%7C0
>>> %7C0%7C636363972100230488=kvueX%2B4MeHMF1PVOHWvF0MP3zPpGLfjeCgBuG0W
>>> Im%2FI%3D=0
>>> Diff: 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip-u 
>>> 
>>> s.apache.org 
>>> %2Frepos%2Fasf%2Fflex-asjs%2Fdiff%2F3b2a8feb=02%7C01%7C%
>>> 7C6220b295f3164be8c9b608d4d1a93840%7Cfa7b1b5a7b34438794aed2c178decee1%7C0
>>> %7C0%7C636363972100230488=cKc96Cx35C1MupN66KbdtYJ6eRpcGOfatDqoAPEHi
>>> d0%3D=0
>>> 
>>> Branch: refs/heads/feature/browser-event
>>> Commit: 3b2a8feb763771d6d3e371d89b251068d0cca4fc
>>> Parents: f53e941
>>> Author: Harbs >
>>> Authored: Sun Jul 23 11:36:48 2017 +0300
>>> Committer: Harbs >
>>> Committed: Sun Jul 23 11:36:48 2017 +0300
>>> 
>>> --
>>> .../Core/src/main/flex/org/apache/flex/events/KeyboardEvent.as   | 4
>>> ++--
>>> .../Core/src/main/flex/org/apache/flex/events/MouseEvent.as  | 4
>>> ++--
>>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>> --
>>> 
>>> 
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip-u 
>>> 
>>> s.apache.org 
>>> %2Frepos%2Fasf%2Fflex-asjs%2Fblob%2F3b2a8feb%2Fframeworks%2Fp
>>> rojects%2FCore%2Fsrc%2Fmain%2Fflex%2Forg%2Fapache%2Fflex%2Fevents%2FKeybo
>>> ardEvent.as=02%7C01%7C%7C6220b295f3164be8c9b608d4d1a93840%7Cfa7b1b5a
>>> 7b34438794aed2c178decee1%7C0%7C0%7C636363972100230488=EMmm0ImlYAdzd
>>> myVcQF%2BWeJffDHBIryk%2FFrqTs8M4I0%3D=0
>>> --
>>> diff --git 
>>> 

Re: [FlexJS] PAYG and dataGroups

[piotrz]

Hi Harbs,

In such cases where you preventing from RTE I'm thinking that having bead
would be weird. PreventDataGroupFromRte? Cause you do not do anything more
adding such just-in-case code. Maybe this case is one of those when we
should have that code? 

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63502.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] stopImmediatePropagation

[piotrz]

Hi Harbs,

I will check your changes later today or tomorrow evening. 

Thank you,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-stopImmediatePropagation-tp63418p63501.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.