Re: Package, Class and Method renaming

I’ll give it a go and see. > On Aug 9, 2017, at 8:31 AM, Alex Harui wrote: > > I don't think getters and setters get renamed because they are keys in the > Object.defineProperties data structure. I'm wondering if that will be > enough obfuscation for you or not. > >

Re: Package, Class and Method renaming

The problem is as follows: Taking textInput as an example, the MXML gets compiled into the following: textInput: { /** @this {com.printui.view.components.PaletteSlider} */ get: function() { return this.textInput_; }, /** @this {com.printui.view.components.PaletteSlider} */

Re: Package, Class and Method renaming

TextField has already this bead, so there is no need to add it. If TextField look bad once you run app without it - that would be a bug - maybe similar to menu where you had to add UpgradeElement after "beadsAdded". Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in

Re: Package, Class and Method renaming

Harbs, Questions out of scope of your problem: 1) Is this whole component is created dynamically ? I mean new MyComponent()? 2) MDL TextField has UpgradeElement and you are adding it in MXML - didn't you get upgrade? Something went wrong? Piotr - Apache Flex PMC piotrzarzyck...@gmail.com

Re: Package, Class and Method renaming

It’s used elsewhere in MXML and it works just fine. The whole component which has this subcomponent is added at runtime which is why I think the UpgradeElement bead was necessary. The only issue I ran into was with the renaming when using the new option for leaving out @exports. > On Aug 9,

Re: [FlexJS][Docs] Started with some docs using a github repo

+1. Here’s some topics that we need: 1. Different Layout beads and what they do. 2. What beads can be applied to which components 3. List of components and differences between them (i.e. Container vs Group) There’s probably much more, but these come immediately to mind. > On Aug 9, 2017, at

[FlexJS][Docs] Started with some docs using a github repo

Hi guys, it seems to me that since Adobe announced the EOL of FlashPlayer there's some more interest in FlexJS. And it also seems to me that is still not so easy to get in touch with FlexJS for others. One reason is probably the lack of the documentation. My feeling is that some more

Re: Package, Class and Method renaming

I just compiled with the new option and it appears to work. Yay. On the other hand, only functions and variables are being minified. getters and setters (which is a very large percentage of the signature of my code) is not. It looks like that adds the @exports for non-mxml files as well. Can we

Re: Package, Class and Method renaming

Hmm. I thought GCC didn't rename those. Anyway, I added back the @export. See if that works for you and then see if you think there is enough obfuscation. Thanks, -Alex On 8/9/17, 12:45 AM, "Harbs" wrote: >The problem is as follows: > >Taking textInput as an example,

Re: Package, Class and Method renaming

The change I just made should only be for MXML. But I think I saw that I never did remove the @export for getters and setters in AS. However, doing so would probably break MXML setting of those properties. I don't think you can tell when compiling a SWC which properties someone is going to use

Re: [FlexJS][Docs] Started with some docs using a github repo

Data Binding needs special coverage because it requires some getting used to. I’m not sure what the status of formatters and validators are. I think pretty weak at the moment. We’re using the MDL dialog. Another good topic is the fact that there’s a big difference between the behavior of

Re: [FlexJS][Docs] Started with some docs using a github repo

please add few pages on following topics. These are commonly used in enterprise applications. FlexJS Data Binding Formatters - Date Formatter , Number Formatter etc Validators - StringValidator, DateValidator etc Popupwindow or Dialog in FlexJS File Browse, Upload and Download HTTPService

Re: Package, Class and Method renaming

> On Aug 9, 2017, at 11:56 PM, Alex Harui wrote: > > The change I just made should only be for MXML. But I think I saw that I > never did remove the @export for getters and setters in AS. However, > doing so would probably break MXML setting of those properties. > >

Re: Package, Class and Method renaming

I've seen GCC not track renames before. The Object.defineProperty is just a data structure and doesn't add to the set of APIs for a class definition. I just realized that the class names are used by SimpleCSSValuesImpl to determine the type selectors. So if you rename those strings you will

Re: Package, Class and Method renaming

I hate to visit this topic again, but I’m not sure I understand why we’re defining members the way we are. There’s two ways to define getters and setters. One is using Object.defineProperties. The second is by using object literals.[1] I believe browser support of the two are the same. Object

Re: Package, Class and Method renaming

I don't think GCC knows how to handle the object literal pattern. It doesn't seem to know about using the object literal for Object.defineProperties. GCC sometimes creates a temp var for foo.prototype. Not quite sure when/why, but the minified output isn't always repeating foo.prototype for

Re: [FlexJS][Docs] Started with some docs using a github repo

I recommend including a review of basic MXML language features in the getting started material. Things like binding, states, and even just how to add children to containers, listen to events, and things like that. It's good for people completely new to Flex/FlexJS, but I think it's also important