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

[Alex Harui]

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 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:A
>r
>ray;type:String;"
>
>Then before creating a new child class, you first build the UID and see if
>already exists.  That way you can handle an Employee class being used in
>two different fields of a Company object.
>
>Also, you build out a cache of instances so you don't loop for references
>back to parent objects.
>
>If anyone gets started on the utility, let us know so we don't have more
>than one person working on it.
>
>Thanks,
>-Alex
>
>On 2/6/18, 9:53 AM, "Alex Harui"  wrote:
>
>>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 DataGrid.json, it looks like this:
>>
>>{ "type": "class",
>>  "qname": "org.apache.royale.express.DataGrid",
>>  "baseClassname": "org.apache.royale.html.DataGrid",
>>  "description": "This class extends DataGrid and adds beads for drag and
>>drop and column reordering.",
>>  "tags": [
>> {  "tagName": "flexdocurl",
>>"values":
>>["https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflex.a
>>p
>>ache.org%2Fasdoc%2Fspark%2Fcomponents%2FDataGrid.html&data=02%7C01%7Cahar
>>u
>>i%40adobe.com%7C364fbca7fc9144384fd808d56d8a96c0%7C71f1da39c0a84d5a8d88a6
>>7
>>b23c30bf4%7C0%7C0%7C636535364360288547&sdata=5%2FZyPUsg30zGUdqwPxr3XFu6Qi
>>o
>>FFL3%2BZ1RBl5kDADw%3D&reserved=0"]},
>> {  "tagName": "flexcomponent",
>>"values": ["spark.components.DataGrid"]}],
>>  "members": [
>> { "type": "method",
>>   "qname": "org.apache.royale.express.DataGrid",
>>   "namespace": "",
>>   "return": "",
>>   "params": []},
>> { "type": "method",
>>   "qname": "addedToParent",
>>   "namespace": "public",
>>   "override": true,
>>   "return": "void",
>>   "params": []}]
>>}
>>
>>So, I might call this "ClassData".  The utility would JSON.parse the
>>structure and walk each property.  If it sees the value is a String then
>>it sets the property type to String, if a number, then Number or int if
>>the value doesn't have decimal places.  True and false are Booleans.
>>Array for Arrays.
>>
>>If the value is an Array, it looks at the first element in the Array.  IF
>>the first element Is an Object, like it is for tags, it would create the
>>class ClassData_tags and walk the object.  Same for any value of a field
>>that is an Object.
>>
>>IMO, it doesn't have to be perfect, just save you most of the tedious
>>work.  And if you don't like the generated class names, the IDEs should
>>support refactoring (now or eventually).
>>
>>Of course, I could be wrong...
>>
>>-Alex
>>
>>
>>
>>On 2/6/18, 9:16 AM, "Gabe Harbs"  wrote:
>>
>>>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 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 hash map.  IMO, most C and Java apps don't use
>generic
> untyped dynamic bags of properties.  If I add a warning about Object
>use,
> there will be a directive to suppress it.  Objects are prone to
>error,
>and
> there is some indication that runtimes work better with type
>information.
> The JS runtimes wouldn't bother type inferencing otherwise.  WASM
>hints
> that it wants types.
> 
> My 2 cents,
> -Alex
> 
> On 2/6/18, 8:45 AM, "Gabe Harbs"  wrote:
> 
>> 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
>> app.
>> 
>> Right now, I’m creating VOs for the ASDoc app. It’s kind of tedious
>>work…
>> 
>> Harbs
>> 
>>> On Feb 6, 2018, at 6:40 PM, Alex Harui 
>>>wrote:
>>> 
>>> Good catch. I fixed t

Re: ASDoc, Routing, Releases

[Carlos Rovira]

Hi Alex,

I expect to google for a concrete version for example write in google
"royale asdoc 0.9.0", and google bring me the docs for that version.
I think this will be easier or more productive that implement something in
the same ASDoc...but maybe I'm wrong

About ASDocs, this start to look better. Congrats for the great work!. Hope
I can help here improving the look and feel if I get some time.
One thing that can be done quickly is to remove most of the top menu and
the top right icons, since seems a bit useless in ASDocs, Hope I can help
with that header soon.

Thanks!


2018-02-13 17:54 GMT+01:00 Alex Harui :

> The link is: http://royale.apache.org/asdoc/
>
> I think it took GitPubSub a while push it all to the production web server.
>
> I agree that documentation is important, but to me, everything is a
> trade-off.  I could stop coding and spend days on improving ASDoc, or I
> can use that same time to provide functionality that helps someone migrate
> their app to Royale.  I tend to choose the latter because I think lots
> more folks are capable of helping improve the ASDoc than are capable of
> providing virtual lists and editable data grids.  Now that our ASDoc looks
> better, I will try to make sure there is at least minimal ASDoc for new
> APIs.  But it would be great if some volunteers could go scrub what we
> have.
>
> I suppose we could keep a copy of ASDoc per release on the website.  But
> would that help or hurt Search Engine rankings (assuming we can get ASDoc
> indexed in the first place)?  There is already an ASDoc directive
> (@productversion) we should be using to annotate when an API first
> appeared and we could add functionality to ASDoc to filter on that.  The
> thing is that in a hurry, folks often copy an existing ASDoc block and may
> forget to update @productversion.  That's what I meant by being diligent.
>
> If we add filtering to the UX, we need to consider whether filtering
> should be part of the routing URL.
>
> My 2 cents,
> -Alex
>
> On 2/13/18, 12:59 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi Alex,
> >
> >I tried the link royale.apache.org/asdoc but it doesn't work. Is that
> link
> >right?
> >For versions I think ASDocs has sense if we all focus in create right
> >ASDoc. I'm trying to do it with Vivid, and did with MDL times. This is
> >important and makes us to take care of the code we make. The code is not
> >ready after we make it, is ready  when we try to think far beyond of what
> >it does and what people needs from it in terms of documentation, ease of
> >use, ...
> >So if we all create good ASDoc, I think is ok to release with each
> >release.
> >With time, and more releases, people will want to check ASDoc from
> >specific
> >version.
> >I think we will need to store that versions so people could check it, and
> >will be easily discovered by url.
> >For example:
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Froyale.apa
> >che.org%2Fasdoc%2F0.9.0%2F&data=02%7C01%7Caharui%40adobe.com
> %7C820b1d29d9e
> >b4c90d1cf08d572c0248f%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6365410
> >91942987055&sdata=jqIfArjx5Jop3Ac77gYIc2IOqB4r2A
> GF1mHoVOJzKgM%3D&reserved=
> >0...
> >
> >
> >
> >2018-02-13 9:47 GMT+01:00 Piotr Zarzycki :
> >
> >> I think simplicity is the key here. Pushing after release ASDoc - I like
> >> the idea. The filtering could also appear, but I would still stay with
> >> pushing after every release instead all the time.
> >>
> >> Thanks,
> >> Piotr
> >>
> >> 2018-02-13 9:32 GMT+01:00 Alex Harui :
> >>
> >> > Filtering by version is certainly possible, but would require that we
> >>are
> >> > diligent about specifying the correct version when entering data.
> >> >
> >> > -Alex
> >> >
> >> > On 2/12/18, 11:53 PM, "Gabe Harbs"  wrote:
> >> >
> >> > >Yes. Having it as part of the release process makes sense.
> >> > >
> >> > >Another way to go about it would be to have some way to limit which
> >> > >version data is displayed, so if unreleased data is set to display,
> >>it
> >> > >would show up, but by default the ASDoc app would only show data
> >>that is
> >> > >relevant to the latest release.
> >> > >
> >> > >> On Feb 13, 2018, at 9:43 AM, Alex Harui 
> >> > >>wrote:
> >> > >>
> >> > >> I pushed an Ant script that copies ASDoc from the CI server and
> >>copies
> >> > >>it
> >> > >> to the asdoc folder on the site.
> >> > >> I also pushed the ASDoc.
> >> > >>
> >> > >> I was going to hook this up to a CI build but am having second
> >> thoughts.
> >> > >> Maybe we should only update after a release.  Otherwise, folks may
> >> find
> >> > >> stuff in ASDoc that is only in the nightly and hasn't been
> >>released.
> >> > >>
> >> > >> Thoughts?
> >> > >> -Alex
> >> > >>
> >> > >> On 2/6/18, 12:38 AM, "carlos.rov...@gmail.com
> >> > >> on behalf of Carlos Rovira"
> >> > >> mailto:carlos.rov...@gmail.com> on
> behalf
> >> of
> >> > >>carlosrov...@apache.org 

Re: ASDoc, Routing, Releases

[Alex Harui]

The link is: http://royale.apache.org/asdoc/

I think it took GitPubSub a while push it all to the production web server.

I agree that documentation is important, but to me, everything is a
trade-off.  I could stop coding and spend days on improving ASDoc, or I
can use that same time to provide functionality that helps someone migrate
their app to Royale.  I tend to choose the latter because I think lots
more folks are capable of helping improve the ASDoc than are capable of
providing virtual lists and editable data grids.  Now that our ASDoc looks
better, I will try to make sure there is at least minimal ASDoc for new
APIs.  But it would be great if some volunteers could go scrub what we
have.

I suppose we could keep a copy of ASDoc per release on the website.  But
would that help or hurt Search Engine rankings (assuming we can get ASDoc
indexed in the first place)?  There is already an ASDoc directive
(@productversion) we should be using to annotate when an API first
appeared and we could add functionality to ASDoc to filter on that.  The
thing is that in a hurry, folks often copy an existing ASDoc block and may
forget to update @productversion.  That's what I meant by being diligent.

If we add filtering to the UX, we need to consider whether filtering
should be part of the routing URL.

My 2 cents,
-Alex

On 2/13/18, 12:59 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>I tried the link royale.apache.org/asdoc but it doesn't work. Is that link
>right?
>For versions I think ASDocs has sense if we all focus in create right
>ASDoc. I'm trying to do it with Vivid, and did with MDL times. This is
>important and makes us to take care of the code we make. The code is not
>ready after we make it, is ready  when we try to think far beyond of what
>it does and what people needs from it in terms of documentation, ease of
>use, ...
>So if we all create good ASDoc, I think is ok to release with each
>release.
>With time, and more releases, people will want to check ASDoc from
>specific
>version.
>I think we will need to store that versions so people could check it, and
>will be easily discovered by url.
>For example: 
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Froyale.apa
>che.org%2Fasdoc%2F0.9.0%2F&data=02%7C01%7Caharui%40adobe.com%7C820b1d29d9e
>b4c90d1cf08d572c0248f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365410
>91942987055&sdata=jqIfArjx5Jop3Ac77gYIc2IOqB4r2AGF1mHoVOJzKgM%3D&reserved=
>0...
>
>
>
>2018-02-13 9:47 GMT+01:00 Piotr Zarzycki :
>
>> I think simplicity is the key here. Pushing after release ASDoc - I like
>> the idea. The filtering could also appear, but I would still stay with
>> pushing after every release instead all the time.
>>
>> Thanks,
>> Piotr
>>
>> 2018-02-13 9:32 GMT+01:00 Alex Harui :
>>
>> > Filtering by version is certainly possible, but would require that we
>>are
>> > diligent about specifying the correct version when entering data.
>> >
>> > -Alex
>> >
>> > On 2/12/18, 11:53 PM, "Gabe Harbs"  wrote:
>> >
>> > >Yes. Having it as part of the release process makes sense.
>> > >
>> > >Another way to go about it would be to have some way to limit which
>> > >version data is displayed, so if unreleased data is set to display,
>>it
>> > >would show up, but by default the ASDoc app would only show data
>>that is
>> > >relevant to the latest release.
>> > >
>> > >> On Feb 13, 2018, at 9:43 AM, Alex Harui 
>> > >>wrote:
>> > >>
>> > >> I pushed an Ant script that copies ASDoc from the CI server and
>>copies
>> > >>it
>> > >> to the asdoc folder on the site.
>> > >> I also pushed the ASDoc.
>> > >>
>> > >> I was going to hook this up to a CI build but am having second
>> thoughts.
>> > >> Maybe we should only update after a release.  Otherwise, folks may
>> find
>> > >> stuff in ASDoc that is only in the nightly and hasn't been
>>released.
>> > >>
>> > >> Thoughts?
>> > >> -Alex
>> > >>
>> > >> On 2/6/18, 12:38 AM, "carlos.rov...@gmail.com
>> > >> on behalf of Carlos Rovira"
>> > >> mailto:carlos.rov...@gmail.com> on behalf
>> of
>> > >>carlosrov...@apache.org > wrote:
>> > >>
>> > >>> Hi Alex,
>> > >>>
>> > >>> in fact I think that's what it should be :)
>> > >>> don't know if as part of the website or in the royale-docs live
>>url.
>> > >>> Anyway the proposed url is ok.
>> > >>>
>> > >>> When I updated the website I overlay the folder with changes, as
>>in
>> the
>> > >>> website there's no "/asdoc/" url it will be untouched by my
>>changes
>> > >>>
>> > >>> thanks
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> 2018-02-06 6:29 GMT+01:00 Alex Harui :
>> > >>>
>> >  ASDoc is looking better.  I was looking into tools to understand
>>how
>> >  google crawls sites and found that I can't use them on Jenkins.
>>I
>> > also
>> >  saw in another thread that there is a way to get ASF Jenkins to
>>push
>> >  changes to a gitpubsub site.  Also, 

Re: ASDoc, Routing, Releases

[Carlos Rovira]

Hi Alex,

I tried the link royale.apache.org/asdoc but it doesn't work. Is that link
right?
For versions I think ASDocs has sense if we all focus in create right
ASDoc. I'm trying to do it with Vivid, and did with MDL times. This is
important and makes us to take care of the code we make. The code is not
ready after we make it, is ready  when we try to think far beyond of what
it does and what people needs from it in terms of documentation, ease of
use, ...
So if we all create good ASDoc, I think is ok to release with each release.
With time, and more releases, people will want to check ASDoc from specific
version.
I think we will need to store that versions so people could check it, and
will be easily discovered by url.
For example: http://royale.apache.org/asdoc/0.9.0/...



2018-02-13 9:47 GMT+01:00 Piotr Zarzycki :

> I think simplicity is the key here. Pushing after release ASDoc - I like
> the idea. The filtering could also appear, but I would still stay with
> pushing after every release instead all the time.
>
> Thanks,
> Piotr
>
> 2018-02-13 9:32 GMT+01:00 Alex Harui :
>
> > Filtering by version is certainly possible, but would require that we are
> > diligent about specifying the correct version when entering data.
> >
> > -Alex
> >
> > On 2/12/18, 11:53 PM, "Gabe Harbs"  wrote:
> >
> > >Yes. Having it as part of the release process makes sense.
> > >
> > >Another way to go about it would be to have some way to limit which
> > >version data is displayed, so if unreleased data is set to display, it
> > >would show up, but by default the ASDoc app would only show data that is
> > >relevant to the latest release.
> > >
> > >> On Feb 13, 2018, at 9:43 AM, Alex Harui 
> > >>wrote:
> > >>
> > >> I pushed an Ant script that copies ASDoc from the CI server and copies
> > >>it
> > >> to the asdoc folder on the site.
> > >> I also pushed the ASDoc.
> > >>
> > >> I was going to hook this up to a CI build but am having second
> thoughts.
> > >> Maybe we should only update after a release.  Otherwise, folks may
> find
> > >> stuff in ASDoc that is only in the nightly and hasn't been released.
> > >>
> > >> Thoughts?
> > >> -Alex
> > >>
> > >> On 2/6/18, 12:38 AM, "carlos.rov...@gmail.com
> > >> on behalf of Carlos Rovira"
> > >> mailto:carlos.rov...@gmail.com> on behalf
> of
> > >>carlosrov...@apache.org > wrote:
> > >>
> > >>> Hi Alex,
> > >>>
> > >>> in fact I think that's what it should be :)
> > >>> don't know if as part of the website or in the royale-docs live url.
> > >>> Anyway the proposed url is ok.
> > >>>
> > >>> When I updated the website I overlay the folder with changes, as in
> the
> > >>> website there's no "/asdoc/" url it will be untouched by my changes
> > >>>
> > >>> thanks
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> 2018-02-06 6:29 GMT+01:00 Alex Harui :
> > >>>
> >  ASDoc is looking better.  I was looking into tools to understand how
> >  google crawls sites and found that I can't use them on Jenkins.  I
> > also
> >  saw in another thread that there is a way to get ASF Jenkins to push
> >  changes to a gitpubsub site.  Also, the ASDoc URL is long and ugly.
> > 
> >  So, I'm thinking we should create a Jenkins job to copy ASDoc to
> >  royale.a.o.  Does anybody have any reason we shouldn't publish ASDoc
> > on
> >  royale.a.o?  Also, what folder should we use?  royale.a.o/asdoc/?
> > 
> >  Thoughts?
> >  -Alex
> > 
> >  On 2/5/18, 9:44 AM, "Gabe Harbs"  wrote:
> > 
> > >> What did you clean out?
> > >
> > > Everything.
> > >
> > > I deleted the entire contents of the three repo folders except the
> > >.git
> > > folder.
> > >
> > > I then stashed my local “changes" and pulled develop to bring my
> repo
> > > into a clean up-to-date state.
> > >
> > > I’m not sure what the problem was.
> > >
> > > Harbs
> > >
> > >> On Feb 5, 2018, at 7:37 PM, Alex Harui 
> >  wrote:
> > >>
> > >> What did you clean out?  It might help others if you update the
> >  scripts
> > >> to
> > >> clean up better.  I thought it was working correctly.
> > >>
> > >> When things get renamed, the scripts don't always clean out the
> old
> > >> folders.
> > >>
> > >> -Alex
> > >>
> > >> On 2/5/18, 9:29 AM, "Gabe Harbs"  > >> > wrote:
> > >>
> > >>> I manually cleaned out my repo folders, pulled again and now it
> >  seems
> > >>> to
> > >>> be working.
> > >>>
> > >>> It looks like ant wipe-all on the compiler and ant clean all on
> >  asjs,
> > >>> doesn’t quite clean everything…
> > >>>
> >  On Feb 5, 2018, at 7:13 PM, Gabe Harbs 
> >  wrote:
> > 
> >  It looks like I needed to set some env vars.
> > 
> >  I did so, and I’m getting some JSON files,

Re: ASDoc, Routing, Releases

[Piotr Zarzycki]

I think simplicity is the key here. Pushing after release ASDoc - I like
the idea. The filtering could also appear, but I would still stay with
pushing after every release instead all the time.

Thanks,
Piotr

2018-02-13 9:32 GMT+01:00 Alex Harui :

> Filtering by version is certainly possible, but would require that we are
> diligent about specifying the correct version when entering data.
>
> -Alex
>
> On 2/12/18, 11:53 PM, "Gabe Harbs"  wrote:
>
> >Yes. Having it as part of the release process makes sense.
> >
> >Another way to go about it would be to have some way to limit which
> >version data is displayed, so if unreleased data is set to display, it
> >would show up, but by default the ASDoc app would only show data that is
> >relevant to the latest release.
> >
> >> On Feb 13, 2018, at 9:43 AM, Alex Harui 
> >>wrote:
> >>
> >> I pushed an Ant script that copies ASDoc from the CI server and copies
> >>it
> >> to the asdoc folder on the site.
> >> I also pushed the ASDoc.
> >>
> >> I was going to hook this up to a CI build but am having second thoughts.
> >> Maybe we should only update after a release.  Otherwise, folks may find
> >> stuff in ASDoc that is only in the nightly and hasn't been released.
> >>
> >> Thoughts?
> >> -Alex
> >>
> >> On 2/6/18, 12:38 AM, "carlos.rov...@gmail.com
> >> on behalf of Carlos Rovira"
> >> mailto:carlos.rov...@gmail.com> on behalf of
> >>carlosrov...@apache.org > wrote:
> >>
> >>> Hi Alex,
> >>>
> >>> in fact I think that's what it should be :)
> >>> don't know if as part of the website or in the royale-docs live url.
> >>> Anyway the proposed url is ok.
> >>>
> >>> When I updated the website I overlay the folder with changes, as in the
> >>> website there's no "/asdoc/" url it will be untouched by my changes
> >>>
> >>> thanks
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 2018-02-06 6:29 GMT+01:00 Alex Harui :
> >>>
>  ASDoc is looking better.  I was looking into tools to understand how
>  google crawls sites and found that I can't use them on Jenkins.  I
> also
>  saw in another thread that there is a way to get ASF Jenkins to push
>  changes to a gitpubsub site.  Also, the ASDoc URL is long and ugly.
> 
>  So, I'm thinking we should create a Jenkins job to copy ASDoc to
>  royale.a.o.  Does anybody have any reason we shouldn't publish ASDoc
> on
>  royale.a.o?  Also, what folder should we use?  royale.a.o/asdoc/?
> 
>  Thoughts?
>  -Alex
> 
>  On 2/5/18, 9:44 AM, "Gabe Harbs"  wrote:
> 
> >> What did you clean out?
> >
> > Everything.
> >
> > I deleted the entire contents of the three repo folders except the
> >.git
> > folder.
> >
> > I then stashed my local “changes" and pulled develop to bring my repo
> > into a clean up-to-date state.
> >
> > I’m not sure what the problem was.
> >
> > Harbs
> >
> >> On Feb 5, 2018, at 7:37 PM, Alex Harui 
>  wrote:
> >>
> >> What did you clean out?  It might help others if you update the
>  scripts
> >> to
> >> clean up better.  I thought it was working correctly.
> >>
> >> When things get renamed, the scripts don't always clean out the old
> >> folders.
> >>
> >> -Alex
> >>
> >> On 2/5/18, 9:29 AM, "Gabe Harbs"  >> > wrote:
> >>
> >>> I manually cleaned out my repo folders, pulled again and now it
>  seems
> >>> to
> >>> be working.
> >>>
> >>> It looks like ant wipe-all on the compiler and ant clean all on
>  asjs,
> >>> doesn’t quite clean everything…
> >>>
>  On Feb 5, 2018, at 7:13 PM, Gabe Harbs 
>  wrote:
> 
>  It looks like I needed to set some env vars.
> 
>  I did so, and I’m getting some JSON files, but not the full thing.
> 
>  I just updated my repos and did ant clean all. I’m now getting a
>  failed
>  build of Royale and I’m not sure why...
> 
>  royale.royaletasks.jar:
> 
>  jar:
> 
>  main:
> 
>  main:
> 
>  download:
> [echo] /Apache/royale-asjs
>    [unjar] Expanding:
>  /Apache/royale-asjs/js/lib/google/closure-compiler/compiler.jar
>  into
>  /Apache/royale-typedefs/js/target/temp/externs
>    [unzip] Expanding:
>  /Apache/royale-typedefs/js/target/temp/externs/externs.zip into
>  /Apache/royale-typedefs/js/target/downloads
>  [get] Getting:
> 
>  https://na01.safelinks.protection.outlook.com/?url=
>  https%3A%2F%2Fstorag
>  e
>    https%3A%2F%2Fstora
>  ge>.
>  googleapis.com
>    http%3A%2F%2Fgoo

Re: ASDoc, Routing, Releases

[Alex Harui]

Filtering by version is certainly possible, but would require that we are
diligent about specifying the correct version when entering data.

-Alex

On 2/12/18, 11:53 PM, "Gabe Harbs"  wrote:

>Yes. Having it as part of the release process makes sense.
>
>Another way to go about it would be to have some way to limit which
>version data is displayed, so if unreleased data is set to display, it
>would show up, but by default the ASDoc app would only show data that is
>relevant to the latest release.
>
>> On Feb 13, 2018, at 9:43 AM, Alex Harui 
>>wrote:
>> 
>> I pushed an Ant script that copies ASDoc from the CI server and copies
>>it
>> to the asdoc folder on the site.
>> I also pushed the ASDoc.
>> 
>> I was going to hook this up to a CI build but am having second thoughts.
>> Maybe we should only update after a release.  Otherwise, folks may find
>> stuff in ASDoc that is only in the nightly and hasn't been released.
>> 
>> Thoughts?
>> -Alex
>> 
>> On 2/6/18, 12:38 AM, "carlos.rov...@gmail.com
>> on behalf of Carlos Rovira"
>> mailto:carlos.rov...@gmail.com> on behalf of
>>carlosrov...@apache.org > wrote:
>> 
>>> Hi Alex,
>>> 
>>> in fact I think that's what it should be :)
>>> don't know if as part of the website or in the royale-docs live url.
>>> Anyway the proposed url is ok.
>>> 
>>> When I updated the website I overlay the folder with changes, as in the
>>> website there's no "/asdoc/" url it will be untouched by my changes
>>> 
>>> thanks
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 2018-02-06 6:29 GMT+01:00 Alex Harui :
>>> 
 ASDoc is looking better.  I was looking into tools to understand how
 google crawls sites and found that I can't use them on Jenkins.  I
also
 saw in another thread that there is a way to get ASF Jenkins to push
 changes to a gitpubsub site.  Also, the ASDoc URL is long and ugly.
 
 So, I'm thinking we should create a Jenkins job to copy ASDoc to
 royale.a.o.  Does anybody have any reason we shouldn't publish ASDoc
on
 royale.a.o?  Also, what folder should we use?  royale.a.o/asdoc/?
 
 Thoughts?
 -Alex
 
 On 2/5/18, 9:44 AM, "Gabe Harbs"  wrote:
 
>> What did you clean out?
> 
> Everything.
> 
> I deleted the entire contents of the three repo folders except the
>.git
> folder.
> 
> I then stashed my local “changes" and pulled develop to bring my repo
> into a clean up-to-date state.
> 
> I’m not sure what the problem was.
> 
> Harbs
> 
>> On Feb 5, 2018, at 7:37 PM, Alex Harui 
 wrote:
>> 
>> What did you clean out?  It might help others if you update the
 scripts
>> to
>> clean up better.  I thought it was working correctly.
>> 
>> When things get renamed, the scripts don't always clean out the old
>> folders.
>> 
>> -Alex
>> 
>> On 2/5/18, 9:29 AM, "Gabe Harbs" > > wrote:
>> 
>>> I manually cleaned out my repo folders, pulled again and now it
 seems
>>> to
>>> be working.
>>> 
>>> It looks like ant wipe-all on the compiler and ant clean all on
 asjs,
>>> doesn’t quite clean everything…
>>> 
 On Feb 5, 2018, at 7:13 PM, Gabe Harbs 
 wrote:
 
 It looks like I needed to set some env vars.
 
 I did so, and I’m getting some JSON files, but not the full thing.
 
 I just updated my repos and did ant clean all. I’m now getting a
 failed
 build of Royale and I’m not sure why...
 
 royale.royaletasks.jar:
 
 jar:
 
 main:
 
 main:
 
 download:
[echo] /Apache/royale-asjs
   [unjar] Expanding:
 /Apache/royale-asjs/js/lib/google/closure-compiler/compiler.jar
 into
 /Apache/royale-typedefs/js/target/temp/externs
   [unzip] Expanding:
 /Apache/royale-typedefs/js/target/temp/externs/externs.zip into
 /Apache/royale-typedefs/js/target/downloads
 [get] Getting:
 
 https://na01.safelinks.protection.outlook.com/?url=
 https%3A%2F%2Fstorag
 e
 .
 googleapis.com
 
%
 2Fg
 oogle-code-archive-downloads%2Fv2%2Fcode.google.com
 

Re: ASDoc, Routing, Releases

[Gabe Harbs]

Yes. Having it as part of the release process makes sense.

Another way to go about it would be to have some way to limit which version 
data is displayed, so if unreleased data is set to display, it would show up, 
but by default the ASDoc app would only show data that is relevant to the 
latest release.

> On Feb 13, 2018, at 9:43 AM, Alex Harui  wrote:
> 
> I pushed an Ant script that copies ASDoc from the CI server and copies it
> to the asdoc folder on the site.
> I also pushed the ASDoc.
> 
> I was going to hook this up to a CI build but am having second thoughts.
> Maybe we should only update after a release.  Otherwise, folks may find
> stuff in ASDoc that is only in the nightly and hasn't been released.
> 
> Thoughts?
> -Alex
> 
> On 2/6/18, 12:38 AM, "carlos.rov...@gmail.com 
>  on behalf of Carlos Rovira"
> mailto:carlos.rov...@gmail.com> on behalf of 
> carlosrov...@apache.org > wrote:
> 
>> Hi Alex,
>> 
>> in fact I think that's what it should be :)
>> don't know if as part of the website or in the royale-docs live url.
>> Anyway the proposed url is ok.
>> 
>> When I updated the website I overlay the folder with changes, as in the
>> website there's no "/asdoc/" url it will be untouched by my changes
>> 
>> thanks
>> 
>> 
>> 
>> 
>> 
>> 
>> 2018-02-06 6:29 GMT+01:00 Alex Harui :
>> 
>>> ASDoc is looking better.  I was looking into tools to understand how
>>> google crawls sites and found that I can't use them on Jenkins.  I also
>>> saw in another thread that there is a way to get ASF Jenkins to push
>>> changes to a gitpubsub site.  Also, the ASDoc URL is long and ugly.
>>> 
>>> So, I'm thinking we should create a Jenkins job to copy ASDoc to
>>> royale.a.o.  Does anybody have any reason we shouldn't publish ASDoc on
>>> royale.a.o?  Also, what folder should we use?  royale.a.o/asdoc/?
>>> 
>>> Thoughts?
>>> -Alex
>>> 
>>> On 2/5/18, 9:44 AM, "Gabe Harbs"  wrote:
>>> 
> What did you clean out?
 
 Everything.
 
 I deleted the entire contents of the three repo folders except the .git
 folder.
 
 I then stashed my local “changes" and pulled develop to bring my repo
 into a clean up-to-date state.
 
 I’m not sure what the problem was.
 
 Harbs
 
> On Feb 5, 2018, at 7:37 PM, Alex Harui 
>>> wrote:
> 
> What did you clean out?  It might help others if you update the
>>> scripts
> to
> clean up better.  I thought it was working correctly.
> 
> When things get renamed, the scripts don't always clean out the old
> folders.
> 
> -Alex
> 
> On 2/5/18, 9:29 AM, "Gabe Harbs"  > wrote:
> 
>> I manually cleaned out my repo folders, pulled again and now it
>>> seems
>> to
>> be working.
>> 
>> It looks like ant wipe-all on the compiler and ant clean all on
>>> asjs,
>> doesn’t quite clean everything…
>> 
>>> On Feb 5, 2018, at 7:13 PM, Gabe Harbs 
>>> wrote:
>>> 
>>> It looks like I needed to set some env vars.
>>> 
>>> I did so, and I’m getting some JSON files, but not the full thing.
>>> 
>>> I just updated my repos and did ant clean all. I’m now getting a
>>> failed
>>> build of Royale and I’m not sure why...
>>> 
>>> royale.royaletasks.jar:
>>> 
>>> jar:
>>> 
>>> main:
>>> 
>>> main:
>>> 
>>> download:
>>>[echo] /Apache/royale-asjs
>>>   [unjar] Expanding:
>>> /Apache/royale-asjs/js/lib/google/closure-compiler/compiler.jar
>>> into
>>> /Apache/royale-typedefs/js/target/temp/externs
>>>   [unzip] Expanding:
>>> /Apache/royale-typedefs/js/target/temp/externs/externs.zip into
>>> /Apache/royale-typedefs/js/target/downloads
>>> [get] Getting:
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=
>>> https%3A%2F%2Fstorag
>>> e
>>> >> https%3A%2F%2Fstora
>>> ge>.
>>> googleapis.com
>>> >> http%3A%2F%2Fgoogle
>>> apis.com%2F&data=02%7C01%7Caharui%40adobe.com%
>>> 7Cea3588c69d96467c165f08d
>>> 56cc01d3d%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
>>> 7C6365344947393196
>>> 87&sdata=wz0mlDPXSNb9R9uIL55hVuaRVCE1Qsxa5EN5XZoF1K4%3D&reserved=0>%
>>> 2Fg
>>> oogle-code-archive-downloads%2Fv2%2Fcode.google.com
>>> >> http%3A%2F%2F2fcode
>>> .google.com%2F&data=02%7C01%7Caharui%40adobe.com%
>>> 7Cea3588c69d96467c165f
>>> 08d56cc01d3d%7C71f1da39c0a84d5a8d88a67b23c3
>>> 0bf4%7C0%7C0%7C6365344947393
>>> 19687&sdata=kkKyUtW7yWmIlI2YaMM2084mFatUbp
>>> lmnr6PBa26PDU%3D&reserved=0>%
>>> 2Fc
>>> losureidl%2Fsvg.js&data=02%7C01%7Caharui%40adobe.com
>>> >> http%3A%2F%2F40adob
>>> e.com%2F&dat

Re: ASDoc, Routing, Releases

[Alex Harui]

I pushed an Ant script that copies ASDoc from the CI server and copies it
to the asdoc folder on the site.
I also pushed the ASDoc.

I was going to hook this up to a CI build but am having second thoughts.
Maybe we should only update after a release.  Otherwise, folks may find
stuff in ASDoc that is only in the nightly and hasn't been released.

Thoughts?
-Alex

On 2/6/18, 12:38 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>in fact I think that's what it should be :)
>don't know if as part of the website or in the royale-docs live url.
>Anyway the proposed url is ok.
>
>When I updated the website I overlay the folder with changes, as in the
>website there's no "/asdoc/" url it will be untouched by my changes
>
>thanks
>
>
>
>
>
>
>2018-02-06 6:29 GMT+01:00 Alex Harui :
>
>> ASDoc is looking better.  I was looking into tools to understand how
>> google crawls sites and found that I can't use them on Jenkins.  I also
>> saw in another thread that there is a way to get ASF Jenkins to push
>> changes to a gitpubsub site.  Also, the ASDoc URL is long and ugly.
>>
>> So, I'm thinking we should create a Jenkins job to copy ASDoc to
>> royale.a.o.  Does anybody have any reason we shouldn't publish ASDoc on
>> royale.a.o?  Also, what folder should we use?  royale.a.o/asdoc/?
>>
>> Thoughts?
>> -Alex
>>
>> On 2/5/18, 9:44 AM, "Gabe Harbs"  wrote:
>>
>> >> What did you clean out?
>> >
>> >Everything.
>> >
>> >I deleted the entire contents of the three repo folders except the .git
>> >folder.
>> >
>> >I then stashed my local “changes" and pulled develop to bring my repo
>> >into a clean up-to-date state.
>> >
>> >I’m not sure what the problem was.
>> >
>> >Harbs
>> >
>> >> On Feb 5, 2018, at 7:37 PM, Alex Harui 
>> wrote:
>> >>
>> >> What did you clean out?  It might help others if you update the
>>scripts
>> >>to
>> >> clean up better.  I thought it was working correctly.
>> >>
>> >> When things get renamed, the scripts don't always clean out the old
>> >> folders.
>> >>
>> >> -Alex
>> >>
>> >> On 2/5/18, 9:29 AM, "Gabe Harbs" > >>> wrote:
>> >>
>> >>> I manually cleaned out my repo folders, pulled again and now it
>>seems
>> >>>to
>> >>> be working.
>> >>>
>> >>> It looks like ant wipe-all on the compiler and ant clean all on
>>asjs,
>> >>> doesn’t quite clean everything…
>> >>>
>>  On Feb 5, 2018, at 7:13 PM, Gabe Harbs 
>>wrote:
>> 
>>  It looks like I needed to set some env vars.
>> 
>>  I did so, and I’m getting some JSON files, but not the full thing.
>> 
>>  I just updated my repos and did ant clean all. I’m now getting a
>> failed
>>  build of Royale and I’m not sure why...
>> 
>>  royale.royaletasks.jar:
>> 
>>  jar:
>> 
>>  main:
>> 
>>  main:
>> 
>>  download:
>>  [echo] /Apache/royale-asjs
>> [unjar] Expanding:
>>  /Apache/royale-asjs/js/lib/google/closure-compiler/compiler.jar
>>into
>>  /Apache/royale-typedefs/js/target/temp/externs
>> [unzip] Expanding:
>>  /Apache/royale-typedefs/js/target/temp/externs/externs.zip into
>>  /Apache/royale-typedefs/js/target/downloads
>>   [get] Getting:
>> 
>> https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fstorag
>> e
>> > https%3A%2F%2Fstora
>> ge>.
>>  googleapis.com
>> > http%3A%2F%2Fgoogle
>> apis.com%2F&data=02%7C01%7Caharui%40adobe.com%
>> 7Cea3588c69d96467c165f08d
>> 56cc01d3d%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
>> 7C6365344947393196
>> 87&sdata=wz0mlDPXSNb9R9uIL55hVuaRVCE1Qsxa5EN5XZoF1K4%3D&reserved=0>%
>> 2Fg
>> oogle-code-archive-downloads%2Fv2%2Fcode.google.com
>> > http%3A%2F%2F2fcode
>> .google.com%2F&data=02%7C01%7Caharui%40adobe.com%
>> 7Cea3588c69d96467c165f
>> 08d56cc01d3d%7C71f1da39c0a84d5a8d88a67b23c3
>> 0bf4%7C0%7C0%7C6365344947393
>> 19687&sdata=kkKyUtW7yWmIlI2YaMM2084mFatUbp
>> lmnr6PBa26PDU%3D&reserved=0>%
>> 2Fc
>>  losureidl%2Fsvg.js&data=02%7C01%7Caharui%40adobe.com
>> > http%3A%2F%2F40adob
>> e.com%2F&data=02%7C01%7Caharui%40adobe.com%
>> 7Cea3588c69d96467c165f08d56c
>> c01d3d%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
>> 7C636534494739319687&
>> sdata=OdEf7fY9Th9Rzl0I47YgM0c%2F0nkANAERsBzzoNptghc%3D&
>> reserved=0>%7Ce7
>> 402a81cda54e1dbc
>> 
>> e608d56cbe0f88%7C71f1da39c0a84d5a8d88a67b23c3
>> 0bf4%7C0%7C0%7C63653448592
>> 05
>> 
>> 06853&sdata=NwzNAbDc3gdOLz94AJG1T8sf1%2FYeEzPZIjxsLLCCN68%3D&
>> reserved=0
>> 
>> > https%3A%2F%2Fstora
>> ge
>> > https%3A%2F%2Fstora
>> ge>
>>  .g

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

[Dave Fisher]

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 with ADVANCED_OPTIMIZATIONS
> and that messes up how you use plain objects.
> 
> IMO, there is enough to gain from using ValueObjects (code hinting,
> type-checking, etc) that we should promote use of them and make it really
> easy to use them, like creating typedefs via some utility.  IOW, if it
> only took 5 minutes to generate ValueObjects for your JSON responses,
> would you just use them because it saved you time making mistakes using
> plain object?
> 
> But if enough folks want to use plain objects in production (this is not
> an issue for the bin/js-debug version) I have no objection to making it
> work, I'm just wondering if we should just use SIMPLE_OPTIMIZATIONS since
> that is easy, or take the time to add another compiler option and fork the
> output code generators to generate different code (and write tests for all
> of that).  Would ADVANCED_OPTIMIZATIONS plus this new option be worth it
> over SIMPLE_OPTIMIZATIONS?
> 
> If we change our default to SIMPLE_OPTIMIZATIONS our HelloWorld will be
> fatter, but I don't know by how much.  But that is a consideration if
> folks are going to care about download size.

A comparison would help. I don’t know what scale you have in mind. 

FWIW - If someone hosting a Royale app truly cares then there are additional 
outside the scope of Royale solutions like gzip and PageSpeed.

Regards,
Dave

> 
> Thoughts?
> -Alex
> 
> On 2/8/18, 1:55 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
> 
>> 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 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 new option if we have rough equivalents.
>>> 
>>> -Alex
>>> 
>>> On 2/8/18, 10:36 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>> Rovira"
>>>  wrote:
>>> 
 Although I'm pro typed,  I agree with Josh that we should not enforce
 that.
 That's one of the great points in Flash/Flex.
 For make things quick, I use simple objects with bracket notation, when
 the
 application is more relevant I go the right typed path.
 It's up to the developer decide when they want one or another.
 
 
 
 2018-02-08 18:50 GMT+01:00 Josh Tynjala :
 
> 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
> objects, that shouldn't be forced on everyone. I frequently use
>>> untyped
> objects when prototyping because it's more convenient. They're also
> useful
> in example code to reduce boilerplate that isn't particularly
>>> relevant
> to
> the concept/feature that you're trying to demonstrate. And, of
>>> course,
> there's the already mentioned JSON.
> 
> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS
>>> the
> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
> larger file size is an acceptable trade off, if it reduces the
> frustration
> of this situation. Especially for new users who will absolutely think
> its a
> serious bug in the Royale compiler. However, as Harbs notes here, if
>>> the
> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be
> retained.
> The compiler could generate code differently when something resolves
>>> as
> the
> Object type. The emitter could translate dot notation normally most
>>> of
> the
> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
> detects Object, switch to bracket notation instead. I believe it
>>> would
> also
> need to add quotes around properties defined in object literals.
> 
> Ideally, the following code should work properly out of the box:
> 
> var obj:Object = {one: 1, "two": 2};
> obj.three = 3;
> obj["four"] = 4;
> var one:Number = obj["one"];
> var two:Number = obj.two;
> var three:Number = obj["three"];
> var four:Number = obj.four;
> 
> The compiler would probably emit something like this to make it work
> with
> the Closure compiler's ADVANCED_OPTIMIZATIO

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

[Alex Harui]

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 from using ValueObjects (code hinting,
type-checking, etc) that we should promote use of them and make it really
easy to use them, like creating typedefs via some utility.  IOW, if it
only took 5 minutes to generate ValueObjects for your JSON responses,
would you just use them because it saved you time making mistakes using
plain object?

But if enough folks want to use plain objects in production (this is not
an issue for the bin/js-debug version) I have no objection to making it
work, I'm just wondering if we should just use SIMPLE_OPTIMIZATIONS since
that is easy, or take the time to add another compiler option and fork the
output code generators to generate different code (and write tests for all
of that).  Would ADVANCED_OPTIMIZATIONS plus this new option be worth it
over SIMPLE_OPTIMIZATIONS?

If we change our default to SIMPLE_OPTIMIZATIONS our HelloWorld will be
fatter, but I don't know by how much.  But that is a consideration if
folks are going to care about download size.

Thoughts?
-Alex

On 2/8/18, 1:55 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>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 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 new option if we have rough equivalents.
>>
>> -Alex
>>
>> On 2/8/18, 10:36 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>  wrote:
>>
>> >Although I'm pro typed,  I agree with Josh that we should not enforce
>> >that.
>> >That's one of the great points in Flash/Flex.
>> >For make things quick, I use simple objects with bracket notation, when
>> >the
>> >application is more relevant I go the right typed path.
>> >It's up to the developer decide when they want one or another.
>> >
>> >
>> >
>> >2018-02-08 18:50 GMT+01:00 Josh Tynjala :
>> >
>> >> 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
>> >> objects, that shouldn't be forced on everyone. I frequently use
>>untyped
>> >> objects when prototyping because it's more convenient. They're also
>> >>useful
>> >> in example code to reduce boilerplate that isn't particularly
>>relevant
>> >>to
>> >> the concept/feature that you're trying to demonstrate. And, of
>>course,
>> >> there's the already mentioned JSON.
>> >>
>> >> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS
>>the
>> >> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
>> >> larger file size is an acceptable trade off, if it reduces the
>> >>frustration
>> >> of this situation. Especially for new users who will absolutely think
>> >>its a
>> >> serious bug in the Royale compiler. However, as Harbs notes here, if
>>the
>> >> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be
>> >>retained.
>> >> The compiler could generate code differently when something resolves
>>as
>> >>the
>> >> Object type. The emitter could translate dot notation normally most
>>of
>> >>the
>> >> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
>> >> detects Object, switch to bracket notation instead. I believe it
>>would
>> >>also
>> >> need to add quotes around properties defined in object literals.
>> >>
>> >> Ideally, the following code should work properly out of the box:
>> >>
>> >> var obj:Object = {one: 1, "two": 2};
>> >> obj.three = 3;
>> >> obj["four"] = 4;
>> >> var one:Number = obj["one"];
>> >> var two:Number = obj.two;
>> >> var three:Number = obj["three"];
>> >> var four:Number = obj.four;
>> >>
>> >> The compiler would probably emit something like this to make it work
>> >>with
>> >> the Closure compiler's ADVANCED_OPTIMIZATIONS:
>> >>
>> >> var obj:Object = {"one": 1, "two": 2};
>> >> obj["three"] = 3;
>> >> obj["four"] = 4;
>> >> var one:Number = obj["one"];
>> >> var two:Number = obj["two"];
>> >> var three:Number = obj["three"];
>> >> var four:Number = obj["four"];
>> >>
>> >> Again, that's only for when something is typed as Object. If
>>something
>> >> actually has a class, let Closure compiler go nuts and rename
>> >>everything it
>> >> wants.
>> >>
>> >> 

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

[Carlos Rovira]

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 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 new option if we have rough equivalents.
>
> -Alex
>
> On 2/8/18, 10:36 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Although I'm pro typed,  I agree with Josh that we should not enforce
> >that.
> >That's one of the great points in Flash/Flex.
> >For make things quick, I use simple objects with bracket notation, when
> >the
> >application is more relevant I go the right typed path.
> >It's up to the developer decide when they want one or another.
> >
> >
> >
> >2018-02-08 18:50 GMT+01:00 Josh Tynjala :
> >
> >> 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
> >> objects, that shouldn't be forced on everyone. I frequently use untyped
> >> objects when prototyping because it's more convenient. They're also
> >>useful
> >> in example code to reduce boilerplate that isn't particularly relevant
> >>to
> >> the concept/feature that you're trying to demonstrate. And, of course,
> >> there's the already mentioned JSON.
> >>
> >> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS the
> >> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
> >> larger file size is an acceptable trade off, if it reduces the
> >>frustration
> >> of this situation. Especially for new users who will absolutely think
> >>its a
> >> serious bug in the Royale compiler. However, as Harbs notes here, if the
> >> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be
> >>retained.
> >> The compiler could generate code differently when something resolves as
> >>the
> >> Object type. The emitter could translate dot notation normally most of
> >>the
> >> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
> >> detects Object, switch to bracket notation instead. I believe it would
> >>also
> >> need to add quotes around properties defined in object literals.
> >>
> >> Ideally, the following code should work properly out of the box:
> >>
> >> var obj:Object = {one: 1, "two": 2};
> >> obj.three = 3;
> >> obj["four"] = 4;
> >> var one:Number = obj["one"];
> >> var two:Number = obj.two;
> >> var three:Number = obj["three"];
> >> var four:Number = obj.four;
> >>
> >> The compiler would probably emit something like this to make it work
> >>with
> >> the Closure compiler's ADVANCED_OPTIMIZATIONS:
> >>
> >> var obj:Object = {"one": 1, "two": 2};
> >> obj["three"] = 3;
> >> obj["four"] = 4;
> >> var one:Number = obj["one"];
> >> var two:Number = obj["two"];
> >> var three:Number = obj["three"];
> >> var four:Number = obj["four"];
> >>
> >> Again, that's only for when something is typed as Object. If something
> >> actually has a class, let Closure compiler go nuts and rename
> >>everything it
> >> wants.
> >>
> >> - Josh
> >>
> >> On 2018/02/06 08:51:19, Gabe Harbs  wrote:
> >> > Quite sure. In my angular app I was using an older version of the
> >> closure compiler to minify the js files. I was using the default options
> >> which clearly does not use ADVANCED_OPTIMIZATIONS, so the object
> >>literals
> >> didn’t get renamed.
> >> >
> >> > I think most modern app frameworks use other tools such as Babel for
> >> magnification, but I believe that handles object literals correctly too.
> >> >
> >> > We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
> >> object literals. I’m proposing a compiler *option* to allow to continue
> >> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
> >>should
> >> not be renamed.
> >> >
> >> > Harbs
> >> >
> >> > > On Feb 6, 2018, at 9:38 AM, Alex Harui 
> >> wrote:
> >> > >
> >> > > 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 Frameworks have.  If you want to
> >> minify,
> >> > >>> you have to use brackets and strings.
> >> > >>
> >> > >> It does.
> >> > >>
> >> > >> I’ve written angular apps and I’ve never had to worry about using
> >> bracket
> >> > >> notation for minifying simple js objects. I’m pretty sure the same
> >>is
> >>

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

[Alex Harui]

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 new option if we have rough equivalents.

-Alex

On 2/8/18, 10:36 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Although I'm pro typed,  I agree with Josh that we should not enforce
>that.
>That's one of the great points in Flash/Flex.
>For make things quick, I use simple objects with bracket notation, when
>the
>application is more relevant I go the right typed path.
>It's up to the developer decide when they want one or another.
>
>
>
>2018-02-08 18:50 GMT+01:00 Josh Tynjala :
>
>> 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
>> objects, that shouldn't be forced on everyone. I frequently use untyped
>> objects when prototyping because it's more convenient. They're also
>>useful
>> in example code to reduce boilerplate that isn't particularly relevant
>>to
>> the concept/feature that you're trying to demonstrate. And, of course,
>> there's the already mentioned JSON.
>>
>> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS the
>> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
>> larger file size is an acceptable trade off, if it reduces the
>>frustration
>> of this situation. Especially for new users who will absolutely think
>>its a
>> serious bug in the Royale compiler. However, as Harbs notes here, if the
>> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be
>>retained.
>> The compiler could generate code differently when something resolves as
>>the
>> Object type. The emitter could translate dot notation normally most of
>>the
>> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
>> detects Object, switch to bracket notation instead. I believe it would
>>also
>> need to add quotes around properties defined in object literals.
>>
>> Ideally, the following code should work properly out of the box:
>>
>> var obj:Object = {one: 1, "two": 2};
>> obj.three = 3;
>> obj["four"] = 4;
>> var one:Number = obj["one"];
>> var two:Number = obj.two;
>> var three:Number = obj["three"];
>> var four:Number = obj.four;
>>
>> The compiler would probably emit something like this to make it work
>>with
>> the Closure compiler's ADVANCED_OPTIMIZATIONS:
>>
>> var obj:Object = {"one": 1, "two": 2};
>> obj["three"] = 3;
>> obj["four"] = 4;
>> var one:Number = obj["one"];
>> var two:Number = obj["two"];
>> var three:Number = obj["three"];
>> var four:Number = obj["four"];
>>
>> Again, that's only for when something is typed as Object. If something
>> actually has a class, let Closure compiler go nuts and rename
>>everything it
>> wants.
>>
>> - Josh
>>
>> On 2018/02/06 08:51:19, Gabe Harbs  wrote:
>> > Quite sure. In my angular app I was using an older version of the
>> closure compiler to minify the js files. I was using the default options
>> which clearly does not use ADVANCED_OPTIMIZATIONS, so the object
>>literals
>> didn’t get renamed.
>> >
>> > I think most modern app frameworks use other tools such as Babel for
>> magnification, but I believe that handles object literals correctly too.
>> >
>> > We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
>> object literals. I’m proposing a compiler *option* to allow to continue
>> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
>>should
>> not be renamed.
>> >
>> > Harbs
>> >
>> > > On Feb 6, 2018, at 9:38 AM, Alex Harui 
>> wrote:
>> > >
>> > > 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 Frameworks have.  If you want to
>> minify,
>> > >>> you have to use brackets and strings.
>> > >>
>> > >> It does.
>> > >>
>> > >> I’ve written angular apps and I’ve never had to worry about using
>> bracket
>> > >> notation for minifying simple js objects. I’m pretty sure the same
>>is
>> for
>> > >> React, etc.
>> > >>
>> > >>> On Feb 5, 2018, at 11:34 PM, Alex Harui 
>> > >>> wrote:
>> > >>>
>> > >>> 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?
>> > >>>
>> > >>>
>> > >

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

[Carlos Rovira]

Although I'm pro typed,  I agree with Josh that we should not enforce that.
That's one of the great points in Flash/Flex.
For make things quick, I use simple objects with bracket notation, when the
application is more relevant I go the right typed path.
It's up to the developer decide when they want one or another.



2018-02-08 18:50 GMT+01:00 Josh Tynjala :

> 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
> objects, that shouldn't be forced on everyone. I frequently use untyped
> objects when prototyping because it's more convenient. They're also useful
> in example code to reduce boilerplate that isn't particularly relevant to
> the concept/feature that you're trying to demonstrate. And, of course,
> there's the already mentioned JSON.
>
> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS the
> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
> larger file size is an acceptable trade off, if it reduces the frustration
> of this situation. Especially for new users who will absolutely think its a
> serious bug in the Royale compiler. However, as Harbs notes here, if the
> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be retained.
> The compiler could generate code differently when something resolves as the
> Object type. The emitter could translate dot notation normally most of the
> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
> detects Object, switch to bracket notation instead. I believe it would also
> need to add quotes around properties defined in object literals.
>
> Ideally, the following code should work properly out of the box:
>
> var obj:Object = {one: 1, "two": 2};
> obj.three = 3;
> obj["four"] = 4;
> var one:Number = obj["one"];
> var two:Number = obj.two;
> var three:Number = obj["three"];
> var four:Number = obj.four;
>
> The compiler would probably emit something like this to make it work with
> the Closure compiler's ADVANCED_OPTIMIZATIONS:
>
> var obj:Object = {"one": 1, "two": 2};
> obj["three"] = 3;
> obj["four"] = 4;
> var one:Number = obj["one"];
> var two:Number = obj["two"];
> var three:Number = obj["three"];
> var four:Number = obj["four"];
>
> Again, that's only for when something is typed as Object. If something
> actually has a class, let Closure compiler go nuts and rename everything it
> wants.
>
> - Josh
>
> On 2018/02/06 08:51:19, Gabe Harbs  wrote:
> > Quite sure. In my angular app I was using an older version of the
> closure compiler to minify the js files. I was using the default options
> which clearly does not use ADVANCED_OPTIMIZATIONS, so the object literals
> didn’t get renamed.
> >
> > I think most modern app frameworks use other tools such as Babel for
> magnification, but I believe that handles object literals correctly too.
> >
> > We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
> object literals. I’m proposing a compiler *option* to allow to continue
> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which should
> not be renamed.
> >
> > Harbs
> >
> > > On Feb 6, 2018, at 9:38 AM, Alex Harui 
> wrote:
> > >
> > > 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 Frameworks have.  If you want to
> minify,
> > >>> you have to use brackets and strings.
> > >>
> > >> It does.
> > >>
> > >> I’ve written angular apps and I’ve never had to worry about using
> bracket
> > >> notation for minifying simple js objects. I’m pretty sure the same is
> for
> > >> React, etc.
> > >>
> > >>> On Feb 5, 2018, at 11:34 PM, Alex Harui 
> > >>> wrote:
> > >>>
> > >>> 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 something like a "reviver".  Has anyone played with that to
> see
> > >>> if it can be used to convert straight to VO's?
> > >>>
> > >>> Thanks,
> > >>> -Alex
> > >>>
> > >>> On 2/5/18, 1:08 PM, "Gabe Harbs"  wrote:
> > >>>
> >  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

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

[Josh Tynjala]

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 objects, that 
shouldn't be forced on everyone. I frequently use untyped objects when 
prototyping because it's more convenient. They're also useful in example code 
to reduce boilerplate that isn't particularly relevant to the concept/feature 
that you're trying to demonstrate. And, of course, there's the already 
mentioned JSON.

In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS the default 
instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly larger file size 
is an acceptable trade off, if it reduces the frustration of this situation. 
Especially for new users who will absolutely think its a serious bug in the 
Royale compiler. However, as Harbs notes here, if the compiler were a little 
smarter, ADVANCED_OPTIMIZATIONS could be retained. The compiler could generate 
code differently when something resolves as the Object type. The emitter could 
translate dot notation normally most of the time, and let 
ADVANCED_OPTIMIZATIONS do its renaming. However, if it detects Object, switch 
to bracket notation instead. I believe it would also need to add quotes around 
properties defined in object literals.

Ideally, the following code should work properly out of the box:

var obj:Object = {one: 1, "two": 2};
obj.three = 3;
obj["four"] = 4;
var one:Number = obj["one"];
var two:Number = obj.two;
var three:Number = obj["three"];
var four:Number = obj.four;

The compiler would probably emit something like this to make it work with the 
Closure compiler's ADVANCED_OPTIMIZATIONS:

var obj:Object = {"one": 1, "two": 2};
obj["three"] = 3;
obj["four"] = 4;
var one:Number = obj["one"];
var two:Number = obj["two"];
var three:Number = obj["three"];
var four:Number = obj["four"];

Again, that's only for when something is typed as Object. If something actually 
has a class, let Closure compiler go nuts and rename everything it wants.

- Josh

On 2018/02/06 08:51:19, Gabe Harbs  wrote: 
> Quite sure. In my angular app I was using an older version of the closure 
> compiler to minify the js files. I was using the default options which 
> clearly does not use ADVANCED_OPTIMIZATIONS, so the object literals didn’t 
> get renamed.
> 
> I think most modern app frameworks use other tools such as Babel for 
> magnification, but I believe that handles object literals correctly too.
> 
> We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing object 
> literals. I’m proposing a compiler *option* to allow to continue using 
> ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which should not be 
> renamed.
> 
> Harbs
> 
> > On Feb 6, 2018, at 9:38 AM, Alex Harui  wrote:
> > 
> > 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 Frameworks have.  If you want to minify,
> >>> you have to use brackets and strings.
> >> 
> >> It does.
> >> 
> >> I’ve written angular apps and I’ve never had to worry about using 
> >> bracket
> >> notation for minifying simple js objects. I’m pretty sure the same is for
> >> React, etc.
> >> 
> >>> On Feb 5, 2018, at 11:34 PM, Alex Harui 
> >>> wrote:
> >>> 
> >>> 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 something like a "reviver".  Has anyone played with that to see
> >>> if it can be used to convert straight to VO's?
> >>> 
> >>> Thanks,
> >>> -Alex 
> >>> 
> >>> On 2/5/18, 1:08 PM, "Gabe Harbs"  wrote:
> >>> 
>  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
>  foo[“baz”][“thingy”][“uid”]. Of course the average user is 
>  not going to
>  remember to do that until their release build doesn’t work…
>  
>  Creating VOs means you can’t simply use JSON.parse(). You’d need your
>  own
>  parser for each type of json you’re consuming. OK. Maybe not full
>  parsing, but the constructors for these VOs will get pretty messy —
>  especially if the structure is a bit fluid.
>  
>  Har

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

[Alex Harui]

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;"

Then before creating a new child class, you first build the UID and see if
already exists.  That way you can handle an Employee class being used in
two different fields of a Company object.

Also, you build out a cache of instances so you don't loop for references
back to parent objects.

If anyone gets started on the utility, let us know so we don't have more
than one person working on it.

Thanks,
-Alex

On 2/6/18, 9:53 AM, "Alex Harui"  wrote:

>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 DataGrid.json, it looks like this:
>
>{ "type": "class",
>  "qname": "org.apache.royale.express.DataGrid",
>  "baseClassname": "org.apache.royale.html.DataGrid",
>  "description": "This class extends DataGrid and adds beads for drag and
>drop and column reordering.",
>  "tags": [
> {  "tagName": "flexdocurl",
>"values": 
>["https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflex.ap
>ache.org%2Fasdoc%2Fspark%2Fcomponents%2FDataGrid.html&data=02%7C01%7Caharu
>i%40adobe.com%7C364fbca7fc9144384fd808d56d8a96c0%7C71f1da39c0a84d5a8d88a67
>b23c30bf4%7C0%7C0%7C636535364360288547&sdata=5%2FZyPUsg30zGUdqwPxr3XFu6Qio
>FFL3%2BZ1RBl5kDADw%3D&reserved=0"]},
> {  "tagName": "flexcomponent",
>"values": ["spark.components.DataGrid"]}],
>  "members": [
> { "type": "method",
>   "qname": "org.apache.royale.express.DataGrid",
>   "namespace": "",
>   "return": "",
>   "params": []},
> { "type": "method",
>   "qname": "addedToParent",
>   "namespace": "public",
>   "override": true,
>   "return": "void",
>   "params": []}]
>}
>
>So, I might call this "ClassData".  The utility would JSON.parse the
>structure and walk each property.  If it sees the value is a String then
>it sets the property type to String, if a number, then Number or int if
>the value doesn't have decimal places.  True and false are Booleans.
>Array for Arrays.
>
>If the value is an Array, it looks at the first element in the Array.  IF
>the first element Is an Object, like it is for tags, it would create the
>class ClassData_tags and walk the object.  Same for any value of a field
>that is an Object.
>
>IMO, it doesn't have to be perfect, just save you most of the tedious
>work.  And if you don't like the generated class names, the IDEs should
>support refactoring (now or eventually).
>
>Of course, I could be wrong...
>
>-Alex
>
>
>
>On 2/6/18, 9:16 AM, "Gabe Harbs"  wrote:
>
>>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 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 hash map.  IMO, most C and Java apps don't use generic
 untyped dynamic bags of properties.  If I add a warning about Object
use,
 there will be a directive to suppress it.  Objects are prone to error,
and
 there is some indication that runtimes work better with type
information.
 The JS runtimes wouldn't bother type inferencing otherwise.  WASM
hints
 that it wants types.
 
 My 2 cents,
 -Alex
 
 On 2/6/18, 8:45 AM, "Gabe Harbs"  wrote:
 
> 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
> app.
> 
> Right now, I’m creating VOs for the ASDoc app. It’s kind of tedious
>work…
> 
> Harbs
> 
>> On Feb 6, 2018, at 6:40 PM, Alex Harui 
>>wrote:
>> 
>> 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 it is time for
>

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

[Alex Harui]

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 DataGrid.json, it looks like this:

{ "type": "class",
  "qname": "org.apache.royale.express.DataGrid",
  "baseClassname": "org.apache.royale.html.DataGrid",
  "description": "This class extends DataGrid and adds beads for drag and
drop and column reordering.",
  "tags": [
 {  "tagName": "flexdocurl",
"values": 
["https://flex.apache.org/asdoc/spark/components/DataGrid.html"]},
 {  "tagName": "flexcomponent",
"values": ["spark.components.DataGrid"]}],
  "members": [
 { "type": "method",
   "qname": "org.apache.royale.express.DataGrid",
   "namespace": "",
   "return": "",
   "params": []},
 { "type": "method",
   "qname": "addedToParent",
   "namespace": "public",
   "override": true,
   "return": "void",
   "params": []}]
}

So, I might call this "ClassData".  The utility would JSON.parse the
structure and walk each property.  If it sees the value is a String then
it sets the property type to String, if a number, then Number or int if
the value doesn't have decimal places.  True and false are Booleans.
Array for Arrays.

If the value is an Array, it looks at the first element in the Array.  IF
the first element Is an Object, like it is for tags, it would create the
class ClassData_tags and walk the object.  Same for any value of a field
that is an Object.

IMO, it doesn't have to be perfect, just save you most of the tedious
work.  And if you don't like the generated class names, the IDEs should
support refactoring (now or eventually).

Of course, I could be wrong...

-Alex



On 2/6/18, 9:16 AM, "Gabe Harbs"  wrote:

>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 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 hash map.  IMO, most C and Java apps don't use generic
>>> untyped dynamic bags of properties.  If I add a warning about Object
>>>use,
>>> there will be a directive to suppress it.  Objects are prone to error,
>>>and
>>> there is some indication that runtimes work better with type
>>>information.
>>> The JS runtimes wouldn't bother type inferencing otherwise.  WASM hints
>>> that it wants types.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 2/6/18, 8:45 AM, "Gabe Harbs"  wrote:
>>> 
 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
 app.
 
 Right now, I’m creating VOs for the ASDoc app. It’s kind of tedious
work…
 
 Harbs
 
> On Feb 6, 2018, at 6:40 PM, Alex Harui 
>wrote:
> 
> 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 it is time for
>me
> to
> figure out how to generate warnings on every use of plain Object.
> Eventually we will have typedefs for the GitHub value objects and
>then
> there wouldn't be an issue like this.
> 
> Thanks for proving my point.
> 
> -Alex
> 
> On 2/6/18, 2:59 AM, "Gabe Harbs"  wrote:
> 
>> To illustrate that the VO solution is also error prone, I’m pretty
>>sure
>> that this page has a mistake:
>> 
>> 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapach
>>ero
>> ya
>> 
>> 
>>leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Fl
>>ast
>> Su
>> 
>> 
>>ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicatio
>>n-t
>> ut
>> 
>> 
>>orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b22
>>9e4
>> 9b
>> 
>> 
>>b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63
>>653
>> 51
>> 
>> 
>>16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&re
>>ser
>> ve
>> d=0 
>

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

[OmPrakash Muppirala]

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 Jackson
http://www.baeldung.com/jackson-annotations

Look for @jsonsetter.

Thanks
Om

On Feb 6, 2018 9:16 AM, "Gabe Harbs"  wrote:

> 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 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 hash map.  IMO, most C and Java apps don't use generic
> >> untyped dynamic bags of properties.  If I add a warning about Object
> use,
> >> there will be a directive to suppress it.  Objects are prone to error,
> and
> >> there is some indication that runtimes work better with type
> information.
> >> The JS runtimes wouldn't bother type inferencing otherwise.  WASM hints
> >> that it wants types.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 2/6/18, 8:45 AM, "Gabe Harbs"  wrote:
> >>
> >>> 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
> >>> app.
> >>>
> >>> Right now, I’m creating VOs for the ASDoc app. It’s kind of tedious
> work…
> >>>
> >>> Harbs
> >>>
>  On Feb 6, 2018, at 6:40 PM, Alex Harui 
> wrote:
> 
>  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 it is time for me
>  to
>  figure out how to generate warnings on every use of plain Object.
>  Eventually we will have typedefs for the GitHub value objects and then
>  there wouldn't be an issue like this.
> 
>  Thanks for proving my point.
> 
>  -Alex
> 
>  On 2/6/18, 2:59 AM, "Gabe Harbs"  wrote:
> 
> > To illustrate that the VO solution is also error prone, I’m pretty
> sure
> > that this page has a mistake:
> >
> > https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fapachero
> > ya
> >
> > leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_
> Staging%2Flast
> > Su
> >
> > ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%
> 2Fapplication-t
> > ut
> >
> > orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com
> %7C924b229e4
> > 9b
> >
> > b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C63653
> > 51
> >
> > 16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&
> reser
> > ve
> > d=0
> >
> >  http%3A%2F%2Fapacher
> > oy
> >
> > aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_
> Staging%2Flas
> > tS
> >
> > uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%
> 2Fapplication-
> > tu
> >
> > torial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com
> %7C924b229e
> > 49
> >
> > bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C6365
> > 35
> >
> > 116172825365&sdata=3m3kTW910JYWV8MaM4%2F%
> 2B3v82l5EvxIqgRjqAtIC7N%2BU%3D&
> > re
> > served=0>
> >
> > Unless I’m missing something, the following line can be renamed:
> > data.message = commitObj.message;
> >
> > I think it should have been:
> > data.message = commitObj[“message”];
> >
> > Harbs
> >
> >> On Feb 6, 2018, at 12:48 PM, Gabe Harbs 
> wrote:
> >>
> >> Related:
> >>
> >> On this page:
> >>
> >> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fapacher
> >> oy
> >>
> >> aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_
> Staging%2Fla
> >> st
> >>
> >> SuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%
> 2Fapplicatio
> >> n-
> >>
> >> tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%
> 7C924b229e49bb44
> >> 3d
> >>
> >> dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C636535116
> >

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

[Gabe Harbs]

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 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 hash map.  IMO, most C and Java apps don't use generic
>> untyped dynamic bags of properties.  If I add a warning about Object use,
>> there will be a directive to suppress it.  Objects are prone to error, and
>> there is some indication that runtimes work better with type information.
>> The JS runtimes wouldn't bother type inferencing otherwise.  WASM hints
>> that it wants types.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 2/6/18, 8:45 AM, "Gabe Harbs"  wrote:
>> 
>>> 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
>>> app.
>>> 
>>> Right now, I’m creating VOs for the ASDoc app. It’s kind of tedious work…
>>> 
>>> Harbs
>>> 
 On Feb 6, 2018, at 6:40 PM, Alex Harui  wrote:
 
 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 it is time for me
 to
 figure out how to generate warnings on every use of plain Object.
 Eventually we will have typedefs for the GitHub value objects and then
 there wouldn't be an issue like this.
 
 Thanks for proving my point.
 
 -Alex
 
 On 2/6/18, 2:59 AM, "Gabe Harbs"  wrote:
 
> To illustrate that the VO solution is also error prone, I’m pretty sure
> that this page has a mistake:
> 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachero
> ya
> 
> leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flast
> Su
> 
> ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-t
> ut
> 
> orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e4
> 9b
> 
> b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653
> 51
> 
> 16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&reser
> ve
> d=0 
> 
>  oy
> 
> aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flas
> tS
> 
> uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-
> tu
> 
> torial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e
> 49
> 
> bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365
> 35
> 
> 116172825365&sdata=3m3kTW910JYWV8MaM4%2F%2B3v82l5EvxIqgRjqAtIC7N%2BU%3D&
> re
> served=0>
> 
> Unless I’m missing something, the following line can be renamed:
> data.message = commitObj.message;
> 
> I think it should have been:
> data.message = commitObj[“message”];
> 
> Harbs
> 
>> On Feb 6, 2018, at 12:48 PM, Gabe Harbs  wrote:
>> 
>> Related:
>> 
>> On this page: 
>> 
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacher
>> oy
>> 
>> aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Fla
>> st
>> 
>> SuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicatio
>> n-
>> 
>> tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb44
>> 3d
>> 
>> dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535116
>> 17
>> 
>> 2825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&re
>> se
>> rved=0 
>> 
>> > ro
>> 
>> yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Fl
>> as
>> 
>> tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicati
>> on
>> 
>> -tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb4
>> 43
>> 
>> ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511
>> 61
>> 
>> 72825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&r
>> es
>> erved=0

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

[Gabe Harbs]

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 not use ADVANCED_OPTIMIZATIONS for now.
> 
> There are lots of reasons to avoid using plain Object in a Royale app
> other than as a hash map.  IMO, most C and Java apps don't use generic
> untyped dynamic bags of properties.  If I add a warning about Object use,
> there will be a directive to suppress it.  Objects are prone to error, and
> there is some indication that runtimes work better with type information.
> The JS runtimes wouldn't bother type inferencing otherwise.  WASM hints
> that it wants types.
> 
> My 2 cents,
> -Alex
> 
> On 2/6/18, 8:45 AM, "Gabe Harbs"  wrote:
> 
>> 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
>> app.
>> 
>> Right now, I’m creating VOs for the ASDoc app. It’s kind of tedious work…
>> 
>> Harbs
>> 
>>> On Feb 6, 2018, at 6:40 PM, Alex Harui  wrote:
>>> 
>>> 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 it is time for me
>>> to
>>> figure out how to generate warnings on every use of plain Object.
>>> Eventually we will have typedefs for the GitHub value objects and then
>>> there wouldn't be an issue like this.
>>> 
>>> Thanks for proving my point.
>>> 
>>> -Alex
>>> 
>>> On 2/6/18, 2:59 AM, "Gabe Harbs"  wrote:
>>> 
 To illustrate that the VO solution is also error prone, I’m pretty sure
 that this page has a mistake:
 
 https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachero
 ya
 
 leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flast
 Su
 
 ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-t
 ut
 
 orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e4
 9b
 
 b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653
 51
 
 16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&reser
 ve
 d=0 
 
 
 
 Unless I’m missing something, the following line can be renamed:
  data.message = commitObj.message;
 
 I think it should have been:
  data.message = commitObj[“message”];
 
 Harbs
 
> On Feb 6, 2018, at 12:48 PM, Gabe Harbs  wrote:
> 
> Related:
> 
> On this page: 
> 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacher
> oy
> 
> aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Fla
> st
> 
> SuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicatio
> n-
> 
> tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb44
> 3d
> 
> dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535116
> 17
> 
> 2825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&re
> se
> rved=0 
> 
>  ro
> 
> yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Fl
> as
> 
> tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicati
> on
> 
> -tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb4
> 43
> 
> ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511
> 61
> 
> 72825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&r
> es
> erved=0>
> 
> Shouldn’t the following code have trouble with minification?
> 
> {
> repos = configurator.json.repos;
> projectName = configurator.json.projectName;
> }
> 
> What’s preventing json.repos and json.projectName from being renamed?
> 
>

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

[Alex Harui]

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 hash map.  IMO, most C and Java apps don't use generic
untyped dynamic bags of properties.  If I add a warning about Object use,
there will be a directive to suppress it.  Objects are prone to error, and
there is some indication that runtimes work better with type information.
The JS runtimes wouldn't bother type inferencing otherwise.  WASM hints
that it wants types.

My 2 cents,
-Alex

On 2/6/18, 8:45 AM, "Gabe Harbs"  wrote:

>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
>app.
>
>Right now, I’m creating VOs for the ASDoc app. It’s kind of tedious work…
>
>Harbs
>
>> On Feb 6, 2018, at 6:40 PM, Alex Harui  wrote:
>> 
>> 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 it is time for me
>>to
>> figure out how to generate warnings on every use of plain Object.
>> Eventually we will have typedefs for the GitHub value objects and then
>> there wouldn't be an issue like this.
>> 
>> Thanks for proving my point.
>> 
>> -Alex
>> 
>> On 2/6/18, 2:59 AM, "Gabe Harbs"  wrote:
>> 
>>> To illustrate that the VO solution is also error prone, I’m pretty sure
>>> that this page has a mistake:
>>> 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachero
>>>ya
>>> 
>>>leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flast
>>>Su
>>> 
>>>ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-t
>>>ut
>>> 
>>>orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e4
>>>9b
>>> 
>>>b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653
>>>51
>>> 
>>>16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&reser
>>>ve
>>> d=0 
>>> 
>>>>>oy
>>> 
>>>aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flas
>>>tS
>>> 
>>>uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-
>>>tu
>>> 
>>>torial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e
>>>49
>>> 
>>>bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365
>>>35
>>> 
>>>116172825365&sdata=3m3kTW910JYWV8MaM4%2F%2B3v82l5EvxIqgRjqAtIC7N%2BU%3D&
>>>re
>>> served=0>
>>> 
>>> Unless I’m missing something, the following line can be renamed:
>>>   data.message = commitObj.message;
>>> 
>>> I think it should have been:
>>>   data.message = commitObj[“message”];
>>> 
>>> Harbs
>>> 
 On Feb 6, 2018, at 12:48 PM, Gabe Harbs  wrote:
 
 Related:
 
 On this page: 
 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacher
oy
 
aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Fla
st
 
SuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicatio
n-
 
tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb44
3d
 
dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535116
17
 
2825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&re
se
 rved=0 
 

 
 Shouldn’t the following code have trouble with minification?
 
 {
  repos = configurator.json.repos;
  projectName = configurator.json.projectName;
 }
 
 What’s preventing json.repos and json.projectName from being renamed?
 
> On Feb 5, 2018, at 11:34 PM, Alex Harui  > wrote:
> 
> 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'

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

[Gabe Harbs]

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 app.

Right now, I’m creating VOs for the ASDoc app. It’s kind of tedious work…

Harbs

> On Feb 6, 2018, at 6:40 PM, Alex Harui  wrote:
> 
> 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 it is time for me to
> figure out how to generate warnings on every use of plain Object.
> Eventually we will have typedefs for the GitHub value objects and then
> there wouldn't be an issue like this.
> 
> Thanks for proving my point.
> 
> -Alex
> 
> On 2/6/18, 2:59 AM, "Gabe Harbs"  wrote:
> 
>> To illustrate that the VO solution is also error prone, I’m pretty sure
>> that this page has a mistake:
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheroya
>> leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2FlastSu
>> ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-tut
>> orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49b
>> b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351
>> 16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&reserve
>> d=0 
>> > aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2FlastS
>> uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-tu
>> torial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49
>> bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535
>> 116172825365&sdata=3m3kTW910JYWV8MaM4%2F%2B3v82l5EvxIqgRjqAtIC7N%2BU%3D&re
>> served=0>
>> 
>> Unless I’m missing something, the following line can be renamed:
>>   data.message = commitObj.message;
>> 
>> I think it should have been:
>>   data.message = commitObj[“message”];
>> 
>> Harbs
>> 
>>> On Feb 6, 2018, at 12:48 PM, Gabe Harbs  wrote:
>>> 
>>> Related:
>>> 
>>> On this page: 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheroy
>>> aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flast
>>> SuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-
>>> tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443d
>>> dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511617
>>> 2825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&rese
>>> rved=0 
>>> >> yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flas
>>> tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication
>>> -tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443
>>> ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351161
>>> 72825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&res
>>> erved=0>
>>> 
>>> Shouldn’t the following code have trouble with minification?
>>> 
>>> {
>>>  repos = configurator.json.repos;
>>>  projectName = configurator.json.projectName;
>>> }
>>> 
>>> What’s preventing json.repos and json.projectName from being renamed?
>>> 
 On Feb 5, 2018, at 11:34 PM, Alex Harui >>> > wrote:
 
 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 something like a "reviver".  Has anyone played with that to
 see
 if it can be used to convert straight to VO's?
 
 Thanks,
 -Alex 
 
 On 2/5/18, 1:08 PM, "Gabe Harbs" >>> > wrote:
 
> 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
> foo[“baz”][“thingy”][“uid”]. Of course the average user is not going
> to
> remember to do that until their release build doesn’t work…
> 
> Creating VOs means you can’t simply use JSON.parse(). You’d need your
> own
> parser for each type of json you’re consuming. OK. Maybe not full
> parsing, but the 

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

[Alex Harui]

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 it is time for me to
figure out how to generate warnings on every use of plain Object.
Eventually we will have typedefs for the GitHub value objects and then
there wouldn't be an issue like this.

Thanks for proving my point.

-Alex

On 2/6/18, 2:59 AM, "Gabe Harbs"  wrote:

>To illustrate that the VO solution is also error prone, I’m pretty sure
>that this page has a mistake:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheroya
>leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2FlastSu
>ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-tut
>orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49b
>b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351
>16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&reserve
>d=0 
>aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2FlastS
>uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-tu
>torial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49
>bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535
>116172825365&sdata=3m3kTW910JYWV8MaM4%2F%2B3v82l5EvxIqgRjqAtIC7N%2BU%3D&re
>served=0>
>
>Unless I’m missing something, the following line can be renamed:
>data.message = commitObj.message;
>
>I think it should have been:
>data.message = commitObj[“message”];
>
>Harbs
>
>> On Feb 6, 2018, at 12:48 PM, Gabe Harbs  wrote:
>> 
>> Related:
>> 
>> On this page: 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheroy
>>aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flast
>>SuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-
>>tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443d
>>dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511617
>>2825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&rese
>>rved=0 
>>>yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flas
>>tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication
>>-tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443
>>ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351161
>>72825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&res
>>erved=0>
>> 
>> Shouldn’t the following code have trouble with minification?
>> 
>> {
>>   repos = configurator.json.repos;
>>   projectName = configurator.json.projectName;
>> }
>> 
>> What’s preventing json.repos and json.projectName from being renamed?
>> 
>>> On Feb 5, 2018, at 11:34 PM, Alex Harui >>> wrote:
>>> 
>>> 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 something like a "reviver".  Has anyone played with that to
>>>see
>>> if it can be used to convert straight to VO's?
>>> 
>>> Thanks,
>>> -Alex 
>>> 
>>> On 2/5/18, 1:08 PM, "Gabe Harbs" >>> wrote:
>>> 
 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
 foo[“baz”][“thingy”][“uid”]. Of course the average user is not going
to
 remember to do that until their release build doesn’t work…
 
 Creating VOs means you can’t simply use JSON.parse(). You’d need your
own
 parser for each type of json you’re consuming. OK. Maybe not full
 parsing, but the constructors for these VOs will get pretty messy —
 especially if the structure is a bit fluid.
 
 Harbs
 
 
> On Feb 5, 2018, at 10:36 PM, Gabe Harbs > wrote:
> 
> 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 constructor and declaring the variabl

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

[Gabe Harbs]

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
 


Unless I’m missing something, the following line can be renamed:
data.message = commitObj.message;

I think it should have been:
data.message = commitObj[“message”];

Harbs

> On Feb 6, 2018, at 12:48 PM, Gabe Harbs  wrote:
> 
> Related:
> 
> On this page: 
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/RoyaleDocs_Staging/lastSuccessfulBuild/artifact/_site/create-an-application/application-tutorial/data.html
>  
> 
> 
> Shouldn’t the following code have trouble with minification?
> 
> {
>   repos = configurator.json.repos;
>   projectName = configurator.json.projectName;
> }
> 
> What’s preventing json.repos and json.projectName from being renamed?
> 
>> On Feb 5, 2018, at 11:34 PM, Alex Harui > > wrote:
>> 
>> 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 something like a "reviver".  Has anyone played with that to see
>> if it can be used to convert straight to VO's?
>> 
>> Thanks,
>> -Alex 
>> 
>> On 2/5/18, 1:08 PM, "Gabe Harbs" > > wrote:
>> 
>>> 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
>>> foo[“baz”][“thingy”][“uid”]. Of course the average user is not going to
>>> remember to do that until their release build doesn’t work…
>>> 
>>> Creating VOs means you can’t simply use JSON.parse(). You’d need your own
>>> parser for each type of json you’re consuming. OK. Maybe not full
>>> parsing, but the constructors for these VOs will get pretty messy —
>>> especially if the structure is a bit fluid.
>>> 
>>> Harbs
>>> 
>>> 
 On Feb 5, 2018, at 10:36 PM, Gabe Harbs >>> > wrote:
 
 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 constructor and declaring the variables using
 bracketed access. I was likely going about it wrong, but it was easier
 to just go with the bracketed literals.
 
 Again: Suggesting using VOs (if we can figure out easy instructions to
 do so) is probably a good idea and better recommended practice, but
 people live on the edge using other JS frameworks, and I’d rather not
 make it harder than it needs to be if they do want to use untyped object
 literals.
 
 Harbs
 
> On Feb 5, 2018, at 8:01 PM, Alex Harui  >
> wrote:
> 
> 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 on nice new painted highways.  Flash's runtime wouldn't let
> you
> make type mismatches so it effectively had lane lines.  JS is a road
> without lane lines.  A ValueObject keeps your eyes on the road.  An
> ounce
> of prevention is better than a pound of cure.
> 
> IMO, you might be better off writing a bead that you can pass a JSON
> object and it will generate the AS class for you to copy from the
> clipboard and paste into a file.  Then you could guess at the types.
> That
> wouldn't require compiler changes and would encourage early prevention.
> 
> Just an idea,
> -Alex
> 
> On 2/5/18, 9:39 AM, "Gabe Harbs"  > wrote:
> 
>> Yeah. That’s what you’ve argued in the past, and in a pure world
>> you’d be
>> right.
>> 
>> However, I’d prefer the option to be practical when dealing with m

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

[Gabe Harbs]

Related:

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


Shouldn’t the following code have trouble with minification?

{
  repos = configurator.json.repos;
  projectName = configurator.json.projectName;
}

What’s preventing json.repos and json.projectName from being renamed?

> On Feb 5, 2018, at 11:34 PM, Alex Harui  wrote:
> 
> 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 something like a "reviver".  Has anyone played with that to see
> if it can be used to convert straight to VO's?
> 
> Thanks,
> -Alex 
> 
> On 2/5/18, 1:08 PM, "Gabe Harbs"  wrote:
> 
>> 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
>> foo[“baz”][“thingy”][“uid”]. Of course the average user is not going to
>> remember to do that until their release build doesn’t work…
>> 
>> Creating VOs means you can’t simply use JSON.parse(). You’d need your own
>> parser for each type of json you’re consuming. OK. Maybe not full
>> parsing, but the constructors for these VOs will get pretty messy —
>> especially if the structure is a bit fluid.
>> 
>> Harbs
>> 
>> 
>>> On Feb 5, 2018, at 10:36 PM, Gabe Harbs  wrote:
>>> 
>>> 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 constructor and declaring the variables using
>>> bracketed access. I was likely going about it wrong, but it was easier
>>> to just go with the bracketed literals.
>>> 
>>> Again: Suggesting using VOs (if we can figure out easy instructions to
>>> do so) is probably a good idea and better recommended practice, but
>>> people live on the edge using other JS frameworks, and I’d rather not
>>> make it harder than it needs to be if they do want to use untyped object
>>> literals.
>>> 
>>> Harbs
>>> 
 On Feb 5, 2018, at 8:01 PM, Alex Harui 
 wrote:
 
 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 on nice new painted highways.  Flash's runtime wouldn't let
 you
 make type mismatches so it effectively had lane lines.  JS is a road
 without lane lines.  A ValueObject keeps your eyes on the road.  An
 ounce
 of prevention is better than a pound of cure.
 
 IMO, you might be better off writing a bead that you can pass a JSON
 object and it will generate the AS class for you to copy from the
 clipboard and paste into a file.  Then you could guess at the types.
 That
 wouldn't require compiler changes and would encourage early prevention.
 
 Just an idea,
 -Alex
 
 On 2/5/18, 9:39 AM, "Gabe Harbs"  wrote:
 
> Yeah. That’s what you’ve argued in the past, and in a pure world
> you’d be
> right.
> 
> However, I’d prefer the option to be practical when dealing with more
> data types. Being forced to fiddle with properly typed objects
> *always*
> is too confining IMO. What I personally ended up doing when dealing
> with
> APIs and the like was the make sure to quote everything in my app
> rather
> than declare VOs even though finding all the instances were a pain.
> 
> I think it’s pretty common for folks to use untyped objects
> *especially*
> when dealing with APIs in classic Flex apps. It seem overly draconian
> to
> make that a requirement for Royale.
> 
> Part of the attraction of ActionScript has been that it’s *optionally*
> typed. Minification in JS makes the optional typing pretty weak.
> 
>> If you don't care about SWF support, you can quickly make
>> ValueObjects
>> just for the compiler.
> 
> Quickly? I’m not sure how.
> 
> My $0.02.
> Harbs
> 
>> On Feb 5, 2018, at 7:28 PM, Alex Harui 
>> wrote:
>> 
>> IMO, your proposa

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

[Piotr Zarzycki]

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 :

> 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
> renaming.
>
> I’m all for making using value objects easier too.
>
> You lost me on the part about SOAP.
>
> Harbs
>
> > On Feb 6, 2018, at 11:05 AM, Alex Harui 
> wrote:
> >
> > 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 of ValueObjects easier.  IMO,
> type
> > information will make development faster by catching errors sooner, and
> > has the potential to make the runtime performance faster, especially if
> we
> > consider other targets besides JS some day.
> >
> > To me, the problem is roughly the same as XML decoding into ValueObjects.
> > In XML/SOAP there was a WSDL and some utility converted it to AS
> > ValueObjects.  Other metadata instructed AMF to construct real classes
> > instead of plain objects.  I think there are APIs for that in JSON.parse.
> > I guess I will look into that for the next release.  IMO, if we can't
> > convince folks to use the type system, we lose a major productivity
> > advantage of Royale.  There is always going to be more setup work for
> > Royale. You can't just copy a file and view it in the browser.  You have
> > to run our compiler first.  We should encourage you to create
> ValueObjects
> > at some point.  My tutorial suggests doing it before creating a
> production
> > version.
> >
> > My 2 cents,
> > -Alex
> >
> > On 2/6/18, 12:51 AM, "Gabe Harbs"  wrote:
> >
> >> Quite sure. In my angular app I was using an older version of the
> closure
> >> compiler to minify the js files. I was using the default options which
> >> clearly does not use ADVANCED_OPTIMIZATIONS, so the object literals
> >> didn’t get renamed.
> >>
> >> I think most modern app frameworks use other tools such as Babel for
> >> magnification, but I believe that handles object literals correctly too.
> >>
> >> We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
> >> object literals. I’m proposing a compiler *option* to allow to continue
> >> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
> >> should not be renamed.
> >>
> >> Harbs
> >>
> >>> On Feb 6, 2018, at 9:38 AM, Alex Harui 
> wrote:
> >>>
> >>> 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 Frameworks have.  If you want to
> > minify,
> > you have to use brackets and strings.
> 
>  It does.
> 
>  I’ve written angular apps and I’ve never had to worry about using
>  bracket
>  notation for minifying simple js objects. I’m pretty sure the same is
>  for
>  React, etc.
> 
> > On Feb 5, 2018, at 11:34 PM, Alex Harui 
> > wrote:
> >
> > 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 something like a "reviver".  Has anyone played with that to
> > see
> > if it can be used to convert straight to VO's?
> >
> > Thanks,
> > -Alex
> >
> > On 2/5/18, 1:08 PM, "Gabe Harbs"  wrote:
> >
> >> 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
> >> foo[“baz”][“thingy”][“uid”]. Of course the average user is not going
> >> to
> >> remember to do that until their release build doesn’t work…
> >>
> >> Creating VOs means you can’t simply use JSON.parse(). You’d need
> your
> >> own
> >> parser for each type of json you’re consuming. OK. Maybe not full
> >> parsing, but the constructors for these

Re: ASDoc, Routing, Releases

[Piotr Zarzycki]

+1 for automatic copying ASDoc app to the Royale website. :)

Thanks, Piotr

2018-02-06 9:53 GMT+01:00 Alex Harui :

> The current implementation only calls your custom logic when the hash
> changes.  I'm not sure if there is a way to make that more generic, but
> maybe we'll start seeing a pattern as more folks implement routing in
> Royale apps.
>
> -Alex
>
> On 2/6/18, 12:29 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi Alex,
> >
> >for "generic" I want to say that "routing" should be a framework feature
> >and we should have a library that could link and use with some API in
> >order
> >to make any royale app capable of use permalinks
> >
> >2018-02-05 17:15 GMT+01:00 Alex Harui :
> >
> >> Regarding Routing.  I don't know what "generic" means.  There is now a
> >> bead that dispatches an event when the hash fragment changes.  Logic in
> >> ASDoc processes that hash.  Maybe there is some standard encoding we can
> >> pack in the hash that could map to view states or something, but it
> >>would
> >> make the hash uglier, IMO.
> >>
> >> Thoughts?
> >> -Alex
> >>
> >> On 2/5/18, 12:33 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >>Rovira"
> >>  wrote:
> >>
> >> >Hi Alex,
> >> >
> >> >great work on this part. I'll try to build it localy and see if I can
> >> >tweak
> >> >a bit the look and feel to help with presentation as I get some free
> >>time.
> >> >
> >> >About routing, you made something generic for Royale? or is only made
> >>for
> >> >this ASDoc Reference App?
> >> >
> >> >Thanks
> >> >
> >> >
> >> >
> >> >2018-02-05 9:21 GMT+01:00 Alex Harui :
> >> >
> >> >>
> >> >>
> >> >> On 2/4/18, 1:10 AM, "Gabe Harbs"  wrote:
> >> >>
> >> >> >Typo. I meant js-reease.
> >> >>
> >> >> Yeah, at some later point in time someone should build Value Objects
> >>for
> >> >> the JSON and get js-release working.  Maybe after this release.  I'm
> >> >>just
> >> >> trying to make the ASDoc useful.
> >> >>
> >> >> I'm going to add Events to the class detail page and anchor links
> >>from
> >> >>the
> >> >> lists to the details and maybe a simple search-for-class feature,
> >>then I
> >> >> think it will be time for a release.
> >> >>
> >> >> -Alex
> >> >> >
> >> >> >> On Feb 4, 2018, at 8:08 AM, Alex Harui 
> >> >> wrote:
> >> >> >>
> >> >> >>> 1. Why is bin-release not working?
> >> >> >>
> >> >> >> Do you mean SWF support?
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >Carlos Rovira
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%2
> >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> 7Cf2ee1b2fc0da463b8e8d08d5
> >> >6c7345fa%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> >> 7C636534164705226067&s
> >> >data=7lSe%2BtUKFNWRKCXKm8naElOEAwM17IUNNvjxHgGuAWU%3D&reserved=0
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7Ccf00eb48d20844c6c35508d5
> >6d3bd97b%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C636535026179637700&s
> >data=smCu4I6xnB4mrgiICwy9bHZnO%2BdvOijuFumzASoy1vI%3D&reserved=0
>
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

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

[Gabe Harbs]

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 renaming.

I’m all for making using value objects easier too.

You lost me on the part about SOAP.

Harbs

> On Feb 6, 2018, at 11:05 AM, Alex Harui  wrote:
> 
> 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 of ValueObjects easier.  IMO, type
> information will make development faster by catching errors sooner, and
> has the potential to make the runtime performance faster, especially if we
> consider other targets besides JS some day.
> 
> To me, the problem is roughly the same as XML decoding into ValueObjects.
> In XML/SOAP there was a WSDL and some utility converted it to AS
> ValueObjects.  Other metadata instructed AMF to construct real classes
> instead of plain objects.  I think there are APIs for that in JSON.parse.
> I guess I will look into that for the next release.  IMO, if we can't
> convince folks to use the type system, we lose a major productivity
> advantage of Royale.  There is always going to be more setup work for
> Royale. You can't just copy a file and view it in the browser.  You have
> to run our compiler first.  We should encourage you to create ValueObjects
> at some point.  My tutorial suggests doing it before creating a production
> version.
> 
> My 2 cents,
> -Alex
> 
> On 2/6/18, 12:51 AM, "Gabe Harbs"  wrote:
> 
>> Quite sure. In my angular app I was using an older version of the closure
>> compiler to minify the js files. I was using the default options which
>> clearly does not use ADVANCED_OPTIMIZATIONS, so the object literals
>> didn’t get renamed.
>> 
>> I think most modern app frameworks use other tools such as Babel for
>> magnification, but I believe that handles object literals correctly too.
>> 
>> We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
>> object literals. I’m proposing a compiler *option* to allow to continue
>> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
>> should not be renamed.
>> 
>> Harbs
>> 
>>> On Feb 6, 2018, at 9:38 AM, Alex Harui  wrote:
>>> 
>>> 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 Frameworks have.  If you want to
> minify,
> you have to use brackets and strings.
 
 It does.
 
 I’ve written angular apps and I’ve never had to worry about using
 bracket
 notation for minifying simple js objects. I’m pretty sure the same is
 for
 React, etc.
 
> On Feb 5, 2018, at 11:34 PM, Alex Harui 
> wrote:
> 
> 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 something like a "reviver".  Has anyone played with that to
> see
> if it can be used to convert straight to VO's?
> 
> Thanks,
> -Alex 
> 
> On 2/5/18, 1:08 PM, "Gabe Harbs"  wrote:
> 
>> 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
>> foo[“baz”][“thingy”][“uid”]. Of course the average user is not going
>> to
>> remember to do that until their release build doesn’t work…
>> 
>> Creating VOs means you can’t simply use JSON.parse(). You’d need your
>> own
>> parser for each type of json you’re consuming. OK. Maybe not full
>> parsing, but the constructors for these VOs will get pretty messy —
>> especially if the structure is a bit fluid.
>> 
>> Harbs
>> 
>> 
>>> On Feb 5, 2018, at 10:36 PM, Gabe Harbs 
>>> wrote:
>>> 
>>> 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 pr

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

[Alex Harui]

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 of ValueObjects easier.  IMO, type
information will make development faster by catching errors sooner, and
has the potential to make the runtime performance faster, especially if we
consider other targets besides JS some day.

To me, the problem is roughly the same as XML decoding into ValueObjects.
In XML/SOAP there was a WSDL and some utility converted it to AS
ValueObjects.  Other metadata instructed AMF to construct real classes
instead of plain objects.  I think there are APIs for that in JSON.parse.
I guess I will look into that for the next release.  IMO, if we can't
convince folks to use the type system, we lose a major productivity
advantage of Royale.  There is always going to be more setup work for
Royale. You can't just copy a file and view it in the browser.  You have
to run our compiler first.  We should encourage you to create ValueObjects
at some point.  My tutorial suggests doing it before creating a production
version.

My 2 cents,
-Alex

On 2/6/18, 12:51 AM, "Gabe Harbs"  wrote:

>Quite sure. In my angular app I was using an older version of the closure
>compiler to minify the js files. I was using the default options which
>clearly does not use ADVANCED_OPTIMIZATIONS, so the object literals
>didn’t get renamed.
>
>I think most modern app frameworks use other tools such as Babel for
>magnification, but I believe that handles object literals correctly too.
>
>We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
>object literals. I’m proposing a compiler *option* to allow to continue
>using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
>should not be renamed.
>
>Harbs
>
>> On Feb 6, 2018, at 9:38 AM, Alex Harui  wrote:
>> 
>> 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 Frameworks have.  If you want to
minify,
 you have to use brackets and strings.
>>> 
>>> It does.
>>> 
>>> I’ve written angular apps and I’ve never had to worry about using
>>>bracket
>>> notation for minifying simple js objects. I’m pretty sure the same is
>>>for
>>> React, etc.
>>> 
 On Feb 5, 2018, at 11:34 PM, Alex Harui 
 wrote:
 
 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 something like a "reviver".  Has anyone played with that to
see
 if it can be used to convert straight to VO's?
 
 Thanks,
 -Alex 
 
 On 2/5/18, 1:08 PM, "Gabe Harbs"  wrote:
 
> 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
> foo[“baz”][“thingy”][“uid”]. Of course the average user is not going
>to
> remember to do that until their release build doesn’t work…
> 
> Creating VOs means you can’t simply use JSON.parse(). You’d need your
> own
> parser for each type of json you’re consuming. OK. Maybe not full
> parsing, but the constructors for these VOs will get pretty messy —
> especially if the structure is a bit fluid.
> 
> Harbs
> 
> 
>> On Feb 5, 2018, at 10:36 PM, Gabe Harbs 
>>wrote:
>> 
>> 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 constructor and declaring the variables using
>> bracketed access. I was likely going about it wrong, but it was
>>easier
>> to just go with the bracketed literals.
>> 
>> Again: Suggesting using VOs (if we can figure out easy instructions
>>to
>> do so) is probably a good idea and better recommended practice, but
>> people live on the edge using other JS frameworks, and I’d rather
>>not
>> make it harder than it needs to be if they do want to use untyped
>> object
>> literals.
>> 
>> Harbs
>> 
>>>

Re: ASDoc, Routing, Releases

[Alex Harui]

The current implementation only calls your custom logic when the hash
changes.  I'm not sure if there is a way to make that more generic, but
maybe we'll start seeing a pattern as more folks implement routing in
Royale apps.

-Alex

On 2/6/18, 12:29 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>for "generic" I want to say that "routing" should be a framework feature
>and we should have a library that could link and use with some API in
>order
>to make any royale app capable of use permalinks
>
>2018-02-05 17:15 GMT+01:00 Alex Harui :
>
>> Regarding Routing.  I don't know what "generic" means.  There is now a
>> bead that dispatches an event when the hash fragment changes.  Logic in
>> ASDoc processes that hash.  Maybe there is some standard encoding we can
>> pack in the hash that could map to view states or something, but it
>>would
>> make the hash uglier, IMO.
>>
>> Thoughts?
>> -Alex
>>
>> On 2/5/18, 12:33 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>  wrote:
>>
>> >Hi Alex,
>> >
>> >great work on this part. I'll try to build it localy and see if I can
>> >tweak
>> >a bit the look and feel to help with presentation as I get some free
>>time.
>> >
>> >About routing, you made something generic for Royale? or is only made
>>for
>> >this ASDoc Reference App?
>> >
>> >Thanks
>> >
>> >
>> >
>> >2018-02-05 9:21 GMT+01:00 Alex Harui :
>> >
>> >>
>> >>
>> >> On 2/4/18, 1:10 AM, "Gabe Harbs"  wrote:
>> >>
>> >> >Typo. I meant js-reease.
>> >>
>> >> Yeah, at some later point in time someone should build Value Objects
>>for
>> >> the JSON and get js-release working.  Maybe after this release.  I'm
>> >>just
>> >> trying to make the ASDoc useful.
>> >>
>> >> I'm going to add Events to the class detail page and anchor links
>>from
>> >>the
>> >> lists to the details and maybe a simple search-for-class feature,
>>then I
>> >> think it will be time for a release.
>> >>
>> >> -Alex
>> >> >
>> >> >> On Feb 4, 2018, at 8:08 AM, Alex Harui 
>> >> wrote:
>> >> >>
>> >> >>> 1. Why is bin-release not working?
>> >> >>
>> >> >> Do you mean SWF support?
>> >> >
>> >>
>> >>
>> >
>> >
>> >--
>> >Carlos Rovira
>> >https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
>> 7Cf2ee1b2fc0da463b8e8d08d5
>> >6c7345fa%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
>> 7C636534164705226067&s
>> >data=7lSe%2BtUKFNWRKCXKm8naElOEAwM17IUNNvjxHgGuAWU%3D&reserved=0
>>
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccf00eb48d20844c6c35508d5
>6d3bd97b%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535026179637700&s
>data=smCu4I6xnB4mrgiICwy9bHZnO%2BdvOijuFumzASoy1vI%3D&reserved=0

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

[Gabe Harbs]

Quite sure. In my angular app I was using an older version of the closure 
compiler to minify the js files. I was using the default options which clearly 
does not use ADVANCED_OPTIMIZATIONS, so the object literals didn’t get renamed.

I think most modern app frameworks use other tools such as Babel for 
magnification, but I believe that handles object literals correctly too.

We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing object 
literals. I’m proposing a compiler *option* to allow to continue using 
ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which should not be 
renamed.

Harbs

> On Feb 6, 2018, at 9:38 AM, Alex Harui  wrote:
> 
> 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 Frameworks have.  If you want to minify,
>>> you have to use brackets and strings.
>> 
>> It does.
>> 
>> I’ve written angular apps and I’ve never had to worry about using bracket
>> notation for minifying simple js objects. I’m pretty sure the same is for
>> React, etc.
>> 
>>> On Feb 5, 2018, at 11:34 PM, Alex Harui 
>>> wrote:
>>> 
>>> 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 something like a "reviver".  Has anyone played with that to see
>>> if it can be used to convert straight to VO's?
>>> 
>>> Thanks,
>>> -Alex 
>>> 
>>> On 2/5/18, 1:08 PM, "Gabe Harbs"  wrote:
>>> 
 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
 foo[“baz”][“thingy”][“uid”]. Of course the average user is not going to
 remember to do that until their release build doesn’t work…
 
 Creating VOs means you can’t simply use JSON.parse(). You’d need your
 own
 parser for each type of json you’re consuming. OK. Maybe not full
 parsing, but the constructors for these VOs will get pretty messy —
 especially if the structure is a bit fluid.
 
 Harbs
 
 
> On Feb 5, 2018, at 10:36 PM, Gabe Harbs  wrote:
> 
> 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 constructor and declaring the variables using
> bracketed access. I was likely going about it wrong, but it was easier
> to just go with the bracketed literals.
> 
> Again: Suggesting using VOs (if we can figure out easy instructions to
> do so) is probably a good idea and better recommended practice, but
> people live on the edge using other JS frameworks, and I’d rather not
> make it harder than it needs to be if they do want to use untyped
> object
> literals.
> 
> Harbs
> 
>> On Feb 5, 2018, at 8:01 PM, Alex Harui 
>> wrote:
>> 
>> 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 on nice new painted highways.  Flash's runtime wouldn't let
>> you
>> make type mismatches so it effectively had lane lines.  JS is a road
>> without lane lines.  A ValueObject keeps your eyes on the road.  An
>> ounce
>> of prevention is better than a pound of cure.
>> 
>> IMO, you might be better off writing a bead that you can pass a JSON
>> object and it will generate the AS class for you to copy from the
>> clipboard and paste into a file.  Then you could guess at the types.
>> That
>> wouldn't require compiler changes and would encourage early
>> prevention.
>> 
>> Just an idea,
>> -Alex
>> 
>> On 2/5/18, 9:39 AM, "Gabe Harbs"  wrote:
>> 
>>> Yeah. That’s what you’ve argued in the past, and in a pure world
>>> you’d be
>>> right.
>>> 
>>> However, I’d prefer the option to be practical when dealing with
>>> more
>>> data types. Being forced to fiddle with properly typed objects
>>> *always*
>>> is too confining IMO. Wh

Re: ASDoc, Routing, Releases

[Carlos Rovira]

Hi Alex,

in fact I think that's what it should be :)
don't know if as part of the website or in the royale-docs live url.
Anyway the proposed url is ok.

When I updated the website I overlay the folder with changes, as in the
website there's no "/asdoc/" url it will be untouched by my changes

thanks






2018-02-06 6:29 GMT+01:00 Alex Harui :

> ASDoc is looking better.  I was looking into tools to understand how
> google crawls sites and found that I can't use them on Jenkins.  I also
> saw in another thread that there is a way to get ASF Jenkins to push
> changes to a gitpubsub site.  Also, the ASDoc URL is long and ugly.
>
> So, I'm thinking we should create a Jenkins job to copy ASDoc to
> royale.a.o.  Does anybody have any reason we shouldn't publish ASDoc on
> royale.a.o?  Also, what folder should we use?  royale.a.o/asdoc/?
>
> Thoughts?
> -Alex
>
> On 2/5/18, 9:44 AM, "Gabe Harbs"  wrote:
>
> >> What did you clean out?
> >
> >Everything.
> >
> >I deleted the entire contents of the three repo folders except the .git
> >folder.
> >
> >I then stashed my local “changes" and pulled develop to bring my repo
> >into a clean up-to-date state.
> >
> >I’m not sure what the problem was.
> >
> >Harbs
> >
> >> On Feb 5, 2018, at 7:37 PM, Alex Harui 
> wrote:
> >>
> >> What did you clean out?  It might help others if you update the scripts
> >>to
> >> clean up better.  I thought it was working correctly.
> >>
> >> When things get renamed, the scripts don't always clean out the old
> >> folders.
> >>
> >> -Alex
> >>
> >> On 2/5/18, 9:29 AM, "Gabe Harbs"  >>> wrote:
> >>
> >>> I manually cleaned out my repo folders, pulled again and now it seems
> >>>to
> >>> be working.
> >>>
> >>> It looks like ant wipe-all on the compiler and ant clean all on asjs,
> >>> doesn’t quite clean everything…
> >>>
>  On Feb 5, 2018, at 7:13 PM, Gabe Harbs  wrote:
> 
>  It looks like I needed to set some env vars.
> 
>  I did so, and I’m getting some JSON files, but not the full thing.
> 
>  I just updated my repos and did ant clean all. I’m now getting a
> failed
>  build of Royale and I’m not sure why...
> 
>  royale.royaletasks.jar:
> 
>  jar:
> 
>  main:
> 
>  main:
> 
>  download:
>  [echo] /Apache/royale-asjs
> [unjar] Expanding:
>  /Apache/royale-asjs/js/lib/google/closure-compiler/compiler.jar into
>  /Apache/royale-typedefs/js/target/temp/externs
> [unzip] Expanding:
>  /Apache/royale-typedefs/js/target/temp/externs/externs.zip into
>  /Apache/royale-typedefs/js/target/downloads
>   [get] Getting:
> 
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fstorag
> e
>  https%3A%2F%2Fstora
> ge>.
>  googleapis.com
>  http%3A%2F%2Fgoogle
> apis.com%2F&data=02%7C01%7Caharui%40adobe.com%
> 7Cea3588c69d96467c165f08d
> 56cc01d3d%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C6365344947393196
> 87&sdata=wz0mlDPXSNb9R9uIL55hVuaRVCE1Qsxa5EN5XZoF1K4%3D&reserved=0>%
> 2Fg
> oogle-code-archive-downloads%2Fv2%2Fcode.google.com
>  http%3A%2F%2F2fcode
> .google.com%2F&data=02%7C01%7Caharui%40adobe.com%
> 7Cea3588c69d96467c165f
> 08d56cc01d3d%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C6365344947393
> 19687&sdata=kkKyUtW7yWmIlI2YaMM2084mFatUbp
> lmnr6PBa26PDU%3D&reserved=0>%
> 2Fc
>  losureidl%2Fsvg.js&data=02%7C01%7Caharui%40adobe.com
>  http%3A%2F%2F40adob
> e.com%2F&data=02%7C01%7Caharui%40adobe.com%
> 7Cea3588c69d96467c165f08d56c
> c01d3d%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C636534494739319687&
> sdata=OdEf7fY9Th9Rzl0I47YgM0c%2F0nkANAERsBzzoNptghc%3D&
> reserved=0>%7Ce7
> 402a81cda54e1dbc
> 
> e608d56cbe0f88%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C63653448592
> 05
> 
> 06853&sdata=NwzNAbDc3gdOLz94AJG1T8sf1%2FYeEzPZIjxsLLCCN68%3D&
> reserved=0
> 
>  https%3A%2F%2Fstora
> ge
>  https%3A%2F%2Fstora
> ge>
>  .googleapis.com
>  http%3A%2F%2Fgoogle
> apis.com%2F&data=02%7C01%7Caharui%40adobe.com%
> 7Cea3588c69d96467c165f08d
> 56cc01d3d%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C6365344947393196
> 87&sdata=wz0mlDPXSNb9R9uIL55hVuaRVCE1Qsxa5EN5XZoF1K4%3D&reserved=0>%
> 2Fg
> oogle-code-archive-downloads%2Fv2%2Fcode.google.com
>  http%3A%2F%2F2fcode
> .google.com%2F&data=02%7C01%7Caharui%40adobe.com%
> 7Cea3588c69d96467c165f
> 08d56cc01d3d%7C71f1da39c0a84d5a8d88a67b2

Re: ASDoc, Routing, Releases

[Carlos Rovira]

Hi Alex,

for "generic" I want to say that "routing" should be a framework feature
and we should have a library that could link and use with some API in order
to make any royale app capable of use permalinks

2018-02-05 17:15 GMT+01:00 Alex Harui :

> Regarding Routing.  I don't know what "generic" means.  There is now a
> bead that dispatches an event when the hash fragment changes.  Logic in
> ASDoc processes that hash.  Maybe there is some standard encoding we can
> pack in the hash that could map to view states or something, but it would
> make the hash uglier, IMO.
>
> Thoughts?
> -Alex
>
> On 2/5/18, 12:33 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi Alex,
> >
> >great work on this part. I'll try to build it localy and see if I can
> >tweak
> >a bit the look and feel to help with presentation as I get some free time.
> >
> >About routing, you made something generic for Royale? or is only made for
> >this ASDoc Reference App?
> >
> >Thanks
> >
> >
> >
> >2018-02-05 9:21 GMT+01:00 Alex Harui :
> >
> >>
> >>
> >> On 2/4/18, 1:10 AM, "Gabe Harbs"  wrote:
> >>
> >> >Typo. I meant js-reease.
> >>
> >> Yeah, at some later point in time someone should build Value Objects for
> >> the JSON and get js-release working.  Maybe after this release.  I'm
> >>just
> >> trying to make the ASDoc useful.
> >>
> >> I'm going to add Events to the class detail page and anchor links from
> >>the
> >> lists to the details and maybe a simple search-for-class feature, then I
> >> think it will be time for a release.
> >>
> >> -Alex
> >> >
> >> >> On Feb 4, 2018, at 8:08 AM, Alex Harui 
> >> wrote:
> >> >>
> >> >>> 1. Why is bin-release not working?
> >> >>
> >> >> Do you mean SWF support?
> >> >
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7Cf2ee1b2fc0da463b8e8d08d5
> >6c7345fa%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C636534164705226067&s
> >data=7lSe%2BtUKFNWRKCXKm8naElOEAwM17IUNNvjxHgGuAWU%3D&reserved=0
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

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

[Alex Harui]

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 Frameworks have.  If you want to minify,
>> you have to use brackets and strings.
>
>It does.
>
>I’ve written angular apps and I’ve never had to worry about using bracket
>notation for minifying simple js objects. I’m pretty sure the same is for
>React, etc.
>
>> On Feb 5, 2018, at 11:34 PM, Alex Harui 
>>wrote:
>> 
>> 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 something like a "reviver".  Has anyone played with that to see
>> if it can be used to convert straight to VO's?
>> 
>> Thanks,
>> -Alex 
>> 
>> On 2/5/18, 1:08 PM, "Gabe Harbs"  wrote:
>> 
>>> 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
>>> foo[“baz”][“thingy”][“uid”]. Of course the average user is not going to
>>> remember to do that until their release build doesn’t work…
>>> 
>>> Creating VOs means you can’t simply use JSON.parse(). You’d need your
>>>own
>>> parser for each type of json you’re consuming. OK. Maybe not full
>>> parsing, but the constructors for these VOs will get pretty messy —
>>> especially if the structure is a bit fluid.
>>> 
>>> Harbs
>>> 
>>> 
 On Feb 5, 2018, at 10:36 PM, Gabe Harbs  wrote:
 
 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 constructor and declaring the variables using
 bracketed access. I was likely going about it wrong, but it was easier
 to just go with the bracketed literals.
 
 Again: Suggesting using VOs (if we can figure out easy instructions to
 do so) is probably a good idea and better recommended practice, but
 people live on the edge using other JS frameworks, and I’d rather not
 make it harder than it needs to be if they do want to use untyped
object
 literals.
 
 Harbs
 
> On Feb 5, 2018, at 8:01 PM, Alex Harui 
> wrote:
> 
> 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 on nice new painted highways.  Flash's runtime wouldn't let
> you
> make type mismatches so it effectively had lane lines.  JS is a road
> without lane lines.  A ValueObject keeps your eyes on the road.  An
> ounce
> of prevention is better than a pound of cure.
> 
> IMO, you might be better off writing a bead that you can pass a JSON
> object and it will generate the AS class for you to copy from the
> clipboard and paste into a file.  Then you could guess at the types.
> That
> wouldn't require compiler changes and would encourage early
>prevention.
> 
> Just an idea,
> -Alex
> 
> On 2/5/18, 9:39 AM, "Gabe Harbs"  wrote:
> 
>> Yeah. That’s what you’ve argued in the past, and in a pure world
>> you’d be
>> right.
>> 
>> However, I’d prefer the option to be practical when dealing with
>>more
>> data types. Being forced to fiddle with properly typed objects
>> *always*
>> is too confining IMO. What I personally ended up doing when dealing
>> with
>> APIs and the like was the make sure to quote everything in my app
>> rather
>> than declare VOs even though finding all the instances were a pain.
>> 
>> I think it’s pretty common for folks to use untyped objects
>> *especially*
>> when dealing with APIs in classic Flex apps. It seem overly
>>draconian
>> to
>> make that a requirement for Royale.
>> 
>> Part of the attraction of ActionScript has been that it’s
>>*optionally*
>> typed. Minification in JS makes the optional typing pretty weak.
>> 
>>> If you don't care about SWF support, you can quickly make
>>> ValueObjects
>>> just for the compiler.
>> 
>> Quickly? I’m not sure how.
>> 
>> My $0.02.
>> H

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

[Gabe Harbs]

> 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.

It does.

I’ve written angular apps and I’ve never had to worry about using bracket 
notation for minifying simple js objects. I’m pretty sure the same is for 
React, etc.

> On Feb 5, 2018, at 11:34 PM, Alex Harui  wrote:
> 
> 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 something like a "reviver".  Has anyone played with that to see
> if it can be used to convert straight to VO's?
> 
> Thanks,
> -Alex 
> 
> On 2/5/18, 1:08 PM, "Gabe Harbs"  wrote:
> 
>> 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
>> foo[“baz”][“thingy”][“uid”]. Of course the average user is not going to
>> remember to do that until their release build doesn’t work…
>> 
>> Creating VOs means you can’t simply use JSON.parse(). You’d need your own
>> parser for each type of json you’re consuming. OK. Maybe not full
>> parsing, but the constructors for these VOs will get pretty messy —
>> especially if the structure is a bit fluid.
>> 
>> Harbs
>> 
>> 
>>> On Feb 5, 2018, at 10:36 PM, Gabe Harbs  wrote:
>>> 
>>> 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 constructor and declaring the variables using
>>> bracketed access. I was likely going about it wrong, but it was easier
>>> to just go with the bracketed literals.
>>> 
>>> Again: Suggesting using VOs (if we can figure out easy instructions to
>>> do so) is probably a good idea and better recommended practice, but
>>> people live on the edge using other JS frameworks, and I’d rather not
>>> make it harder than it needs to be if they do want to use untyped object
>>> literals.
>>> 
>>> Harbs
>>> 
 On Feb 5, 2018, at 8:01 PM, Alex Harui 
 wrote:
 
 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 on nice new painted highways.  Flash's runtime wouldn't let
 you
 make type mismatches so it effectively had lane lines.  JS is a road
 without lane lines.  A ValueObject keeps your eyes on the road.  An
 ounce
 of prevention is better than a pound of cure.
 
 IMO, you might be better off writing a bead that you can pass a JSON
 object and it will generate the AS class for you to copy from the
 clipboard and paste into a file.  Then you could guess at the types.
 That
 wouldn't require compiler changes and would encourage early prevention.
 
 Just an idea,
 -Alex
 
 On 2/5/18, 9:39 AM, "Gabe Harbs"  wrote:
 
> Yeah. That’s what you’ve argued in the past, and in a pure world
> you’d be
> right.
> 
> However, I’d prefer the option to be practical when dealing with more
> data types. Being forced to fiddle with properly typed objects
> *always*
> is too confining IMO. What I personally ended up doing when dealing
> with
> APIs and the like was the make sure to quote everything in my app
> rather
> than declare VOs even though finding all the instances were a pain.
> 
> I think it’s pretty common for folks to use untyped objects
> *especially*
> when dealing with APIs in classic Flex apps. It seem overly draconian
> to
> make that a requirement for Royale.
> 
> Part of the attraction of ActionScript has been that it’s *optionally*
> typed. Minification in JS makes the optional typing pretty weak.
> 
>> If you don't care about SWF support, you can quickly make
>> ValueObjects
>> just for the compiler.
> 
> Quickly? I’m not sure how.
> 
> My $0.02.
> Harbs
> 
>> On Feb 5, 2018, at 7:28 PM, Alex Harui 
>> wrote:
>> 
>> IMO, your proposal sort of defeats the purpose of ActionScript and
>> Royale,
>> which is to provide a type system at compile time.  Not only should
>> you
>> want to address your JSON fields, but you should want to 

Re: ASDoc, Routing, Releases

[Alex Harui]

ASDoc is looking better.  I was looking into tools to understand how
google crawls sites and found that I can't use them on Jenkins.  I also
saw in another thread that there is a way to get ASF Jenkins to push
changes to a gitpubsub site.  Also, the ASDoc URL is long and ugly.

So, I'm thinking we should create a Jenkins job to copy ASDoc to
royale.a.o.  Does anybody have any reason we shouldn't publish ASDoc on
royale.a.o?  Also, what folder should we use?  royale.a.o/asdoc/?

Thoughts?
-Alex

On 2/5/18, 9:44 AM, "Gabe Harbs"  wrote:

>> What did you clean out?
>
>Everything.
>
>I deleted the entire contents of the three repo folders except the .git
>folder.
>
>I then stashed my local “changes" and pulled develop to bring my repo
>into a clean up-to-date state.
>
>I’m not sure what the problem was.
>
>Harbs
>
>> On Feb 5, 2018, at 7:37 PM, Alex Harui  wrote:
>> 
>> What did you clean out?  It might help others if you update the scripts
>>to
>> clean up better.  I thought it was working correctly.
>> 
>> When things get renamed, the scripts don't always clean out the old
>> folders.
>> 
>> -Alex
>> 
>> On 2/5/18, 9:29 AM, "Gabe Harbs" >> wrote:
>> 
>>> I manually cleaned out my repo folders, pulled again and now it seems
>>>to
>>> be working.
>>> 
>>> It looks like ant wipe-all on the compiler and ant clean all on asjs,
>>> doesn’t quite clean everything…
>>> 
 On Feb 5, 2018, at 7:13 PM, Gabe Harbs  wrote:
 
 It looks like I needed to set some env vars.
 
 I did so, and I’m getting some JSON files, but not the full thing.
 
 I just updated my repos and did ant clean all. I’m now getting a
failed
 build of Royale and I’m not sure why...
 
 royale.royaletasks.jar:
 
 jar:
 
 main:
 
 main:
 
 download:
 [echo] /Apache/royale-asjs
[unjar] Expanding:
 /Apache/royale-asjs/js/lib/google/closure-compiler/compiler.jar into
 /Apache/royale-typedefs/js/target/temp/externs
[unzip] Expanding:
 /Apache/royale-typedefs/js/target/temp/externs/externs.zip into
 /Apache/royale-typedefs/js/target/downloads
  [get] Getting:
 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstorag
e 
.
 googleapis.com
%2Fg
oogle-code-archive-downloads%2Fv2%2Fcode.google.com
%
2Fc
 losureidl%2Fsvg.js&data=02%7C01%7Caharui%40adobe.com
%7Ce7
402a81cda54e1dbc
 
e608d56cbe0f88%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653448592
05
 
06853&sdata=NwzNAbDc3gdOLz94AJG1T8sf1%2FYeEzPZIjxsLLCCN68%3D&reserved=0
 

 .googleapis.com
%2Fg
oogle-code-archive-downloads%2Fv2%2Fcode.google.com
%
2F
 closureidl%2Fsvg.js&data=02%7C01%7Caharui%40adobe.com
%7Ce7
402a81cda54e1db
 
ce608d56cbe0f88%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365344859
20
 
506853&sdata=NwzNAbDc3gdOLz94AJG1T8

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

[Alex Harui]

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 something like a "reviver".  Has anyone played with that to see
if it can be used to convert straight to VO's?

Thanks,
-Alex 

On 2/5/18, 1:08 PM, "Gabe Harbs"  wrote:

>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
>foo[“baz”][“thingy”][“uid”]. Of course the average user is not going to
>remember to do that until their release build doesn’t work…
>
>Creating VOs means you can’t simply use JSON.parse(). You’d need your own
>parser for each type of json you’re consuming. OK. Maybe not full
>parsing, but the constructors for these VOs will get pretty messy —
>especially if the structure is a bit fluid.
>
>Harbs
>
>
>> On Feb 5, 2018, at 10:36 PM, Gabe Harbs  wrote:
>> 
>> 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 constructor and declaring the variables using
>>bracketed access. I was likely going about it wrong, but it was easier
>>to just go with the bracketed literals.
>> 
>> Again: Suggesting using VOs (if we can figure out easy instructions to
>>do so) is probably a good idea and better recommended practice, but
>>people live on the edge using other JS frameworks, and I’d rather not
>>make it harder than it needs to be if they do want to use untyped object
>>literals.
>> 
>> Harbs
>> 
>>> On Feb 5, 2018, at 8:01 PM, Alex Harui 
>>>wrote:
>>> 
>>> 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 on nice new painted highways.  Flash's runtime wouldn't let
>>>you
>>> make type mismatches so it effectively had lane lines.  JS is a road
>>> without lane lines.  A ValueObject keeps your eyes on the road.  An
>>>ounce
>>> of prevention is better than a pound of cure.
>>> 
>>> IMO, you might be better off writing a bead that you can pass a JSON
>>> object and it will generate the AS class for you to copy from the
>>> clipboard and paste into a file.  Then you could guess at the types.
>>>That
>>> wouldn't require compiler changes and would encourage early prevention.
>>> 
>>> Just an idea,
>>> -Alex
>>> 
>>> On 2/5/18, 9:39 AM, "Gabe Harbs"  wrote:
>>> 
 Yeah. That’s what you’ve argued in the past, and in a pure world
you’d be
 right.
 
 However, I’d prefer the option to be practical when dealing with more
 data types. Being forced to fiddle with properly typed objects
*always*
 is too confining IMO. What I personally ended up doing when dealing
with
 APIs and the like was the make sure to quote everything in my app
rather
 than declare VOs even though finding all the instances were a pain.
 
 I think it’s pretty common for folks to use untyped objects
*especially*
 when dealing with APIs in classic Flex apps. It seem overly draconian
to
 make that a requirement for Royale.
 
 Part of the attraction of ActionScript has been that it’s *optionally*
 typed. Minification in JS makes the optional typing pretty weak.
 
> If you don't care about SWF support, you can quickly make
>ValueObjects
> just for the compiler.
 
 Quickly? I’m not sure how.
 
 My $0.02.
 Harbs
 
> On Feb 5, 2018, at 7:28 PM, Alex Harui 
>wrote:
> 
> IMO, your proposal sort of defeats the purpose of ActionScript and
> Royale,
> which is to provide a type system at compile time.  Not only should
>you
> want to address your JSON fields, but you should want to have them
> type-checked, and that you spelled the field name correctly.
>Otherwise,
> the compiler is going to also allow you to mistype:
> 
> var name = myProps["nme"];
> 
> 
> And there will be no errors.  And similarly:
> 
> var myObj:Object = {
> nme: "foo",
> age : 30.1415
> }
> 
> Will be allowed when it probably shouldn't.  And also, you could then
> use
> myObj when you intended to use myOtherObj and nobody will know until
>you
> try to debug in JS.
> 
> 
> If you don't care about SWF sup

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

[Gabe Harbs]

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 foo[“baz”][“thingy”][“uid”]. Of course the 
average user is not going to remember to do that until their release build 
doesn’t work…

Creating VOs means you can’t simply use JSON.parse(). You’d need your own 
parser for each type of json you’re consuming. OK. Maybe not full parsing, but 
the constructors for these VOs will get pretty messy — especially if the 
structure is a bit fluid.

Harbs


> On Feb 5, 2018, at 10:36 PM, Gabe Harbs  wrote:
> 
> 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 
> constructor and declaring the variables using bracketed access. I was likely 
> going about it wrong, but it was easier to just go with the bracketed 
> literals.
> 
> Again: Suggesting using VOs (if we can figure out easy instructions to do so) 
> is probably a good idea and better recommended practice, but people live on 
> the edge using other JS frameworks, and I’d rather not make it harder than it 
> needs to be if they do want to use untyped object literals.
> 
> Harbs
> 
>> On Feb 5, 2018, at 8:01 PM, Alex Harui  wrote:
>> 
>> 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 on nice new painted highways.  Flash's runtime wouldn't let you
>> make type mismatches so it effectively had lane lines.  JS is a road
>> without lane lines.  A ValueObject keeps your eyes on the road.  An ounce
>> of prevention is better than a pound of cure.
>> 
>> IMO, you might be better off writing a bead that you can pass a JSON
>> object and it will generate the AS class for you to copy from the
>> clipboard and paste into a file.  Then you could guess at the types.  That
>> wouldn't require compiler changes and would encourage early prevention.
>> 
>> Just an idea,
>> -Alex
>> 
>> On 2/5/18, 9:39 AM, "Gabe Harbs"  wrote:
>> 
>>> Yeah. That’s what you’ve argued in the past, and in a pure world you’d be
>>> right.
>>> 
>>> However, I’d prefer the option to be practical when dealing with more
>>> data types. Being forced to fiddle with properly typed objects *always*
>>> is too confining IMO. What I personally ended up doing when dealing with
>>> APIs and the like was the make sure to quote everything in my app rather
>>> than declare VOs even though finding all the instances were a pain.
>>> 
>>> I think it’s pretty common for folks to use untyped objects *especially*
>>> when dealing with APIs in classic Flex apps. It seem overly draconian to
>>> make that a requirement for Royale.
>>> 
>>> Part of the attraction of ActionScript has been that it’s *optionally*
>>> typed. Minification in JS makes the optional typing pretty weak.
>>> 
 If you don't care about SWF support, you can quickly make ValueObjects
 just for the compiler.
>>> 
>>> Quickly? I’m not sure how.
>>> 
>>> My $0.02.
>>> Harbs
>>> 
 On Feb 5, 2018, at 7:28 PM, Alex Harui  wrote:
 
 IMO, your proposal sort of defeats the purpose of ActionScript and
 Royale,
 which is to provide a type system at compile time.  Not only should you
 want to address your JSON fields, but you should want to have them
 type-checked, and that you spelled the field name correctly.  Otherwise,
 the compiler is going to also allow you to mistype:
 
 var name = myProps["nme"];
 
 
 And there will be no errors.  And similarly:
 
 var myObj:Object = {
 nme: "foo",
 age : 30.1415
 }
 
 Will be allowed when it probably shouldn't.  And also, you could then
 use
 myObj when you intended to use myOtherObj and nobody will know until you
 try to debug in JS.
 
 
 If you don't care about SWF support, you can quickly make ValueObjects
 just for the compiler.  In ASDoc, the ValueObject is never instantiated.
 It is just like a typedef for the compiler.
 
 HTH,
 -Alex
 
 On 2/5/18, 8:43 AM, "Gabe Harbs"  wrote:
 
>> JSON Objects are not destroyed.
> 
> Yeah. I know, but untyped js literals are pretty much useless in
> minified
> Royale apps.
> 
>> Propose a way to determine that a data structure
>> is external and what the compiler should generate and implement it.
>> IMO,
>> the answer is to create ValueObjects.  That is essent

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

[Gabe Harbs]

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 
constructor and declaring the variables using bracketed access. I was likely 
going about it wrong, but it was easier to just go with the bracketed literals.

Again: Suggesting using VOs (if we can figure out easy instructions to do so) 
is probably a good idea and better recommended practice, but people live on the 
edge using other JS frameworks, and I’d rather not make it harder than it needs 
to be if they do want to use untyped object literals.

Harbs

> On Feb 5, 2018, at 8:01 PM, Alex Harui  wrote:
> 
> 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 on nice new painted highways.  Flash's runtime wouldn't let you
> make type mismatches so it effectively had lane lines.  JS is a road
> without lane lines.  A ValueObject keeps your eyes on the road.  An ounce
> of prevention is better than a pound of cure.
> 
> IMO, you might be better off writing a bead that you can pass a JSON
> object and it will generate the AS class for you to copy from the
> clipboard and paste into a file.  Then you could guess at the types.  That
> wouldn't require compiler changes and would encourage early prevention.
> 
> Just an idea,
> -Alex
> 
> On 2/5/18, 9:39 AM, "Gabe Harbs"  wrote:
> 
>> Yeah. That’s what you’ve argued in the past, and in a pure world you’d be
>> right.
>> 
>> However, I’d prefer the option to be practical when dealing with more
>> data types. Being forced to fiddle with properly typed objects *always*
>> is too confining IMO. What I personally ended up doing when dealing with
>> APIs and the like was the make sure to quote everything in my app rather
>> than declare VOs even though finding all the instances were a pain.
>> 
>> I think it’s pretty common for folks to use untyped objects *especially*
>> when dealing with APIs in classic Flex apps. It seem overly draconian to
>> make that a requirement for Royale.
>> 
>> Part of the attraction of ActionScript has been that it’s *optionally*
>> typed. Minification in JS makes the optional typing pretty weak.
>> 
>>> If you don't care about SWF support, you can quickly make ValueObjects
>>> just for the compiler.
>> 
>> Quickly? I’m not sure how.
>> 
>> My $0.02.
>> Harbs
>> 
>>> On Feb 5, 2018, at 7:28 PM, Alex Harui  wrote:
>>> 
>>> IMO, your proposal sort of defeats the purpose of ActionScript and
>>> Royale,
>>> which is to provide a type system at compile time.  Not only should you
>>> want to address your JSON fields, but you should want to have them
>>> type-checked, and that you spelled the field name correctly.  Otherwise,
>>> the compiler is going to also allow you to mistype:
>>> 
>>> var name = myProps["nme"];
>>> 
>>> 
>>> And there will be no errors.  And similarly:
>>> 
>>> var myObj:Object = {
>>> nme: "foo",
>>> age : 30.1415
>>> }
>>> 
>>> Will be allowed when it probably shouldn't.  And also, you could then
>>> use
>>> myObj when you intended to use myOtherObj and nobody will know until you
>>> try to debug in JS.
>>> 
>>> 
>>> If you don't care about SWF support, you can quickly make ValueObjects
>>> just for the compiler.  In ASDoc, the ValueObject is never instantiated.
>>> It is just like a typedef for the compiler.
>>> 
>>> HTH,
>>> -Alex
>>> 
>>> On 2/5/18, 8:43 AM, "Gabe Harbs"  wrote:
>>> 
> JSON Objects are not destroyed.
 
 Yeah. I know, but untyped js literals are pretty much useless in
 minified
 Royale apps.
 
> Propose a way to determine that a data structure
> is external and what the compiler should generate and implement it.
> IMO,
> the answer is to create ValueObjects.  That is essentially typedefs
> and
> AFAIK, there is no way to automate typedef generation.
 
 I already made a suggestion once:
 
 For untyped Objects, the compiler could convert dot notation to bracket
 notation.
 
 The other half of that would be to convert all object literals to
 “quoted” literals automatically.
 
 So if I have a function:
 
 function parseMyJson(json:String):Object{
return JSON.parse(json);
 }
 
 var myProps:Object = parseMyJson(json);
 
 var name:string = myProps.name;
 
 Would become:
 
 function parseMyJson(json){
return JSON.parse(json);
 }
 
 var myProps = parseMyJson(json);
 
 var name = myProps["name"];
 
 And this:
 var myObj:Object = {
name: "foo",
age : 30
 }
 
 Would b

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

[Alex Harui]

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 on nice new painted highways.  Flash's runtime wouldn't let you
make type mismatches so it effectively had lane lines.  JS is a road
without lane lines.  A ValueObject keeps your eyes on the road.  An ounce
of prevention is better than a pound of cure.

IMO, you might be better off writing a bead that you can pass a JSON
object and it will generate the AS class for you to copy from the
clipboard and paste into a file.  Then you could guess at the types.  That
wouldn't require compiler changes and would encourage early prevention.

Just an idea,
-Alex

On 2/5/18, 9:39 AM, "Gabe Harbs"  wrote:

>Yeah. That’s what you’ve argued in the past, and in a pure world you’d be
>right.
>
>However, I’d prefer the option to be practical when dealing with more
>data types. Being forced to fiddle with properly typed objects *always*
>is too confining IMO. What I personally ended up doing when dealing with
>APIs and the like was the make sure to quote everything in my app rather
>than declare VOs even though finding all the instances were a pain.
>
>I think it’s pretty common for folks to use untyped objects *especially*
>when dealing with APIs in classic Flex apps. It seem overly draconian to
>make that a requirement for Royale.
>
>Part of the attraction of ActionScript has been that it’s *optionally*
>typed. Minification in JS makes the optional typing pretty weak.
>
>> If you don't care about SWF support, you can quickly make ValueObjects
>> just for the compiler.
>
>Quickly? I’m not sure how.
>
>My $0.02.
>Harbs
>
>> On Feb 5, 2018, at 7:28 PM, Alex Harui  wrote:
>> 
>> IMO, your proposal sort of defeats the purpose of ActionScript and
>>Royale,
>> which is to provide a type system at compile time.  Not only should you
>> want to address your JSON fields, but you should want to have them
>> type-checked, and that you spelled the field name correctly.  Otherwise,
>> the compiler is going to also allow you to mistype:
>> 
>> var name = myProps["nme"];
>> 
>> 
>> And there will be no errors.  And similarly:
>> 
>> var myObj:Object = {
>>  nme: "foo",
>>  age : 30.1415
>> }
>> 
>> Will be allowed when it probably shouldn't.  And also, you could then
>>use
>> myObj when you intended to use myOtherObj and nobody will know until you
>> try to debug in JS.
>> 
>> 
>> If you don't care about SWF support, you can quickly make ValueObjects
>> just for the compiler.  In ASDoc, the ValueObject is never instantiated.
>> It is just like a typedef for the compiler.
>> 
>> HTH,
>> -Alex
>> 
>> On 2/5/18, 8:43 AM, "Gabe Harbs"  wrote:
>> 
 JSON Objects are not destroyed.
>>> 
>>> Yeah. I know, but untyped js literals are pretty much useless in
>>>minified
>>> Royale apps.
>>> 
 Propose a way to determine that a data structure
 is external and what the compiler should generate and implement it.
 IMO,
 the answer is to create ValueObjects.  That is essentially typedefs
and
 AFAIK, there is no way to automate typedef generation.
>>> 
>>> I already made a suggestion once:
>>> 
>>> For untyped Objects, the compiler could convert dot notation to bracket
>>> notation.
>>> 
>>> The other half of that would be to convert all object literals to
>>> “quoted” literals automatically.
>>> 
>>> So if I have a function:
>>> 
>>> function parseMyJson(json:String):Object{
>>> return JSON.parse(json);
>>> }
>>> 
>>> var myProps:Object = parseMyJson(json);
>>> 
>>> var name:string = myProps.name;
>>> 
>>> Would become:
>>> 
>>> function parseMyJson(json){
>>> return JSON.parse(json);
>>> }
>>> 
>>> var myProps = parseMyJson(json);
>>> 
>>> var name = myProps["name"];
>>> 
>>> And this:
>>> var myObj:Object = {
>>> name: "foo",
>>> age : 30
>>> }
>>> 
>>> Would become:
>>> var myObj = {
>>> "name": "foo",
>>> "age" : 30
>>> }
>>> 
>>> These two features would have solved almost all minification issues
>>>I’ve
>>> run into.
>>> 
>>> I’d love to work on this myself, but I’m still not up to making any
>>>major
>>> changes to the compiler… :-(
>>> 
 On Feb 5, 2018, at 6:13 PM, Alex Harui 
wrote:
 
 
 
 On 2/5/18, 2:01 AM, "Gabe Harbs"  wrote:
 
> I’ll try to work on this. It’s pretty slow loading the debug build.
> 
> I still maintain there should be a compiler setting or language
>feature
> to prevent objects produced from JSON being destroyed on
>minification.
 
 JSON Objects are not destroyed.  The code referencing their fields by
 name
 has those names changed.  Propose a way to determine that a data
 structure
 is external and what the compiler should generate and implement it.
 IMO,
 the answer is to create ValueObjects.  That i

Re: ASDoc, Routing, Releases

[Gabe Harbs]

> What did you clean out?

Everything.

I deleted the entire contents of the three repo folders except the .git folder.

I then stashed my local “changes" and pulled develop to bring my repo into a 
clean up-to-date state.

I’m not sure what the problem was.

Harbs

> On Feb 5, 2018, at 7:37 PM, Alex Harui  wrote:
> 
> What did you clean out?  It might help others if you update the scripts to
> clean up better.  I thought it was working correctly.
> 
> When things get renamed, the scripts don't always clean out the old
> folders.
> 
> -Alex
> 
> On 2/5/18, 9:29 AM, "Gabe Harbs"  > wrote:
> 
>> I manually cleaned out my repo folders, pulled again and now it seems to
>> be working.
>> 
>> It looks like ant wipe-all on the compiler and ant clean all on asjs,
>> doesn’t quite clean everything…
>> 
>>> On Feb 5, 2018, at 7:13 PM, Gabe Harbs  wrote:
>>> 
>>> It looks like I needed to set some env vars.
>>> 
>>> I did so, and I’m getting some JSON files, but not the full thing.
>>> 
>>> I just updated my repos and did ant clean all. I’m now getting a failed
>>> build of Royale and I’m not sure why...
>>> 
>>> royale.royaletasks.jar:
>>> 
>>> jar:
>>> 
>>> main:
>>> 
>>> main:
>>> 
>>> download:
>>> [echo] /Apache/royale-asjs
>>>[unjar] Expanding:
>>> /Apache/royale-asjs/js/lib/google/closure-compiler/compiler.jar into
>>> /Apache/royale-typedefs/js/target/temp/externs
>>>[unzip] Expanding:
>>> /Apache/royale-typedefs/js/target/temp/externs/externs.zip into
>>> /Apache/royale-typedefs/js/target/downloads
>>>  [get] Getting:
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstorage 
>>> .
>>> googleapis.com 
>>> %2Fgoogle-code-archive-downloads%2Fv2%2Fcode.google.com
>>>  %2Fc
>>> losureidl%2Fsvg.js&data=02%7C01%7Caharui%40adobe.com 
>>> %7Ce7402a81cda54e1dbc
>>> e608d56cbe0f88%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365344859205
>>> 06853&sdata=NwzNAbDc3gdOLz94AJG1T8sf1%2FYeEzPZIjxsLLCCN68%3D&reserved=0
>>> >> 
>>> .googleapis.com 
>>> %2Fgoogle-code-archive-downloads%2Fv2%2Fcode.google.com
>>>  %2F
>>> closureidl%2Fsvg.js&data=02%7C01%7Caharui%40adobe.com 
>>> %7Ce7402a81cda54e1db
>>> ce608d56cbe0f88%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636534485920
>>> 506853&sdata=NwzNAbDc3gdOLz94AJG1T8sf1%2FYeEzPZIjxsLLCCN68%3D&reserved=0>
>>>  [get] To: /Apache/royale-typedefs/js/target/downloads/svg.js
>>> 
>>> double-check-file:
>>> [echo] ${env.ROYALE_DOWNLOAD_CACHE}
>>> [echo] Need file: ${still_no_file}
>>> 
>>> get-from-cache-if-needed:
>>> 
>>> fail-if-not-found:
>>> 
>>> preprocess:
>>> 
>>> externc:
>>> [java] Error: Could not find or load main class
>>> org.apache.royale.compiler.clients.EXTERNC
>>> 
>>> BUILD FAILED
>>> /Apache/royale-asjs/build.xml:1753: The following error occurred while
>>> executing this line:
>>> /Apache/royale-asjs/build.xml:1825: The following error occurred while
>>> executing this line:
>>> /Apache/royale-typedefs/build.xml:52: The following error occurred
>>> while executing this line:
>>> /Apache/royale-typedefs/js/build.xml:159: Java returned: 1
>>> 
>>> Total time: 58 seconds
>>> Harbss-MacBook-Pro:royale-asjs harbs$
>>> 
 On Feb 5, 2018, at 6:32 PM, Gabe Harbs >>> 
 >> wrote:
 
 I’m using ant, but I’m not getting the json files.
 
 Now that I know where to look, I’ll try and examine the script and see
 if I can figure it out…
 
> On Feb 5, 2018, at 6:09 PM, Alex Harui  
> >> 
> wrote:
> 
> The Ant script for examples/royale/ASDoc builds the JSON files.  I
> have
> not taken the time to figure out how to make Maven call the ASDoc
> compiler.  Someone with more Maven knowledge might be faster at
> figuring
> that out.
> 
> Thanks,
> -Alex
> 
> On 2/5/18, 7:21 AM, "carlos.rov...@gmail.com 
> 
> > on 
> behalf of Carlos Rovira"
> mailto:carlos.rov...@gmail.com> 
> > on 
> behalf
> of carlosrov...@apache.org  
> >> wrote:
> 
>> Hi I'm in the same boat.
>> I can build the App with Maven.
>> I ran it and saw the main layout but the list are not populated
>

Re: ASDoc, Routing, Releases

[Gabe Harbs]

Yeah. That’s what you’ve argued in the past, and in a pure world you’d be right.

However, I’d prefer the option to be practical when dealing with more data 
types. Being forced to fiddle with properly typed objects *always* is too 
confining IMO. What I personally ended up doing when dealing with APIs and the 
like was the make sure to quote everything in my app rather than declare VOs 
even though finding all the instances were a pain.

I think it’s pretty common for folks to use untyped objects *especially* when 
dealing with APIs in classic Flex apps. It seem overly draconian to make that a 
requirement for Royale.

Part of the attraction of ActionScript has been that it’s *optionally* typed. 
Minification in JS makes the optional typing pretty weak.

> If you don't care about SWF support, you can quickly make ValueObjects
> just for the compiler.

Quickly? I’m not sure how.

My $0.02.
Harbs

> On Feb 5, 2018, at 7:28 PM, Alex Harui  wrote:
> 
> IMO, your proposal sort of defeats the purpose of ActionScript and Royale,
> which is to provide a type system at compile time.  Not only should you
> want to address your JSON fields, but you should want to have them
> type-checked, and that you spelled the field name correctly.  Otherwise,
> the compiler is going to also allow you to mistype:
> 
> var name = myProps["nme"];
> 
> 
> And there will be no errors.  And similarly:
> 
> var myObj:Object = {
>  nme: "foo",
>  age : 30.1415
> }
> 
> Will be allowed when it probably shouldn't.  And also, you could then use
> myObj when you intended to use myOtherObj and nobody will know until you
> try to debug in JS.
> 
> 
> If you don't care about SWF support, you can quickly make ValueObjects
> just for the compiler.  In ASDoc, the ValueObject is never instantiated.
> It is just like a typedef for the compiler.
> 
> HTH,
> -Alex
> 
> On 2/5/18, 8:43 AM, "Gabe Harbs"  wrote:
> 
>>> JSON Objects are not destroyed.
>> 
>> Yeah. I know, but untyped js literals are pretty much useless in minified
>> Royale apps.
>> 
>>> Propose a way to determine that a data structure
>>> is external and what the compiler should generate and implement it.
>>> IMO,
>>> the answer is to create ValueObjects.  That is essentially typedefs and
>>> AFAIK, there is no way to automate typedef generation.
>> 
>> I already made a suggestion once:
>> 
>> For untyped Objects, the compiler could convert dot notation to bracket
>> notation.
>> 
>> The other half of that would be to convert all object literals to
>> “quoted” literals automatically.
>> 
>> So if I have a function:
>> 
>> function parseMyJson(json:String):Object{
>>  return JSON.parse(json);
>> }
>> 
>> var myProps:Object = parseMyJson(json);
>> 
>> var name:string = myProps.name;
>> 
>> Would become:
>> 
>> function parseMyJson(json){
>>  return JSON.parse(json);
>> }
>> 
>> var myProps = parseMyJson(json);
>> 
>> var name = myProps["name"];
>> 
>> And this:
>> var myObj:Object = {
>>  name: "foo",
>>  age : 30
>> }
>> 
>> Would become:
>> var myObj = {
>>  "name": "foo",
>>  "age" : 30
>> }
>> 
>> These two features would have solved almost all minification issues I’ve
>> run into.
>> 
>> I’d love to work on this myself, but I’m still not up to making any major
>> changes to the compiler… :-(
>> 
>>> On Feb 5, 2018, at 6:13 PM, Alex Harui  wrote:
>>> 
>>> 
>>> 
>>> On 2/5/18, 2:01 AM, "Gabe Harbs"  wrote:
>>> 
 I’ll try to work on this. It’s pretty slow loading the debug build.
 
 I still maintain there should be a compiler setting or language feature
 to prevent objects produced from JSON being destroyed on minification.
>>> 
>>> JSON Objects are not destroyed.  The code referencing their fields by
>>> name
>>> has those names changed.  Propose a way to determine that a data
>>> structure
>>> is external and what the compiler should generate and implement it.
>>> IMO,
>>> the answer is to create ValueObjects.  That is essentially typedefs and
>>> AFAIK, there is no way to automate typedef generation.
>>> 
>>> Also, you can turn off minification for the app as a whole.
>>> 
>>> Other ideas welcome,
>>> -Alex
>>> 
 This remains a pain point for developing apps and having to create VOs
 for every API is a drag.
 
> On Feb 5, 2018, at 10:21 AM, Alex Harui 
> wrote:
> 
> 
> 
> On 2/4/18, 1:10 AM, "Gabe Harbs"  wrote:
> 
>> Typo. I meant js-reease.
> 
> Yeah, at some later point in time someone should build Value Objects
> for
> the JSON and get js-release working.  Maybe after this release.  I'm
> just
> trying to make the ASDoc useful.
> 
> I'm going to add Events to the class detail page and anchor links from
> the
> lists to the details and maybe a simple search-for-class feature,
> then I
> think it will be time for a release.
> 
> -Alex
>> 
>>> On Feb 4, 2018, at 8:08 AM, Alex Harui 
>>> wrote:
>>> 
 1. Why is bin-release 

Re: ASDoc, Routing, Releases

[Alex Harui]

What did you clean out?  It might help others if you update the scripts to
clean up better.  I thought it was working correctly.

When things get renamed, the scripts don't always clean out the old
folders.

-Alex

On 2/5/18, 9:29 AM, "Gabe Harbs"  wrote:

>I manually cleaned out my repo folders, pulled again and now it seems to
>be working.
>
>It looks like ant wipe-all on the compiler and ant clean all on asjs,
>doesn’t quite clean everything…
>
>> On Feb 5, 2018, at 7:13 PM, Gabe Harbs  wrote:
>> 
>> It looks like I needed to set some env vars.
>> 
>> I did so, and I’m getting some JSON files, but not the full thing.
>> 
>> I just updated my repos and did ant clean all. I’m now getting a failed
>>build of Royale and I’m not sure why...
>> 
>> royale.royaletasks.jar:
>> 
>> jar:
>> 
>> main:
>> 
>> main:
>> 
>> download:
>>  [echo] /Apache/royale-asjs
>> [unjar] Expanding:
>>/Apache/royale-asjs/js/lib/google/closure-compiler/compiler.jar into
>>/Apache/royale-typedefs/js/target/temp/externs
>> [unzip] Expanding:
>>/Apache/royale-typedefs/js/target/temp/externs/externs.zip into
>>/Apache/royale-typedefs/js/target/downloads
>>   [get] Getting:
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstorage.
>>googleapis.com%2Fgoogle-code-archive-downloads%2Fv2%2Fcode.google.com%2Fc
>>losureidl%2Fsvg.js&data=02%7C01%7Caharui%40adobe.com%7Ce7402a81cda54e1dbc
>>e608d56cbe0f88%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365344859205
>>06853&sdata=NwzNAbDc3gdOLz94AJG1T8sf1%2FYeEzPZIjxsLLCCN68%3D&reserved=0
>>>.googleapis.com%2Fgoogle-code-archive-downloads%2Fv2%2Fcode.google.com%2F
>>closureidl%2Fsvg.js&data=02%7C01%7Caharui%40adobe.com%7Ce7402a81cda54e1db
>>ce608d56cbe0f88%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636534485920
>>506853&sdata=NwzNAbDc3gdOLz94AJG1T8sf1%2FYeEzPZIjxsLLCCN68%3D&reserved=0>
>>   [get] To: /Apache/royale-typedefs/js/target/downloads/svg.js
>> 
>> double-check-file:
>>  [echo] ${env.ROYALE_DOWNLOAD_CACHE}
>>  [echo] Need file: ${still_no_file}
>> 
>> get-from-cache-if-needed:
>> 
>> fail-if-not-found:
>> 
>> preprocess:
>> 
>> externc:
>>  [java] Error: Could not find or load main class
>>org.apache.royale.compiler.clients.EXTERNC
>> 
>> BUILD FAILED
>> /Apache/royale-asjs/build.xml:1753: The following error occurred while
>>executing this line:
>> /Apache/royale-asjs/build.xml:1825: The following error occurred while
>>executing this line:
>> /Apache/royale-typedefs/build.xml:52: The following error occurred
>>while executing this line:
>> /Apache/royale-typedefs/js/build.xml:159: Java returned: 1
>> 
>> Total time: 58 seconds
>> Harbss-MacBook-Pro:royale-asjs harbs$
>> 
>>> On Feb 5, 2018, at 6:32 PM, Gabe Harbs >>> wrote:
>>> 
>>> I’m using ant, but I’m not getting the json files.
>>> 
>>> Now that I know where to look, I’ll try and examine the script and see
>>>if I can figure it out…
>>> 
 On Feb 5, 2018, at 6:09 PM, Alex Harui >>>> wrote:
 
 The Ant script for examples/royale/ASDoc builds the JSON files.  I
have
 not taken the time to figure out how to make Maven call the ASDoc
 compiler.  Someone with more Maven knowledge might be faster at
figuring
 that out.
 
 Thanks,
 -Alex
 
 On 2/5/18, 7:21 AM, "carlos.rov...@gmail.com
 on behalf of Carlos Rovira"
 mailto:carlos.rov...@gmail.com> on behalf
of carlosrov...@apache.org > wrote:
 
> Hi I'm in the same boat.
> I can build the App with Maven.
> I ran it and saw the main layout but the list are not populated
> 
> 2018-02-05 11:10 GMT+01:00 Gabe Harbs >:
> 
>> I don’t see any son files when I build the framework.
>> 
>> Building the ASDoc project builds the ASDoc app, but again, I see no
>> JSON
>> files anywhere.
>> 
>> What creates the JSON files?
>> 
>>> On Feb 4, 2018, at 8:08 AM, Alex Harui >>>
>> wrote:
>>> 
 
 The big question: How do I build this with real JSON data locally,
>> so I
 can work on the ASDoc app?
>>> 
>>> What error are you getting?  It builds with Ant for me and the CI
>> server
>>> is building it.  The build script will build the JSON.
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> 
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.
>me%2 
>.me%2>
> Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com
>be.com%2F&data=02%7C01%7Caharui%40adobe.com%7Ce7402a81cda54e1dbce608d5
>6cbe0f88%7C71f1da39c0a84d5a8d88a67b

Re: ASDoc, Routing, Releases

[Alex Harui]

What commands were you running?  What environment vars did you need to
set?  No environment vars should be required other than as specified in
the README.

Your output looks like the tail end of the compiler build, not the
royale-asjs/examples/royale/ASDoc/build.xml

Note that the royale-asjs build copies the compiler from royale-compiler,
so if you make changes to the compiler you have to run enough of the
royale-asjs build as well to copy the compiler over.

Thanks,
-Alex

On 2/5/18, 9:13 AM, "Gabe Harbs"  wrote:

>It looks like I needed to set some env vars.
>
>I did so, and I’m getting some JSON files, but not the full thing.
>
>I just updated my repos and did ant clean all. I’m now getting a failed
>build of Royale and I’m not sure why...
>
>royale.royaletasks.jar:
>
>jar:
>
>main:
>
>main:
>
>download:
> [echo] /Apache/royale-asjs
>[unjar] Expanding:
>/Apache/royale-asjs/js/lib/google/closure-compiler/compiler.jar into
>/Apache/royale-typedefs/js/target/temp/externs
>[unzip] Expanding:
>/Apache/royale-typedefs/js/target/temp/externs/externs.zip into
>/Apache/royale-typedefs/js/target/downloads
>  [get] Getting:
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstorage.g
>oogleapis.com%2Fgoogle-code-archive-downloads%2Fv2%2Fcode.google.com%2Fclo
>sureidl%2Fsvg.js&data=02%7C01%7Caharui%40adobe.com%7C3adf73d4ff584fe4bd350
>8d56cbbdc35%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653447647268233
>5&sdata=htrF8KLkzD2CcpliKTC5tneDHYE19Za75LzjtzCAqms%3D&reserved=0
>  [get] To: /Apache/royale-typedefs/js/target/downloads/svg.js
>
>double-check-file:
> [echo] ${env.ROYALE_DOWNLOAD_CACHE}
> [echo] Need file: ${still_no_file}
>
>get-from-cache-if-needed:
>
>fail-if-not-found:
>
>preprocess:
>
>externc:
> [java] Error: Could not find or load main class
>org.apache.royale.compiler.clients.EXTERNC
>
>BUILD FAILED
>/Apache/royale-asjs/build.xml:1753: The following error occurred while
>executing this line:
>/Apache/royale-asjs/build.xml:1825: The following error occurred while
>executing this line:
>/Apache/royale-typedefs/build.xml:52: The following error occurred while
>executing this line:
>/Apache/royale-typedefs/js/build.xml:159: Java returned: 1
>
>Total time: 58 seconds
>Harbss-MacBook-Pro:royale-asjs harbs$
>
>> On Feb 5, 2018, at 6:32 PM, Gabe Harbs  wrote:
>> 
>> I’m using ant, but I’m not getting the json files.
>> 
>> Now that I know where to look, I’ll try and examine the script and see
>>if I can figure it out…
>> 
>>> On Feb 5, 2018, at 6:09 PM, Alex Harui >>> wrote:
>>> 
>>> The Ant script for examples/royale/ASDoc builds the JSON files.  I have
>>> not taken the time to figure out how to make Maven call the ASDoc
>>> compiler.  Someone with more Maven knowledge might be faster at
>>>figuring
>>> that out.
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 2/5/18, 7:21 AM, "carlos.rov...@gmail.com
>>> on behalf of Carlos Rovira"
>>> mailto:carlos.rov...@gmail.com> on behalf of
>>>carlosrov...@apache.org > wrote:
>>> 
 Hi I'm in the same boat.
 I can build the App with Maven.
 I ran it and saw the main layout but the list are not populated
 
 2018-02-05 11:10 GMT+01:00 Gabe Harbs >>>>:
 
> I don’t see any son files when I build the framework.
> 
> Building the ASDoc project builds the ASDoc app, but again, I see no
> JSON
> files anywhere.
> 
> What creates the JSON files?
> 
>> On Feb 4, 2018, at 8:08 AM, Alex Harui >>
> wrote:
>> 
>>> 
>>> The big question: How do I build this with real JSON data locally,
> so I
>>> can work on the ASDoc app?
>> 
>> What error are you getting?  It builds with Ant for me and the CI
> server
>> is building it.  The build script will build the JSON.
> 
> 
 
 
 -- 
 Carlos Rovira
 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.m
e%2 

 Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com
%7C6b
c182a710ed4ce440e408d5
 
6cac3212%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653440918450578
4&s
 data=lNdSFaLQoU9IXHtzD0ryoGXjgupvjEh314hc9nTKyds%3D&reserved=0
>> 
>

Re: ASDoc, Routing, Releases

[Gabe Harbs]

I manually cleaned out my repo folders, pulled again and now it seems to be 
working.

It looks like ant wipe-all on the compiler and ant clean all on asjs, doesn’t 
quite clean everything…

> On Feb 5, 2018, at 7:13 PM, Gabe Harbs  wrote:
> 
> It looks like I needed to set some env vars.
> 
> I did so, and I’m getting some JSON files, but not the full thing.
> 
> I just updated my repos and did ant clean all. I’m now getting a failed build 
> of Royale and I’m not sure why...
> 
> royale.royaletasks.jar:
> 
> jar:
> 
> main:
> 
> main:
> 
> download:
>  [echo] /Apache/royale-asjs
> [unjar] Expanding: 
> /Apache/royale-asjs/js/lib/google/closure-compiler/compiler.jar into 
> /Apache/royale-typedefs/js/target/temp/externs
> [unzip] Expanding: 
> /Apache/royale-typedefs/js/target/temp/externs/externs.zip into 
> /Apache/royale-typedefs/js/target/downloads
>   [get] Getting: 
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/closureidl/svg.js
>  
> 
>   [get] To: /Apache/royale-typedefs/js/target/downloads/svg.js
> 
> double-check-file:
>  [echo] ${env.ROYALE_DOWNLOAD_CACHE}
>  [echo] Need file: ${still_no_file}
> 
> get-from-cache-if-needed:
> 
> fail-if-not-found:
> 
> preprocess:
> 
> externc:
>  [java] Error: Could not find or load main class 
> org.apache.royale.compiler.clients.EXTERNC
> 
> BUILD FAILED
> /Apache/royale-asjs/build.xml:1753: The following error occurred while 
> executing this line:
> /Apache/royale-asjs/build.xml:1825: The following error occurred while 
> executing this line:
> /Apache/royale-typedefs/build.xml:52: The following error occurred while 
> executing this line:
> /Apache/royale-typedefs/js/build.xml:159: Java returned: 1
> 
> Total time: 58 seconds
> Harbss-MacBook-Pro:royale-asjs harbs$ 
> 
>> On Feb 5, 2018, at 6:32 PM, Gabe Harbs > > wrote:
>> 
>> I’m using ant, but I’m not getting the json files.
>> 
>> Now that I know where to look, I’ll try and examine the script and see if I 
>> can figure it out…
>> 
>>> On Feb 5, 2018, at 6:09 PM, Alex Harui >> > wrote:
>>> 
>>> The Ant script for examples/royale/ASDoc builds the JSON files.  I have
>>> not taken the time to figure out how to make Maven call the ASDoc
>>> compiler.  Someone with more Maven knowledge might be faster at figuring
>>> that out.
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 2/5/18, 7:21 AM, "carlos.rov...@gmail.com 
>>>  on behalf of Carlos Rovira"
>>> mailto:carlos.rov...@gmail.com> on behalf of 
>>> carlosrov...@apache.org > wrote:
>>> 
 Hi I'm in the same boat.
 I can build the App with Maven.
 I ran it and saw the main layout but the list are not populated
 
 2018-02-05 11:10 GMT+01:00 Gabe Harbs >>> >:
 
> I don’t see any son files when I build the framework.
> 
> Building the ASDoc project builds the ASDoc app, but again, I see no
> JSON
> files anywhere.
> 
> What creates the JSON files?
> 
>> On Feb 4, 2018, at 8:08 AM, Alex Harui > >
> wrote:
>> 
>>> 
>>> The big question: How do I build this with real JSON data locally,
> so I
>>> can work on the ASDoc app?
>> 
>> What error are you getting?  It builds with Ant for me and the CI
> server
>> is building it.  The build script will build the JSON.
> 
> 
 
 
 -- 
 Carlos Rovira
 https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 
 
 Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com 
 %7C6bc182a710ed4ce440e408d5
 6cac3212%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636534409184505784&s
 data=lNdSFaLQoU9IXHtzD0ryoGXjgupvjEh314hc9nTKyds%3D&reserved=0
>> 
> 

Re: ASDoc, Routing, Releases

[Alex Harui]

IMO, your proposal sort of defeats the purpose of ActionScript and Royale,
which is to provide a type system at compile time.  Not only should you
want to address your JSON fields, but you should want to have them
type-checked, and that you spelled the field name correctly.  Otherwise,
the compiler is going to also allow you to mistype:

var name = myProps["nme"];


And there will be no errors.  And similarly:

var myObj:Object = {
  nme: "foo",
  age : 30.1415
}

Will be allowed when it probably shouldn't.  And also, you could then use
myObj when you intended to use myOtherObj and nobody will know until you
try to debug in JS.


If you don't care about SWF support, you can quickly make ValueObjects
just for the compiler.  In ASDoc, the ValueObject is never instantiated.
It is just like a typedef for the compiler.

HTH,
-Alex

On 2/5/18, 8:43 AM, "Gabe Harbs"  wrote:

>> JSON Objects are not destroyed.
>
>Yeah. I know, but untyped js literals are pretty much useless in minified
>Royale apps.
>
>> Propose a way to determine that a data structure
>> is external and what the compiler should generate and implement it.
>>IMO,
>> the answer is to create ValueObjects.  That is essentially typedefs and
>> AFAIK, there is no way to automate typedef generation.
>
>I already made a suggestion once:
>
>For untyped Objects, the compiler could convert dot notation to bracket
>notation.
>
>The other half of that would be to convert all object literals to
>“quoted” literals automatically.
>
>So if I have a function:
>
>function parseMyJson(json:String):Object{
>   return JSON.parse(json);
>}
>
>var myProps:Object = parseMyJson(json);
>
>var name:string = myProps.name;
>
>Would become:
>
>function parseMyJson(json){
>   return JSON.parse(json);
>}
>
>var myProps = parseMyJson(json);
>
>var name = myProps["name"];
>
>And this:
>var myObj:Object = {
>   name: "foo",
>   age : 30
>}
>
>Would become:
>var myObj = {
>   "name": "foo",
>   "age" : 30
>}
>
>These two features would have solved almost all minification issues I’ve
>run into.
>
>I’d love to work on this myself, but I’m still not up to making any major
>changes to the compiler… :-(
>
>> On Feb 5, 2018, at 6:13 PM, Alex Harui  wrote:
>> 
>> 
>> 
>> On 2/5/18, 2:01 AM, "Gabe Harbs"  wrote:
>> 
>>> I’ll try to work on this. It’s pretty slow loading the debug build.
>>> 
>>> I still maintain there should be a compiler setting or language feature
>>> to prevent objects produced from JSON being destroyed on minification.
>> 
>> JSON Objects are not destroyed.  The code referencing their fields by
>>name
>> has those names changed.  Propose a way to determine that a data
>>structure
>> is external and what the compiler should generate and implement it.
>>IMO,
>> the answer is to create ValueObjects.  That is essentially typedefs and
>> AFAIK, there is no way to automate typedef generation.
>> 
>> Also, you can turn off minification for the app as a whole.
>> 
>> Other ideas welcome,
>> -Alex
>> 
>>> This remains a pain point for developing apps and having to create VOs
>>> for every API is a drag.
>>> 
 On Feb 5, 2018, at 10:21 AM, Alex Harui 
 wrote:
 
 
 
 On 2/4/18, 1:10 AM, "Gabe Harbs"  wrote:
 
> Typo. I meant js-reease.
 
 Yeah, at some later point in time someone should build Value Objects
for
 the JSON and get js-release working.  Maybe after this release.  I'm
 just
 trying to make the ASDoc useful.
 
 I'm going to add Events to the class detail page and anchor links from
 the
 lists to the details and maybe a simple search-for-class feature,
then I
 think it will be time for a release.
 
 -Alex
> 
>> On Feb 4, 2018, at 8:08 AM, Alex Harui 
>> wrote:
>> 
>>> 1. Why is bin-release not working?
>> 
>> Do you mean SWF support?
> 
 
>>> 
>> 
>

Re: ASDoc, Routing, Releases

[Gabe Harbs]

It looks like I needed to set some env vars.

I did so, and I’m getting some JSON files, but not the full thing.

I just updated my repos and did ant clean all. I’m now getting a failed build 
of Royale and I’m not sure why...

royale.royaletasks.jar:

jar:

main:

main:

download:
 [echo] /Apache/royale-asjs
[unjar] Expanding: 
/Apache/royale-asjs/js/lib/google/closure-compiler/compiler.jar into 
/Apache/royale-typedefs/js/target/temp/externs
[unzip] Expanding: 
/Apache/royale-typedefs/js/target/temp/externs/externs.zip into 
/Apache/royale-typedefs/js/target/downloads
  [get] Getting: 
https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/closureidl/svg.js
  [get] To: /Apache/royale-typedefs/js/target/downloads/svg.js

double-check-file:
 [echo] ${env.ROYALE_DOWNLOAD_CACHE}
 [echo] Need file: ${still_no_file}

get-from-cache-if-needed:

fail-if-not-found:

preprocess:

externc:
 [java] Error: Could not find or load main class 
org.apache.royale.compiler.clients.EXTERNC

BUILD FAILED
/Apache/royale-asjs/build.xml:1753: The following error occurred while 
executing this line:
/Apache/royale-asjs/build.xml:1825: The following error occurred while 
executing this line:
/Apache/royale-typedefs/build.xml:52: The following error occurred while 
executing this line:
/Apache/royale-typedefs/js/build.xml:159: Java returned: 1

Total time: 58 seconds
Harbss-MacBook-Pro:royale-asjs harbs$ 

> On Feb 5, 2018, at 6:32 PM, Gabe Harbs  wrote:
> 
> I’m using ant, but I’m not getting the json files.
> 
> Now that I know where to look, I’ll try and examine the script and see if I 
> can figure it out…
> 
>> On Feb 5, 2018, at 6:09 PM, Alex Harui > > wrote:
>> 
>> The Ant script for examples/royale/ASDoc builds the JSON files.  I have
>> not taken the time to figure out how to make Maven call the ASDoc
>> compiler.  Someone with more Maven knowledge might be faster at figuring
>> that out.
>> 
>> Thanks,
>> -Alex
>> 
>> On 2/5/18, 7:21 AM, "carlos.rov...@gmail.com 
>>  on behalf of Carlos Rovira"
>> mailto:carlos.rov...@gmail.com> on behalf of 
>> carlosrov...@apache.org > wrote:
>> 
>>> Hi I'm in the same boat.
>>> I can build the App with Maven.
>>> I ran it and saw the main layout but the list are not populated
>>> 
>>> 2018-02-05 11:10 GMT+01:00 Gabe Harbs >> >:
>>> 
 I don’t see any son files when I build the framework.
 
 Building the ASDoc project builds the ASDoc app, but again, I see no
 JSON
 files anywhere.
 
 What creates the JSON files?
 
> On Feb 4, 2018, at 8:08 AM, Alex Harui  >
 wrote:
> 
>> 
>> The big question: How do I build this with real JSON data locally,
 so I
>> can work on the ASDoc app?
> 
> What error are you getting?  It builds with Ant for me and the CI
 server
> is building it.  The build script will build the JSON.
 
 
>>> 
>>> 
>>> -- 
>>> Carlos Rovira
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 
>>> 
>>> Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com 
>>> %7C6bc182a710ed4ce440e408d5
>>> 6cac3212%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636534409184505784&s
>>> data=lNdSFaLQoU9IXHtzD0ryoGXjgupvjEh314hc9nTKyds%3D&reserved=0
> 

Re: ASDoc, Routing, Releases

[Gabe Harbs]

> JSON Objects are not destroyed.

Yeah. I know, but untyped js literals are pretty much useless in minified 
Royale apps.

> Propose a way to determine that a data structure
> is external and what the compiler should generate and implement it.  IMO,
> the answer is to create ValueObjects.  That is essentially typedefs and
> AFAIK, there is no way to automate typedef generation.

I already made a suggestion once:

For untyped Objects, the compiler could convert dot notation to bracket 
notation.

The other half of that would be to convert all object literals to “quoted” 
literals automatically.

So if I have a function:

function parseMyJson(json:String):Object{
return JSON.parse(json);
}

var myProps:Object = parseMyJson(json);

var name:string = myProps.name;

Would become:

function parseMyJson(json){
return JSON.parse(json);
}

var myProps = parseMyJson(json);

var name = myProps["name"];

And this:
var myObj:Object = {
name: "foo",
age : 30
}

Would become:
var myObj = {
"name": "foo",
"age" : 30
}

These two features would have solved almost all minification issues I’ve run 
into.

I’d love to work on this myself, but I’m still not up to making any major 
changes to the compiler… :-(

> On Feb 5, 2018, at 6:13 PM, Alex Harui  wrote:
> 
> 
> 
> On 2/5/18, 2:01 AM, "Gabe Harbs"  wrote:
> 
>> I’ll try to work on this. It’s pretty slow loading the debug build.
>> 
>> I still maintain there should be a compiler setting or language feature
>> to prevent objects produced from JSON being destroyed on minification.
> 
> JSON Objects are not destroyed.  The code referencing their fields by name
> has those names changed.  Propose a way to determine that a data structure
> is external and what the compiler should generate and implement it.  IMO,
> the answer is to create ValueObjects.  That is essentially typedefs and
> AFAIK, there is no way to automate typedef generation.
> 
> Also, you can turn off minification for the app as a whole.
> 
> Other ideas welcome,
> -Alex
> 
>> This remains a pain point for developing apps and having to create VOs
>> for every API is a drag.
>> 
>>> On Feb 5, 2018, at 10:21 AM, Alex Harui 
>>> wrote:
>>> 
>>> 
>>> 
>>> On 2/4/18, 1:10 AM, "Gabe Harbs"  wrote:
>>> 
 Typo. I meant js-reease.
>>> 
>>> Yeah, at some later point in time someone should build Value Objects for
>>> the JSON and get js-release working.  Maybe after this release.  I'm
>>> just
>>> trying to make the ASDoc useful.
>>> 
>>> I'm going to add Events to the class detail page and anchor links from
>>> the
>>> lists to the details and maybe a simple search-for-class feature, then I
>>> think it will be time for a release.
>>> 
>>> -Alex
 
> On Feb 4, 2018, at 8:08 AM, Alex Harui 
> wrote:
> 
>> 1. Why is bin-release not working?
> 
> Do you mean SWF support?
 
>>> 
>> 
> 

Re: ASDoc, Routing, Releases

[Gabe Harbs]

I’m using ant, but I’m not getting the json files.

Now that I know where to look, I’ll try and examine the script and see if I can 
figure it out…

> On Feb 5, 2018, at 6:09 PM, Alex Harui  wrote:
> 
> The Ant script for examples/royale/ASDoc builds the JSON files.  I have
> not taken the time to figure out how to make Maven call the ASDoc
> compiler.  Someone with more Maven knowledge might be faster at figuring
> that out.
> 
> Thanks,
> -Alex
> 
> On 2/5/18, 7:21 AM, "carlos.rov...@gmail.com  
> on behalf of Carlos Rovira"
> mailto:carlos.rov...@gmail.com> on behalf of 
> carlosrov...@apache.org > wrote:
> 
>> Hi I'm in the same boat.
>> I can build the App with Maven.
>> I ran it and saw the main layout but the list are not populated
>> 
>> 2018-02-05 11:10 GMT+01:00 Gabe Harbs :
>> 
>>> I don’t see any son files when I build the framework.
>>> 
>>> Building the ASDoc project builds the ASDoc app, but again, I see no
>>> JSON
>>> files anywhere.
>>> 
>>> What creates the JSON files?
>>> 
 On Feb 4, 2018, at 8:08 AM, Alex Harui 
>>> wrote:
 
> 
> The big question: How do I build this with real JSON data locally,
>>> so I
> can work on the ASDoc app?
 
 What error are you getting?  It builds with Ant for me and the CI
>>> server
 is building it.  The build script will build the JSON.
>>> 
>>> 
>> 
>> 
>> -- 
>> Carlos Rovira
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 
>> 
>> Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com 
>> %7C6bc182a710ed4ce440e408d5
>> 6cac3212%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636534409184505784&s
>> data=lNdSFaLQoU9IXHtzD0ryoGXjgupvjEh314hc9nTKyds%3D&reserved=0

Re: ASDoc, Routing, Releases

[Alex Harui]

Regarding Routing.  I don't know what "generic" means.  There is now a
bead that dispatches an event when the hash fragment changes.  Logic in
ASDoc processes that hash.  Maybe there is some standard encoding we can
pack in the hash that could map to view states or something, but it would
make the hash uglier, IMO.

Thoughts?
-Alex

On 2/5/18, 12:33 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>great work on this part. I'll try to build it localy and see if I can
>tweak
>a bit the look and feel to help with presentation as I get some free time.
>
>About routing, you made something generic for Royale? or is only made for
>this ASDoc Reference App?
>
>Thanks
>
>
>
>2018-02-05 9:21 GMT+01:00 Alex Harui :
>
>>
>>
>> On 2/4/18, 1:10 AM, "Gabe Harbs"  wrote:
>>
>> >Typo. I meant js-reease.
>>
>> Yeah, at some later point in time someone should build Value Objects for
>> the JSON and get js-release working.  Maybe after this release.  I'm
>>just
>> trying to make the ASDoc useful.
>>
>> I'm going to add Events to the class detail page and anchor links from
>>the
>> lists to the details and maybe a simple search-for-class feature, then I
>> think it will be time for a release.
>>
>> -Alex
>> >
>> >> On Feb 4, 2018, at 8:08 AM, Alex Harui 
>> wrote:
>> >>
>> >>> 1. Why is bin-release not working?
>> >>
>> >> Do you mean SWF support?
>> >
>>
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cf2ee1b2fc0da463b8e8d08d5
>6c7345fa%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636534164705226067&s
>data=7lSe%2BtUKFNWRKCXKm8naElOEAwM17IUNNvjxHgGuAWU%3D&reserved=0

Re: ASDoc, Routing, Releases

[Alex Harui]

On 2/5/18, 2:01 AM, "Gabe Harbs"  wrote:

>I’ll try to work on this. It’s pretty slow loading the debug build.
>
>I still maintain there should be a compiler setting or language feature
>to prevent objects produced from JSON being destroyed on minification.

JSON Objects are not destroyed.  The code referencing their fields by name
has those names changed.  Propose a way to determine that a data structure
is external and what the compiler should generate and implement it.  IMO,
the answer is to create ValueObjects.  That is essentially typedefs and
AFAIK, there is no way to automate typedef generation.

Also, you can turn off minification for the app as a whole.

Other ideas welcome,
-Alex

>This remains a pain point for developing apps and having to create VOs
>for every API is a drag.
>
>> On Feb 5, 2018, at 10:21 AM, Alex Harui 
>>wrote:
>> 
>> 
>> 
>> On 2/4/18, 1:10 AM, "Gabe Harbs"  wrote:
>> 
>>> Typo. I meant js-reease.
>> 
>> Yeah, at some later point in time someone should build Value Objects for
>> the JSON and get js-release working.  Maybe after this release.  I'm
>>just
>> trying to make the ASDoc useful.
>> 
>> I'm going to add Events to the class detail page and anchor links from
>>the
>> lists to the details and maybe a simple search-for-class feature, then I
>> think it will be time for a release.
>> 
>> -Alex
>>> 
 On Feb 4, 2018, at 8:08 AM, Alex Harui 
wrote:
 
> 1. Why is bin-release not working?
 
 Do you mean SWF support?
>>> 
>> 
>

Re: ASDoc, Routing, Releases

[Alex Harui]

The Ant script for examples/royale/ASDoc builds the JSON files.  I have
not taken the time to figure out how to make Maven call the ASDoc
compiler.  Someone with more Maven knowledge might be faster at figuring
that out.

Thanks,
-Alex

On 2/5/18, 7:21 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi I'm in the same boat.
>I can build the App with Maven.
>I ran it and saw the main layout but the list are not populated
>
>2018-02-05 11:10 GMT+01:00 Gabe Harbs :
>
>> I don’t see any son files when I build the framework.
>>
>> Building the ASDoc project builds the ASDoc app, but again, I see no
>>JSON
>> files anywhere.
>>
>> What creates the JSON files?
>>
>> > On Feb 4, 2018, at 8:08 AM, Alex Harui 
>>wrote:
>> >
>> >>
>> >> The big question: How do I build this with real JSON data locally,
>>so I
>> >> can work on the ASDoc app?
>> >
>> > What error are you getting?  It builds with Ant for me and the CI
>>server
>> > is building it.  The build script will build the JSON.
>>
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6bc182a710ed4ce440e408d5
>6cac3212%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636534409184505784&s
>data=lNdSFaLQoU9IXHtzD0ryoGXjgupvjEh314hc9nTKyds%3D&reserved=0

Re: ASDoc, Routing, Releases

[Carlos Rovira]

Hi I'm in the same boat.
I can build the App with Maven.
I ran it and saw the main layout but the list are not populated

2018-02-05 11:10 GMT+01:00 Gabe Harbs :

> I don’t see any son files when I build the framework.
>
> Building the ASDoc project builds the ASDoc app, but again, I see no JSON
> files anywhere.
>
> What creates the JSON files?
>
> > On Feb 4, 2018, at 8:08 AM, Alex Harui  wrote:
> >
> >>
> >> The big question: How do I build this with real JSON data locally, so I
> >> can work on the ASDoc app?
> >
> > What error are you getting?  It builds with Ant for me and the CI server
> > is building it.  The build script will build the JSON.
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: ASDoc, Routing, Releases

[Gabe Harbs]

I don’t see any son files when I build the framework.

Building the ASDoc project builds the ASDoc app, but again, I see no JSON files 
anywhere.

What creates the JSON files?

> On Feb 4, 2018, at 8:08 AM, Alex Harui  wrote:
> 
>> 
>> The big question: How do I build this with real JSON data locally, so I
>> can work on the ASDoc app?
> 
> What error are you getting?  It builds with Ant for me and the CI server
> is building it.  The build script will build the JSON.

Re: ASDoc, Routing, Releases

[Gabe Harbs]

I’ll try to work on this. It’s pretty slow loading the debug build.

I still maintain there should be a compiler setting or language feature to 
prevent objects produced from JSON being destroyed on minification.

This remains a pain point for developing apps and having to create VOs for 
every API is a drag.

> On Feb 5, 2018, at 10:21 AM, Alex Harui  wrote:
> 
> 
> 
> On 2/4/18, 1:10 AM, "Gabe Harbs"  wrote:
> 
>> Typo. I meant js-reease.
> 
> Yeah, at some later point in time someone should build Value Objects for
> the JSON and get js-release working.  Maybe after this release.  I'm just
> trying to make the ASDoc useful.
> 
> I'm going to add Events to the class detail page and anchor links from the
> lists to the details and maybe a simple search-for-class feature, then I
> think it will be time for a release.
> 
> -Alex
>> 
>>> On Feb 4, 2018, at 8:08 AM, Alex Harui  wrote:
>>> 
 1. Why is bin-release not working?
>>> 
>>> Do you mean SWF support?
>> 
> 

Re: ASDoc, Routing, Releases

[Alex Harui]

Hi Carlos,

Yes, your input on the UX is more than welcome.  Another approach you
could take is to download the last successful artifacts (bin/js-debug) and
tweak the ASDoc.css file and refresh the browser and let us know what
changes you made.

http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/Royale_ASDoc_Exam
ple/lastSuccessfulBuild/artifact/examples/royale/ASDoc/bin/

Thanks,
-Alex

On 2/5/18, 12:33 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>great work on this part. I'll try to build it localy and see if I can
>tweak
>a bit the look and feel to help with presentation as I get some free time.
>
>About routing, you made something generic for Royale? or is only made for
>this ASDoc Reference App?
>
>Thanks
>
>
>
>2018-02-05 9:21 GMT+01:00 Alex Harui :
>
>>
>>
>> On 2/4/18, 1:10 AM, "Gabe Harbs"  wrote:
>>
>> >Typo. I meant js-reease.
>>
>> Yeah, at some later point in time someone should build Value Objects for
>> the JSON and get js-release working.  Maybe after this release.  I'm
>>just
>> trying to make the ASDoc useful.
>>
>> I'm going to add Events to the class detail page and anchor links from
>>the
>> lists to the details and maybe a simple search-for-class feature, then I
>> think it will be time for a release.
>>
>> -Alex
>> >
>> >> On Feb 4, 2018, at 8:08 AM, Alex Harui 
>> wrote:
>> >>
>> >>> 1. Why is bin-release not working?
>> >>
>> >> Do you mean SWF support?
>> >
>>
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cf2ee1b2fc0da463b8e8d08d5
>6c7345fa%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636534164705226067&s
>data=7lSe%2BtUKFNWRKCXKm8naElOEAwM17IUNNvjxHgGuAWU%3D&reserved=0

Re: ASDoc, Routing, Releases

[Carlos Rovira]

Hi Alex,

great work on this part. I'll try to build it localy and see if I can tweak
a bit the look and feel to help with presentation as I get some free time.

About routing, you made something generic for Royale? or is only made for
this ASDoc Reference App?

Thanks



2018-02-05 9:21 GMT+01:00 Alex Harui :

>
>
> On 2/4/18, 1:10 AM, "Gabe Harbs"  wrote:
>
> >Typo. I meant js-reease.
>
> Yeah, at some later point in time someone should build Value Objects for
> the JSON and get js-release working.  Maybe after this release.  I'm just
> trying to make the ASDoc useful.
>
> I'm going to add Events to the class detail page and anchor links from the
> lists to the details and maybe a simple search-for-class feature, then I
> think it will be time for a release.
>
> -Alex
> >
> >> On Feb 4, 2018, at 8:08 AM, Alex Harui 
> wrote:
> >>
> >>> 1. Why is bin-release not working?
> >>
> >> Do you mean SWF support?
> >
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: ASDoc, Routing, Releases

[Alex Harui]

On 2/4/18, 1:10 AM, "Gabe Harbs"  wrote:

>Typo. I meant js-reease.

Yeah, at some later point in time someone should build Value Objects for
the JSON and get js-release working.  Maybe after this release.  I'm just
trying to make the ASDoc useful.

I'm going to add Events to the class detail page and anchor links from the
lists to the details and maybe a simple search-for-class feature, then I
think it will be time for a release.

-Alex
>
>> On Feb 4, 2018, at 8:08 AM, Alex Harui  wrote:
>> 
>>> 1. Why is bin-release not working?
>> 
>> Do you mean SWF support?
>

Re: ASDoc, Routing, Releases

[Gabe Harbs]

Typo. I meant js-reease.

> On Feb 4, 2018, at 8:08 AM, Alex Harui  wrote:
> 
>> 1. Why is bin-release not working?
> 
> Do you mean SWF support?

Re: ASDoc, Routing, Releases

[Alex Harui]

On 2/3/18, 12:32 PM, "Gabe Harbs"  wrote:

>Looking good. Very exciting that you’ve got routing working. That’s huge!

I am not an expert at all in routing, but it in my research, it appears
that hash-bang routing is considered deprecated, and only Google ever made
it work.  The "new" way seems to be something called "pushstate", but it
appears to require server-side support for "permalinks".  Hash-bang means
our permalinks and history have "#!" in them.  "Pushstate" allows for
virtual directories in URLs.  "Pushstate" seems to be designed for always
starting at foo.com and retaining history as you navigate around instead
of starting "anywhere" with a permalink.  Server-side support is required
to redirect the virtual directories to something real.  So we need to
decide whether we want to live with hash-bang or not.

And all of this still may not work well depending on whether the crawler
will run JS or not.  Most don't.  I've heard that Google will but may not
wait forever.  So more work may be needed to be indexed by the search
engines.
>
>Some points/questions:
>
>1. Why is bin-release not working?

Do you mean SWF support?  I haven't spent any time on SWF parity for
ASDoc.  If you mean bin/js-release, you need to read my tutorial ;-).
Plain objects from external sources like JSON usually fail in release.  I
will deal with it later, probably for the March release.

>2. Classes with internal classes produce invalid JSON (i.e.
>org.apache.royale.BrowserInfo)
>3. I don’t package level functions listed (i.e.
>org.apache.royale.utils.array.rangeCheck)

Feel free to work on that.

>4. Has anyone put any work into getting “details” populated? (The JSON
>appears to have the data.)

I think it used to work.  I'll probably get it working this weekend.

>5. I don’t see events listed.

If it isn't in the JSON, then it may have to wait for a later release.

>6. The inheritance breadcrumb trail has links which sort of work, but
>they don’t actually change the displayed contents.

I may get to that.
>
>The big question: How do I build this with real JSON data locally, so I
>can work on the ASDoc app?

What error are you getting?  It builds with Ant for me and the CI server
is building it.  The build script will build the JSON.

Thanks,
-Alex

Re: ASDoc, Routing, Releases

[Gabe Harbs]

Looking good. Very exciting that you’ve got routing working. That’s huge!

Some points/questions:

1. Why is bin-release not working?
2. Classes with internal classes produce invalid JSON (i.e. 
org.apache.royale.BrowserInfo)
3. I don’t package level functions listed (i.e. 
org.apache.royale.utils.array.rangeCheck)
4. Has anyone put any work into getting “details” populated? (The JSON appears 
to have the data.)
5. I don’t see events listed.
6. The inheritance breadcrumb trail has links which sort of work, but they 
don’t actually change the displayed contents.

The big question: How do I build this with real JSON data locally, so I can 
work on the ASDoc app?

Harbs

> On Feb 3, 2018, at 2:23 AM, Alex Harui  wrote:
> 
> Hi,
> 
> I just merged some changes to ASDoc in the develop branch.  It is still a
> work in progress, but I wanted to try out the routing feature on the
> nightly ASDoc build and didn't want to use a separate branch and CI build
> that could go away.
> 
> It occurred to me that if I use Anchor tags in the ASDoc's list renderers,
> that Google's search engine might be able to see it and chase it. I've
> implemented hash-based routing (actually, hash-bang) because it doesn't
> seem to require server-side support.  It seems to work for copy/pasting
> URLs and for history back/forward.  The HTML5 History API seems to require
> server-side support for copy/pasting URLs.  In theory the CI server is
> indexed, and in theory Google's crawler will run some JS but we'll see.
> 
> I also made some cosmetic changes to ASDoc and am working on the class
> details list which is still pretty ugly.  Feedback is welcome.  Once I get
> ASDoc looking a little better, it will be time to cut a release (0.9.1)
> whether Google's Crawler can crawl ASDoc or not.
> 
> Looks like the nightly build built.  The main ASDoc url is:
> 
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/Royale_ASDoc_Exam
> ple/lastSuccessfulBuild/artifact/examples/royale/ASDoc/bin/js-debug/index.h
> tml
> 
> But now you can jump straight to BarChart, for example, by hitting this
> link:
> 
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/Royale_ASDoc_Exam
> ple/lastSuccessfulBuild/artifact/examples/royale/ASDoc/bin/js-debug/index.h
> tml#!org.apache.royale.charts/BarChart
> 
> Later,
> -Alex
> 

ASDoc, Routing, Releases

[Alex Harui]

Hi,

I just merged some changes to ASDoc in the develop branch.  It is still a
work in progress, but I wanted to try out the routing feature on the
nightly ASDoc build and didn't want to use a separate branch and CI build
that could go away.

It occurred to me that if I use Anchor tags in the ASDoc's list renderers,
that Google's search engine might be able to see it and chase it. I've
implemented hash-based routing (actually, hash-bang) because it doesn't
seem to require server-side support.  It seems to work for copy/pasting
URLs and for history back/forward.  The HTML5 History API seems to require
server-side support for copy/pasting URLs.  In theory the CI server is
indexed, and in theory Google's crawler will run some JS but we'll see.

I also made some cosmetic changes to ASDoc and am working on the class
details list which is still pretty ugly.  Feedback is welcome.  Once I get
ASDoc looking a little better, it will be time to cut a release (0.9.1)
whether Google's Crawler can crawl ASDoc or not.

Looks like the nightly build built.  The main ASDoc url is:

http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/Royale_ASDoc_Exam
ple/lastSuccessfulBuild/artifact/examples/royale/ASDoc/bin/js-debug/index.h
tml

But now you can jump straight to BarChart, for example, by hitting this
link:

http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/Royale_ASDoc_Exam
ple/lastSuccessfulBuild/artifact/examples/royale/ASDoc/bin/js-debug/index.h
tml#!org.apache.royale.charts/BarChart

Later,
-Alex