Re: FlexJS Bead dilemma

I was thinking the wrapper would just wait for the show event then set the strand on the actual layout bead. I'm not sure how much actually would need to be proxied or forwarded in that case. Or maybe the wrapper could just put the actual layout bead on the strand. Just tossing ideas around...

Re: FlexJS Bead dilemma

That would make it a pretty thick wrapper. It would have to dispatch all the events that layout beads expect ,and implement ILayoutChild and ILayoutParent. Have a look at LayoutBase to see the dependencies on the strand assumed by most layouts (and there are probably more in the concrete

Re: FlexJS Applying a bead by default

I suppose it is technically possible, but IMO, the compiler should not be generating code. Right now, it mostly generates data, leaving it up to the framework to run code based on the data. Also, the compiler currently does not think about the CSS it converts to data. However, you reminded me

Re: FlexJS Applying a bead by default

Why can’t the compiler use the CSS declarations to add beads to a beads array in MXML? I think it’s an acceptable compromise that injectable beads in CSS would only work for MXML files. > On Aug 8, 2017, at 12:32 AM, Alex Harui wrote: > > All of the implementations

Re: FlexJS Applying a bead by default

All of the implementations I can think of add just-in-case code to check for a CSS property and/or check for an array. I suppose you could write some code that watches for changes to the DOM and adds a bead as things get added to the DOM. In your specific example, you want to customize layout

Re: FlexJS Applying a bead by default

Yeah. But we really should have a way to declare beads that are injected. Since we are already using CSS files to declare beads of specific types, maybe we can abuse CSS a bit more and allow declaring an array of beads there? Either way, I think the code which delays layout of hidden elements

Re: FlexJS Applying a bead by default

I hear you, but IMO, that's PAYG. Otherwise we would keep adding little bits of "just-in-case" code and end up with the same problems as regular Flex. UIBase knows to look for a model, view and controller. Container also looks for Layout. We don't want just-in-case code looking for other

Re: FlexJS Applying a bead by default

I actually just tried that, and it all blew up. I'll probably figure out why soon... It feels broken that I have to create my own Container just to get layout to happen when it becomes visible. > On Aug 7, 2017, at 11:55 PM, Alex Harui wrote: > > IMO, you should

Re: FlexJS Applying a bead by default

IMO, you should create a different Container (probably a cheap subclass of Container) and apply the bead in the constructor or fetch it from CSS in addedtoParent(). -Alex On 8/7/17, 1:12 PM, "Harbs" wrote: >I would like to apply a bead (LayoutOnShow) to every Container

Re: Comparison of type inconsistencies

I find it very tedious to write in the wiki. Google Docs is much more user friendly to me. We can copy it to wherever we want… > On Aug 7, 2017, at 11:34 PM, piotrz wrote: > > Hi Harbs, > > It sounds interesting - I've looked into it briefly, but will do this more

Re: FlexJS Model beads

If most apps are paying for removeBead just-in-case, we should take it. Last time this topic came up my suggestion was to turn removeBead into a utility function. That way those who really do need it can pay for it. The model setter probably could use some improvements. It shouldn't need change

Re: FlexJS Model beads

Great subject. I think bead remove api can bring us more damage than benefits. It won't be easy clean up some resources after remove. If we would like to use extensively we might need each time to do something with our class before removing. - It could be painful... Piotr - Apache

Re: Comparison of type inconsistencies

Hi Harbs, It sounds interesting - I've looked into it briefly, but will do this more soon. I'm wondering why you didn't start this document on our confluence. I hope it will land it there finally :) Thank you, Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in

FlexJS Applying a bead by default

I would like to apply a bead (LayoutOnShow) to every Container in my app. I know I can subclass Container and add the bead using AS (or mxml), but I’d like to keep my mxml markup and just inject the bead. I think I want to use CSS to do that, but I cannot figure out how to specify a bead which

Re: FlexJS Model beads

I’d be wary of taking out removeBead. The bead lifecycle is pretty basic, and I’m not sure PAYG should be applied to that. I didn’t run into any scenario, I just noticed the following code in Strand.as: public function set model(value:IBeadModel):void { if (_model != value) {

Image caching

I had some code in my old Flex application to load and cache image files. The code used Loader and then created a Bitmap object from the downloaded image file. Can anyone suggest the possibilities for how I could approach this process in FlexJS, or point me to an example?

Re: FlexJS Bead dilemma

A bead could have a property which is another bead. Of course, I could be wrong... -Alex On 8/7/17, 11:13 AM, "yishayw" wrote: >Alex Harui-2 wrote >> A fancier alternative would be a bead that wraps a layout bead and adds >> the visible check.

Re: FlexJS Model beads

I would not expect a need to switch models at runtime, so clean up after removal shouldn't be needed. Honestly, I'd try to prevent any beads from being swapped at runtime unless you are willing to pay for the cost. I've been thinking we should take out the removeBead API. What kind of scenario

Re: FlexJS Bead dilemma

Alex Harui-2 wrote > A fancier alternative would be a bead that wraps a layout bead and adds > the visible check. That might be the best way to apply PAYG. Can you explain what you mean? How would you wrap a bead? -- View this message in context:

Comparison of type inconsistencies

Here’s the promised doc. I still need to fill in Numbers Strings and Objects, but it’s a start… Anyone who wants to help fill in the details, is welcome to… https://docs.google.com/document/d/1xKH9nIF68pZQD0W6H39PAW_0BeVkAffoWCoYxKDekj0/edit?usp=sharing

FlexJS Model beads

Studying the bead architecture it looks to me like IBeadModels should never attach event listeners. (Strand allows for setting a new model and does not allow for cleaning up event listeners on the old model.) Is that right?

Re: FlexJS Random crazy thought

Combining Josh’s idea and this one sounds really interesting. > It is probably technically possible. But would it attract TS folks? I don’t know, but there’s lots of advantages to Flex that might attract folks if they could use a language they’re comfortable with. I’m not sure how well

Re: FlexJS MXML ids and classNames - FLEX-35310

I pushed some code that tries to implement a "localId" property. It seemed to work in a simple test. -Alex On 8/3/17, 10:58 AM, "piotrz" wrote: >Hi All, > >This issue started to be real blocker for my client's application. If we >could ask anyone from compiler sight

Re: FlexJS Random crazy thought

Sure, trying to replicate the TS compiler in our code base would be a lot of work especially if we wanted to also get SWF output. But I think for JS-only output there is a possible shortcut where we replace Google Closure Compiler with the TS compiler and essentially pass through the TS code. Of

Re: [1/2] git commit: [flex-asjs] [refs/heads/develop] - Upgrade should wait for other beads (e.g. IDataProviderItemRendererMapper) to do their thing

Harbs, Cool! If you will have after refactor in the base class registration for those events "beadsAdded" or "initComplete" my point is that try to reuse it in Menu. Thanks, Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in context:

Re: FlexJS Random crazy thought

I've considered the idea of extending the TypeScript compiler to understand MXML, and elements would contain TypeScript instead of ActionScript. Creating a new compiler for TypeScript would be a massive effort (even considering the similarities between ActionScript and TypeScript), so it would be

Re: Package, Class and Method renaming

From the output side, it probably isn't hard, but there is no way succinct way to tell the compiler which classes should use @export or not. You could annotate the class definitions, but then you can't choose to output @export without changing source. Why do you think we need per-class control

Re: FlexJS Random crazy thought

It is probably technically possible. But would it attract TS folks? Other crazy ideas along these lines are: 1) have FalconJX output TS as well as JS 2) extend AS with some of the popular TS features 3) make sure it is really easy to use TS libraries in FlexJS. My 2 cents, -Alex On 8/7/17,

Re: Package, Class and Method renaming

Cool. How difficult would it be to allow this on a class-by-class basis? > On Aug 7, 2017, at 6:35 PM, Alex Harui wrote: > > First thing I will do, though, is allow turning off @export output on > entire compiler sessions. That might allow you to have your text

Re: Package, Class and Method renaming

Calling get__ and set__ function instead of accessing properties makes for very ugly output. That's how the original output was before we switched to using object.defineProperties and getters and setters. I'd rather not go back. Simple things like: Foo.someInt++ Become:

FlexJS Random crazy thought

I was thinking about how we could increase adoption of FlexJS and I had a thought: How crazy would it be to make Falcon understand TypeScript? TypeScript is currently very popular for many of the reasons that we like ActionScript. The difference is that ActionScript is not the current fad.

Re: Package, Class and Method renaming

> On Aug 7, 2017, at 5:52 PM, Alex Harui wrote: > > GCC has some static flow analysis, so yes, they can detect unused > functions, but I don't think it can detect bracket access to functions any > better than bracket access to properties, both of which are allowed in

Re: Package, Class and Method renaming

GCC has some static flow analysis, so yes, they can detect unused functions, but I don't think it can detect bracket access to functions any better than bracket access to properties, both of which are allowed in AS and JS. FalconJX doesn't call GCC on the command line. It uses a Java API. I

Re: FlexJS Express Components

You make good points. The Express package is in its infancy. I packaged things together that were, I felt, the most common combinations, such as all Views and Container classes have data binding. This also means Containers have scrolling with the idea that you would use Group if you did not want

Re: [1/2] git commit: [flex-asjs] [refs/heads/develop] - Upgrade should wait for other beads (e.g. IDataProviderItemRendererMapper) to do their thing

DataContainerBase is a mess. I’m planning on reorganizing that when I finish my work with the strand branch. The problem here was that the bead was added too soon. > On Aug 7, 2017, at 3:02 PM, Piotr Zarzycki wrote: > > Yishay, > > Please check DataContainer which

Re: [1/2] git commit: [flex-asjs] [refs/heads/develop] - Upgrade should wait for other beads (e.g. IDataProviderItemRendererMapper) to do their thing

Yishay, Please check DataContainer which is extended by List for Menu. It may already had functions which you could override. Thanks, Piotr On Mon, Aug 7, 2017, 13:28 wrote: > Repository: flex-asjs > Updated Branches: > refs/heads/develop 8d6d7ca84 -> dee26275e > > >

Re: Package, Class and Method renaming

Yishay came across this post: https://stackoverflow.com/questions/10433716/google-closure-compilers-advanced-optimizations-option I wonder if there’s some way to use the property_map options to

Re: Package, Class and Method renaming

Another case which seems to need exports is any property used in MXML. It seems like the low hanging fruit would be to allow some kind of markup to specify classes which don’t need exports. Rewriting constants to literals is another one which should be pretty easy to solve. > On Aug 7, 2017,

Re: Package, Class and Method renaming

Dynamic access (aka square bracket access) is used in data binding, but people use it for other things as well. The really hard case involves "string math" where you access something like foo[someValue + "label"]. It is hard to know that "enUSLabel" and "frFRLabel" should not be renamed. And