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%.
Thank
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 depend
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
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 orig
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
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 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
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 sa
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 o
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
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
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
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
>
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:
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,
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.
>
> HT
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 sh
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 l
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-tp620
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.
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
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-g
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. 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 rende
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.
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 loo
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 ?
Hi,
> Justin you are compiling by Maven ?
Yep and Debug builds are noticeably slower for me.
Justin
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
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.
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 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.ap
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 Dev
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
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 productio
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 m
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 ar
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
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
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
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 he
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.
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
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?
44 matches
Mail list logo
