Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

I'm going to work on this utility to generate AS classes from a JSON result today unless someone is already working on it. -Alex On 2/7/18, 11:13 AM, "Alex Harui" wrote: >Two more thoughts on this utility. I think you create a UID for each >child class. I think the

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

Sent from my iPhone > On Feb 8, 2018, at 2:10 PM, Alex Harui wrote: > > We can "leave it as it was" by making SIMPLE_OPTIMIZATIONS the default. > The difference between Flex and Royale is that Royale currently crunches > your code through the Google Closure Compiler

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

We can "leave it as it was" by making SIMPLE_OPTIMIZATIONS the default. The difference between Flex and Royale is that Royale currently crunches your code through the Google Closure Compiler with ADVANCED_OPTIMIZATIONS and that messes up how you use plain objects. IMO, there is enough to gain

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

but why to complicate this so much? I think we always had in Flex/Flash the opportunity to make this without any additional config. Why not left it as it always was? thanks 2018-02-08 19:48 GMT+01:00 Alex Harui : > I'm not disagreeing. I think the question is whether

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

I'm not disagreeing. I think the question is whether we need yet another compiler option to generate bracket notation for objects or just ask folks to use SIMPLE_OPTIMIZATIONS. And whether we switch to SIMPLE_OPTIMIZATIONS by default. I can think of lots of other things to work on besides this

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

Nothing frustrated me more about Royale/FlexJS than the fact that I couldn't use untyped objects without bracket notation. It's a very bad user experience when trying to consume JSON, or even when choosing to create my own object literals. While it's a good best practice to create value

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

Two more thoughts on this utility. I think you create a UID for each child class. I think the UID can consist of the sorted property values and their types so for the snippet below the UID would be: "baseClassname:String;description:String;members:Array;qname:String;tags:Ar ray;type:String;"

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

Pretty sure something like this was done for Flash Builder. You could direct FB to generate ValueObjects from a WSDL. I'm imagining an AIR app that lets you specify a path to an output folder and a class name and lets you paste a JSON result. If you look at the ASDoc structure for

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

The java Jackson parser supports metadata based specification that can tell the deserializer to use a custom parser for specific sub properties. https://fasterxml.github.io/jackson-annotations/javadoc/2.0.0/com/fasterxml/jackson/annotation/JsonSetter.html This site has a pretty good rundown on

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

I’m really not sure how you plan on going about strongly typing hierarchical data. > On Feb 6, 2018, at 7:13 PM, Gabe Harbs wrote: > > What kind of utility do you have in mind? > > >> On Feb 6, 2018, at 7:09 PM, Alex Harui wrote: >> >> Don't

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

What kind of utility do you have in mind? > On Feb 6, 2018, at 7:09 PM, Alex Harui wrote: > > Don't bother making VO's by hand for ASDoc. Let's write a utility to > generate it. It will save everyone time. If you want to see > bin/js-release, change the build to

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

Don't bother making VO's by hand for ASDoc. Let's write a utility to generate it. It will save everyone time. If you want to see bin/js-release, change the build to not use ADVANCED_OPTIMIZATIONS for now. There are lots of reasons to avoid using plain Object in a Royale app other than as a

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

Huh? I don’t see how it’s possible to avoid Object completely. Even using VOs require constructing them from Objects when coming from outside sources. Again: I’m not arguing against using VOs when possible/practical. I’m just arguing that use of dot notation on Objects shouldn’t blow up your

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

Good catch. I fixed that. Actually, you are arguing in favor of ValueObjects. The error was there because commitObj was a plain Object so the compiler couldn't understand more about it. We want to not have any plain objects in a Royale app. They only create potential problems. In fact, maybe

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

To illustrate that the VO solution is also error prone, I’m pretty sure that this page has a mistake: http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/RoyaleDocs_Staging/lastSuccessfulBuild/artifact/_site/create-an-application/application-tutorial/value-objects.html

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

Related: On this page: http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/RoyaleDocs_Staging/lastSuccessfulBuild/artifact/_site/create-an-application/application-tutorial/data.html

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

I'm not sure how solution should look like, but in case of going by the parse path I have raised some time ago jira [1]. Maybe it is a good place to refresh that. [1] https://issues.apache.org/jira/browse/FLEX-35297 Thanks, Piotr 2018-02-06 10:14 GMT+01:00 Gabe Harbs : >

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

I’m suggesting we have a compiler option to do it for all Object-typed properties. This problem is not limited to objects coming from JSON. The bracket access gets converted to dot access when google minifies the code, so there’s no effect on the minified code other than preventing the

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

I'm not convinced we can know when to generate obj.property vs obj["property"] unless we do it for all Objects, not just ones that came from JSON. Or for all property access. And that is at least 3 extra characters per access for anything that isn't JSON. I would rather we find ways to make use

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

Are you sure Angular and React minify your code instead of running it against their minified framework? -Alex On 2/5/18, 11:22 PM, "Gabe Harbs" wrote: >> Maybe I'm missing something. I don't think Royale has any extra >>problems >> with JSON objects than other JS

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

Maybe I'm missing something. I don't think Royale has any extra problems with JSON objects than other JS Frameworks have. If you want to minify, you have to use brackets and strings. If you don't want to minify, then you don't need to worry about that. Am I wrong about that? JSON has

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

An additional point: How do you propose handling json that’s multiple levels deep? Walk the json and construct VOs on each level? That seems to me just as bad as the problem. Imagine you just want foo.baz.thingy.uid? You’d need to create a VO of foo, baz and thingy or be forced to use

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

In theory, everything you say is true. It might even be good practice. I’m telling you that this was a pain point when migrating my app. Simply declaring types as VOs didn't solve the problem for me. The way I’ve found that’s needed to solve the problem was passing the object literal into a VO

JSON Objects renaming (was Re: ASDoc, Routing, Releases)

It was great to skip type-checking in Flash at times, but the runtime was also strongly typed. Also, JS was not a practical language for Flash. It is more risky to do skip type-checking in Royale for JS. These new cars with lane warnings are a rough analogy. They only let you be less attentive