Re: [FlexJS] Removing PasswordInputBead has no effect

[justin]

Hi,

> Both the original version and my JS compile down to to same size of 92 bytes. 
> The unzipped versions differ by 2% with my version being slighter larger. The 
> AS versions are identical.

Even with simple optimisation (i.e. no code optimised out or renamed) the size 
increase is 7%.

Thanks,
Justin

Re: [MAVEN-BUILD] FlexJS Framework (maven) - Build # 943 - Still Failing

[Alex Harui]

I think I need Maven expert help to fix this.  It builds fine for me
locally.  I believe my change to flex-typedefs caused this.  The
flex-typedefs build seems to be generating artifacts with a timestamp in
the artifact name instead of "SNAPSHOT" and this frameworks build now
cannot find the dependencies it is looking for.

Thanks,
-Alex

On 6/4/17, 9:45 PM, "Apache Jenkins Server" 
wrote:

>The Apache Jenkins build system has built FlexJS Framework (maven) (build
>#943)
>
>Status: Still Failing
>
>Check console output at
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuilds.ap
>ache.org%2Fjob%2FFlexJS%2520Framework%2520(maven)%2F943%2F=02%7C01%7C
>%7Ce017359edae84451e1af08d4abcda478%7Cfa7b1b5a7b34438794aed2c178decee1%7C0
>%7C0%7C636322347104963177=IXnqnJCJBChw8y3tdy0rK7TH2NKsXnjdr2LaMten71
>U%3D=0 to view the results.

Re: [FlexJS] Removing PasswordInputBead has no effect

[Justin Mclean]

Hi,

Sorry autocorrect seems to have got the better of me - correcting:

I think you are forgetting the optimisation that goes on, yes the source code 
has a few more lines of code, but hardly double the size.

Perhaps we can come up with some rules/guildlines to what PAYG actually is? Say 
no more than 5% or 10% final size or runtime cost?

In this case the code has zero cost re final size or practical runtime 
performance (and extra null check on the JS side) and zero cost on the AS side.

Thanks,
Justin

Re: [FlexJS] Removing PasswordInputBead has no effect

[Justin Mclean]

Hi,

> The removal code doubles the practical size of the bead. Definitely not PAYG.

I think you are forging the optimisation that goes so, yes the source code has 
a few moraines of code, but hardly double the size. So sorry to say that that 
an exaggeration and frankly incorrect. 

Both the original version and my JS compile down to to same size of 92 bytes. 
The unzipped versions differ by 2% with my version being slighter larger. The 
AS versions are identical.

Thanks,
Justin

Re: [FlexJS] Removing PasswordInputBead has no effect

[Justin Mclean]

Hi,

> Actually, the fix can probably be simplified to replacing the original:
> e.type = 'password’;
> with
> e.type = value ? 'password' : 'text’;

Not quite as in one case e is derived from the the TextInput passed in, the 
other it’s derived from the existing stand as null is passed in.

Thanks,
Justin

Re: [FlexJS] Removing PasswordInputBead has no effect

[Harbs]

Actually, the fix can probably be simplified to replacing the original:
e.type = 'password’;
with
e.type = value ? 'password' : 'text’;

I’m personally ok with keeping that change in the original bead.

> On Jun 5, 2017, at 7:15 AM, Harbs  wrote:
> 
> The removal code doubles the practical size of the bead. Definitely not PAYG.
> 
> Subclassing the bead and overidding set strand on JS or creating a new one is 
> definitely the way to go.
> 
> Harbs
> 
>> On Jun 5, 2017, at 6:55 AM, Justin Mclean  wrote:
>> 
>> Hi,
>> 
>>> I would recommend handling removal in an enhanced bead, maybe call it
>>> RemovablePasswordInputBead.  Not everybody will need to remove the bead so
>>> PAYG would say to offer folks the original and your version.
>> 
>> I’d prefer not to.
>> 
>> There is no extra PAYG cost on the AS side and a null check on the JS side.
>> 
>> Copy and pasting 100 lines of code to a new class just to make those simple 
>> changes doesn't seem like PAYG to me. What do other people think?
>> 
>> Thanks,
>> Justin
> 

Re: [FlexJS] Removing PasswordInputBead has no effect

[Harbs]

The removal code doubles the practical size of the bead. Definitely not PAYG.

Subclassing the bead and overidding set strand on JS or creating a new one is 
definitely the way to go.

Harbs

> On Jun 5, 2017, at 6:55 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> I would recommend handling removal in an enhanced bead, maybe call it
>> RemovablePasswordInputBead.  Not everybody will need to remove the bead so
>> PAYG would say to offer folks the original and your version.
> 
> I’d prefer not to.
> 
> There is no extra PAYG cost on the AS side and a null check on the JS side.
> 
> Copy and pasting 100 lines of code to a new class just to make those simple 
> changes doesn't seem like PAYG to me. What do other people think?
> 
> Thanks,
> Justin

Re: [FlexJS] Removing PasswordInputBead has no effect

[Alex Harui]

It can't be done in a subclass with an override of the strand setter?

-Alex

On 6/4/17, 8:55 PM, "Justin Mclean"  wrote:

>Hi,
>
>> I would recommend handling removal in an enhanced bead, maybe call it
>> RemovablePasswordInputBead.  Not everybody will need to remove the bead
>>so
>> PAYG would say to offer folks the original and your version.
>
>I’d prefer not to.
>
>There is no extra PAYG cost on the AS side and a null check on the JS
>side.
>
>Copy and pasting 100 lines of code to a new class just to make those
>simple changes doesn't seem like PAYG to me. What do other people think?
>
>Thanks,
>Justin

Re: [FlexJS] Removing PasswordInputBead has no effect

[Justin Mclean]

Hi,

> I would recommend handling removal in an enhanced bead, maybe call it
> RemovablePasswordInputBead.  Not everybody will need to remove the bead so
> PAYG would say to offer folks the original and your version.

I’d prefer not to.

There is no extra PAYG cost on the AS side and a null check on the JS side.

Copy and pasting 100 lines of code to a new class just to make those simple 
changes doesn't seem like PAYG to me. What do other people think?

Thanks,
Justin

Re: [FlexJS] Removing PasswordInputBead has no effect

[Alex Harui]

I would recommend handling removal in an enhanced bead, maybe call it
RemovablePasswordInputBead.  Not everybody will need to remove the bead so
PAYG would say to offer folks the original and your version.

Thanks,
-Alex

On 6/4/17, 8:25 PM, "Justin Mclean"  wrote:

>Hi,
>
>I just run into an issue with removing the PasswordInputBead when removed
>the text in the input field was still stared out / hidden.
>
>The way to fix is is the set the strand to null on removing the bead and
>then having the PasswordInputBead reset the input type to “text" when
>null is passed into the stand setter.
>
>I've done this and pushed up to develop. This was discussed on the list
>before (when I added the CORS bead) as the way to fix this but if there's
>a better way to do fix this please suggest so.
>
>Thanks,
>Justin
>

[FlexJS] Removing PasswordInputBead has no effect

[Justin Mclean]

Hi,

I just run into an issue with removing the PasswordInputBead when removed the 
text in the input field was still stared out / hidden.

The way to fix is is the set the strand to null on removing the bead and then 
having the PasswordInputBead reset the input type to “text" when null is passed 
into the stand setter.

I've done this and pushed up to develop. This was discussed on the list before 
(when I added the CORS bead) as the way to fix this but if there's a better way 
to do fix this please suggest so.

Thanks,
Justin

Re: [FlexJS] Accordion broken

[Alex Harui]

On 6/3/17, 2:10 PM, "Harbs"  wrote:

>It turns out the children are actually Containers which have a
>TitleBarModel bead. Sorry about the confusion. It might make sense to
>have an interface for an accordion-compatible container.

My recommendation, as an alternative to an interface, would be to have an
"AccordionInfoBead" that the Accordion expects to find on each child.
That way, just about anything can be an Accordion child without having to
always carry around a title property.  And fancier versions of Accordion
could have fancier AccordionInfoBeads that might dictate close and open
effects, maybe minimum sizes, label sizes, and more.

Food for thought for the next release,
-Alex

Re: Private properties are undefined in JS and null in AS

[Josh Tynjala]

The release branch has diverged far enough from develop that I assume most
people aren't using develop until the release breach gets merged back in.

- Josh

On Jun 4, 2017 1:55 AM, "Justin Mclean"  wrote:

> Hi,
>
> > Well I like what Justin did in case of css and some other changes. It
> seems
> > be performance improver, but please do not make changes more till people
> who
> > has real world app like Harbs do not give some feedback whether there are
> > not breaking changes.
>
> I’m using a application in production and those changes are working fine
> for me.
>
> Anyone else seen any issues with them? If there are any issues I’m happy
> to fix them.
>
> If you use develop over the past couple of week you would of been using
> them.
>
> Thanks,
> Justin

Re: dual issues

[Alex Harui]

For me, the Ant build calls the "compile" target in
examples/build_example.xml and sets the config_arg to use
frameworks/js-config.xml which has targets set to just JS.

A better example might be examples/flexjs/MDLExample.  For Ant, it has a
src/main/config/compile-app-config.xml which specifies:
JSFlex

And for me, no SWF is produced.


HTH,
-Alex

On 6/4/17, 10:31 AM, "Harbs"  wrote:

>That is using -js-output-type=FLEXJS
>
>My understanding is that we are supposed to use -targets=JSFlex now.
>
>Is that not right?
>
>> On Jun 4, 2017, at 5:43 PM, Alex Harui  wrote:
>> 
>> The examples/native/ButtonExample does not produce a SWF for me, so
>>maybe
>> compare that setup against yours.
>> 
>> HTH,
>> -Alex
>> 
>> On 6/4/17, 12:56 AM, "Harbs"  wrote:
>> 
>>> Good news: Prior to the switch to dual, I was not getting a minified
>>> release build working. That’s now working.
>>> Bad news: It takes much longer than it used to, and I’m getting a swf
>>> file even though I’m only using -targets=JSFlex
>>> 
>>> Harbs
>> 
>

Re: [FlexJS] more on undefined / non initialised values

[Josh Tynjala]

Good points. I'm all for initializing more than we do now. Even if we don't
achieve parity with all types, Booleans should definitely default to false
and Numbers to NaN, if they aren't explicitly initialized with a value, in
my opinion.

- Josh

On Jun 3, 2017 7:27 PM, "Justin Mclean"  wrote:

Hi,

So if you run this code on AS
public var s:String;
public var o:Object;
public var i:int;
public var n:Number;
public var b:Boolean;

public function init():void {
trace(s);
trace(o);
trace(i);
trace(n);
trace(b);
}

You get:
null
null
0
NaN
false
null

but on JS you get:
undefined
undefined
0
undefined
undefined
undefined

Now with strings, objects and Arrays you can get issues with === and !== as
they are null on one platform and undefined on an another - as discussed in
the other thread.

But the issue is worse with Numbers and Booleans as there are additional
concerns. Performance is also an issue as JS doesn't know what type they
are and will be slowed down by implicit casting.

For example this code will not do as you expect and say b is true when it
is not as undefined != false.

var b:Boolean;

if (b == false)
{
  trace(“b is false”);
}
else
{
  trace(“b is true”);
}

Luckily isNaN(undefined) returns true, NaN != undefined so that may cause
some issues as well.

Thanks,
Justin

Re: dual issues

[Harbs]

That is using -js-output-type=FLEXJS

My understanding is that we are supposed to use -targets=JSFlex now.

Is that not right?

> On Jun 4, 2017, at 5:43 PM, Alex Harui  wrote:
> 
> The examples/native/ButtonExample does not produce a SWF for me, so maybe
> compare that setup against yours.
> 
> HTH,
> -Alex
> 
> On 6/4/17, 12:56 AM, "Harbs"  wrote:
> 
>> Good news: Prior to the switch to dual, I was not getting a minified
>> release build working. That’s now working.
>> Bad news: It takes much longer than it used to, and I’m getting a swf
>> file even though I’m only using -targets=JSFlex
>> 
>> Harbs
> 

Re: [FlexJS] Accordion broken

[Peter Ent]

Thanks. I'll look into this today if I get a chance and definitely tomorrow. 

Peter 


> On Jun 4, 2017, at 6:05 AM, yishayw  wrote:
> 
> Here's [1] an example app.
> 
> The 2 problems I see:
> 
> 1) DataBinding problems [2] cause titles to be undefined. I hacked a fix on
> TLF branch, but this should probably addressed differently.
> 2) TitleBar.height returns 0, even though the measured height is 30. I think
> this is a bug, am I wrong?
> 
> Thanks.
> 
> [1] 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FQUj1=02%7C01%7C%7Cb335b9934ee44b3faf9d08d4ab3143ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636321675477479646=0qp76vTwMIdyOnFnuFZh1CPn62T3ALjIvYV47j3Aqvs%3D=0
> [2]
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.247.n4.nabble.com%2FFlexJS-DataBinding-Problem-td62073.html=02%7C01%7C%7Cb335b9934ee44b3faf9d08d4ab3143ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636321675477489658=1y0o9R2qZWimrsFH%2FTyU%2B5061RVbnFQgpRsQ5CKtmfc%3D=0
> 
> 
> 
> 
> --
> View this message in context: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.247.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937p62080.html=02%7C01%7C%7Cb335b9934ee44b3faf9d08d4ab3143ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636321675477489658=s3BPfklP65X5fXGknNX0ZB%2FfREeToXzsiGhKV%2BSpSJo%3D=0
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: dual issues

[Alex Harui]

The examples/native/ButtonExample does not produce a SWF for me, so maybe
compare that setup against yours.

HTH,
-Alex

On 6/4/17, 12:56 AM, "Harbs"  wrote:

>Good news: Prior to the switch to dual, I was not getting a minified
>release build working. That’s now working.
>Bad news: It takes much longer than it used to, and I’m getting a swf
>file even though I’m only using -targets=JSFlex
>
>Harbs

Re: [FlexJS] DataBinding Problem

[piotrz]

Yishay,

Try to make one more test. Add to this example bead ApplicationDataBinding
and let me know if something changed.

Piotr



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

Re: [FlexJS] DataBinding Problem

[yishayw]

You got it [1]. Thanks Piotr.

[1] https://issues.apache.org/jira/browse/FLEX-35320



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-DataBinding-Problem-tp62073p62083.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] DataBinding Problem

[piotrz]

Hi Yishay,

Please raise jira with above information and I will look into that.

Thanks,
Piotr



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

Re: git commit: [flex-asjs] [refs/heads/tlf] - Temp fix for labels of accordion not working.

[piotrz]

Hi Harbs,

Please raise jira and if it is still plan to create some example with
Accordion it would be helpful.
I will look into the Binding.

Thanks,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Re-git-commit-flex-asjs-refs-heads-tlf-Temp-fix-for-labels-of-accordion-not-working-tp62071p62081.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Accordion broken

[yishayw]

Here's [1] an example app.

The 2 problems I see:

1) DataBinding problems [2] cause titles to be undefined. I hacked a fix on
TLF branch, but this should probably addressed differently.
2) TitleBar.height returns 0, even though the measured height is 30. I think
this is a bug, am I wrong?

Thanks.

[1] https://paste.apache.org/QUj1
[2]
http://apache-flex-development.247.n4.nabble.com/FlexJS-DataBinding-Problem-td62073.html




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Accordion-broken-tp61937p62080.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Accordion broken

[Harbs]

1. Seems to be a data binding problem. (See other thread.) Yishay committed a 
temporary work-around, but we don’t think that’s the right way to fix the 
problem.
2. seems to be a measurement problem. The titleBar height is not being measured 
correctly. This is a workaround (in a custom item renderer)

override public function get collapsedHeight():Number{
return 30;
}


> On Jun 4, 2017, at 12:41 AM, Harbs  wrote:
> 
> I worked around the Promise issue (by copying js.swc to my project and not 
> using the one in the SDK).
> 
> There’s at least 2 issues still:
> 1. The title property from the model is not being applied to the view of the 
> item renderer.
> 2. The collapsed height of the collapsed items are 0 instead of the title bar 
> height.
> 
>> On Jun 4, 2017, at 12:10 AM, Harbs  wrote:
>> 
>> Yishay did the implementation of this so I was a bit shaky on the details.
>> 
>> I just looked at our code, and it appears that we did not actually use 
>> panels for the children.
>> 
>> It turns out the children are actually Containers which have a TitleBarModel 
>> bead. Sorry about the confusion. It might make sense to have an interface 
>> for an accordion-compatible container.
>> 
>> We will put together an example which should work better in the morning.
>> 
>> I cannot test my app which uses the Accordion right now because Promise is 
>> currently broken (like I wrote in my other email).
>> 
>> Harbs
>> 
>>> On Jun 2, 2017, at 7:01 PM, Peter Ent  wrote:
>>> 
>>> Hi,
>>> 
>>> It looks like this is the last thing to be resolved before we can make
>>> FlexJS 0.8 release.
>>> 
>>> I'm seeing two title bars per item in the Accordion. Any suggestions for
>>> how to resolve this, based on the information I've given below?
>>> 
>>> Thanks,
>>> Peter
>>> 
>>> On 6/1/17, 3:49 PM, "Peter Ent"  wrote:
>>> 
 I've checked in my changes to the Accordion components. It still is not
 working correctly and I cannot figure out what is happening. The
  used as the data to the Accordion are being placed as children
 of AccordionItemRenderers which are themselves Panels. So there are two
 TitleBars present per Accordion section.
 
 The layout mechanism changed so that the GroupView (the base view bead for
 all container-type view beads) no longer controls when layouts run; that
 is done by the layouts themselves. GroupView et al has a beforeLayout()
 and afterLayout() functions called by the layout classes which might be
 helpful, I'm not sure.
 
 Panel also changed quite a bit. A Panel is now a Group with its own layout
 that controls the placement of the TitleBar and Container which is its
 content area. When you specify a layout bead on a Panel, the Panel
 actually moves it to the content area Container. Perhaps this has
 something to do with the behavior we are now seeing.
 
 Please let me know if you have any suggestions on how to handle the
 Accordion as it now sits and I'll be happy to answer any questions about
 how the current view/layout system works now.
 
 If I may, perhaps Accordion could be changed as follows:
 
 
 

 
 
 
 
 
 
 The Accordion + AccordionView would create 2 children for each
 AccordionSection in the Accordion's space: an AccordionHeader + >>> child>. 
 
 The model would indicate which  is being viewed and the
 layout, such as OneFlexibleChildVerticalLayout or
 OneFlexibleChildHorizontalLayout, would take care of sizing and
 positioning the AccordionHeader and  elements. The >>> child> elements not visible would simply have visible=false set; the
 layout will then ignore them.
 
 For the HTML side, this example would create a  with four children
 and not have any deep nesting unless that what the 
 produces. The  that's visible would have overflow:auto or
 overflow:hidden while the other  elements would have
 display:none set. 
 
 Merely a suggestion, and could probably use some refinement.
 
 ‹peter
 
 
 On 6/1/17, 2:03 PM, "yishayw"  wrote:
 
> Harbs wrote
>> \2. The Collapse bead can only infer that it¹s collapsed by the fact
>> that
>> the size is the collapsed size ‹ which only makes sense if the size is
>> set.
> 
> Shouldn't .height return the measured height, regardless of whether it
> was
> explicitly set?
> 
> 
> 
> 
> --
> View this message in context:
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
> e
> x-development.247.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937p620
> 0
> 8.html=02%7C01%7C%7C9b640697ac694828308808d4a91a8573%7Cfa7b1b5a7b344
> 3
> 

Re: [FlexJS] DataBinding Problem

[yishayw]

Example app [1]

[1] https://paste.apache.org/hdOl



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-DataBinding-Problem-tp62073p62078.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Private properties are undefined in JS and null in AS

[justin]

Hi,

>> What is the point of initializing properties if there is a guarantee that
>> they'll be initialized in other code before it is ever tested.  Code like:
>> 
>> var foo:String;
>> if (someCondition)
>> foo = "bar";
>> else
>> foo = "foo”;
> 
> Could be optimised away by the compiler.

And looks like this is currently likely.

For instance this code:

test = function() {
var foo = 'hello';
var cond = true;
if (cond)
 foo = 'bar';
else
 foo = 'foo';

 console.log(foo);
}
test();

Gets optimised to:
test=function(){console.log("bar")};test();

So there’s no cost in this case for the initial assignment and the variable 
doesn’t even exists in the final result. In more complex code you’ll probably 
get something different.

Thanks,
Justin

Re: dual issues

[Harbs]

I’m seeing similar times using both ant and asconfig for debug. (Both are good.)

asconfig is not compiling a release build at all — even if I specify 
debug=false.

I have not tried with Maven.

> On Jun 4, 2017, at 12:06 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Justin you are compiling by Maven ?
> 
> Yep and Debug builds are noticeably slower for me.
> 
> Justin

Re: dual issues

[Justin Mclean]

Hi,

> Justin you are compiling by Maven ?

Yep and Debug builds are noticeably slower for me.

Justin

Re: git commit: [flex-asjs] [refs/heads/tlf] - Temp fix for labels of accordion not working.

[Harbs]

This fix should not be necessary.

It looks like binding is broken.

Changing the model causes the titleChange event to not be caught by the view. 
This used to work.

> On Jun 4, 2017, at 12:02 PM, Piotr Zarzycki  wrote:
> 
> Hi Yishay,
> 
> I think those changes probably should be propagated also to release branch.
> 
> Piotr
> 
> 2017-06-04 10:51 GMT+02:00 :
> 
>> Repository: flex-asjs
>> Updated Branches:
>>  refs/heads/tlf 65c599330 -> 608a7b91e
>> 
>> 
>> Temp fix for labels of accordion not working.
>> 
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/608a7b91
>> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/608a7b91
>> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/608a7b91
>> 
>> Branch: refs/heads/tlf
>> Commit: 608a7b91e4742b53a93f8a09037a75f5a8df57a3
>> Parents: 65c5993
>> Author: DESKTOP-RH4S838\Yishay 
>> Authored: Sun Jun 4 11:50:37 2017 +0300
>> Committer: DESKTOP-RH4S838\Yishay 
>> Committed: Sun Jun 4 11:50:37 2017 +0300
>> 
>> --
>> .../org/apache/flex/html/supportClasses/AccordionItemRenderer.as | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>> --
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
>> 608a7b91/frameworks/projects/Basic/src/main/flex/org/apache/flex/html/
>> supportClasses/AccordionItemRenderer.as
>> --
>> diff --git a/frameworks/projects/Basic/src/main/flex/org/apache/flex/
>> html/supportClasses/AccordionItemRenderer.as b/frameworks/projects/Basic/
>> src/main/flex/org/apache/flex/html/supportClasses/AccordionItemRenderer.as
>> index e1e4b0d..b720f47 100644
>> --- a/frameworks/projects/Basic/src/main/flex/org/apache/flex/
>> html/supportClasses/AccordionItemRenderer.as
>> +++ b/frameworks/projects/Basic/src/main/flex/org/apache/flex/
>> html/supportClasses/AccordionItemRenderer.as
>> @@ -22,6 +22,7 @@ package org.apache.flex.html.supportClasses
>>import org.apache.flex.core.ISelectableItemRenderer;
>>import org.apache.flex.core.IStrand;
>>import org.apache.flex.core.ITitleBarModel;
>> +   import org.apache.flex.events.Event;
>>import org.apache.flex.html.Panel;
>>import org.apache.flex.html.TitleBar;
>>import org.apache.flex.html.beads.PanelView;
>> @@ -114,7 +115,8 @@ package org.apache.flex.html.supportClasses
>>var dataTitleModel:ITitleBarModel =
>> dataAsStrand.getBeadByType(ITitleBarModel) as ITitleBarModel;
>>if (dataTitleModel)
>>{
>> -   titleBar.model = dataTitleModel;
>> +// titleBar.model = dataTitleModel;
>> +   titleBar.title =
>> dataTitleModel.title; // temp fix. The line above should be swapoped with
>> this one once databinding works.
>>}
>>}
>>}
>> 
>> 

[FlexJS] DataBinding Problem

[yishayw]

Trying to debug accordion I ran into a data binding issue. 

TitleBarView.mxml has this line:

 

But if I change the model to a tbModel where tbModel.title == "hi" I will
not the label text is empty instead of it being 'hi'. 

In other words, data binding only works if the host stays the same.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-DataBinding-Problem-tp62073.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: dual issues

[Harbs]

To be clear:
Debug builds are as fast if not faster than they used to be.
Release build are much slower.

I’m getting a debug build (with remove circulars) of my (complex) app taking 
about 10 seconds.
The release build takes about 3 minutes.


> On Jun 4, 2017, at 11:57 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Bad news: It takes much longer than it used to, and I’m getting a swf file 
>> even though I’m only using -targets=JSFlex
> 
> Compiles are also taking a lot longer for me and I’m also only using the 
> JSFlex target.
> 
> Thanks,
> Justin

Re: dual issues

[piotrz]

As I remember Harbs is compiling it by ANT ? Am I right ? Justin you are
compiling by Maven ?

Piotr



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

Re: dual issues

[Justin Mclean]

Hi,

> Bad news: It takes much longer than it used to, and I’m getting a swf file 
> even though I’m only using -targets=JSFlex

Compiles are also taking a lot longer for me and I’m also only using the JSFlex 
target.

Thanks,
Justin

Re: Private properties are undefined in JS and null in AS

[Justin Mclean]

Hi,

> Well I like what Justin did in case of css and some other changes. It seems
> be performance improver, but please do not make changes more till people who
> has real world app like Harbs do not give some feedback whether there are
> not breaking changes.

I’m using a application in production and those changes are working fine for me.

Anyone else seen any issues with them? If there are any issues I’m happy to fix 
them.

If you use develop over the past couple of week you would of been using them.

Thanks,
Justin

Re: Private properties are undefined in JS and null in AS

[Justin Mclean]

Hi,

> Here is a link [1] to you saying "I’m a strong believer in getting it to
> work first, then optimise it, premature optimisation wastes time and often
> makes incorrect assumptions.”

That’s exactly what I’m doing. I has something that works and I want to improve 
the performance. 

I’d say making something working 5x as fast, with no other costs, is hardly 
premature optimisation. You’re milage of cause may vary.

> Manually trying to determine whether to use "==" or "===" might be
> better left to tooling someday, so folks don't have to worry about it and
> can just get their features to work first.

Folk will run into this issue right away. Most JS devs use == and !== and !== 
instead often evil twins != and ==. 

The current behaviour will confuse people as code that works on JS will work 
differently in AS and vice versa.

> I'd personally lean towards warning when folks use JS patterns that can cause 
> trouble.

What patterns in particular are you referring to here? Sonar cube is waring 
about issues in our AS code not JS code.

> For uninitialized references to instances, maybe
> leaving it uninitialized and using "== null" is best.

Unlikely as it’s between 2x and 10x as slow and using == null as opposed to === 
null can have unexpected results.

> What is the point of initializing properties if there is a guarantee that
> they'll be initialized in other code before it is ever tested.  Code like:
> 
> var foo:String;
> if (someCondition)
> foo = "bar";
> else
> foo = "foo”;

Could be optimised away by the compiler.

> Ints are initialized to zero because the common patterns fail if you
> don't, not just because of "==" tests.

And I think we have the same issue with Booleans and perhaps Numbers.

> But there might be other ways to end up with
> better code than manually scrubbing the source.

Like what? Please provide data an/or examples and/or facts over option please.

Thanks,
Justin

Re: dual issues

[piotrz]

Ahh..That's not good. Another thing for resolve in release definitly.

Piotr



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

Re: dual issues

[Harbs]

Good news: Prior to the switch to dual, I was not getting a minified release 
build working. That’s now working.
Bad news: It takes much longer than it used to, and I’m getting a swf file even 
though I’m only using -targets=JSFlex

Harbs

Re: Private properties are undefined in JS and null in AS

[piotrz]

Well I like what Justin did in case of css and some other changes. It seems
be performance improver, but please do not make changes more till people who
has real world app like Harbs do not give some feedback whether there are
not breaking changes.

>From the developer point of view and as an more Flex developer than
JavaScript I doubt that in my application code I will be remember about
giving "===" almost every time. I will probably mostly use "==". 

I'm waiting till release cause those changes are not for 0.8.0. Once we
merge release branch to develop and have 0.9.0 I will test my real world
app. - If it behave differently cause of this I will vote for revert.

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Private-properties-are-undefined-in-JS-and-null-in-AS-tp62033p62064.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: dual issues

[Harbs]

Objects like Promise, Map, Set etc. are available by default in pretty much all 
modern browsers.

Things like await, arrow functions, let, etc. are being added by browsers all 
the time. I’m not sure exactly which ones have what right now, but they are 
pretty far along already, so that article is already out of date. ;-)

Either way, we’re not outputting ES6-style code (currently), so those features 
are a non-issue.

> On Jun 4, 2017, at 10:34 AM, Alex Harui  wrote:
> 
> I thought es6 wasn't always on by default?
> 
> https://thenextweb.com/dd/2016/03/09/6-reasons-need-learn-javascript-es6-no
> w-not-later/#.tnw_5KKUOOPX
> 
> I haven't been paying attention so maybe all browsers are fully compliant
> now?
> 
> -Alex
> 
> On 6/4/17, 12:01 AM, "Harbs"  wrote:
> 
>> Not sure what you mean here.
>> 
>>> On Jun 4, 2017, at 8:52 AM, Alex Harui  wrote:
>>> 
>>> Does FlexJS emit the right code to enable es6 APIs?
>> 
> 

Re: dual issues

[Alex Harui]

I thought es6 wasn't always on by default?

https://thenextweb.com/dd/2016/03/09/6-reasons-need-learn-javascript-es6-no
w-not-later/#.tnw_5KKUOOPX

I haven't been paying attention so maybe all browsers are fully compliant
now?

-Alex

On 6/4/17, 12:01 AM, "Harbs"  wrote:

>Not sure what you mean here.
>
>> On Jun 4, 2017, at 8:52 AM, Alex Harui  wrote:
>> 
>> Does FlexJS emit the right code to enable es6 APIs?
>

Re: [FlexJS] Release Branch Not Building

[yishayw]

False alarm, I wasn't using the latest falcon. Apologize for the noise.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Release-Branch-Not-Building-tp62057p62061.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Private properties are undefined in JS and null in AS

[Alex Harui]

Here is a link [1] to you saying "I’m a strong believer in getting it to
work first, then optimise it, premature optimisation wastes time and often
makes incorrect assumptions."

This is an interesting topic, but I want to make sure this isn't premature
optimizing.  And me, I just want to get it to work and get a release out.

IMO, the key to success for Flex is developer productivity.  Because we
have a couple of compilers in the workflow (FalconJX and Google Closure
Compiler), we have a couple of chances to make good small code that runs
well.  Manually trying to determine whether to use "==" or "===" might be
better left to tooling someday, so folks don't have to worry about it and
can just get their features to work first.  I don't want to tell folks,
"sorry, we don't have AMF support yet, but we've made sure we've used
strict equality!".

IMO, if folks can be more productive by using common patterns and we can
generate better code, then everybody wins.  I'd personally lean towards
warning when folks use JS patterns that can cause trouble.  JS lets you do
lots of things and the value undefined can get you in a lot of trouble,
but AS lets you do fewer things that can get you in trouble.  Undefined is
only allowed for type '*' for example.  So if we can know that a string
can't be null, then maybe the compiler should always generate "===" even
if you wrote "==".  For uninitialized references to instances, maybe
leaving it uninitialized and using "== null" is best.  Or maybe there
isn't a right answer and folks will want compiler options to generate
better code.  AS gives us real type information.

What is the point of initializing properties if there is a guarantee that
they'll be initialized in other code before it is ever tested.  Code like:

var foo:String;
if (someCondition)
  foo = "bar";
else
  foo = "foo";

Ints are initialized to zero because the common patterns fail if you
don't, not just because of "==" tests.

There are articles about JavaScript type inferencing in V8 and WebAssembly
is sort of implying something similar if I understand it correctly so type
"annotation" may eliminate some of the need to choose between "==" and
"===".

Sounds like the CSS code, which does use '*' could be improved by not
using "==" so much.  And that in many cases string compares can be faster
with "===".  That's great.  But there might be other ways to end up with
better code than manually scrubbing the source.

Of course, I could be wrong...
-Alex

[1] 
http://mail-archives.apache.org/mod_mbox/flex-dev/201703.mbox/%3cDB1BB6CD-B
373-4d82-8b72-6491a306f...@classsoftware.com%3e

On 6/3/17, 6:40 PM, "Justin Mclean"  wrote:

>Hi,
>
>So here’s some data for you:
>
>In string_old.js:
>
>var s;
>
>for (var i = 0; i < 1e8; i++) {
>if (s == "") {
>}
>}
>
>In string.js:
>
>var s = "";
>
>for (var i = 0; i < 1e8; i++) {
>if (s === "") {
>}
>}
>
>time node string.js
>real   0m0.246s
>user   0m0.114s
>sys0m0.046s
>
>time node string_old.js
>real   0m2.496s
>user   0m2.452s
>sys0m0.019s
>
>The === and setting to “" is an order of magnitude faster (in node
>anyway), similar results with initialising to null rather than “”.
>
>Running similar code (converted to AS ) through the chrome profiler gives
>results where setting to null and using === is faster.
>
>It even twice as fast if you initialise the variable and compare on every
>time through the loop. So 1e8 lots = null and a === is faster than no
>initialisation and a ==.
>
>I think what is happening currently is that because we are not
>initialising the variable it’s doing a implicit cast on every every
>comparison that is very expensive when using != and ==, using === and !==
>significantly speeds this up but then you have the issues of uninitialise
>strings and objects being null in AS and undefined in JS but it still
>twice as fast.
>
>BTW I do note that we are setting ints to 0. I assume because of similar
>reasons? But it seems you were not concerned with the overhead of this?
>
>Thanks,
>Justin

Re: dual issues

[Harbs]

Not sure what you mean here.

> On Jun 4, 2017, at 8:52 AM, Alex Harui  wrote:
> 
> Does FlexJS emit the right code to enable es6 APIs?

Re: [FlexJS] Release Branch Not Building

[Alex Harui]

Looks like the "all" target doesn't support being in a release branch.  It
will try to use the "develop" branch of flex-falcon.

I would suggest switching your flex-falcon working copy to its
release0.8.0 branch, run "ant wipe-all".  Then try "ant all" in flex-asjs
again.

-Alex

On 6/3/17, 11:07 PM, "yishayw"  wrote:

>When doing ant clean all I get
>
>compile:
> [echo] Compiling libs/Language.swc
> [echo] FLEX_HOME: C:\dev\flexjs\flex-asjs
> [echo] FALCON_HOME: C:\dev\flexjs\flex-asjs/../flex-falcon/compiler
> [echo] FALCONJX_HOME:
>C:\dev\flexjs\flex-asjs/../flex-falcon/compiler-jx
> [java] Exception in thread "main"
>java.lang.UnsupportedOperationException
> [java] at
>org.apache.flex.compiler.internal.driver.as.ASBackend.getSourceFileHandler
>Instance(ASBackend.java:72)
> [java] at
>org.apache.flex.compiler.clients.MXMLJSC.(MXMLJSC.java:260)
> [java] at
>org.apache.flex.compiler.clients.COMPJSC.(COMPJSC.java:167)
> [java] at
>org.apache.flex.compiler.clients.COMPJSC.staticMainNoExit(COMPJSC.java:155
>)
> [java] at
>org.apache.flex.compiler.clients.COMPJSC.main(COMPJSC.java:109)
> [java] Java Result: 1
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Release-Branch-Not-Building-t
>p62057.html=02%7C01%7C%7C412a34fc95734aa0601008d4ab12143c%7Cfa7b1b5a7
>b34438794aed2c178decee1%7C0%7C0%7C636321541539181037=OEpSYZcOMPoUzHz
>A4spfZR2l%2FFK62sEFN000pA7n3qE%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

[FlexJS] Release Branch Not Building

[yishayw]

When doing ant clean all I get

compile:
 [echo] Compiling libs/Language.swc
 [echo] FLEX_HOME: C:\dev\flexjs\flex-asjs
 [echo] FALCON_HOME: C:\dev\flexjs\flex-asjs/../flex-falcon/compiler
 [echo] FALCONJX_HOME:
C:\dev\flexjs\flex-asjs/../flex-falcon/compiler-jx
 [java] Exception in thread "main"
java.lang.UnsupportedOperationException
 [java] at
org.apache.flex.compiler.internal.driver.as.ASBackend.getSourceFileHandlerInstance(ASBackend.java:72)
 [java] at
org.apache.flex.compiler.clients.MXMLJSC.(MXMLJSC.java:260)
 [java] at
org.apache.flex.compiler.clients.COMPJSC.(COMPJSC.java:167)
 [java] at
org.apache.flex.compiler.clients.COMPJSC.staticMainNoExit(COMPJSC.java:155)
 [java] at
org.apache.flex.compiler.clients.COMPJSC.main(COMPJSC.java:109)
 [java] Java Result: 1



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Release-Branch-Not-Building-tp62057.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.