Finding tools in the toolbox

[Harbs]

One of the most difficult part of dealing with FlexJS and beads is knowing what 
beads are available and what beads are interchangeable.

I think we need a system to programmatically be able to look up bead and strand 
relationships. This could be used by documentation as well as tooling to give 
hints as to what beads to use.

I think there’s been some discussion already on this, but I’m kind of fuzzy and 
it probably needs some more.

Harbs

Re: [FlexJS] Removing PasswordInputBead has no effect

[Harbs]

We’ve all already been implementing things as Alex states. He architected the 
framework and it’s a good architecture. No need to change things. We need 
consistent architecture. We can’t have a free-for-all...

Percentage of code really has nothing to do with it. Unless something is 
functionality that you would (virtually) always need, it’s a separate bead. 
That’s the way the whole SDK is implemented. If there are cases where it’s not, 
it’s a bug and should be fixed. Removal of password functionality is NOT 
usually required for password beads.

PAYG is already well understood: All functionality should be implemented as 
beads when practical. Beads should be as modular as possible with the smallest 
possible functional set.

That’s pretty much it. It’s difficult to make the mental switch to working this 
way. I had similar difficulty when I started implementing things for FlexJS. It 
takes some getting used to, but it’s a very good design.

Harbs

> On Jun 6, 2017, at 1:16 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> If you have a different vision, you can execute that vision in another
>> component set or fork FlexJS entirely.  Please do not impose your vision
>> on my vision.
> 
> Since when is this your project Alex or that the project has to only include 
> your vision? That is not the Apache way.
> 
> I would prefer that we all come to a consensus of what PAYG means and clearly 
> document it rather that you dictating it.
> 
> Thanks,
> Justin

Re: [FlexJS] Removing PasswordInputBead has no effect

[piotrz]

Another thing - How to resolve this thread ?

1) Setting strand to null - let say that is fine and there is no NO for that
- Am I right ?
2) Some code which maybe can be extracted to separate bead.

For 2 I have an ide:
1 - Revert back
2 - Create Separate bead for cleaning 
3 - Create in Express bead which has everything what Justin add.

Would it be satisfactory ? 

Piotr



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

Re: [FlexJS] Removing PasswordInputBead has no effect

[piotrz]

+1 for documenting it and stick with it. 



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Removing-PasswordInputBead-has-no-effect-tp62092p62128.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 Mclean]

Hi,

> Are you using a Sonar Cube plugin for ActionScript?  Using a JS review of
> AS is likely to be inaccurate, IMO.

It’s AS see [1]

> it may turn out that at runtime, there is no difference
> between "==" and "===" for ints.

For int the is less of a difference but as discussed it depends if JS knows 
there are ints on both sides or not. Given that int are defaulting to 0 it’s 
unlikely to be an issue for AS code involving ints.

Thanks,
Justin

1. https://builds.apache.org/analysis/overview?id=20942

Re: [FlexJS] Removing PasswordInputBead has no effect

[Justin Mclean]

Hi,

> If you have a different vision, you can execute that vision in another
> component set or fork FlexJS entirely.  Please do not impose your vision
> on my vision.

Since when is this your project Alex or that the project has to only include 
your vision? That is not the Apache way.

I would prefer that we all come to a consensus of what PAYG means and clearly 
document it rather that you dictating it.

Thanks,
Justin

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

[Justin Mclean]

Hi,

> I believe in AS, there is no way to have
> 
>   if (b === false)
> 
> Have any semantically different meaning than
> 
>   if (b)

One will check for false the other true so they have opposite meaning. You'll 
also note I stated “b == false” not “b === false”. 

Currently for an uninitialised variable b == false will equal true on AS but 
false on JS

> This latter pattern is fastest and smallest.  If we ever add optimizing to
> the compiler, it might the first pattern to the latter.

I hope not as it will produce a lot of errors.

You’ll also need to consider b == condition where the condition evaluates to 
false but b is undefined, again you will get the result of true on AS and false 
on JS.

Thanks,
Justin

Re: [FlexJS] DataBinding Problem

[piotrz]

Hi Yishay,

I did spent some time on this but cannot find so far why binding is not
working after model change. I think it should be. 

There is SimpleBinding class involve in all of this. Array _bindings [1]
seems to contains everything what needed, but maybe we should react
somewhere on "modelChanged" event. 

But where ? Changing model on the fly should reflected into refreshing in
somehow binding.

The only thing which I noticed that when I'm assigning new model [2], it's
being added as bead but the old one is not removed. Basically when you do
this one:

pv.titleBar.model = new TitleBarModel(); - You will have many models in
_beads Array.

Not sure if it is ok.

[1] https://paste.apache.org/SsO4
[2] https://paste.apache.org/Efit

Piotr



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

Re: [FlexJS] List

[Peter Ent]

Yes. I think people expect lists to scroll by default. Sorry I missed that
when I made those changes.
—peter

On 6/5/17, 1:43 PM, "Harbs"  wrote:

>That’s what I did for my app css. Changing it to ScrollingViewport fixed
>it.
>
>I did not know whether I should change defaults.css in Basic. It sounds
>like you are saying yes.
>
>> On Jun 5, 2017, at 5:25 PM, Peter Ent  wrote:
>> 
>> That had to be accidental. I see in defaults.css that List has a
>>Viewport
>> rather than ScrollingViewport. Just change that and lists should default
>> to scrolling.
>> 
>> Need to watch the DataGrid because its lists should not scroll - they
>>just
>> grow and the enclosing container scrolls them all together.
>> 
>> ‹peter
>> 
>> On 6/5/17, 3:01 AM, "Harbs"  wrote:
>> 
>>> It looks like List defaults to overflow: hidden while it used to allow
>>> scrolling by default.
>>> 
>>> Was this an intentional change?
>> 
>

Re: dual issues

[Harbs]

In compilerOptions.

Here’s my tasks.json file:
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "0.1.0",
"command": "asconfigc",
"isShellCommand": true,
"args": [
"--flexHome=/FlexSDK/FlexJSNightly"
],
"windows": {
"args": [
"--flexHome=C:\\dev\\flexjs_builds\\nightly_07"
]
},
"showOutput": "always"
}

asconfig.json:
{
"config": "flex",
"compilerOptions": {
"debug": true,
"targets": ["JSFlex"],
"source-map": false,
"library-path": [
"lib"
],
"external-library-path": [
"typedefs"
]
},
"copySourcePathAssets": true,
"additionalOptions": "-remove-circulars 
-js-output-optimization=skipAsCoercions 
-html-template=src/resources/mdl-js-index-template.html 
-js-external-library-path+=typedefs -js-library-path+=lib",
"files":
[
"src/PortedPrintUI.mxml"
]
}

I’m having other issues after switching to dual as well. Maybe I should show 
you…

Harbs

> On Jun 5, 2017, at 4:31 PM, Josh Tynjala  wrote:
> 
> Are you setting debug in an argument passed to asconfigc, like this?
> 
> asconfigc --debug=false
> 
> Or is it specified in asconfig.json in the compilerOptions section?
> 
> Both will work, but the asconfigc command line option will always override
> whatever is in asconfig.json. In VSCode, the generated tasks.json now
> defaults to --debug=true, so that could take precedence if you're trying to
> set debug to false in asconfig.json. You might want to double-check both
> locations (asconfig.json and tasks.json).
> 
> - Josh
> 
> On Sun, Jun 4, 2017 at 2:08 AM, Harbs  wrote:
> 
>> 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
>> 
>> 

Odgovor: [3/3] git commit: [flex-asjs] [refs/heads/develop] - set input type back to text when bead is removed

[Silvije Mudri]

 Bok na.  

Poslano s pametnog telefona BlackBerry 10.
  Originalna poruka  
Šalje: Piotr Zarzycki
Poslano: ponedjeljak, 5. lipnja 2017. 17:26
Prima: dev@flex.apache.org
Odgovor za: dev@flex.apache.org
Predmet: Re: [3/3] git commit: [flex-asjs] [refs/heads/develop] - set input 
type back to text when bead is removed

Hi Justin,

Can it be close as part of separate bead ? What actually are you doing here
?

Piotr

2017-06-05 5:19 GMT+02:00 :

> set input type back to text when bead is removed
>
>
> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/0d696541
> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/0d696541
> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/0d696541
>
> Branch: refs/heads/develop
> Commit: 0d69654163d8fe0ae7d027f027fa06bb7d71f4bd
> Parents: 385655a
> Author: Justin Mclean 
> Authored: Mon Jun 5 13:17:04 2017 +1000
> Committer: Justin Mclean 
> Committed: Mon Jun 5 13:17:04 2017 +1000
>
> --
> .../flex/html/accessories/PasswordInputBead.as | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> 0d696541/frameworks/projects/Basic/src/main/flex/org/
> apache/flex/html/accessories/PasswordInputBead.as
> --
> diff --git a/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> html/accessories/PasswordInputBead.as b/frameworks/projects/Basic/
> src/main/flex/org/apache/flex/html/accessories/PasswordInputBead.as
> index e73822b..4312100 100644
> --- a/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> html/accessories/PasswordInputBead.as
> +++ b/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> html/accessories/PasswordInputBead.as
> @@ -68,17 +68,27 @@ package org.apache.flex.html.accessories
> */
> public function set strand(value:IStrand):void
> {
> - _strand = value;
> -
> COMPILE::SWF
> {
> + _strand = value;
> IEventDispatcher(value).
> addEventListener("viewChanged",viewChangeHandler);
> }
> COMPILE::JS
> {
> - var host:UIBase = value as UIBase;
> - var e:HTMLInputElement = host.element as
> HTMLInputElement;
> - e.type = 'password';
> + var host:UIBase;
> + var e:HTMLInputElement;
> +
> + if (value !== null) {;
> + host = value as UIBase;
> + e = host.element as
> HTMLInputElement;
> + e.type = 'password';
> + }
> + else {
> + host = _strand as UIBase;
> + e = host.element as
> HTMLInputElement;
> + e.type = 'text';
> + }
> + _strand = value;
> }
> }
>
>
>

Re: [FlexJS] Removing PasswordInputBead has no effect

[piotrz]

Hi,

Ahh I saw your commit and respond to it, but somehow miss this discussion.
It seems to be again different thoughts and view of what is PAYG.

PAYG for me is:
Whenever I can extract something (code - one thing) into separate class
called - Bead - which can be reusable or switch ON/OFF something in my
component.

The question is: Can you extract this part of code into separate class ? 

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Removing-PasswordInputBead-has-no-effect-tp62092p62116.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]

On 6/4/17, 1:52 AM, "Justin Mclean"  wrote:

>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.

I think everyone is supporting your work dealing with "*" in the CSS code.
 I haven't looked into it in detail myself, but * is where undefined is
allowed in AS so it makes sense in principle.  But I'm not sure there is a
need to manually scrub places in AS where undefined is not allowed.
Changing the compiler output might be the better option.  The data you've
provided so far in that regard is helpful though.
>
>> 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.

Are you using a Sonar Cube plugin for ActionScript?  Using a JS review of
AS is likely to be inaccurate, IMO.

>
>> 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.

I don't remember seeing your test for this.  Can you post it again (or a
link to the original)?

>> 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.

Again, think of the allowed patterns when coming from AS, not all possible
JS patterns.
>
>> 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.

[1] mentions hidden classes.  If we can make sure our code leverages these
hidden classes, it may turn out that at runtime, there is no difference
between "==" and "===" for ints.

Thanks,
-Alex

[1] https://www.html5rocks.com/en/tutorials/speed/v8/

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

[Alex Harui]

Sounds like there is no one right answer, so we should offer choices in
compiler output.

To me, if there are valid and common AS coding patterns that don't require
initialization, I would happily use them and make changes where warnings
detect unsafe usage.

IOW, for

var b:Boolean;

I believe in AS, there is no way to have

if (b === false)

Have any semantically different meaning than

if (b)

This latter pattern is fastest and smallest.  If we ever add optimizing to
the compiler, it might the first pattern to the latter.

IMO, we are not here to be able to reproduce every line of JS ever written
by writing AS, we are purposefully limiting the kinds of JS you can write
by making you use AS, so you don't screw yourself over and have improved
developer productivity.  We won't let you assign types that mismatch, or
have the wrong number of parameters.

So once you agree that we only want to support AS semantics in JS, then we
can see where we must initialize, and where we might want to offer options.

My 2 cents,
-Alex

On 6/4/17, 6:38 PM, "Josh Tynjala"  wrote:

>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: [3/3] git commit: [flex-asjs] [refs/heads/develop] - set input type back to text when bead is removed

[Piotr Zarzycki]

Hi Justin,

Can it be close as part of separate bead ? What actually are you doing here
?

Piotr

2017-06-05 5:19 GMT+02:00 :

> set input type back to text when bead is removed
>
>
> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/0d696541
> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/0d696541
> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/0d696541
>
> Branch: refs/heads/develop
> Commit: 0d69654163d8fe0ae7d027f027fa06bb7d71f4bd
> Parents: 385655a
> Author: Justin Mclean 
> Authored: Mon Jun 5 13:17:04 2017 +1000
> Committer: Justin Mclean 
> Committed: Mon Jun 5 13:17:04 2017 +1000
>
> --
>  .../flex/html/accessories/PasswordInputBead.as  | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> 0d696541/frameworks/projects/Basic/src/main/flex/org/
> apache/flex/html/accessories/PasswordInputBead.as
> --
> diff --git a/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> html/accessories/PasswordInputBead.as b/frameworks/projects/Basic/
> src/main/flex/org/apache/flex/html/accessories/PasswordInputBead.as
> index e73822b..4312100 100644
> --- a/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> html/accessories/PasswordInputBead.as
> +++ b/frameworks/projects/Basic/src/main/flex/org/apache/flex/
> html/accessories/PasswordInputBead.as
> @@ -68,17 +68,27 @@ package org.apache.flex.html.accessories
>  */
> public function set strand(value:IStrand):void
> {
> -   _strand = value;
> -
> COMPILE::SWF
> {
> +   _strand = value;
> IEventDispatcher(value).
> addEventListener("viewChanged",viewChangeHandler);
> }
> COMPILE::JS
> {
> -   var host:UIBase = value as UIBase;
> -   var e:HTMLInputElement = host.element as
> HTMLInputElement;
> -   e.type = 'password';
> +   var host:UIBase;
> +   var e:HTMLInputElement;
> +
> +   if (value !== null) {;
> +   host = value as UIBase;
> +   e = host.element as
> HTMLInputElement;
> +   e.type = 'password';
> +}
> +   else {
> +   host = _strand as UIBase;
> +   e = host.element as
> HTMLInputElement;
> +e.type = 'text';
> +}
> +   _strand = value;
> }
> }
>
>
>

Re: [FlexJS] Removing PasswordInputBead has no effect

[Alex Harui]

On 6/4/17, 9:46 PM, "Justin Mclean"  wrote:

>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?

Since November of 2012, my vision has been to make it possible to
eliminate all just-in-case code from a FlexJS customer's application.
Sure, that may not be 100% achievable, but I want everyone to be role
models for how this is attempted.  No matter how you measure it, you have
added just-in-case code for those who don't need to remove the
PasswordInputBead.  The vision has been to offer customers choices of
beads.

If we instead model that we can ignore this vision and just add 7% or 2%,
we will just be repeating the same mistake we made in regular Flex and
over time, FlexJS will be just as fat and slow as regular Flex.  I can't
tell you how many times we said in regular Flex "this is only adds a
little bit of code".  But when customers started rejecting Flex because it
couldn't run as fast and small as they needed, we lost our chance to be
part of solutions that people couldn't live without.

If you have a different vision, you can execute that vision in another
component set or fork FlexJS entirely.  Please do not impose your vision
on my vision.

Thanks,
-Alex

Re: [FlexJS] Layout of NumericStepper is broken

[Alex Harui]

Run the FlexJSStore example and go to the Products tab.  NumericStepper
looks fine to me there.

-Alex

On 6/5/17, 7:49 AM, "piotrz"  wrote:

>Hi Peter,
>
>It is Windows 10 and Chrome 59.0.3071.82
>I tried also on Firefox: 53.0.3 (32 bits)
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Layout-of-NumericStepper-is-b
>roken-tp62108p62110.html=02%7C01%7C%7Cbda19d424c0b45a9d60508d4ac2432c
>4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636322718850362569=nW
>1D5fHhhRvqVe40HWaEaJgnvRfofBb8Ejw8B1q2dh4%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Layout of NumericStepper is broken

[piotrz]

Hi Peter,

It is Windows 10 and Chrome 59.0.3071.82
I tried also on Firefox: 53.0.3 (32 bits)

Piotr



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

Re: [FlexJS] Layout of NumericStepper is broken

[Peter Ent]

I'm looking into it. The SWF and JS versions are different. There's a
border around it, which is specified in the defaults.css. I'm not sure why
that is there; maybe I put it there awhile ago I just don't remember. It
looks better without it.

The SWF version, for me, has some extra graphics in the incrementing
button and the JS version has the buttons just slightly misaligned with
the input field. Running this on macOS Sierra, Safari 10.1.1, Firefox
50.0.3, and Chrome 58.0.3.

on which OS(es) and browser(s) are you seeing this?

‹peter

On 6/5/17, 10:31 AM, "piotrz"  wrote:

>Hi,
>
>I just tried NumericStepper on our release branch and it looks horrible. I
>have following code [1], can someone look into that ? I will raise jira
>later.
>
>ex-development.247.n4.nabble.com%2Ffile%2Fn62108%2Fbroken_numeric_step
>per.png=02%7C01%7C%7Cccc8644d5a054e8cd1e508d4ac21a197%7Cfa7b1b5a7b344
>38794aed2c178decee1%7C0%7C0%7C636322707827257340=uLxglwUpmvJYZRzMtXF
>iAi0W65ytuPaVL1DxfVYBCUo%3D=0>
>
>[1] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2FwbLN=02%7C01%7C%7Cccc8644d5a054e8cd1e508d4ac21a197%7Cfa7b1b
>5a7b34438794aed2c178decee1%7C0%7C0%7C636322707827257340=8wSGQeRReell
>5enJgXlniYVCvf9Jq0OQazKyfksWBdI%3D=0
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Layout-of-NumericStepper-is-b
>roken-tp62108.html=02%7C01%7C%7Cccc8644d5a054e8cd1e508d4ac21a197%7Cfa
>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636322707827257340=VESRAJBK
>DR%2FiSQd6M3xC7tB78jqMEgq%2Bh%2BPPMfj7f%2FM%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

[FlexJS] Layout of NumericStepper is broken

[piotrz]

Hi,

I just tried NumericStepper on our release branch and it looks horrible. I
have following code [1], can someone look into that ? I will raise jira
later.


 

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

Piotr



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

Re: [FlexJS] List

[Peter Ent]

That had to be accidental. I see in defaults.css that List has a Viewport
rather than ScrollingViewport. Just change that and lists should default
to scrolling.

Need to watch the DataGrid because its lists should not scroll - they just
grow and the enclosing container scrolls them all together.

‹peter

On 6/5/17, 3:01 AM, "Harbs"  wrote:

>It looks like List defaults to overflow: hidden while it used to allow
>scrolling by default.
>
>Was this an intentional change?

Re: [FlexJS] Accordion broken

[Peter Ent]

I haven't sync'd anything since Friday, but I don't seem to be having the
measurement problem you are talking about.

I changed the Accordion children to VContainer and added the
TitleBarModel. Now I see the TitleBar (although it is blank) and the
segment contents. When I expose or hide the segments, I see all of the
bars stacked above and below the opened segment.

On SWF, the title bars are blank; on HTML the title bars are "undefined"
(as expected and noted in another thread on null vs undefined).

—peter

On 6/4/17, 5:57 AM, "Harbs"  wrote:

>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, 

Re: dual issues

[Josh Tynjala]

Are you setting debug in an argument passed to asconfigc, like this?

asconfigc --debug=false

Or is it specified in asconfig.json in the compilerOptions section?

Both will work, but the asconfigc command line option will always override
whatever is in asconfig.json. In VSCode, the generated tasks.json now
defaults to --debug=true, so that could take precedence if you're trying to
set debug to false in asconfig.json. You might want to double-check both
locations (asconfig.json and tasks.json).

- Josh

On Sun, Jun 4, 2017 at 2:08 AM, Harbs  wrote:

> 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
>
>

Fwd: [jira] [Updated] (FLEX-35321) LayoutManager initializes components which are no longer on stage

[Mihai Chira]

Hi all, I just want to make sure that my assumptions about LayoutManager
are sound. This behavior (which I would personally catalogue as a bug) is
causing our application some problems: dialogues initialised after they've
been removed from stage, thus triggering their mediators' onRegister method
(via RobotLegs), which try to work with data that's no longer there,
resulting in fatal errors.

Thanks.
-- Forwarded message --
From: "Mihai Chira (JIRA)" 
Date: 5 Jun 2017 14:00
Subject: [jira] [Updated] (FLEX-35321) LayoutManager initializes components
which are no longer on stage
To: 
Cc:


 [ https://issues.apache.org/jira/browse/FLEX-35321?page=
com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mihai Chira updated FLEX-35321:
---
Description:
*Scenario A*: during an object's validation cycle some code resulting from
{{validateSize()}}, {{validateProperties()}} or {{validateDisplayList()}}
results in the object's removal from stage.

*Scenario B*: a user performs an action whose effect is the removal of a
component, exactly when that component is being validated in phases
({{LayoutManager.usePhasedInstantiation == true}}, which is to say, in the
span of two-three frames.
(For the unit test that models this scenario.)



*Expected behaviour*: {{LayoutManager}} detects the object's removal from
stage, stops validating it, and never sets its {{initialized}} flag to
{{true}}.
*Actual behaviour*: {{LayoutManager}} does not detect the object's removal
from stage, continues validating it, and ends up setting the object's
{{initialized}} flag to {{true}}.
*Unit test*: {{LayoutManager_FLEX_35321_Tests}}.

  was:
*Scenario A*: during an object's validation cycle some code resulting from
{{validateSize()}}, {{validateProperties()}} or {{validateDisplayList()}}
results in the object's removal from stage.

*Scenario B*: a user performs an action whose effect is the removal of a
component, exactly when that component is being validated in phases
({{LayoutManager.usePhasedInstantiation == true}}, which is to say, in the
span of two-three frames.
(For the unit test that models this scenario, see {{LayoutManagerTests}}.)



*Expected behaviour*: {{LayoutManager}} detects the object's removal from
stage, stops validating it, and never sets its {{initialized}} flag to
{{true}}.
*Actual behaviour*: {{LayoutManager}} does not detect the object's removal
from stage, continues validating it, and ends up setting the object's
{{initialized}} flag to {{true}}.


> LayoutManager initializes components which are no longer on stage
> -
>
> Key: FLEX-35321
> URL: https://issues.apache.org/jira/browse/FLEX-35321
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Layout - General
>Affects Versions: Apache Flex 4.16.0
>Reporter: Mihai Chira
>Assignee: Mihai Chira
> Fix For: Apache Flex 4.17.0
>
>
> *Scenario A*: during an object's validation cycle some code resulting
from {{validateSize()}}, {{validateProperties()}} or
{{validateDisplayList()}} results in the object's removal from stage.
> *Scenario B*: a user performs an action whose effect is the removal of a
component, exactly when that component is being validated in phases
({{LayoutManager.usePhasedInstantiation == true}}, which is to say, in the
span of two-three frames.
> (For the unit test that models this scenario.)
> 
> *Expected behaviour*: {{LayoutManager}} detects the object's removal from
stage, stops validating it, and never sets its {{initialized}} flag to
{{true}}.
> *Actual behaviour*: {{LayoutManager}} does not detect the object's
removal from stage, continues validating it, and ends up setting the
object's {{initialized}} flag to {{true}}.
> *Unit test*: {{LayoutManager_FLEX_35321_Tests}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[FlexJS] List

[Harbs]

It looks like List defaults to overflow: hidden while it used to allow 
scrolling by default.

Was this an intentional change?