Re: Moonshine 1.5.0 Release

[Olaf Krueger]

Thank you!
I've just installed it on Windows7 and it works!

Olaf


BTW:
Seems that your Moonshine web side is outdated? [1]

[1]
Moonshine is being developed using:

Apache Flex® SDK 4.15.0
Adobe AIR® SDK 22.0
Apache FlexJS® SDK 0.7.0
Apache Ant® 1.9.2



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Moonshine-1-5-0-Release-tp63237p63255.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Bead Lifecycle (was Re: git commit: [flex-asjs] [refs/heads/develop] - Add FileUploaderWithResponseData)

[Harbs]

1. I think so, or at most, only slightly. We’d probably save some code by not 
adding lots of functions for events and the like. I feel like the event system 
in general is bloated more than it needs to be.
2. I think there’s probably some and some. There’s probably going to be some 
lazy beads, and that’s ok. The way I see it is that there are two kinds of 
beads. There’s required ones which are not lazy and then there’s 
possibly-required, lazy ones. Lazy ones by definition will not need to listen 
for every notification. As long as there’s structure for the required ones, 
it’s good.
3. I think it’s okay to require certain classes of beads to be loaded in a 
certain order (i.e. controllers and views), as long as it doesn’t lead to 
pitfall bugs, but there’s probably others where requiring the order makes 
things difficult.

Totally agree about the compiler bit.

I generally think better by doing rather than writing.

What I might do when I have some spare time is to do some experiments on a 
branch and see what happens. I have no problem if my experiments turn out to be 
pointless. Either way, it should be educational. I think it would give a 
concrete point of reference.

Harbs

> On Jul 14, 2017, at 2:48 AM, Alex Harui  wrote:
> 
> These are good points.  I'm glad I sent my PAYG email earlier today.  I'm
> not sure I understood points #3 (dependencies) and #5 (cross-referencing)
> so apologies if my thoughts below didn't take them into account.
> 
> I'd say that some of these ideas simply need to be tried and measured
> against the PAYG metrics I proposed.  For example:
> 1) Can we implement a second, lighterweight notification system without
> increasing download size?  Besides mediators I think there is another
> mechanism called AS3Signals.
> 2) Can we have more consistency in when beads get instantiated or will
> that cause too many beads to be instantiated "just-in-case"?  It may just
> be that "just-in-time" or "lazy" instantiation of beads is going to make
> it hard to know when a bead will be added to the strand, but I think
> "just-in-time" instantiation is always going to provide best performance.
> Too much consistency sometimes results in too much just-in-case code.
> 3) Is it better to require certain beads to be placed on the strand before
> other beads?  Does doing so make the code smaller or faster?  Will it be
> more painful for developers to get the order right?  It might be best just
> to find the best patterns for waiting for your partner beads.  One thing
> to consider is that we have more control over when beads get added in
> MXML, but we probably shouldn't have control over when beads get added in
> AS.  I don't think the compiler can or should detect when the application
> developer is going to add a bead and tell them not to do it.
> 
> There are probably at least two different "lifecycles".  Any individual
> bead's lifecycle should be pretty simple: Instantiation, Initial
> Properties, Add To Strand, Listen for Events/Notifications/Property
> Changes.  Depending on how we decide #3 above, some beads may have a "wait
> for my partner bead" phase.
> A UI Component has a lifecycle of: Instantiation, Initial Properties, Add
> To Parent, Add Beads.  But model beads may be instantiated and added on
> demand in Initial Properties.  In "Add Beads" the model is added first if
> not already added, then the view, then everything else.  In theory, the
> "beadsAdded" event can be used by beads to know when significant changes
> to the set of beads has occurred and that can be used to finish setting up
> if you are waiting for partner beads, but otherwise, I think you can count
> on model being instantiated on-demand and finish up in your strand setter.
> 
> The idea I liked the least was the notion that the Strand was some
> intermediary and beads talk to the Strand, tell the Strand what their
> interest are and things like that.  In my view the strand is just a bus
> like you mentioned and isn't involved in any communications.  The beads
> simply use the bus to find each other and find the most PAYG way of
> communicating.  
> 
> Have you found common/popular patterns?  I don't really know because I've
> been spending most of my time in the compiler.  If you have, then yes,
> please document them.
> 
> My 2 cents,
> -Alex
> 
> On 7/13/17, 3:40 PM, "Harbs"  wrote:
> 
>> Now that Yishay and I have spent quite some time with beads, I have some
>> thoughts on the architecture.
>> 
>> Here’s some things I’ve noticed (somewhat randomly):
>> 
>> 1. There’s no clear place to add beads to components in AS. It seems like
>> the catch-all place to do so is in addedToParent(), but many components
>> add beads at other places. Many of these are lazy initialization and the
>> like. There’s probably good reasons for all of these, but it’s confusing.
>> Here’s a list of places where addBead() is called in Basic:
>> start
>> initHandler
>> finishSetup
>> 

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Alex Harui]

I could be wrong, but I'm pretty sure the typedefs/externs prevent the
renaming.  I think it knows that HTMLElement.style is a
CSSStyleDeclaration.

On 7/13/17, 4:15 PM, "Harbs"  wrote:

>One thing I’m curious about:
>
>Why does the Google compiler not rename style properties even when we use
>dot notation? Is it because the object is owned by an external
>HTMLElement object? I’d like to get a better grasp on when Object typed
>variables are renamed and when not. I’ve taken to using bracket notation
>pretty exclusively (at least for object literals) because I never know
>when they will be renamed. I’d like to understand this better.
>
>
>> On Jul 14, 2017, at 1:38 AM, Greg Dove  wrote:
>> 
>> imo, I agree these should be using the javascript camel case properties,
>> but perhaps we need to do a sweep through all the code for that.
>

Re: Bead Lifecycle (was Re: git commit: [flex-asjs] [refs/heads/develop] - Add FileUploaderWithResponseData)

[Alex Harui]

These are good points.  I'm glad I sent my PAYG email earlier today.  I'm
not sure I understood points #3 (dependencies) and #5 (cross-referencing)
so apologies if my thoughts below didn't take them into account.

I'd say that some of these ideas simply need to be tried and measured
against the PAYG metrics I proposed.  For example:
1) Can we implement a second, lighterweight notification system without
increasing download size?  Besides mediators I think there is another
mechanism called AS3Signals.
2) Can we have more consistency in when beads get instantiated or will
that cause too many beads to be instantiated "just-in-case"?  It may just
be that "just-in-time" or "lazy" instantiation of beads is going to make
it hard to know when a bead will be added to the strand, but I think
"just-in-time" instantiation is always going to provide best performance.
Too much consistency sometimes results in too much just-in-case code.
3) Is it better to require certain beads to be placed on the strand before
other beads?  Does doing so make the code smaller or faster?  Will it be
more painful for developers to get the order right?  It might be best just
to find the best patterns for waiting for your partner beads.  One thing
to consider is that we have more control over when beads get added in
MXML, but we probably shouldn't have control over when beads get added in
AS.  I don't think the compiler can or should detect when the application
developer is going to add a bead and tell them not to do it.

There are probably at least two different "lifecycles".  Any individual
bead's lifecycle should be pretty simple: Instantiation, Initial
Properties, Add To Strand, Listen for Events/Notifications/Property
Changes.  Depending on how we decide #3 above, some beads may have a "wait
for my partner bead" phase.
A UI Component has a lifecycle of: Instantiation, Initial Properties, Add
To Parent, Add Beads.  But model beads may be instantiated and added on
demand in Initial Properties.  In "Add Beads" the model is added first if
not already added, then the view, then everything else.  In theory, the
"beadsAdded" event can be used by beads to know when significant changes
to the set of beads has occurred and that can be used to finish setting up
if you are waiting for partner beads, but otherwise, I think you can count
on model being instantiated on-demand and finish up in your strand setter.

The idea I liked the least was the notion that the Strand was some
intermediary and beads talk to the Strand, tell the Strand what their
interest are and things like that.  In my view the strand is just a bus
like you mentioned and isn't involved in any communications.  The beads
simply use the bus to find each other and find the most PAYG way of
communicating.  

Have you found common/popular patterns?  I don't really know because I've
been spending most of my time in the compiler.  If you have, then yes,
please document them.

My 2 cents,
-Alex

On 7/13/17, 3:40 PM, "Harbs"  wrote:

>Now that Yishay and I have spent quite some time with beads, I have some
>thoughts on the architecture.
>
>Here’s some things I’ve noticed (somewhat randomly):
>
>1. There’s no clear place to add beads to components in AS. It seems like
>the catch-all place to do so is in addedToParent(), but many components
>add beads at other places. Many of these are lazy initialization and the
>like. There’s probably good reasons for all of these, but it’s confusing.
>Here’s a list of places where addBead() is called in Basic:
>start
>initHandler
>finishSetup
>set states
>get/set model
>get/set view
>get measurementBead
>setCursor
>get accordionCollapseBead
>get layout
>set strand
>createViewport
>createLists
>displayBackgroundAndBorder
>setupForBorder
>handleMessageChange
>get presentationModel
>constructor
>
>Especially for someone who is new to this, it’s very confusing to know
>where the right place to add a bead is.
>
>2. It’s not immediately obvious that Beads can also be Strands. There are
>quite a few cases where that’s true. The only ones I’ve noticed were View
>Beads.
>
>3. It’s hard to follow which beads have which dependencies. There are
>event listeners added at seemingly random places and events dispatched
>seemingly randomly as well. It’s hard to follow the flow.
>
>4. It’s hard to know when beads are added and in what order.
>
>5. Even if you know what other beads and events your bead relies on, you
>need to cross-reference to know what exact events are being dispatched.
>
>6. The use of events is probably overkill for the needs of stands and
>beads. Strands are effectively a command bus for the beads (there’s many
>terms for the same concept). Events have significant overhead and
>indirection. Really what we need is for beads to tell the Strand “hey, I
>need to know when x happens so I can react and/or change what’s
>happening” and when beads do things they need to say “hey here’s what I
>did/ want to do”.
>
>7. Beads have no way of 

Re: Bead Lifecycle (was Re: git commit: [flex-asjs] [refs/heads/develop] - Add FileUploaderWithResponseData)

[piotrz]

Harbs,

I agree with everything what you just said. I've used PureMVC a lot and
indeed it has really strong communication channel between each parts of
framework which is worth to apply if it possible. 

Apart of that I think your experience should be put at least as an comments
to page about PAYG which Greg started. 

Thank you with sharing with us all of that!
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-develop-Add-FileUploaderWithResponseData-tp63051p63251.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Harbs]

One thing I’m curious about:

Why does the Google compiler not rename style properties even when we use dot 
notation? Is it because the object is owned by an external HTMLElement object? 
I’d like to get a better grasp on when Object typed variables are renamed and 
when not. I’ve taken to using bracket notation pretty exclusively (at least for 
object literals) because I never know when they will be renamed. I’d like to 
understand this better.


> On Jul 14, 2017, at 1:38 AM, Greg Dove  wrote:
> 
> imo, I agree these should be using the javascript camel case properties,
> but perhaps we need to do a sweep through all the code for that.

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Harbs]

I was wondering why bracket access was not working. I should have opened my 
eyes.

I am surprised that both kinds of bracket access works though.

You learn something new all the time. ;-)

Either way, camel case “feels” more correct, but whatever…

Harbs

> On Jul 14, 2017, at 1:46 AM, Harbs  wrote:
> 
> Yes. You are right.
> https://jsfiddle.net/Harbs/9c8zezx5/1/ 
> 
> 
> I’m not sure how I missed that.
> 
> My bad…
> 
>> On Jul 14, 2017, at 1:38 AM, Greg Dove > > wrote:
>> 
>> Harbs I think that jsfiddle is not working because of the missing quotes in
>> the bracket access.
>> 
>> There are a bunch of uses of the bracket access throughout the framework,
>> including, iirc, some things like ['flex-basis'] etc.
>> 
>> imo, I agree these should be using the javascript camel case properties,
>> but perhaps we need to do a sweep through all the code for that.
>> 
>> 
>> 
>> 
>> 
>> On Fri, Jul 14, 2017 at 10:11 AM, Harbs > > wrote:
>> 
>>> I’m not understanding. What worked and what didn’t?
>>> 
>>> In this fiddle: https://jsfiddle.net/Harbs/9c8zezx5/ 
>>>  <
>>> https://jsfiddle.net/Harbs/9c8zezx5/ >
>>> 
>>> You should get an alert when clicking on every div except div1 (the top
>>> left one). Are you seeing something different?
>>> 
 On Jul 14, 2017, at 12:52 AM, Justin Mclean >
>>> wrote:
 
 Hi,
 
> IIRC, style["pointer-events"] works in some browsers but not all.
 
 I tests on Firefox, Safari and Chrome on OSX and in all cases this
>>> failed to work:
 
 style.pointerEvents = "none”;
 
 and the other two styles did work.
 
 Perhaps it’s different on windows?
 
 Thanks,
 Justin
>>> 
>>> 
> 

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Harbs]

Yes. You are right.
https://jsfiddle.net/Harbs/9c8zezx5/1/ 

I’m not sure how I missed that.

My bad…

> On Jul 14, 2017, at 1:38 AM, Greg Dove  wrote:
> 
> Harbs I think that jsfiddle is not working because of the missing quotes in
> the bracket access.
> 
> There are a bunch of uses of the bracket access throughout the framework,
> including, iirc, some things like ['flex-basis'] etc.
> 
> imo, I agree these should be using the javascript camel case properties,
> but perhaps we need to do a sweep through all the code for that.
> 
> 
> 
> 
> 
> On Fri, Jul 14, 2017 at 10:11 AM, Harbs  wrote:
> 
>> I’m not understanding. What worked and what didn’t?
>> 
>> In this fiddle: https://jsfiddle.net/Harbs/9c8zezx5/ <
>> https://jsfiddle.net/Harbs/9c8zezx5/>
>> 
>> You should get an alert when clicking on every div except div1 (the top
>> left one). Are you seeing something different?
>> 
>>> On Jul 14, 2017, at 12:52 AM, Justin Mclean 
>> wrote:
>>> 
>>> Hi,
>>> 
 IIRC, style["pointer-events"] works in some browsers but not all.
>>> 
>>> I tests on Firefox, Safari and Chrome on OSX and in all cases this
>> failed to work:
>>> 
>>> style.pointerEvents = "none”;
>>> 
>>> and the other two styles did work.
>>> 
>>> Perhaps it’s different on windows?
>>> 
>>> Thanks,
>>> Justin
>> 
>> 

Bead Lifecycle (was Re: git commit: [flex-asjs] [refs/heads/develop] - Add FileUploaderWithResponseData)

[Harbs]

Now that Yishay and I have spent quite some time with beads, I have some 
thoughts on the architecture.

Here’s some things I’ve noticed (somewhat randomly):

1. There’s no clear place to add beads to components in AS. It seems like the 
catch-all place to do so is in addedToParent(), but many components add beads 
at other places. Many of these are lazy initialization and the like. There’s 
probably good reasons for all of these, but it’s confusing. Here’s a list of 
places where addBead() is called in Basic:
start
initHandler
finishSetup
set states
get/set model
get/set view
get measurementBead
setCursor
get accordionCollapseBead
get layout
set strand
createViewport
createLists
displayBackgroundAndBorder
setupForBorder
handleMessageChange
get presentationModel
constructor

Especially for someone who is new to this, it’s very confusing to know where 
the right place to add a bead is.

2. It’s not immediately obvious that Beads can also be Strands. There are quite 
a few cases where that’s true. The only ones I’ve noticed were View Beads.

3. It’s hard to follow which beads have which dependencies. There are event 
listeners added at seemingly random places and events dispatched seemingly 
randomly as well. It’s hard to follow the flow.

4. It’s hard to know when beads are added and in what order.

5. Even if you know what other beads and events your bead relies on, you need 
to cross-reference to know what exact events are being dispatched.

6. The use of events is probably overkill for the needs of stands and beads. 
Strands are effectively a command bus for the beads (there’s many terms for the 
same concept). Events have significant overhead and indirection. Really what we 
need is for beads to tell the Strand “hey, I need to know when x happens so I 
can react and/or change what’s happening” and when beads do things they need to 
say “hey here’s what I did/ want to do”.

7. Beads have no way of knowing when they can finish setting up. The only way 
to do so is attach event listeners which is a bit awkward.

I really like the Notification architecture in PureMVC, and I think it’s 
perfect for Strands and Beads.

Without going into all the nitty gritty details, the classes have some standard 
info that the “mediator” can use to find who’s interested in what. The classes 
which need to react to specific notifications (i.e. Mediators) list their 
interests and they are directly notified when something that interests them 
happened.

There’s also a clear lifecycle where functions can be called at predetermined 
times. Notification is done by using a Notification object which has three 
properties: name, type and body. Subscription to events happens through their 
names, but Notifications of the same name can modify their behavior by their 
type. body is an Object and can contain any kind of payload.

I’d like to see a couple of things with Strands and Beads.

1. We should publish popular patterns for Strand/Bead interaction. (I’m talking 
to myself as much as anyone else.)

2. I’d like to have a clearly documented lifecycle for beads. There are some 
standard bead types such as Model, Controller, View, Content View. When should 
each of these be created and how? At critical points in this cycle, things 
should happen automatically: The strand should pull from each bead which is 
added what interests it has.

3. At the point when all “necessary” beads are added, the beads should have 
some method automatically called so they can “finish” their setup if they rely 
on another bead.

4. All Strands should have a “notify” method that beads can call to let the 
strand know to let the appropriate beads know about an event. The beads should 
send a notification with the necessary payload if one is needed. Other beads 
can modify this payload and/or change the notification type if necessary. The 
publisher of the notification can examine the notification after it’s sent to 
know if it needs to do something different.

Bonus points if there’s some kind of “post process” on notifications in case a 
bead needs to wait until after some other bead did their thing. This can take 
the form of a “registerPostProcess” call to the bead which is only every called 
once per registration.

5. I’m likely missing some points in the lifecycle…

This is something that I’d work on if others think this makes any kind of 
sense. While a lot of this is not very different from how events are working 
today, it feels to me like it would help give the strand/bead relationships a 
lot more structure.

Thoughts?
Harbs

> 
> On Jul 13, 2017, at 7:34 PM, Alex Harui  wrote:
> 
> Yes, that's how I think of it.  You are right that getting one bead in a
> multi bead set to listen to other beads is tricky.  UIBase defines a
> particular order of model first, then view, then controller.  But
> otherwise, you either have to dictate your own order or find another event
> to listen to that will give a bead another chance to 

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Greg Dove]

Harbs I think that jsfiddle is not working because of the missing quotes in
the bracket access.

There are a bunch of uses of the bracket access throughout the framework,
including, iirc, some things like ['flex-basis'] etc.

imo, I agree these should be using the javascript camel case properties,
but perhaps we need to do a sweep through all the code for that.





On Fri, Jul 14, 2017 at 10:11 AM, Harbs  wrote:

> I’m not understanding. What worked and what didn’t?
>
> In this fiddle: https://jsfiddle.net/Harbs/9c8zezx5/ <
> https://jsfiddle.net/Harbs/9c8zezx5/>
>
> You should get an alert when clicking on every div except div1 (the top
> left one). Are you seeing something different?
>
> > On Jul 14, 2017, at 12:52 AM, Justin Mclean 
> wrote:
> >
> > Hi,
> >
> >> IIRC, style["pointer-events"] works in some browsers but not all.
> >
> > I tests on Firefox, Safari and Chrome on OSX and in all cases this
> failed to work:
> >
> > style.pointerEvents = "none”;
> >
> > and the other two styles did work.
> >
> > Perhaps it’s different on windows?
> >
> > Thanks,
> > Justin
>
>

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Justin Mclean]

Hi,

BTW the only other uses of pointer events in the code is in DragMouseConroller 
and it has:
COMPILE::JS {
   dragImage.element.style['pointer-events'] = 'none';
}

DisableBead which has:
COMPILE::JS {
   (_strand as Object).element.style.pointerEvents = disabled ? "none" : "";
}

And MXMLViewer which has:
element.style.pointerEvents = "none”;

Thanks,
Justin

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Justin Mclean]

Hi,

> I’m not understanding. What worked and what didn’t?

I’ll take a deeper look at it at the end of my work day.

Thanks,
Justin

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Harbs]

I’m not understanding. What worked and what didn’t?

In this fiddle: https://jsfiddle.net/Harbs/9c8zezx5/ 


You should get an alert when clicking on every div except div1 (the top left 
one). Are you seeing something different?

> On Jul 14, 2017, at 12:52 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> IIRC, style["pointer-events"] works in some browsers but not all.
> 
> I tests on Firefox, Safari and Chrome on OSX and in all cases this failed to 
> work:
> 
> style.pointerEvents = "none”;
> 
> and the other two styles did work.
> 
> Perhaps it’s different on windows?
> 
> Thanks,
> Justin

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Justin Mclean]

Hi,

> Wouldn’t string constants be even clearer?

I did consider that but they would come at increased cost in terms of code size.

Thanks,
Justin

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Justin Mclean]

Hi,

> IIRC, style["pointer-events"] works in some browsers but not all.

I tests on Firefox, Safari and Chrome on OSX and in all cases this failed to 
work:

style.pointerEvents = "none”;

and the other two styles did work.

Perhaps it’s different on windows?

Thanks,
Justin

Re: Multipart

[Harbs]

One of them was documentation edits.

Another was a workaround for a Flash permissions issue. It was a sometime yes, 
sometimes no problem. I finally found where the problem lay that required that 
code. You can see the comments in old issues on that repo. That piece of code 
is very necessary for Flash. There’s really only one way to solve that 
particular issue. Not sure if he can own that solution.

The third was some convenience methods. Not a major contribution.

> On Jul 14, 2017, at 12:07 AM, Alex Harui  wrote:
> 
> Made two comments in the GH issue.  Looks like there were other
> contributors so we may need to get their permission to make the license
> ALv2.
> 
> Of course, I could be wrong,...
> -Alex
> 
> On 7/12/17, 9:14 PM, "Harbs"  wrote:
> 
>> I don’t think he has plans on modifying it.
>> 
>> Do you mind making the suggestion about the header to the Github issue?
>> 
>>> On Jul 13, 2017, at 7:10 AM, Alex Harui 
>>> wrote:
>>> 
>>> IMO, if the original author will be helping make changes to this file,
>>> we
>>> want an ICLA.  If he has no plans to work on it, then attaching it to a
>>> JIRA would be sufficient documentation of his intent to donate it.
>>> 
>>> Either way, it would help if he put the 3rd-party ALv2 header in the
>>> file.
>>> 
>>> -Alex
>>> 
>>> On 7/12/17, 8:59 PM, "Harbs"  wrote:
>>> 
 In our repo with my modifications for FlexJS.
 
 
> On Jul 13, 2017, at 1:22 AM, Alex Harui 
> wrote:
> 
> What do you mean by "adopt".  That the new home for further
> improvements
> is in our repo or that we're using it as a third-party dependency?
> 
> -Alex
> 
> On 7/12/17, 12:45 PM, "Harbs"  wrote:
> 
>> There’s a great class for uploading multi-part HTTP requests. I’ve
>> been
>> using it for years, and I’ve ported it for use with FlexJS. It works
>> great in that context too.
>> 
>> I just asked the author if he minds if we adopt it and he’s very
>> happy
>> for us to do so.[1]
>> 
>> It’s one class. Do we need to go through an ICLA, or can we just
>> bring
>> it
>> in with no fuss?
>> 
>> Thanks,
>> Harbs
>> 
>> 
>> 
>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
>> th
>> ub
>> 
>> 
>> .com%2Fjimojon%2FMultipart.as%2Fissues%2F9=02%7C01%7C%7C61a62bf56
>> 17
>> 14
>> 
>> 
>> 5e9929708d4c95e9650%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63635
>> 48
>> 55
>> 
>> 
>> 465043104=2SKnAIfWKXwDacqORK3Td9AyYffkEXBYr%2BTPdtm6efo%3D
>> ve
>> d=
>> 0 
>> 
>> 
>> > ub
>> .c
>> 
>> 
>> om%2Fjimojon%2FMultipart.as%2Fissues%2F9=02%7C01%7C%7C61a62bf5617
>> 14
>> 5e
>> 
>> 
>> 9929708d4c95e9650%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363548
>> 55
>> 46
>> 
>> 
>> 5043104=2SKnAIfWKXwDacqORK3Td9AyYffkEXBYr%2BTPdtm6efo%3D
>> d=
>> 0>
> 
 
>>> 
>> 
> 

Re: Multipart

[Alex Harui]

Made two comments in the GH issue.  Looks like there were other
contributors so we may need to get their permission to make the license
ALv2.

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

On 7/12/17, 9:14 PM, "Harbs"  wrote:

>I don’t think he has plans on modifying it.
>
>Do you mind making the suggestion about the header to the Github issue?
>
>> On Jul 13, 2017, at 7:10 AM, Alex Harui 
>>wrote:
>> 
>> IMO, if the original author will be helping make changes to this file,
>>we
>> want an ICLA.  If he has no plans to work on it, then attaching it to a
>> JIRA would be sufficient documentation of his intent to donate it.
>> 
>> Either way, it would help if he put the 3rd-party ALv2 header in the
>>file.
>> 
>> -Alex
>> 
>> On 7/12/17, 8:59 PM, "Harbs"  wrote:
>> 
>>> In our repo with my modifications for FlexJS.
>>> 
>>> 
 On Jul 13, 2017, at 1:22 AM, Alex Harui 
 wrote:
 
 What do you mean by "adopt".  That the new home for further
improvements
 is in our repo or that we're using it as a third-party dependency?
 
 -Alex
 
 On 7/12/17, 12:45 PM, "Harbs"  wrote:
 
> There’s a great class for uploading multi-part HTTP requests. I’ve
>been
> using it for years, and I’ve ported it for use with FlexJS. It works
> great in that context too.
> 
> I just asked the author if he minds if we adopt it and he’s very
>happy
> for us to do so.[1]
> 
> It’s one class. Do we need to go through an ICLA, or can we just
>bring
> it
> in with no fuss?
> 
> Thanks,
> Harbs
> 
> 
> 
>[1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
>th
> ub
> 
> 
>.com%2Fjimojon%2FMultipart.as%2Fissues%2F9=02%7C01%7C%7C61a62bf56
>17
> 14
> 
> 
>5e9929708d4c95e9650%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63635
>48
> 55
> 
> 
>465043104=2SKnAIfWKXwDacqORK3Td9AyYffkEXBYr%2BTPdtm6efo%3D
>ve
> d=
> 0 
> 
> 
>ub
> .c
> 
> 
>om%2Fjimojon%2FMultipart.as%2Fissues%2F9=02%7C01%7C%7C61a62bf5617
>14
> 5e
> 
> 
>9929708d4c95e9650%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363548
>55
> 46
> 
> 
>5043104=2SKnAIfWKXwDacqORK3Td9AyYffkEXBYr%2BTPdtm6efo%3D
>d=
> 0>
 
>>> 
>> 
>

Re: Moonshine 1.5.0 Release

[Alex Harui]

Congratulations.  I hope to try it out soon.

-Alex

On 7/13/17, 1:06 PM, "JoelProminic"  wrote:

>I am pleased to announce that Moonshine 1.5.0 has been released at
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmoonshine-
>ide.com%2F=02%7C01%7C%7Cc7e1bdc3acf541ffce5e08d4ca2d633e%7Cfa7b1b5a7b
>34438794aed2c178decee1%7C0%7C0%7C636355743674744572=QaYOiROBLTC56Yuf
>d%2Bd6O9x%2BgCWY0TVeYkyfw4JYDOQ%3D=0 and on the App Store.
>
>Updates:
>- Support for FlexJS 0.8.0 and Flex 4.16.0
>- Create Feathers UI projects (SDK must be configured manually)
>- Rename variables and functions
>- Automatically add missing package import statements during code
>completion
>
>Let us know if you encounter any issues with the update.
>
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FMoonshine-1-5-0-Release-tp63237.html
>=02%7C01%7C%7Cc7e1bdc3acf541ffce5e08d4ca2d633e%7Cfa7b1b5a7b34438794ae
>d2c178decee1%7C0%7C0%7C636355743674744572=SoH1PPelVn6L3dDMDtHS641PM%
>2BDe8eEHowTYnnAz4Qw%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Moonshine 1.5.0 Release

[JoelProminic]

I am pleased to announce that Moonshine 1.5.0 has been released at
http://moonshine-ide.com/ and on the App Store. 

Updates:
- Support for FlexJS 0.8.0 and Flex 4.16.0
- Create Feathers UI projects (SDK must be configured manually)
- Rename variables and functions
- Automatically add missing package import statements during code completion

Let us know if you encounter any issues with the update. 




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Moonshine-1-5-0-Release-tp63237.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: FlexJS Yeoman generator

[Harbs]

We’re already discussing that problem here:
https://www.patreon.com/posts/scaffold-apache-12918005?cid=6126089 


It works from the command line, so it seems like it’s an issue that’s connected 
to the VS Code extension.

> On Jul 13, 2017, at 9:12 PM, PKumar  wrote:
> 
> Hi Josh,
> 
> I  tried tried the yeoman & flexjs generator  with VCode. Everything is
> really good and working fine. One  problem i  am getting on creating mxml
> component. when i am trying to create the new mxml then i am getting 
> exception. check the attached screen shot.
> 
> 
>  
> 
> _-_ 
>|   |╭──╮
>|--(o)--|│  Let's create an │
>   `-´   │  MXML component  │
>( _´U`_ )╰──╯
>/___A___\   /
> |  ~  | 
>   __'.___.'__   
> ´   `  |° ´ Y ` 
> 
> Uncaught Exception:  TypeError: Invalid property descriptor. Cannot both
> specify accessors and a value or writable attribute, #
> TypeError: Invalid property descriptor. Cannot both specify accessors and a
> value or writable attribute, #
>at Function.defineProperty ()
>at new ErrorEXError (C:\Users\Prashant
> Kumar\.vscode\extensions\samverschueren.yo-0.9.3\node_modules\error-ex\index.js:79:10)
>at vscode_1.window.showQuickPick.then.result (C:\Users\Prashant
> Kumar\.vscode\extensions\samverschueren.yo-0.9.3\out\prompts\list.js:20:23)
>at Object.m [as _notify] (c:\Program Files (x86)\Microsoft VS
> Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:41973)
>at Object.enter (c:\Program Files (x86)\Microsoft VS
> Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:45538)
>at n.Class.derive._oncancel._run (c:\Program Files (x86)\Microsoft VS
> Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:47366)
>at n.Class.derive._oncancel._completed (c:\Program Files (x86)\Microsoft
> VS
> Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:46807)
>at c:\Program Files (x86)\Microsoft VS
> Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:63502
>at n.Class.derive._creator.done (c:\Program Files (x86)\Microsoft VS
> Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:48667)
>at Object.m [as _notify] (c:\Program Files (x86)\Microsoft VS
> Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:42115)
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-flex-development.247.n4.nabble.com/FlexJS-Yeoman-generator-tp63178p63235.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: FlexJS Yeoman generator

[PKumar]

Hi Josh,

I  tried tried the yeoman & flexjs generator  with VCode. Everything is
really good and working fine. One  problem i  am getting on creating mxml
component. when i am trying to create the new mxml then i am getting 
exception. check the attached screen shot.


 

 _-_ 
|   |╭──╮
|--(o)--|│  Let's create an │
   `-´   │  MXML component  │
( _´U`_ )╰──╯
/___A___\   /
 |  ~  | 
   __'.___.'__   
 ´   `  |° ´ Y ` 

Uncaught Exception:  TypeError: Invalid property descriptor. Cannot both
specify accessors and a value or writable attribute, #
TypeError: Invalid property descriptor. Cannot both specify accessors and a
value or writable attribute, #
at Function.defineProperty ()
at new ErrorEXError (C:\Users\Prashant
Kumar\.vscode\extensions\samverschueren.yo-0.9.3\node_modules\error-ex\index.js:79:10)
at vscode_1.window.showQuickPick.then.result (C:\Users\Prashant
Kumar\.vscode\extensions\samverschueren.yo-0.9.3\out\prompts\list.js:20:23)
at Object.m [as _notify] (c:\Program Files (x86)\Microsoft VS
Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:41973)
at Object.enter (c:\Program Files (x86)\Microsoft VS
Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:45538)
at n.Class.derive._oncancel._run (c:\Program Files (x86)\Microsoft VS
Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:47366)
at n.Class.derive._oncancel._completed (c:\Program Files (x86)\Microsoft
VS
Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:46807)
at c:\Program Files (x86)\Microsoft VS
Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:63502
at n.Class.derive._creator.done (c:\Program Files (x86)\Microsoft VS
Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:48667)
at Object.m [as _notify] (c:\Program Files (x86)\Microsoft VS
Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:23:42115)




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

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Josh Tynjala]

With classic Flex, I believe IDEs would check if the [Inspectable] metadata
had an enumeration field and provide those values as suggestions when a
property is used in MXML.

I've been meaning to add that feature to the VSCode extension. I just added
an issue to remind myself:

https://github.com/BowlerHatLLC/vscode-nextgenas/issues/106

- Josh

On Thu, Jul 13, 2017 at 10:38 AM, Harbs  wrote:

> Something that I keep forgetting to ask:
>
> Do [Inspectable] meta tags work in FlexJS? I’m not sure how they worked in
> classic Flex, but having suggestions of possible values in an IDE was very
> helpful.
>
> Josh, would something like that be possible in VS Code?
>
> > On Jul 13, 2017, at 8:26 PM, Alex Harui 
> wrote:
> >
> > I would also recommend using large numbers for the constants.  It isn't
> > clear I can position a tooltip at 2,0 the way the code is written now.
>
>

PAYG

[Alex Harui]

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: git commit: [flex-asjs] [refs/heads/develop] - Add FileUploaderWithResponseData

[yishayw]

So going back to Piotr's original post, the current approach for adding
functionality to a bead (ControllerForWithoutResponse) is to create a new
bead (ConterollerForWithResponse) that extends the functionality of the
original bead, rather than adding a bead to the original one
(ControllerForResponse + ControllerForWithoutResponse). 

This is what I meant when I said we're being forced out of composition into
inheritance. 



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Re-git-commit-flex-asjs-refs-heads-develop-Add-FileUploaderWithResponseData-tp63051p63231.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Harbs]

Wouldn’t string constants be even clearer?

> On Jul 13, 2017, at 8:26 PM, Alex Harui  wrote:
> 
> I would also recommend using large numbers for the constants.

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Harbs]

Something that I keep forgetting to ask:

Do [Inspectable] meta tags work in FlexJS? I’m not sure how they worked in 
classic Flex, but having suggestions of possible values in an IDE was very 
helpful.

Josh, would something like that be possible in VS Code?

> On Jul 13, 2017, at 8:26 PM, Alex Harui  wrote:
> 
> I would also recommend using large numbers for the constants.  It isn't
> clear I can position a tooltip at 2,0 the way the code is written now.

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Harbs]

It did not work on any Mac browser. Don’t know about Windows.

> On Jul 13, 2017, at 8:26 PM, Alex Harui  wrote:
> 
> IIRC, style["pointer-events"] works in some browsers but not all.

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Alex Harui]

IIRC, style["pointer-events"] works in some browsers but not all.

Anyway, this is quite a bit of new code.  The old bead should have been
preserved and given a name like ToolTipsOnRightBottomBead and the existing
examples updated to use it.

I would also recommend using large numbers for the constants.  It isn't
clear I can position a tooltip at 2,0 the way the code is written now.

Thanks,
-Alex

On 7/13/17, 8:16 AM, "Harbs"  wrote:

>Here’s a fiddle trying to set pointer-events in various ways. Only one
>(with dot notation) works:
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjsfiddle.
>net%2FHarbs%2F9c8zezx5%2F=02%7C01%7C%7C8f52afd516cb4676154e08d4ca021b
>30%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63637782259195=v
>umqhweIzZLNFozgADtC3Hn%2B71kZ1BTcBcb6JyUjY4o%3D=0
>.net%2FHarbs%2F9c8zezx5%2F=02%7C01%7C%7C8f52afd516cb4676154e08d4ca021
>b30%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63637782259195=
>vumqhweIzZLNFozgADtC3Hn%2B71kZ1BTcBcb6JyUjY4o%3D=0>
>
>> On Jul 13, 2017, at 5:51 PM, Harbs  wrote:
>> 
>> More information here:
>> 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelope
>>r.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FCSS%2FCSS_Properties_Reference=
>>02%7C01%7C%7C8f52afd516cb4676154e08d4ca021b30%7Cfa7b1b5a7b34438794aed2c17
>>8decee1%7C0%7C0%7C63637782259195=0JEjaPFP%2FrB7s39JK8%2FKU8izCK
>>c12TkKOL57ND2f0ho%3D=0
>>>er.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FCSS%2FCSS_Properties_Reference
>>=02%7C01%7C%7C8f52afd516cb4676154e08d4ca021b30%7Cfa7b1b5a7b34438794aed2c1
>>78decee1%7C0%7C0%7C63637782259195=0JEjaPFP%2FrB7s39JK8%2FKU8izC
>>Kc12TkKOL57ND2f0ho%3D=0>
>> 
>>> On Jul 13, 2017, at 4:48 PM, Harbs >>> wrote:
>>> 
>>> When specifying css via javascript, the naming is different than
>>>specifying using CSS files.
>>> 
>>> I’d be *very* surprised if the code works as-is.
>>> 
 On Jul 13, 2017, at 3:23 PM, Justin Mclean > wrote:
 
 Hi
 
>> +positioner.style["pointer-events"] = "none”;
> 
> I think that should be positioner.style["pointerEvents"] = "none”;
 
 The style is "pointer-events" [1] so I’m not sure why you would use
"pointerEvents”. I’ve tested ""pointer-events” and it works.
 
 Thanks,
 Justin
 
 
 1. 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelo
per.mozilla.org%2Fen%2Fdocs%2FWeb%2FCSS%2Fpointer-events=02%7C01%7
C%7C8f52afd516cb4676154e08d4ca021b30%7Cfa7b1b5a7b34438794aed2c178decee1
%7C0%7C0%7C63637782259195=H9pPdrZ7iXlpfO2OKgZJaLuynAnYhTiRk59
%2BVSEZyiE%3D=0

>>> 
>> 
>

Re: [FlexJS] Use of typeof

[Josh Tynjala]

I just gave it a try, and I'm not seeing global either. It appears that
"var global" is not defined in the typedefs. I guess we'll need to add it
to the missing.js for Node.

- Josh

On Thu, Jul 13, 2017 at 10:09 AM, Harbs  wrote:

> Adding node.swc makes things like require be recognized, but global is
> still not. Odd. I thought I saw it in the typedefs.
>
> > On Jul 13, 2017, at 8:04 PM, Harbs  wrote:
> >
> > Are you saying we should add node.swc to Core?
> >
> > FWIW, I just tried setting targets to JSNode and global is still not
> recognized. node.swc does not seem to be used even when that’s the target.
> That does not seem right either.
> >
> >> On Jul 13, 2017, at 7:42 PM, Josh Tynjala 
> wrote:
> >>
> >> I think the correct solution is to add node.swc to the
> >> -external-library-path when you need access to global. You need js.swc
> on
> >> the -external-library-path when you want to access window. You can't use
> >> window in a SWF-only project, for instance.
> >>
> >> - Josh
> >>
> >> On Thu, Jul 13, 2017 at 9:29 AM, Harbs  wrote:
> >>
> >>> There is a mention of window in the NativeJSType enums. Not sure why
> it’s
> >>> needed there.
> >>>
> >>> global should already be in node.js (I think). I’m pretty sure it’s
> >>> defined in the node typedefs
> >>>
> >>> I don’t really care how it’s achieved, but by default (without doing
> any
> >>> special imports) global should be recognized. (just like window is)
> >>>
> >>> Right now, typing global into a FlexJS project targeting “JSFlex” or
> any
> >>> one of the framework projects results in a compiler error. How do we
> fix
> >>> that?
> >>>
>  On Jul 13, 2017, at 7:17 PM, Alex Harui 
> >>> wrote:
> 
>  IIRC, the compiler doesn't special case handling of that code.
> "window"
>  is defined in missing.js so the js.swc knows there is such an
> entity.  Is
>  there any reason not to add a "global" to node.swc?
> 
>  -Alex
> 
>  On 7/13/17, 12:29 AM, "Harbs"  wrote:
> 
> > Right now, if you have code that looks like this, the compiler will
> > report and error and it will fail:
> >
> > global[“foo”];
> >
> > I would like for that to be legal code in a COMPILE::JS block and it
> > should compile to:
> >
> > global[“foo”];
> >
> > Exactly the same as window:
> >
> > If you write:
> > window[“foo”];
> >
> > It’s legal code and will compile to:
> > window[“foo”];
> >
> > That’s it.
> >
> >> On Jul 13, 2017, at 10:18 AM, Alex Harui 
> >> wrote:
> >>
> >> I'm still not clear what changes are needed.
> >>
> >> Are you trying to access APIs that are global but not defined in
> JS.SWC
> >> or
> >> Node.SWC?  Otherwise, the APIs on window/global should be defined in
> >> those
> >> SWCs.
> >>
> >> I'm not sure what the test case is supposed to look like.
> >>
> >> Thanks,
> >> -Alex
> >>
> >> On 7/13/17, 12:11 AM, "Harbs"  wrote:
> >>
> >>> Electron has both window and global. Node has global and no
> window. I
> >>> think CEF has window and no global. Browsers have window but not
> >>> global.
> >>> Depending on which environment you are writing for, you’re going to
> >>> need
> >>> either window or global for accessing global variables.
> >>>
> >>> I’m more concerned with general global access in Node than my
> specific
> >>> use case. If general global access works, then that gives a
> solution
> >>> for
> >>> my specific case as well as an other arbitrary one where you’d use
> >>> window
> >>> in the browser.
> >>>
> >>> I think it’s fine to cross compile global[“foo”] to the exact same
> >>> global[“foo”] in JS. In other words, the compiler should accept
> global
> >>> with bracket notation and pass it through unchanged.
> >>>
>  On Jul 13, 2017, at 9:33 AM, Alex Harui  >
>  wrote:
> 
>  I think the only thing the compiler does with "window" is allow
> you
> >>> to
>  use
>  "window" to disambiguate between a "global" API and another API
> in a
>  package with the same name.
> 
>  And then the JS.SWC typedefs specify certain APIs.
> 
>  AIUI, Electron is another runtime that has a window variable and
> you
>  want
>  to detect the difference between Browser, Node and Electron?  Or
> are
>  you
>  willing to just try to check for features instead?
> 
>  If you can show what JS code you'd want to end up with we can look
>  into
>  changing the compiler so you can write AS to generate that JS.
> 
>  Thanks,
>  

Re: [FlexJS] Use of typeof

[Josh Tynjala]

If you need access to global in Core, then yes, you should add node.swc.

The value of -targets does not determine which SWCs are included. It only
determines how the compiler generates the JavaScript. You should probably
continue to use JSFlex, but you should manually add node.swc to the
project's external-library-path. node.swc is only automatically included
when using the js/bin/asnodec compiler, which sets +configname=node and
that causes the compiler to load node-config.xml instead of the default
flex-config.xml.

Note that I'm not saying that you should try to use node-config.xml. I'm
just filling in some details on why changing -targets to JSNode didn't
work. You should add node.swc to the -external-library-path in the
project's compiler options.

- Josh

On Thu, Jul 13, 2017 at 10:04 AM, Harbs  wrote:

> Are you saying we should add node.swc to Core?
>
> FWIW, I just tried setting targets to JSNode and global is still not
> recognized. node.swc does not seem to be used even when that’s the target.
> That does not seem right either.
>
> > On Jul 13, 2017, at 7:42 PM, Josh Tynjala  wrote:
> >
> > I think the correct solution is to add node.swc to the
> > -external-library-path when you need access to global. You need js.swc on
> > the -external-library-path when you want to access window. You can't use
> > window in a SWF-only project, for instance.
> >
> > - Josh
> >
> > On Thu, Jul 13, 2017 at 9:29 AM, Harbs  wrote:
> >
> >> There is a mention of window in the NativeJSType enums. Not sure why
> it’s
> >> needed there.
> >>
> >> global should already be in node.js (I think). I’m pretty sure it’s
> >> defined in the node typedefs
> >>
> >> I don’t really care how it’s achieved, but by default (without doing any
> >> special imports) global should be recognized. (just like window is)
> >>
> >> Right now, typing global into a FlexJS project targeting “JSFlex” or any
> >> one of the framework projects results in a compiler error. How do we fix
> >> that?
> >>
> >>> On Jul 13, 2017, at 7:17 PM, Alex Harui 
> >> wrote:
> >>>
> >>> IIRC, the compiler doesn't special case handling of that code.
> "window"
> >>> is defined in missing.js so the js.swc knows there is such an entity.
> Is
> >>> there any reason not to add a "global" to node.swc?
> >>>
> >>> -Alex
> >>>
> >>> On 7/13/17, 12:29 AM, "Harbs"  wrote:
> >>>
>  Right now, if you have code that looks like this, the compiler will
>  report and error and it will fail:
> 
>  global[“foo”];
> 
>  I would like for that to be legal code in a COMPILE::JS block and it
>  should compile to:
> 
>  global[“foo”];
> 
>  Exactly the same as window:
> 
>  If you write:
>  window[“foo”];
> 
>  It’s legal code and will compile to:
>  window[“foo”];
> 
>  That’s it.
> 
> > On Jul 13, 2017, at 10:18 AM, Alex Harui 
> > wrote:
> >
> > I'm still not clear what changes are needed.
> >
> > Are you trying to access APIs that are global but not defined in
> JS.SWC
> > or
> > Node.SWC?  Otherwise, the APIs on window/global should be defined in
> > those
> > SWCs.
> >
> > I'm not sure what the test case is supposed to look like.
> >
> > Thanks,
> > -Alex
> >
> > On 7/13/17, 12:11 AM, "Harbs"  wrote:
> >
> >> Electron has both window and global. Node has global and no window.
> I
> >> think CEF has window and no global. Browsers have window but not
> >> global.
> >> Depending on which environment you are writing for, you’re going to
> >> need
> >> either window or global for accessing global variables.
> >>
> >> I’m more concerned with general global access in Node than my
> specific
> >> use case. If general global access works, then that gives a solution
> >> for
> >> my specific case as well as an other arbitrary one where you’d use
> >> window
> >> in the browser.
> >>
> >> I think it’s fine to cross compile global[“foo”] to the exact same
> >> global[“foo”] in JS. In other words, the compiler should accept
> global
> >> with bracket notation and pass it through unchanged.
> >>
> >>> On Jul 13, 2017, at 9:33 AM, Alex Harui 
> >>> wrote:
> >>>
> >>> I think the only thing the compiler does with "window" is allow you
> >> to
> >>> use
> >>> "window" to disambiguate between a "global" API and another API in
> a
> >>> package with the same name.
> >>>
> >>> And then the JS.SWC typedefs specify certain APIs.
> >>>
> >>> AIUI, Electron is another runtime that has a window variable and
> you
> >>> want
> >>> to detect the difference between Browser, Node and Electron?  Or
> are
> >>> you
> >>> willing to just try 

Re: [FlexJS] Use of typeof

[Harbs]

Adding node.swc makes things like require be recognized, but global is still 
not. Odd. I thought I saw it in the typedefs.

> On Jul 13, 2017, at 8:04 PM, Harbs  wrote:
> 
> Are you saying we should add node.swc to Core?
> 
> FWIW, I just tried setting targets to JSNode and global is still not 
> recognized. node.swc does not seem to be used even when that’s the target. 
> That does not seem right either.
> 
>> On Jul 13, 2017, at 7:42 PM, Josh Tynjala  wrote:
>> 
>> I think the correct solution is to add node.swc to the
>> -external-library-path when you need access to global. You need js.swc on
>> the -external-library-path when you want to access window. You can't use
>> window in a SWF-only project, for instance.
>> 
>> - Josh
>> 
>> On Thu, Jul 13, 2017 at 9:29 AM, Harbs  wrote:
>> 
>>> There is a mention of window in the NativeJSType enums. Not sure why it’s
>>> needed there.
>>> 
>>> global should already be in node.js (I think). I’m pretty sure it’s
>>> defined in the node typedefs
>>> 
>>> I don’t really care how it’s achieved, but by default (without doing any
>>> special imports) global should be recognized. (just like window is)
>>> 
>>> Right now, typing global into a FlexJS project targeting “JSFlex” or any
>>> one of the framework projects results in a compiler error. How do we fix
>>> that?
>>> 
 On Jul 13, 2017, at 7:17 PM, Alex Harui 
>>> wrote:
 
 IIRC, the compiler doesn't special case handling of that code.  "window"
 is defined in missing.js so the js.swc knows there is such an entity.  Is
 there any reason not to add a "global" to node.swc?
 
 -Alex
 
 On 7/13/17, 12:29 AM, "Harbs"  wrote:
 
> Right now, if you have code that looks like this, the compiler will
> report and error and it will fail:
> 
> global[“foo”];
> 
> I would like for that to be legal code in a COMPILE::JS block and it
> should compile to:
> 
> global[“foo”];
> 
> Exactly the same as window:
> 
> If you write:
> window[“foo”];
> 
> It’s legal code and will compile to:
> window[“foo”];
> 
> That’s it.
> 
>> On Jul 13, 2017, at 10:18 AM, Alex Harui 
>> wrote:
>> 
>> I'm still not clear what changes are needed.
>> 
>> Are you trying to access APIs that are global but not defined in JS.SWC
>> or
>> Node.SWC?  Otherwise, the APIs on window/global should be defined in
>> those
>> SWCs.
>> 
>> I'm not sure what the test case is supposed to look like.
>> 
>> Thanks,
>> -Alex
>> 
>> On 7/13/17, 12:11 AM, "Harbs"  wrote:
>> 
>>> Electron has both window and global. Node has global and no window. I
>>> think CEF has window and no global. Browsers have window but not
>>> global.
>>> Depending on which environment you are writing for, you’re going to
>>> need
>>> either window or global for accessing global variables.
>>> 
>>> I’m more concerned with general global access in Node than my specific
>>> use case. If general global access works, then that gives a solution
>>> for
>>> my specific case as well as an other arbitrary one where you’d use
>>> window
>>> in the browser.
>>> 
>>> I think it’s fine to cross compile global[“foo”] to the exact same
>>> global[“foo”] in JS. In other words, the compiler should accept global
>>> with bracket notation and pass it through unchanged.
>>> 
 On Jul 13, 2017, at 9:33 AM, Alex Harui 
 wrote:
 
 I think the only thing the compiler does with "window" is allow you
>>> to
 use
 "window" to disambiguate between a "global" API and another API in a
 package with the same name.
 
 And then the JS.SWC typedefs specify certain APIs.
 
 AIUI, Electron is another runtime that has a window variable and you
 want
 to detect the difference between Browser, Node and Electron?  Or are
 you
 willing to just try to check for features instead?
 
 If you can show what JS code you'd want to end up with we can look
 into
 changing the compiler so you can write AS to generate that JS.
 
 Thanks,
 -Alex
 
 On 7/12/17, 9:03 PM, "Harbs"  wrote:
 
> What do we currently do with window?
> 
> global in Node is the same as window in the browser. All global
> variables
> are attached to the global object.
> 
> global[“foo”] could compile to global[“foo”], global.foo, or just
> plain
> foo, and it all means the same thing.
> 
>> On Jul 13, 2017, at 2:14 AM, Alex 

Re: [FlexJS] Use of typeof

[Harbs]

Are you saying we should add node.swc to Core?

FWIW, I just tried setting targets to JSNode and global is still not 
recognized. node.swc does not seem to be used even when that’s the target. That 
does not seem right either.

> On Jul 13, 2017, at 7:42 PM, Josh Tynjala  wrote:
> 
> I think the correct solution is to add node.swc to the
> -external-library-path when you need access to global. You need js.swc on
> the -external-library-path when you want to access window. You can't use
> window in a SWF-only project, for instance.
> 
> - Josh
> 
> On Thu, Jul 13, 2017 at 9:29 AM, Harbs  wrote:
> 
>> There is a mention of window in the NativeJSType enums. Not sure why it’s
>> needed there.
>> 
>> global should already be in node.js (I think). I’m pretty sure it’s
>> defined in the node typedefs
>> 
>> I don’t really care how it’s achieved, but by default (without doing any
>> special imports) global should be recognized. (just like window is)
>> 
>> Right now, typing global into a FlexJS project targeting “JSFlex” or any
>> one of the framework projects results in a compiler error. How do we fix
>> that?
>> 
>>> On Jul 13, 2017, at 7:17 PM, Alex Harui 
>> wrote:
>>> 
>>> IIRC, the compiler doesn't special case handling of that code.  "window"
>>> is defined in missing.js so the js.swc knows there is such an entity.  Is
>>> there any reason not to add a "global" to node.swc?
>>> 
>>> -Alex
>>> 
>>> On 7/13/17, 12:29 AM, "Harbs"  wrote:
>>> 
 Right now, if you have code that looks like this, the compiler will
 report and error and it will fail:
 
 global[“foo”];
 
 I would like for that to be legal code in a COMPILE::JS block and it
 should compile to:
 
 global[“foo”];
 
 Exactly the same as window:
 
 If you write:
 window[“foo”];
 
 It’s legal code and will compile to:
 window[“foo”];
 
 That’s it.
 
> On Jul 13, 2017, at 10:18 AM, Alex Harui 
> wrote:
> 
> I'm still not clear what changes are needed.
> 
> Are you trying to access APIs that are global but not defined in JS.SWC
> or
> Node.SWC?  Otherwise, the APIs on window/global should be defined in
> those
> SWCs.
> 
> I'm not sure what the test case is supposed to look like.
> 
> Thanks,
> -Alex
> 
> On 7/13/17, 12:11 AM, "Harbs"  wrote:
> 
>> Electron has both window and global. Node has global and no window. I
>> think CEF has window and no global. Browsers have window but not
>> global.
>> Depending on which environment you are writing for, you’re going to
>> need
>> either window or global for accessing global variables.
>> 
>> I’m more concerned with general global access in Node than my specific
>> use case. If general global access works, then that gives a solution
>> for
>> my specific case as well as an other arbitrary one where you’d use
>> window
>> in the browser.
>> 
>> I think it’s fine to cross compile global[“foo”] to the exact same
>> global[“foo”] in JS. In other words, the compiler should accept global
>> with bracket notation and pass it through unchanged.
>> 
>>> On Jul 13, 2017, at 9:33 AM, Alex Harui 
>>> wrote:
>>> 
>>> I think the only thing the compiler does with "window" is allow you
>> to
>>> use
>>> "window" to disambiguate between a "global" API and another API in a
>>> package with the same name.
>>> 
>>> And then the JS.SWC typedefs specify certain APIs.
>>> 
>>> AIUI, Electron is another runtime that has a window variable and you
>>> want
>>> to detect the difference between Browser, Node and Electron?  Or are
>>> you
>>> willing to just try to check for features instead?
>>> 
>>> If you can show what JS code you'd want to end up with we can look
>>> into
>>> changing the compiler so you can write AS to generate that JS.
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 7/12/17, 9:03 PM, "Harbs"  wrote:
>>> 
 What do we currently do with window?
 
 global in Node is the same as window in the browser. All global
 variables
 are attached to the global object.
 
 global[“foo”] could compile to global[“foo”], global.foo, or just
 plain
 foo, and it all means the same thing.
 
> On Jul 13, 2017, at 2:14 AM, Alex Harui 
> wrote:
> 
> What AS do you want to write and what JS do you want as output?
> 
> -Alex
> 
> On 7/9/17, 12:53 AM, "Harbs"  wrote:
> 
>> Checking for window will work for Node, but it will not work for

Re: [FlexJS] Use of typeof

[Josh Tynjala]

I think the correct solution is to add node.swc to the
-external-library-path when you need access to global. You need js.swc on
the -external-library-path when you want to access window. You can't use
window in a SWF-only project, for instance.

- Josh

On Thu, Jul 13, 2017 at 9:29 AM, Harbs  wrote:

> There is a mention of window in the NativeJSType enums. Not sure why it’s
> needed there.
>
> global should already be in node.js (I think). I’m pretty sure it’s
> defined in the node typedefs
>
> I don’t really care how it’s achieved, but by default (without doing any
> special imports) global should be recognized. (just like window is)
>
> Right now, typing global into a FlexJS project targeting “JSFlex” or any
> one of the framework projects results in a compiler error. How do we fix
> that?
>
> > On Jul 13, 2017, at 7:17 PM, Alex Harui 
> wrote:
> >
> > IIRC, the compiler doesn't special case handling of that code.  "window"
> > is defined in missing.js so the js.swc knows there is such an entity.  Is
> > there any reason not to add a "global" to node.swc?
> >
> > -Alex
> >
> > On 7/13/17, 12:29 AM, "Harbs"  wrote:
> >
> >> Right now, if you have code that looks like this, the compiler will
> >> report and error and it will fail:
> >>
> >> global[“foo”];
> >>
> >> I would like for that to be legal code in a COMPILE::JS block and it
> >> should compile to:
> >>
> >> global[“foo”];
> >>
> >> Exactly the same as window:
> >>
> >> If you write:
> >> window[“foo”];
> >>
> >> It’s legal code and will compile to:
> >> window[“foo”];
> >>
> >> That’s it.
> >>
> >>> On Jul 13, 2017, at 10:18 AM, Alex Harui 
> >>> wrote:
> >>>
> >>> I'm still not clear what changes are needed.
> >>>
> >>> Are you trying to access APIs that are global but not defined in JS.SWC
> >>> or
> >>> Node.SWC?  Otherwise, the APIs on window/global should be defined in
> >>> those
> >>> SWCs.
> >>>
> >>> I'm not sure what the test case is supposed to look like.
> >>>
> >>> Thanks,
> >>> -Alex
> >>>
> >>> On 7/13/17, 12:11 AM, "Harbs"  wrote:
> >>>
>  Electron has both window and global. Node has global and no window. I
>  think CEF has window and no global. Browsers have window but not
>  global.
>  Depending on which environment you are writing for, you’re going to
>  need
>  either window or global for accessing global variables.
> 
>  I’m more concerned with general global access in Node than my specific
>  use case. If general global access works, then that gives a solution
>  for
>  my specific case as well as an other arbitrary one where you’d use
>  window
>  in the browser.
> 
>  I think it’s fine to cross compile global[“foo”] to the exact same
>  global[“foo”] in JS. In other words, the compiler should accept global
>  with bracket notation and pass it through unchanged.
> 
> > On Jul 13, 2017, at 9:33 AM, Alex Harui 
> > wrote:
> >
> > I think the only thing the compiler does with "window" is allow you
> to
> > use
> > "window" to disambiguate between a "global" API and another API in a
> > package with the same name.
> >
> > And then the JS.SWC typedefs specify certain APIs.
> >
> > AIUI, Electron is another runtime that has a window variable and you
> > want
> > to detect the difference between Browser, Node and Electron?  Or are
> > you
> > willing to just try to check for features instead?
> >
> > If you can show what JS code you'd want to end up with we can look
> > into
> > changing the compiler so you can write AS to generate that JS.
> >
> > Thanks,
> > -Alex
> >
> > On 7/12/17, 9:03 PM, "Harbs"  wrote:
> >
> >> What do we currently do with window?
> >>
> >> global in Node is the same as window in the browser. All global
> >> variables
> >> are attached to the global object.
> >>
> >> global[“foo”] could compile to global[“foo”], global.foo, or just
> >> plain
> >> foo, and it all means the same thing.
> >>
> >>> On Jul 13, 2017, at 2:14 AM, Alex Harui 
> >>> wrote:
> >>>
> >>> What AS do you want to write and what JS do you want as output?
> >>>
> >>> -Alex
> >>>
> >>> On 7/9/17, 12:53 AM, "Harbs"  wrote:
> >>>
>  Checking for window will work for Node, but it will not work for
>  Electron.
> 
>  I tried adding global to Falcon, but I was obviously going about
> it
>  wrong, because what I tried did not work.
> 
>  This is not really high priority for me right now, so I’m moving
> on
>  to
>  something else…
> 
> > On Jul 6, 2017, at 3:05 AM, Alex Harui 

Re: git commit: [flex-asjs] [refs/heads/develop] - Add FileUploaderWithResponseData

[Alex Harui]

Yes, that's how I think of it.  You are right that getting one bead in a
multi bead set to listen to other beads is tricky.  UIBase defines a
particular order of model first, then view, then controller.  But
otherwise, you either have to dictate your own order or find another event
to listen to that will give a bead another chance to search the strand for
other beads to listen to.  There is a "beadsAdded" event that can be used.

Maybe as more folks implement multi-bead sets we'll see patterns emerge
and make it is simpler and faster.

My 2 cents,
-Alex

On 7/13/17, 3:54 AM, "Yishay Weiss"  wrote:

>Generally speaking it feels like sometimes I need to insure the order of
>invocation. Since beads communicate with one another through events it’s
>difficult to achieve. Regarding the upload response data I understand
>your suggestion as follows (edges contain event names):
>
>--uploadRequested--request)>---complete---model>---modelChanged--
>
>And for the case where the user isn’t interested in the response, just in
>the status:
>
>---uploadRequested-complete---odelWithoutResponse>--modelChanged--
>
>Is that right?
>
>
>From: Alex Harui
>Sent: Wednesday, July 12, 2017 9:58 AM
>To: dev@flex.apache.org
>Subject: Re: git commit: [flex-asjs] [refs/heads/develop] - Add
>FileUploaderWithResponseData
>
>I think I still don't understand.
>
>It is ok for beads to require other beads.  If a ResponseData bead
>requires a model with a slot for responseData and a controller that knows
>to record that data, that's how you are supposed to "re-compose"
>components.  There doesn't have to be one model or controller per
>component.  The strand is a gathering place for small pieces to work
>together.
>
>I'm not sure what work CheckPermissions needs to do, but is totally fine
>to split its work amongst a set of beads.
>
>HTH,
>-Alex
>
>On 7/11/17, 11:21 PM, "yishayw"  wrote:
>
>>Ideally we wouldn't have to record data that's never read. This may be an
>>extreme case, but some users will want to know the response on an upload,
>>while some will just want to make sure the status is ok. I'd rather not
>>anticipate too many use cases when writing the strand and the model
>>because
>>I might end up with code that's never used. If the bead was responsible
>>for
>>both recording the response and exposing it to the user, we wouldn't have
>>to
>>do that.
>>
>>Perhaps a better example is permissions. I already have an Upload bead.
>>Now
>>I want an alert to pop up if the user is not permitted to upload. I'd
>>like
>>to be able to add a 'CheckPemissionsOnUpload' bead. Right now I don't see
>>how to do that, instead I would probably have to replace 'UploadBead'
>>with
>>'UploadButCheckPermissionsBead'. This takes us away from composition and
>>forces inheritance.
>>
>>Maybe we don't need to modify class definitions. I think it's enough to
>>modify the bead instance. In JS we could simply replace the function, and
>>in
>>flash we could maybe replace the whole original bead with a
>>flash.utils.Proxy. But this will make things a bit complicated to read
>>and
>>maintain.
>>
>>
>>
>>
>>
>>--
>>View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>e
>>x-development.247.n4.nabble.com%2FRe-git-commit-flex-asjs-refs-heads-
>>d
>>evelop-Add-FileUploaderWithResponseData-tp63051p63139.html=02%7C01%7
>>C
>>%7Cbd5414b3ced9495c188908d4c8f0f59b%7Cfa7b1b5a7b34438794aed2c178decee1%7C
>>0
>>%7C0%7C636354384624691027=BGn1g0wbTZr7ikn3uuhcIGDGPEmSVWTwIF%2BlaF6
>>d
>>v8w%3D=0
>>Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] Use of typeof

[Harbs]

There is a mention of window in the NativeJSType enums. Not sure why it’s 
needed there.

global should already be in node.js (I think). I’m pretty sure it’s defined in 
the node typedefs

I don’t really care how it’s achieved, but by default (without doing any 
special imports) global should be recognized. (just like window is)

Right now, typing global into a FlexJS project targeting “JSFlex” or any one of 
the framework projects results in a compiler error. How do we fix that?

> On Jul 13, 2017, at 7:17 PM, Alex Harui  wrote:
> 
> IIRC, the compiler doesn't special case handling of that code.  "window"
> is defined in missing.js so the js.swc knows there is such an entity.  Is
> there any reason not to add a "global" to node.swc?
> 
> -Alex
> 
> On 7/13/17, 12:29 AM, "Harbs"  wrote:
> 
>> Right now, if you have code that looks like this, the compiler will
>> report and error and it will fail:
>> 
>> global[“foo”];
>> 
>> I would like for that to be legal code in a COMPILE::JS block and it
>> should compile to:
>> 
>> global[“foo”];
>> 
>> Exactly the same as window:
>> 
>> If you write:
>> window[“foo”];
>> 
>> It’s legal code and will compile to:
>> window[“foo”];
>> 
>> That’s it.
>> 
>>> On Jul 13, 2017, at 10:18 AM, Alex Harui 
>>> wrote:
>>> 
>>> I'm still not clear what changes are needed.
>>> 
>>> Are you trying to access APIs that are global but not defined in JS.SWC
>>> or
>>> Node.SWC?  Otherwise, the APIs on window/global should be defined in
>>> those
>>> SWCs.
>>> 
>>> I'm not sure what the test case is supposed to look like.
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 7/13/17, 12:11 AM, "Harbs"  wrote:
>>> 
 Electron has both window and global. Node has global and no window. I
 think CEF has window and no global. Browsers have window but not
 global.
 Depending on which environment you are writing for, you’re going to
 need
 either window or global for accessing global variables.
 
 I’m more concerned with general global access in Node than my specific
 use case. If general global access works, then that gives a solution
 for
 my specific case as well as an other arbitrary one where you’d use
 window
 in the browser.
 
 I think it’s fine to cross compile global[“foo”] to the exact same
 global[“foo”] in JS. In other words, the compiler should accept global
 with bracket notation and pass it through unchanged.
 
> On Jul 13, 2017, at 9:33 AM, Alex Harui 
> wrote:
> 
> I think the only thing the compiler does with "window" is allow you to
> use
> "window" to disambiguate between a "global" API and another API in a
> package with the same name.
> 
> And then the JS.SWC typedefs specify certain APIs.
> 
> AIUI, Electron is another runtime that has a window variable and you
> want
> to detect the difference between Browser, Node and Electron?  Or are
> you
> willing to just try to check for features instead?
> 
> If you can show what JS code you'd want to end up with we can look
> into
> changing the compiler so you can write AS to generate that JS.
> 
> Thanks,
> -Alex
> 
> On 7/12/17, 9:03 PM, "Harbs"  wrote:
> 
>> What do we currently do with window?
>> 
>> global in Node is the same as window in the browser. All global
>> variables
>> are attached to the global object.
>> 
>> global[“foo”] could compile to global[“foo”], global.foo, or just
>> plain
>> foo, and it all means the same thing.
>> 
>>> On Jul 13, 2017, at 2:14 AM, Alex Harui 
>>> wrote:
>>> 
>>> What AS do you want to write and what JS do you want as output?
>>> 
>>> -Alex
>>> 
>>> On 7/9/17, 12:53 AM, "Harbs"  wrote:
>>> 
 Checking for window will work for Node, but it will not work for
 Electron.
 
 I tried adding global to Falcon, but I was obviously going about it
 wrong, because what I tried did not work.
 
 This is not really high priority for me right now, so I’m moving on
 to
 something else…
 
> On Jul 6, 2017, at 3:05 AM, Alex Harui 
> wrote:
> 
> I've noticed lots of advice on the internet to use feature
> detection
> instead of browser/runtime detection.  Did you rule out doing
> that?
> Browsers may implement new features over time.
> 
> But otherwise, I see some clever tests that check for "window"
> and a
> few
> other things.
> 
> HTH,
> -Alex
> 
> On 7/5/17, 1:54 PM, "Harbs"  wrote:
> 
>> No. I 

Re: [FlexJS] Use of typeof

[Alex Harui]

IIRC, the compiler doesn't special case handling of that code.  "window"
is defined in missing.js so the js.swc knows there is such an entity.  Is
there any reason not to add a "global" to node.swc?

-Alex

On 7/13/17, 12:29 AM, "Harbs"  wrote:

>Right now, if you have code that looks like this, the compiler will
>report and error and it will fail:
>
>global[“foo”];
>
>I would like for that to be legal code in a COMPILE::JS block and it
>should compile to:
>
>global[“foo”];
>
>Exactly the same as window:
>
>If you write:
>window[“foo”];
>
>It’s legal code and will compile to:
>window[“foo”];
>
>That’s it.
>
>> On Jul 13, 2017, at 10:18 AM, Alex Harui 
>>wrote:
>> 
>> I'm still not clear what changes are needed.
>> 
>> Are you trying to access APIs that are global but not defined in JS.SWC
>>or
>> Node.SWC?  Otherwise, the APIs on window/global should be defined in
>>those
>> SWCs.
>> 
>> I'm not sure what the test case is supposed to look like.
>> 
>> Thanks,
>> -Alex
>> 
>> On 7/13/17, 12:11 AM, "Harbs"  wrote:
>> 
>>> Electron has both window and global. Node has global and no window. I
>>> think CEF has window and no global. Browsers have window but not
>>>global.
>>> Depending on which environment you are writing for, you’re going to
>>>need
>>> either window or global for accessing global variables.
>>> 
>>> I’m more concerned with general global access in Node than my specific
>>> use case. If general global access works, then that gives a solution
>>>for
>>> my specific case as well as an other arbitrary one where you’d use
>>>window
>>> in the browser.
>>> 
>>> I think it’s fine to cross compile global[“foo”] to the exact same
>>> global[“foo”] in JS. In other words, the compiler should accept global
>>> with bracket notation and pass it through unchanged.
>>> 
 On Jul 13, 2017, at 9:33 AM, Alex Harui 
 wrote:
 
 I think the only thing the compiler does with "window" is allow you to
 use
 "window" to disambiguate between a "global" API and another API in a
 package with the same name.
 
 And then the JS.SWC typedefs specify certain APIs.
 
 AIUI, Electron is another runtime that has a window variable and you
 want
 to detect the difference between Browser, Node and Electron?  Or are
you
 willing to just try to check for features instead?
 
 If you can show what JS code you'd want to end up with we can look
into
 changing the compiler so you can write AS to generate that JS.
 
 Thanks,
 -Alex
 
 On 7/12/17, 9:03 PM, "Harbs"  wrote:
 
> What do we currently do with window?
> 
> global in Node is the same as window in the browser. All global
> variables
> are attached to the global object.
> 
> global[“foo”] could compile to global[“foo”], global.foo, or just
>plain
> foo, and it all means the same thing.
> 
>> On Jul 13, 2017, at 2:14 AM, Alex Harui 
>> wrote:
>> 
>> What AS do you want to write and what JS do you want as output?
>> 
>> -Alex
>> 
>> On 7/9/17, 12:53 AM, "Harbs"  wrote:
>> 
>>> Checking for window will work for Node, but it will not work for
>>> Electron.
>>> 
>>> I tried adding global to Falcon, but I was obviously going about it
>>> wrong, because what I tried did not work.
>>> 
>>> This is not really high priority for me right now, so I’m moving on
>>> to
>>> something else…
>>> 
 On Jul 6, 2017, at 3:05 AM, Alex Harui 
 wrote:
 
 I've noticed lots of advice on the internet to use feature
detection
 instead of browser/runtime detection.  Did you rule out doing
that?
 Browsers may implement new features over time.
 
 But otherwise, I see some clever tests that check for "window"
and a
 few
 other things.
 
 HTH,
 -Alex
 
 On 7/5/17, 1:54 PM, "Harbs"  wrote:
 
> No. I was trying to use process to check whether it’s running in
>a
> Node
> runtime (such as Node or Electron). window does not have process.
> 
> I’m trying to add a class that lets the client know what
> environment
> it’s
> running in.
> 
> Adding global sounds like a good idea. Between window and
>global, I
> think
> that would offer a solution everywhere.
> 
>> On Jul 5, 2017, at 7:48 PM, Alex Harui
>>
>> wrote:
>> 
>> Sure, I know it wouldn't work at runtime, but it sounded like
>> Harbs
>> couldn't even get the compiler to accept 

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Harbs]

Here’s a fiddle trying to set pointer-events in various ways. Only one (with 
dot notation) works:
https://jsfiddle.net/Harbs/9c8zezx5/ 

> On Jul 13, 2017, at 5:51 PM, Harbs  wrote:
> 
> More information here:
> https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Properties_Reference 
> 
> 
>> On Jul 13, 2017, at 4:48 PM, Harbs > > wrote:
>> 
>> When specifying css via javascript, the naming is different than specifying 
>> using CSS files.
>> 
>> I’d be *very* surprised if the code works as-is.
>> 
>>> On Jul 13, 2017, at 3:23 PM, Justin Mclean >> > wrote:
>>> 
>>> Hi
>>> 
> + positioner.style["pointer-events"] = "none”;
 
 I think that should be positioner.style["pointerEvents"] = "none”;
>>> 
>>> The style is "pointer-events" [1] so I’m not sure why you would use 
>>> "pointerEvents”. I’ve tested ""pointer-events” and it works.
>>> 
>>> Thanks,
>>> Justin
>>> 
>>> 
>>> 1. https://developer.mozilla.org/en/docs/Web/CSS/pointer-events 
>>> 
>> 
> 

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Harbs]

More information here:
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Properties_Reference 


> On Jul 13, 2017, at 4:48 PM, Harbs  wrote:
> 
> When specifying css via javascript, the naming is different than specifying 
> using CSS files.
> 
> I’d be *very* surprised if the code works as-is.
> 
>> On Jul 13, 2017, at 3:23 PM, Justin Mclean  wrote:
>> 
>> Hi
>> 
 +  positioner.style["pointer-events"] = "none”;
>>> 
>>> I think that should be positioner.style["pointerEvents"] = "none”;
>> 
>> The style is "pointer-events" [1] so I’m not sure why you would use 
>> "pointerEvents”. I’ve tested ""pointer-events” and it works.
>> 
>> Thanks,
>> Justin
>> 
>> 
>> 1. https://developer.mozilla.org/en/docs/Web/CSS/pointer-events
> 

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Harbs]

I don’t see how this is PAYG. It’s more code for no reason.

> On Jul 13, 2017, at 3:25 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Any reason you didn’t just add this to the constructor?
> 
> PAYG - i.e. no need to do it until it added to the UI.
> 
> Thanks,
> Justin

Re: Flash Builder desktop debugging issue

[Fréderic Cox]

Thanks for the help Alex, I'll check it tomorrow when I am back in office

On Wed, Jul 12, 2017 at 5:20 PM, Alex Harui 
wrote:

> Location of mm.cfg is listed here [1]
>
> If mm.cfg is ok, next step is to use the command-line debugger.  For AIR
> apps, you have to launch bin/fdb from the SDK folder, then type 'r' and
> return.  This should cause the debugger to wait for the next runtime to
> launch.
>
> Then run the ads command you see in the launch details below.  The
> debugger report that it connected.  Use the 'c' command until the AIR app
> comes up.  If the AIR app just runs and nothing happened in the debugger,
> the next step is to use "bin/swfdump -abc"  on the SWF in bin-debug.  Look
> for 'debugline' and 'debugfile' in the output.  If it isn't there, then
> some how the build process is not placing debug information into the SWF.
> Then it is time to check all of your settings.
>
> HTH,
> -Alex
>
> [1]
> http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0b
> f69084
> -7fc9.html
>
> On 7/12/17, 1:34 AM, "Fréderic Cox"  wrote:
>
> >When I change my SDK it is giving me the same problem.
> >
> >Process terminated without establishing connection to debugger.
> >
> >trace1
> >trace2
> >
> >Launch command details:  "/Applications/Adobe Flash Builder 4.7/sdks/4.6.0
> >(AIR 3.8)/bin/adl" -runtime "/Applications/Adobe Flash Builder
> >4.7/sdks/4.6.0 (AIR 3.8)/runtimes/air/mac"
> >/Users/frederic/Desktop/Exuvis/Mediahuis/DebugTest/
> bin-debug/DebugTest-app
> >.xml
> >/Users/frederic/Desktop/Exuvis/Mediahuis/DebugTest/bin-debug
> >
> >So it must be something external, no?
> >
> >On Tue, Jul 11, 2017 at 6:08 PM, Fréderic Cox 
> >wrote:
> >
> >> Thanks a lot for your help.
> >>
> >> I have created a new project and the same problem arises so it has
> >>nothing
> >> to do with compiler options. I created a project DebugTest and in
> >> creationComplete I've put two traces and a breakpoint. The debugger does
> >> not connect and shows:
> >>
> >> Process terminated without establishing connection to debugger.
> >>
> >> trace1
> >> trace2
> >>
> >> Launch command details:
> >>/Users/frederic/ApacheFlex/sdk/4.15.0_AIR20/bin/adl
> >> -runtime /Users/frederic/ApacheFlex/sdk/4.15.0_AIR20/runtimes/air/mac
> >>
> >>/Users/frederic/Desktop/Exuvis/Mediahuis/DebugTest/
> bin-debug/DebugTest-ap
> >>p.xml
> >> /Users/frederic/Desktop/Exuvis/Mediahuis/DebugTest/bin-debug
> >>
> >> I have disabled all my chrome and firefox extensions but no luck.
> >>Should I
> >> restart my Mac? Going to try that now...
> >>
> >> Where do I find mm.cfg?
> >>
> >> Regards,
> >>
> >> Fréderic
> >>
> >> On Tue, Jul 11, 2017 at 5:38 PM, Alex Harui 
> >> wrote:
> >>
> >>> Hi Fréderic,
> >>>
> >>> The actual debugger is the same in Flash Builder.  Flash Builder has a
> >>> built-in debugger that tries to connect to a debugger Flash Player in
> >>>the
> >>> browser, or to the Air Debug Launcher (ADL).
> >>>
> >>> When you Run/Debug a Desktop app in Flash Builder, I think it should
> >>> always launch ADL.  I don't think there is any other way to set up the
> >>> launch.  If the app comes up but the debugger doesn't connect, you can
> >>> probably assume ADL is being launched.
> >>>
> >>> If the debugger isn't connecting to ADL, as Jeffry mentioned, if you
> >>>set
> >>> debug=false as a compiler option, the runtime will not try to connect
> >>>to
> >>> the debugger.
> >>>
> >>> Another way the debugger fails to connect is if some other Flash or AIR
> >>> application is also launching around the same time as your application.
> >>> The debugger isn't looking for your app specifically, it is looking for
> >>> the first new instance of a Flash or AIR runtime.  I've seen little
> >>> browser plugins fool the debugger.  I've seen SWFs in the preloader of
> >>>a
> >>> Flex app connect instead of the main app.  I've seen an Flash animation
> >>> embedded in the main app connect instead of the main app.
> >>>
> >>> Also, I've seen where the profiler is set up for launch as well.  Check
> >>> your mm.cfg file to see if the profiler is getting launched. Sometimes
> >>>if
> >>> a profiler session crashed or is aborted, the mm.cfg is not restored.
> >>>
> >>> HTH,
> >>> -Alex
> >>>
> >>> On 7/11/17, 8:11 AM, "Fréderic Cox"  wrote:
> >>>
> >>> >Thanks for the replies.
> >>> >
> >>> >The problem is related to AIR debugging on desktop. I did not change
> >>>my
> >>> >Apache Flex SDK so I really can't understand what caused the problem.
> >>> >
> >>> >Which debugger is used for AIR and where is it located?
> >>> >
> >>> >On Tue, Jul 11, 2017 at 3:41 PM, Harbs  wrote:
> >>> >
> >>> >> Same for me.
> >>> >>
> >>> >> > On Jul 11, 2017, at 4:18 PM, Jeffry Houser  >
> >>> >> wrote:
> >>> >> >
> >>> >> > To debug a browser based applications, I use Firefox.  I couldn't
> >>>get
> >>> 

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Harbs]

When specifying css via javascript, the naming is different than specifying 
using CSS files.

I’d be *very* surprised if the code works as-is.

> On Jul 13, 2017, at 3:23 PM, Justin Mclean  wrote:
> 
> Hi
> 
>>> +   positioner.style["pointer-events"] = "none”;
>> 
>> I think that should be positioner.style["pointerEvents"] = "none”;
> 
> The style is "pointer-events" [1] so I’m not sure why you would use 
> "pointerEvents”. I’ve tested ""pointer-events” and it works.
> 
> Thanks,
> Justin
> 
> 
> 1. https://developer.mozilla.org/en/docs/Web/CSS/pointer-events

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Justin Mclean]

Hi

>> +positioner.style["pointer-events"] = "none”;
> 
> I think that should be positioner.style["pointerEvents"] = "none”;

The style is "pointer-events" [1] so I’m not sure why you would use 
"pointerEvents”. I’ve tested ""pointer-events” and it works.

Thanks,
Justin


1. https://developer.mozilla.org/en/docs/Web/CSS/pointer-events

RE: git commit: [flex-asjs] [refs/heads/develop] - Add FileUploaderWithResponseData

[Yishay Weiss]

Generally speaking it feels like sometimes I need to insure the order of 
invocation. Since beads communicate with one another through events it’s 
difficult to achieve. Regarding the upload response data I understand your 
suggestion as follows (edges contain event names):

--uploadRequested-complete--modelChanged--

And for the case where the user isn’t interested in the response, just in the 
status:

---uploadRequested-complete-modelChanged--

Is that right?


From: Alex Harui
Sent: Wednesday, July 12, 2017 9:58 AM
To: dev@flex.apache.org
Subject: Re: git commit: [flex-asjs] [refs/heads/develop] - Add 
FileUploaderWithResponseData

I think I still don't understand.

It is ok for beads to require other beads.  If a ResponseData bead
requires a model with a slot for responseData and a controller that knows
to record that data, that's how you are supposed to "re-compose"
components.  There doesn't have to be one model or controller per
component.  The strand is a gathering place for small pieces to work
together.

I'm not sure what work CheckPermissions needs to do, but is totally fine
to split its work amongst a set of beads.

HTH,
-Alex

On 7/11/17, 11:21 PM, "yishayw"  wrote:

>Ideally we wouldn't have to record data that's never read. This may be an
>extreme case, but some users will want to know the response on an upload,
>while some will just want to make sure the status is ok. I'd rather not
>anticipate too many use cases when writing the strand and the model
>because
>I might end up with code that's never used. If the bead was responsible
>for
>both recording the response and exposing it to the user, we wouldn't have
>to
>do that.
>
>Perhaps a better example is permissions. I already have an Upload bead.
>Now
>I want an alert to pop up if the user is not permitted to upload. I'd like
>to be able to add a 'CheckPemissionsOnUpload' bead. Right now I don't see
>how to do that, instead I would probably have to replace 'UploadBead' with
>'UploadButCheckPermissionsBead'. This takes us away from composition and
>forces inheritance.
>
>Maybe we don't need to modify class definitions. I think it's enough to
>modify the bead instance. In JS we could simply replace the function, and
>in
>flash we could maybe replace the whole original bead with a
>flash.utils.Proxy. But this will make things a bit complicated to read and
>maintain.
>
>
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FRe-git-commit-flex-asjs-refs-heads-d
>evelop-Add-FileUploaderWithResponseData-tp63051p63139.html=02%7C01%7C
>%7Cbd5414b3ced9495c188908d4c8f0f59b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0
>%7C0%7C636354384624691027=BGn1g0wbTZr7ikn3uuhcIGDGPEmSVWTwIF%2BlaF6d
>v8w%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Flash builder is stucked at 57 %

[after24]

Hi Olaf, Hi Alex,

Firefox was the culprit, I uninstalled/installed it and it works again.

Thanks for your answers.

Vincent.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Flash-builder-is-stucked-at-57-tp63167p63210.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Harbs]

Any reason you didn’t just add this to the constructor?

I think all you need is:
mouseEnabled = false;

In Flash, “element” is a pointer to “this”.

Thanks,
Harbs

> On Jul 13, 2017, at 10:16 AM, jmcl...@apache.org wrote:
> 
> + COMPILE::SWF
> + override public function addedToParent():void
> + {
> + super.addedToParent();
> + (element as InteractiveObject).mouseEnabled = false;
> + }
> +

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Harbs]

> + positioner.style["pointer-events"] = "none”;

I think that should be positioner.style["pointerEvents"] = "none”;

Re: FlexJS Yeoman generator

[Olaf Krueger]

Great Josh, you should post it on the users list!

@All
Please don't forget that everybody can support this awesome guy by being a
patron [1]

Olaf

[1] https://www.patreon.com/josht






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

Re: [FlexJS] Use of typeof

[Harbs]

Right now, if you have code that looks like this, the compiler will report and 
error and it will fail:

global[“foo”];

I would like for that to be legal code in a COMPILE::JS block and it should 
compile to:

global[“foo”];

Exactly the same as window:

If you write:
window[“foo”];

It’s legal code and will compile to:
window[“foo”];

That’s it.

> On Jul 13, 2017, at 10:18 AM, Alex Harui  wrote:
> 
> I'm still not clear what changes are needed.
> 
> Are you trying to access APIs that are global but not defined in JS.SWC or
> Node.SWC?  Otherwise, the APIs on window/global should be defined in those
> SWCs.
> 
> I'm not sure what the test case is supposed to look like.
> 
> Thanks,
> -Alex
> 
> On 7/13/17, 12:11 AM, "Harbs"  wrote:
> 
>> Electron has both window and global. Node has global and no window. I
>> think CEF has window and no global. Browsers have window but not global.
>> Depending on which environment you are writing for, you’re going to need
>> either window or global for accessing global variables.
>> 
>> I’m more concerned with general global access in Node than my specific
>> use case. If general global access works, then that gives a solution for
>> my specific case as well as an other arbitrary one where you’d use window
>> in the browser.
>> 
>> I think it’s fine to cross compile global[“foo”] to the exact same
>> global[“foo”] in JS. In other words, the compiler should accept global
>> with bracket notation and pass it through unchanged.
>> 
>>> On Jul 13, 2017, at 9:33 AM, Alex Harui 
>>> wrote:
>>> 
>>> I think the only thing the compiler does with "window" is allow you to
>>> use
>>> "window" to disambiguate between a "global" API and another API in a
>>> package with the same name.
>>> 
>>> And then the JS.SWC typedefs specify certain APIs.
>>> 
>>> AIUI, Electron is another runtime that has a window variable and you
>>> want
>>> to detect the difference between Browser, Node and Electron?  Or are you
>>> willing to just try to check for features instead?
>>> 
>>> If you can show what JS code you'd want to end up with we can look into
>>> changing the compiler so you can write AS to generate that JS.
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 7/12/17, 9:03 PM, "Harbs"  wrote:
>>> 
 What do we currently do with window?
 
 global in Node is the same as window in the browser. All global
 variables
 are attached to the global object.
 
 global[“foo”] could compile to global[“foo”], global.foo, or just plain
 foo, and it all means the same thing.
 
> On Jul 13, 2017, at 2:14 AM, Alex Harui 
> wrote:
> 
> What AS do you want to write and what JS do you want as output?
> 
> -Alex
> 
> On 7/9/17, 12:53 AM, "Harbs"  wrote:
> 
>> Checking for window will work for Node, but it will not work for
>> Electron.
>> 
>> I tried adding global to Falcon, but I was obviously going about it
>> wrong, because what I tried did not work.
>> 
>> This is not really high priority for me right now, so I’m moving on
>> to
>> something else…
>> 
>>> On Jul 6, 2017, at 3:05 AM, Alex Harui 
>>> wrote:
>>> 
>>> I've noticed lots of advice on the internet to use feature detection
>>> instead of browser/runtime detection.  Did you rule out doing that?
>>> Browsers may implement new features over time.
>>> 
>>> But otherwise, I see some clever tests that check for "window" and a
>>> few
>>> other things.
>>> 
>>> HTH,
>>> -Alex
>>> 
>>> On 7/5/17, 1:54 PM, "Harbs"  wrote:
>>> 
 No. I was trying to use process to check whether it’s running in a
 Node
 runtime (such as Node or Electron). window does not have process.
 
 I’m trying to add a class that lets the client know what
 environment
 it’s
 running in.
 
 Adding global sounds like a good idea. Between window and global, I
 think
 that would offer a solution everywhere.
 
> On Jul 5, 2017, at 7:48 PM, Alex Harui 
> wrote:
> 
> Sure, I know it wouldn't work at runtime, but it sounded like
> Harbs
> couldn't even get the compiler to accept window["process"] which
> it
> should.
> 
> So, it should be ok to write:
> 
> if(typeof window !== "undefined")
> {
> theProcess = window["process"];
> }
> else
> 
> theProcess = global.process
> 
> But is there really a process property in the browser?
> 
> We could create or own single variable if we want.  How often do
> libraries
> need stuff in 

Re: [FlexJS] Bindable and consts

[Harbs]

Thanks.

I just (re)read it. I don’t think I quite understood it the first time around.

> On Jul 13, 2017, at 9:24 AM, Alex Harui  wrote:
> 
> See this background thread if you're
> interested [1]
> -Alex
> 
> [1] 
> https://lists.apache.org/thread.html/9802158cb9bf3b3737d7841ff950130d8e7a6e 
> 
> 10f563e1775aca3b5b@%3Cdev.flex.apache.org %3E

Re: [FlexJS] Use of typeof

[Alex Harui]

I'm still not clear what changes are needed.

Are you trying to access APIs that are global but not defined in JS.SWC or
Node.SWC?  Otherwise, the APIs on window/global should be defined in those
SWCs.

I'm not sure what the test case is supposed to look like.

Thanks,
-Alex

On 7/13/17, 12:11 AM, "Harbs"  wrote:

>Electron has both window and global. Node has global and no window. I
>think CEF has window and no global. Browsers have window but not global.
>Depending on which environment you are writing for, you’re going to need
>either window or global for accessing global variables.
>
>I’m more concerned with general global access in Node than my specific
>use case. If general global access works, then that gives a solution for
>my specific case as well as an other arbitrary one where you’d use window
>in the browser.
>
>I think it’s fine to cross compile global[“foo”] to the exact same
>global[“foo”] in JS. In other words, the compiler should accept global
>with bracket notation and pass it through unchanged.
>
>> On Jul 13, 2017, at 9:33 AM, Alex Harui 
>>wrote:
>> 
>> I think the only thing the compiler does with "window" is allow you to
>>use
>> "window" to disambiguate between a "global" API and another API in a
>> package with the same name.
>> 
>> And then the JS.SWC typedefs specify certain APIs.
>> 
>> AIUI, Electron is another runtime that has a window variable and you
>>want
>> to detect the difference between Browser, Node and Electron?  Or are you
>> willing to just try to check for features instead?
>> 
>> If you can show what JS code you'd want to end up with we can look into
>> changing the compiler so you can write AS to generate that JS.
>> 
>> Thanks,
>> -Alex
>> 
>> On 7/12/17, 9:03 PM, "Harbs"  wrote:
>> 
>>> What do we currently do with window?
>>> 
>>> global in Node is the same as window in the browser. All global
>>>variables
>>> are attached to the global object.
>>> 
>>> global[“foo”] could compile to global[“foo”], global.foo, or just plain
>>> foo, and it all means the same thing.
>>> 
 On Jul 13, 2017, at 2:14 AM, Alex Harui 
 wrote:
 
 What AS do you want to write and what JS do you want as output?
 
 -Alex
 
 On 7/9/17, 12:53 AM, "Harbs"  wrote:
 
> Checking for window will work for Node, but it will not work for
> Electron.
> 
> I tried adding global to Falcon, but I was obviously going about it
> wrong, because what I tried did not work.
> 
> This is not really high priority for me right now, so I’m moving on
>to
> something else…
> 
>> On Jul 6, 2017, at 3:05 AM, Alex Harui 
>> wrote:
>> 
>> I've noticed lots of advice on the internet to use feature detection
>> instead of browser/runtime detection.  Did you rule out doing that?
>> Browsers may implement new features over time.
>> 
>> But otherwise, I see some clever tests that check for "window" and a
>> few
>> other things.
>> 
>> HTH,
>> -Alex
>> 
>> On 7/5/17, 1:54 PM, "Harbs"  wrote:
>> 
>>> No. I was trying to use process to check whether it’s running in a
>>> Node
>>> runtime (such as Node or Electron). window does not have process.
>>> 
>>> I’m trying to add a class that lets the client know what
>>>environment
>>> it’s
>>> running in.
>>> 
>>> Adding global sounds like a good idea. Between window and global, I
>>> think
>>> that would offer a solution everywhere.
>>> 
 On Jul 5, 2017, at 7:48 PM, Alex Harui 
 wrote:
 
 Sure, I know it wouldn't work at runtime, but it sounded like
Harbs
 couldn't even get the compiler to accept window["process"] which
it
 should.
 
 So, it should be ok to write:
 
 if(typeof window !== "undefined")
 {
 theProcess = window["process"];
 }
 else
 
 theProcess = global.process
 
 But is there really a process property in the browser?
 
 We could create or own single variable if we want.  How often do
 libraries
 need stuff in window/global?  Classes that need it should be able
to
 use
 inject_html and run some JS that maps window to global or the
other
 way
 around.
 
 HTH,
 -Alex
 
 On 7/5/17, 6:43 AM, "Josh Tynjala"  wrote:
 
> Node.js doesn't have a window variable, so window["process"]
>won't
> work.
> They have a global variable instead.
> 
> I remember reading that there is a proposal for ECMAScript to
> standardize
> a

Re: [1/5] git commit: [flex-asjs] [refs/heads/develop] - FLEX-35337 place tool tip anchor point in the centre rather than the bottom right

[Harbs]

> On Jul 13, 2017, at 7:21 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> I noticed today that I was actually using ToolTips and your changes make my 
>> buttons very difficult to use as they are significantly obscured by the 
>> tooltips. Also, the tooltips are now under the mouse, so the text in not 
>> legible until you move the mouse out of the way. On small buttons this makes 
>> the tooltip disappear.
> 
> Seems like reason enough to revert the position change. I’ll change the bead 
> so you have some control over the position as neither default seems ideal.

Thanks.

> The flicker is only an issue because the tooltips are partially obscuring the 
> buttons and your code does not seem to resolve the flickering either.
> 
> The fixes I put were for the AS side. On the JS side there still an issue a 
> labels and mouse over don’t play well together and it happen when you mouse 
> over the text pixel and not the background pixels. We have the same issue 
> when trying to click on a label, this has come up beforehand is due to a 
> change in the SDK  but I couldn’t find where it was discussed.

Alex’s suggestion to make it “mouse invisible” should resolve this.

Re: [FlexJS] Use of typeof

[Harbs]

Electron has both window and global. Node has global and no window. I think CEF 
has window and no global. Browsers have window but not global. Depending on 
which environment you are writing for, you’re going to need either window or 
global for accessing global variables.

I’m more concerned with general global access in Node than my specific use 
case. If general global access works, then that gives a solution for my 
specific case as well as an other arbitrary one where you’d use window in the 
browser.

I think it’s fine to cross compile global[“foo”] to the exact same 
global[“foo”] in JS. In other words, the compiler should accept global with 
bracket notation and pass it through unchanged.

> On Jul 13, 2017, at 9:33 AM, Alex Harui  wrote:
> 
> I think the only thing the compiler does with "window" is allow you to use
> "window" to disambiguate between a "global" API and another API in a
> package with the same name.
> 
> And then the JS.SWC typedefs specify certain APIs.
> 
> AIUI, Electron is another runtime that has a window variable and you want
> to detect the difference between Browser, Node and Electron?  Or are you
> willing to just try to check for features instead?
> 
> If you can show what JS code you'd want to end up with we can look into
> changing the compiler so you can write AS to generate that JS.
> 
> Thanks,
> -Alex
> 
> On 7/12/17, 9:03 PM, "Harbs"  wrote:
> 
>> What do we currently do with window?
>> 
>> global in Node is the same as window in the browser. All global variables
>> are attached to the global object.
>> 
>> global[“foo”] could compile to global[“foo”], global.foo, or just plain
>> foo, and it all means the same thing.
>> 
>>> On Jul 13, 2017, at 2:14 AM, Alex Harui 
>>> wrote:
>>> 
>>> What AS do you want to write and what JS do you want as output?
>>> 
>>> -Alex
>>> 
>>> On 7/9/17, 12:53 AM, "Harbs"  wrote:
>>> 
 Checking for window will work for Node, but it will not work for
 Electron.
 
 I tried adding global to Falcon, but I was obviously going about it
 wrong, because what I tried did not work.
 
 This is not really high priority for me right now, so I’m moving on to
 something else…
 
> On Jul 6, 2017, at 3:05 AM, Alex Harui 
> wrote:
> 
> I've noticed lots of advice on the internet to use feature detection
> instead of browser/runtime detection.  Did you rule out doing that?
> Browsers may implement new features over time.
> 
> But otherwise, I see some clever tests that check for "window" and a
> few
> other things.
> 
> HTH,
> -Alex
> 
> On 7/5/17, 1:54 PM, "Harbs"  wrote:
> 
>> No. I was trying to use process to check whether it’s running in a
>> Node
>> runtime (such as Node or Electron). window does not have process.
>> 
>> I’m trying to add a class that lets the client know what environment
>> it’s
>> running in.
>> 
>> Adding global sounds like a good idea. Between window and global, I
>> think
>> that would offer a solution everywhere.
>> 
>>> On Jul 5, 2017, at 7:48 PM, Alex Harui 
>>> wrote:
>>> 
>>> Sure, I know it wouldn't work at runtime, but it sounded like Harbs
>>> couldn't even get the compiler to accept window["process"] which it
>>> should.
>>> 
>>> So, it should be ok to write:
>>> 
>>> if(typeof window !== "undefined")
>>> {
>>> theProcess = window["process"];
>>> }
>>> else
>>> 
>>> theProcess = global.process
>>> 
>>> But is there really a process property in the browser?
>>> 
>>> We could create or own single variable if we want.  How often do
>>> libraries
>>> need stuff in window/global?  Classes that need it should be able to
>>> use
>>> inject_html and run some JS that maps window to global or the other
>>> way
>>> around.
>>> 
>>> HTH,
>>> -Alex
>>> 
>>> On 7/5/17, 6:43 AM, "Josh Tynjala"  wrote:
>>> 
 Node.js doesn't have a window variable, so window["process"] won't
 work.
 They have a global variable instead.
 
 I remember reading that there is a proposal for ECMAScript to
 standardize
 a
 single variable that refers to window in the browser and global in
 Node.js,
 but that doesn't exist yet.
 
 - Josh
 
 On Tue, Jul 4, 2017 at 11:35 PM, Alex Harui
 
 wrote:
 
> What class in Core needs this dependency?  I think one drawback is
> that
> users of that class will need to add node.swc to their project
> dependencies.  But I don't think every consumer of Core will need

Re: [FlexJS] Bindable and consts

[Alex Harui]

Sort of.  That was part of the thread [1].  There was an attempt to use
@expose that resulted in other problems, so we went back to @export and []
access.  That was back in October 2016 and supposedly, access to static
accessors shouldn't have worked after that.

-Alex

On 7/12/17, 11:45 PM, "Greg Dove"  wrote:

>I have a vague recollection of needing some deprecated annotation @expose
>for static accessors to work in the past because @export did not work.
>Maybe it was related?
>
>-Greg
>[sent from my phone]
>
>On 13/07/2017 6:24 PM, "Alex Harui"  wrote:
>
>Well, I looked into this and this definitely falls into the category of
>"how did this ever work?"
>
>The use of [] access is on purpose.  When you use [Bindable], everything
>becomes a getter (and setter if writable) and for statics we have to use
>[] access to deal with GCC renaming.  See this background thread if you're
>interested [1]
>
>The reason it didn't work was that a FlexJS class had an exportSymbol near
>the end of the file, but other methods and variables earlier in the file
>with @export where being exported before the class's exportSymbol got
>called.  This meant that the export logic would build up a plain object of
>the @exports then the exportSymbol would wipe that out by replacing that
>plain object with a reference to the class.
>
>I moved the exportSymbol earlier in the file and things seem to work.  But
>I think this means that any access of static getters never worked before!?
>
>-Alex
>
>[1]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apa
>che.org%2Fthread.html%2F9802158cb9bf3b3737d7841ff950130d8e7a6e=02%7C0
>1%7C%7C5c4362c538094e9a25a508d4c9baba92%7Cfa7b1b5a7b34438794aed2c178decee1
>%7C0%7C0%7C636355251226219465=wE6H%2BFj%2FlpoH75PrBm69xDRfHyBp%2BlDh
>hT%2FFT13UnFE%3D=0
>10f563e1775aca3b5b@%3Cdev.flex.apache.org%3E
>
>
>
>On 7/10/17, 9:22 AM, "Harbs"  wrote:
>
>>Not urgent right now. Once I figured out what the problem was, I removed
>>the Bindable tag. It was not strictly necessary.
>>
>>In my case the public static const was not exported. Not sure why.
>>
>>I’m not sure that we always want to export these things either, but
>>that’s a whole ‘nother discussion that I keep putting off until we’re in
>>a better place.
>>
>>Harbs
>>
>>> On Jul 10, 2017, at 6:54 PM, Alex Harui 
>>>wrote:
>>>
>>> How urgent is this?  I'm trying to figure out why the compiler did not
>>> respond properly to bad MXML.
>>>
>>> I thought public APIs were all exported so they would survive getting
>>> renamed.  In the minified JS, the code will often access the renamed
>>> variable, but a tree of objects with properties also gets created.
>>>
>>> -Alex
>>>
>>> On 7/10/17, 2:12 AM, "Harbs"  wrote:
>>>
 It appears that this is the case with any public static getter.

 public static function get FOO():String{return “foo”}
 or
 public static function get FOO():Foo{return _foo}

 I don’t see any reason why bracket notation would be needed. Is this a
 throwback from before we had the get__ functions?

 Thanks,
 Harbs

> On Jul 9, 2017, at 11:27 PM, Harbs  wrote:
>
> I just discovered something:
>
> Foo.as:
> package com.acme.foobaz.model{
>[Bindable]public class Foo{
>static public const BAZ:String = “baz”;
>}
> }
>
> In some other class:
>
> if(baz == Foo.BAZ){//do something}
>
> compiles to:
> if(baz == com.acme.foobaz.model.Foo[“BAZ”])
>
> If you remove the [Bindable] meta tag on the Foo class, it compiles
>to:
> if(baz == com.acme.foobaz.model.Foo.BAZ)
>
> In the debug build, these two are functionally identical. However,
>when
> Google minifies the file, it has no way of knowing that Foo.BAZ is
>used.
> This results in calling  (assuming com.acme.foobaz.model.Foo becomes
>k)
> k.BAZ even though k.BAZ was optimized away and k.BAZ is undefined.
>
> Why does [Bindable] on a class cause the bracket notation to be used?
>
> Harbs

>>>
>>

Re: Flash builder is stucked at 57 %

[Olaf Krueger]

>only with one workspace, other workspaces are fine

Do you've already tried to re-create the workspace?
I've other weird issues with FB from time to time and re-creating the
workspace helps most of the time.

HTH,
Olaf




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Flash-builder-is-stucked-at-57-tp63167p63200.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Bindable and consts

[Greg Dove]

I have a vague recollection of needing some deprecated annotation @expose
for static accessors to work in the past because @export did not work.
Maybe it was related?

-Greg
[sent from my phone]

On 13/07/2017 6:24 PM, "Alex Harui"  wrote:

Well, I looked into this and this definitely falls into the category of
"how did this ever work?"

The use of [] access is on purpose.  When you use [Bindable], everything
becomes a getter (and setter if writable) and for statics we have to use
[] access to deal with GCC renaming.  See this background thread if you're
interested [1]

The reason it didn't work was that a FlexJS class had an exportSymbol near
the end of the file, but other methods and variables earlier in the file
with @export where being exported before the class's exportSymbol got
called.  This meant that the export logic would build up a plain object of
the @exports then the exportSymbol would wipe that out by replacing that
plain object with a reference to the class.

I moved the exportSymbol earlier in the file and things seem to work.  But
I think this means that any access of static getters never worked before!?

-Alex

[1]
https://lists.apache.org/thread.html/9802158cb9bf3b3737d7841ff950130d8e7a6e
10f563e1775aca3b5b@%3Cdev.flex.apache.org%3E



On 7/10/17, 9:22 AM, "Harbs"  wrote:

>Not urgent right now. Once I figured out what the problem was, I removed
>the Bindable tag. It was not strictly necessary.
>
>In my case the public static const was not exported. Not sure why.
>
>I’m not sure that we always want to export these things either, but
>that’s a whole ‘nother discussion that I keep putting off until we’re in
>a better place.
>
>Harbs
>
>> On Jul 10, 2017, at 6:54 PM, Alex Harui 
>>wrote:
>>
>> How urgent is this?  I'm trying to figure out why the compiler did not
>> respond properly to bad MXML.
>>
>> I thought public APIs were all exported so they would survive getting
>> renamed.  In the minified JS, the code will often access the renamed
>> variable, but a tree of objects with properties also gets created.
>>
>> -Alex
>>
>> On 7/10/17, 2:12 AM, "Harbs"  wrote:
>>
>>> It appears that this is the case with any public static getter.
>>>
>>> public static function get FOO():String{return “foo”}
>>> or
>>> public static function get FOO():Foo{return _foo}
>>>
>>> I don’t see any reason why bracket notation would be needed. Is this a
>>> throwback from before we had the get__ functions?
>>>
>>> Thanks,
>>> Harbs
>>>
 On Jul 9, 2017, at 11:27 PM, Harbs  wrote:

 I just discovered something:

 Foo.as:
 package com.acme.foobaz.model{
[Bindable]public class Foo{
static public const BAZ:String = “baz”;
}
 }

 In some other class:

 if(baz == Foo.BAZ){//do something}

 compiles to:
 if(baz == com.acme.foobaz.model.Foo[“BAZ”])

 If you remove the [Bindable] meta tag on the Foo class, it compiles
to:
 if(baz == com.acme.foobaz.model.Foo.BAZ)

 In the debug build, these two are functionally identical. However,
when
 Google minifies the file, it has no way of knowing that Foo.BAZ is
used.
 This results in calling  (assuming com.acme.foobaz.model.Foo becomes
k)
 k.BAZ even though k.BAZ was optimized away and k.BAZ is undefined.

 Why does [Bindable] on a class cause the bracket notation to be used?

 Harbs
>>>
>>
>

Re: [FlexJS] Use of typeof

[Alex Harui]

I think the only thing the compiler does with "window" is allow you to use
"window" to disambiguate between a "global" API and another API in a
package with the same name.

And then the JS.SWC typedefs specify certain APIs.

AIUI, Electron is another runtime that has a window variable and you want
to detect the difference between Browser, Node and Electron?  Or are you
willing to just try to check for features instead?

If you can show what JS code you'd want to end up with we can look into
changing the compiler so you can write AS to generate that JS.

Thanks,
-Alex

On 7/12/17, 9:03 PM, "Harbs"  wrote:

>What do we currently do with window?
>
>global in Node is the same as window in the browser. All global variables
>are attached to the global object.
>
>global[“foo”] could compile to global[“foo”], global.foo, or just plain
>foo, and it all means the same thing.
>
>> On Jul 13, 2017, at 2:14 AM, Alex Harui 
>>wrote:
>> 
>> What AS do you want to write and what JS do you want as output?
>> 
>> -Alex
>> 
>> On 7/9/17, 12:53 AM, "Harbs"  wrote:
>> 
>>> Checking for window will work for Node, but it will not work for
>>>Electron.
>>> 
>>> I tried adding global to Falcon, but I was obviously going about it
>>> wrong, because what I tried did not work.
>>> 
>>> This is not really high priority for me right now, so I’m moving on to
>>> something else…
>>> 
 On Jul 6, 2017, at 3:05 AM, Alex Harui 
wrote:
 
 I've noticed lots of advice on the internet to use feature detection
 instead of browser/runtime detection.  Did you rule out doing that?
 Browsers may implement new features over time.
 
 But otherwise, I see some clever tests that check for "window" and a
few
 other things.
 
 HTH,
 -Alex
 
 On 7/5/17, 1:54 PM, "Harbs"  wrote:
 
> No. I was trying to use process to check whether it’s running in a
>Node
> runtime (such as Node or Electron). window does not have process.
> 
> I’m trying to add a class that lets the client know what environment
> it’s
> running in.
> 
> Adding global sounds like a good idea. Between window and global, I
> think
> that would offer a solution everywhere.
> 
>> On Jul 5, 2017, at 7:48 PM, Alex Harui 
>> wrote:
>> 
>> Sure, I know it wouldn't work at runtime, but it sounded like Harbs
>> couldn't even get the compiler to accept window["process"] which it
>> should.
>> 
>> So, it should be ok to write:
>> 
>> if(typeof window !== "undefined")
>> {
>>  theProcess = window["process"];
>> }
>> else
>> 
>>  theProcess = global.process
>> 
>> But is there really a process property in the browser?
>> 
>> We could create or own single variable if we want.  How often do
>> libraries
>> need stuff in window/global?  Classes that need it should be able to
>> use
>> inject_html and run some JS that maps window to global or the other
>> way
>> around.
>> 
>> HTH,
>> -Alex
>> 
>> On 7/5/17, 6:43 AM, "Josh Tynjala"  wrote:
>> 
>>> Node.js doesn't have a window variable, so window["process"] won't
>>> work.
>>> They have a global variable instead.
>>> 
>>> I remember reading that there is a proposal for ECMAScript to
>>> standardize
>>> a
>>> single variable that refers to window in the browser and global in
>>> Node.js,
>>> but that doesn't exist yet.
>>> 
>>> - Josh
>>> 
>>> On Tue, Jul 4, 2017 at 11:35 PM, Alex Harui
>>> 
>>> wrote:
>>> 
 What class in Core needs this dependency?  I think one drawback is
 that
 users of that class will need to add node.swc to their project
 dependencies.  But I don't think every consumer of Core will need
 node.swc.
 
 But first, why didn't window["process"] work?  In theory Falcon
will
 let
 you access anything off of window.  We could also add global if we
 want.
 Or maybe we should only allow global and have some bootstrap code
 that
 maps global to window?
 
 -Alex
 
 On 7/4/17, 2:09 PM, "Harbs"  wrote:
 
> Actually, I see that the Node typedefs has all the process
> declarations
> in global.js.
> 
> Is there an issue with adding a dependency in CoreJS to node.swc?
> 
> Should a class that has this dependency go somewhere else? (I
>don’t
> really see an issue with adding the dependency, but I’m throwing
> this
 out
> in case I’m missing something.)
> 
> Harbs
> 

Re: [FlexJS] Bindable and consts

[Alex Harui]

Well, I looked into this and this definitely falls into the category of
"how did this ever work?"

The use of [] access is on purpose.  When you use [Bindable], everything
becomes a getter (and setter if writable) and for statics we have to use
[] access to deal with GCC renaming.  See this background thread if you're
interested [1]

The reason it didn't work was that a FlexJS class had an exportSymbol near
the end of the file, but other methods and variables earlier in the file
with @export where being exported before the class's exportSymbol got
called.  This meant that the export logic would build up a plain object of
the @exports then the exportSymbol would wipe that out by replacing that
plain object with a reference to the class.

I moved the exportSymbol earlier in the file and things seem to work.  But
I think this means that any access of static getters never worked before!?

-Alex

[1] 
https://lists.apache.org/thread.html/9802158cb9bf3b3737d7841ff950130d8e7a6e
10f563e1775aca3b5b@%3Cdev.flex.apache.org%3E
 


On 7/10/17, 9:22 AM, "Harbs"  wrote:

>Not urgent right now. Once I figured out what the problem was, I removed
>the Bindable tag. It was not strictly necessary.
>
>In my case the public static const was not exported. Not sure why.
>
>I’m not sure that we always want to export these things either, but
>that’s a whole ‘nother discussion that I keep putting off until we’re in
>a better place.
>
>Harbs
>
>> On Jul 10, 2017, at 6:54 PM, Alex Harui 
>>wrote:
>> 
>> How urgent is this?  I'm trying to figure out why the compiler did not
>> respond properly to bad MXML.
>> 
>> I thought public APIs were all exported so they would survive getting
>> renamed.  In the minified JS, the code will often access the renamed
>> variable, but a tree of objects with properties also gets created.
>> 
>> -Alex
>> 
>> On 7/10/17, 2:12 AM, "Harbs"  wrote:
>> 
>>> It appears that this is the case with any public static getter.
>>> 
>>> public static function get FOO():String{return “foo”}
>>> or
>>> public static function get FOO():Foo{return _foo}
>>> 
>>> I don’t see any reason why bracket notation would be needed. Is this a
>>> throwback from before we had the get__ functions?
>>> 
>>> Thanks,
>>> Harbs
>>> 
 On Jul 9, 2017, at 11:27 PM, Harbs  wrote:
 
 I just discovered something:
 
 Foo.as:
 package com.acme.foobaz.model{
[Bindable]public class Foo{
static public const BAZ:String = “baz”;
}
 }
 
 In some other class:
 
 if(baz == Foo.BAZ){//do something}
 
 compiles to:
 if(baz == com.acme.foobaz.model.Foo[“BAZ”])
 
 If you remove the [Bindable] meta tag on the Foo class, it compiles
to:
 if(baz == com.acme.foobaz.model.Foo.BAZ)
 
 In the debug build, these two are functionally identical. However,
when
 Google minifies the file, it has no way of knowing that Foo.BAZ is
used.
 This results in calling  (assuming com.acme.foobaz.model.Foo becomes
k)
 k.BAZ even though k.BAZ was optimized away and k.BAZ is undefined.
 
 Why does [Bindable] on a class cause the bracket notation to be used?
 
 Harbs
>>> 
>> 
>