Re: Website description

[Carlos Rovira]

Hi Om,

google now reflects right search values for "Apache Royale", so the fix is
now in place :)

2018-02-06 17:31 GMT+01:00 OmPrakash Muppirala :

> On Feb 5, 2018 11:39 PM, "Justin Mclean"  wrote:
>
> Hi,
>
> Or if you want to use slack for Royale then create a channel on the
> “official” ASF slack group.
>
> Thanks,
> Justin
>
> 1. https://the-asf.slack.com
>
>
> Justin,
>
> Please don't invent issues when there are none.  If you stop for a moment
> to understand what's going on in this thread, you will not make such
> statements.
>
> The issue here is that our website has junk text in the metadata tags.
> Slack, Twitter etc pull that text to display a preview of the website when
> you send the website link.
>
> It does not matter if it is private or public. The problem is with our
> website.  Which has been fixed, as per Carlos.
>
> Let's please move on.
>
> Thanks,
> Om
>



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

Re: Different results for compilation Error in JS and SWF compilation

[Alex Harui]

This should be fixed in the nightly builds.

This is the last thing I wanted to get done before cutting this release.
When I start my day tomorrow I will start the process.

I would also like to push royale-docs to master so it gets published with
this release.  I think it is good enough (or will be by the end of the
72-hour voting period).

Thoughts?
-Alex

On 2/5/18, 9:28 AM, "Alex Harui"  wrote:

>Hopefully, the compiler returns a different exit code if there are only
>warnings and Moonshine is checking exit codes.
>
>Thanks,
>-Alex
>
>On 2/5/18, 9:04 AM, "Piotr Zarzycki"  wrote:
>
>>It would be great, because I have found that Moonshine's build of any
>>Royale app is failing if it contains Warnings from the compiler. I could
>>change the implementation a bit there, but I believe fix in the compiler
>>is
>>more appropriate. It would be consistent then with SWF build.
>>
>>Thanks!
>>Piotr
>>
>>
>>2018-02-05 17:56 GMT+01:00 Alex Harui :
>>
>>> Yep.  I noticed that too.  I have no idea how to fix it.  Maybe I'll
>>>find
>>> time to dig into it before cutting the release.
>>>
>>> -Alex
>>>
>>> On 2/4/18, 12:38 AM, "Piotr Zarzycki" 
>>>wrote:
>>>
>>> >Alex,
>>> >
>>> >The same thing goes with Warnings, not only errors.
>>> >
>>> >Piotr
>>> >
>>> >2018-01-25 18:59 GMT+01:00 Piotr Zarzycki :
>>> >
>>> >> I have raised issue ->
>>> >>https://na01.safelinks.protection.outlook.com/?url=
>>> https%3A%2F%2Fgithub.c
>>> >>om%2Fapache%2Froyale-compiler%2Fissues%2F21=
>>> 02%7C01%7Caharui%40adobe
>>> 
>.com%7Cd46f24996cb841f1e5e208d56baaa2dc%7C71f1da39c0a84d5a8d88a67b23c3
>>> 0bf
>>> >>4%7C0%7C0%7C636533303003198853=srWYw5bL8DlUtwHdZFKEH8nGsbLcsJ
>>> rwX0Te
>>> >>PQhPCCE%3D=0
>>> >>
>>> >> 2018-01-25 18:38 GMT+01:00 Alex Harui :
>>> >>
>>> >>> Hmm.  Maybe MXMLJSC isn't able to pick up the ErrorFormat and just
>>>uses
>>> >>> %s.  I've never looked into how the language resources work.
>>> >>>
>>> >>> HTH,
>>> >>> -Alex
>>> >>>
>>> >>> On 1/25/18, 9:24 AM, "Piotr Zarzycki" 
>>> >>>wrote:
>>> >>>
>>> >>> >Alex,
>>> >>> >
>>> >>> >I looked into that and without debugging there is no option for me
>>> >>>figure
>>> >>> >out what has happened. Both classes are using the same formatter
>>>and
>>> >>> >printer to output errors. WorkspaceProblemFormatter and
>>>ProblemPrinter
>>> >>> >
>>> >>> >MXMLC is taking ErrorFormat=Error: %s from language resources.
>>>During
>>> >>>the
>>> >>> >compilation MXMLJSC is even using methods from MXMLC.
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> >2018-01-24 22:49 GMT+01:00 Piotr Zarzycki
>>>>> >:
>>> >>> >
>>> >>> >> Ok now I understand! I will look into that :)
>>> >>> >>
>>> >>> >> 2018-01-24 21:40 GMT+01:00 Alex Harui
>>>:
>>> >>> >>
>>> >>> >>> I'm saying that if you want JSRoyale to have the same output as
>>>the
>>> >>> SWF
>>> >>> >>> target, I would look at the compiler source in those files and
>>>see
>>> >>>if
>>> >>> >>>they
>>> >>> >>> are doing something different.  I could go fix it myself, but I
>>>am
>>> >>> >>>trying
>>> >>> >>> to encourage other committers to get more familiar with the
>>> >>>compiler
>>> >>> >>> source.
>>> >>> >>>
>>> >>> >>> HTH,
>>> >>> >>> -Alex
>>> >>> >>>
>>> >>> >>> On 1/24/18, 12:37 PM, "Piotr Zarzycki"
>>>
>>> >>> >>>wrote:
>>> >>> >>>
>>> >>> >>> >Not sure what do you mean ? That's how we use it I think so.
>>> >>> >>> >
>>> >>> >>> >2018-01-24 21:28 GMT+01:00 Alex Harui
>>>:
>>> >>> >>> >
>>> >>> >>> >> Interesting.  Hadn't noticed that.  I guess you could
>>>compare
>>> >>>the
>>> >>> >>> output
>>> >>> >>> >> logic in the compilers.  MXMLC.java should be used for SWF
>>> >>>compiles
>>> >>> >>>and
>>> >>> >>> >> MXMLJSC.java for JS compiles.
>>> >>> >>> >>
>>> >>> >>> >> -Alex
>>> >>> >>> >>
>>> >>> >>> >> On 1/24/18, 11:59 AM, "Piotr Zarzycki"
>>> >>>
>>> >>> >>> >>wrote:
>>> >>> >>> >>
>>> >>> >>> >> >Once Again:
>>> >>> >>> >> >
>>> >>> >>> >> >JSRoyale:
>>> >>> >>> >> >col: 12 This attribute is unexpected. It will be ignored.
>>> >>> >>> >> >:
>>> >>> >>> >> >: 
>>> >>> >>> >> >
>>> >>> >>> >> >SWF:
>>> >>> >>> >> >col: 12 Error: This attribute is unexpected. It will be
>>> >>>ignored.
>>> >>> >>> >> >:
>>> >>> >>> >> >: 
>>> >>> >>> >> >
>>> >>> >>> >> >
>>> >>> >>> >> >
>>> >>> >>> >> >2018-01-24 20:47 GMT+01:00 Alex Harui
>>> >>>:
>>> >>> >>> >> >
>>> >>> >>> >> >> Links are still broken.  Paste.a.o might be having
>>>problems.
>>> >>> Try
>>> >>> >>> >>just
>>> >>> >>> >> >>cut
>>> >>> >>> >> >> and paste of a section of the main differences.
>>> >>> >>> >> >>
>>> >>> >>> >> >> -Alex
>>> >>> >>> >> >>
>>> >>> >>> >> >> On 1/24/18, 10:19 AM, "Piotr Zarzycki"
>>> >>> 

Re: Royale substitutes for Flex features

[Alex Harui]

I wouldn't link to ASDoc, but if we have a reverse-search feature, explain
in the main docs how to use it.

I think your suggestions for royale-docs is fine.  The advantage of having
it all in ASDoc is the committer working on the component doesn't have to
go to another repo to document it, but discoverability is probably more
important.

-Alex

On 2/6/18, 10:26 AM, "Andrew Wetmore"  wrote:

>We have created a placeholder in the documentation for migrating an
>existing project from Flex to Royale. That is where I would look for such
>help. Would you suggest that we add links from there to the ASDoc? That
>seems a little awkward to me.
>
>For me, holding an existing Flex application, it would be lovely to be
>able
>to look in the help docs and see quickly:
>
>== This stuff maps to Royale stuff
>== You can do this in Royale by following these steps (popups, Canvas,
>title windows...)
>== Royale will have these things, but does not yet (menu bar...)
>== Royale will not have these things so you need to go about them in a
>different way or forget about them (virtual renderers).
>
>This would be an exercise in capturing the tribal knowledge of the Royale
>development team and making some of it available to the Alinas out there
>who are hovering on the edge of Royale.
>
>Opinions?
>
>
>
>On Tue, Feb 6, 2018 at 2:05 PM, Alex Harui 
>wrote:
>
>> I don't think we have a list.  Some components are just missing (no
>> Menu/MenuBar).  Some components are missing things (locked rows/columns,
>> virtual renderers).  I don't really know how to manage such a list.  The
>> Spark Button has over 100 public APIs.  Tracking all of that would be
>> daunting.
>>
>> Some stuff may never happen (weak references).
>>
>> Some other stuff like PopUpManager can often just be done differently.
>> Although if there is enough demand, we might create shims to ease
>> migration pain.  I know people would love it if Royale eventually had
>>1:1
>> parity with Flex, but that will take quite a while and I'm just not sure
>> it is worth it.  We have a different pattern under-the-hood in Royale in
>> order to best ensure performance in production.  IMO, it would be a
>> mistake to make the port compilation easy but have the results not
>>perform
>> well enough.  We've opted for requiring a bit more work in porting code
>>in
>> order to try to ensure adequate performance in production.
>>
>> So, from Alina's emails today, some documentation around popups is
>>needed.
>>  We've seen that question several times already  Maybe a FAQ?  We've
>>added
>> some ASDoc tags in the Royale classes (@flexdocurl and @flexcomponent
>>that
>> could be added to a few more components that indicate what they can
>> replace from Flex.  But there isn't a reverse search.  A volunteer could
>> add that to the ASDoc app though.
>>
>> My 2 cents,
>> -Alex
>>
>> On 2/6/18, 9:26 AM, "Andrew Wetmore"  wrote:
>>
>> >Do we have a list of Flex features not (yet) available in Royale, and
>> >known
>> >ways of getting to the desired result using Royale? Recent
>>conversations
>> >regarding Alina's product migration make me think that would be a
>>useful
>> >feature in the help documentation.
>> >
>> >a
>> >
>> >--
>> >Andrew Wetmore
>> >
>> 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage1
>>>4
>> .
>> >blogspot.com%2F=02%7C01%7Caharui%40adobe.com%
>> 7Cab1132be823a4a9550a908
>> >d56d86b83a%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
>> 7C636535347739075363
>> >=9GmPciqGZmuYdFrUz12LS%2FIkMACatH4VwrMoEzLllcA%3D=0
>>
>>
>
>
>-- 
>Andrew Wetmore
>
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.
>blogspot.com%2F=02%7C01%7Caharui%40adobe.com%7Cb606bc597d3e4cb895c408
>d56d8f2bbc%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535384047818534
>=ef0S%2Fk8WdldZPH0gl79huifGOCfOt3TNcvmaNTDbY3g%3D=0

Re: Royale substitutes for Flex features

[Andrew Wetmore]

We have created a placeholder in the documentation for migrating an
existing project from Flex to Royale. That is where I would look for such
help. Would you suggest that we add links from there to the ASDoc? That
seems a little awkward to me.

For me, holding an existing Flex application, it would be lovely to be able
to look in the help docs and see quickly:

== This stuff maps to Royale stuff
== You can do this in Royale by following these steps (popups, Canvas,
title windows...)
== Royale will have these things, but does not yet (menu bar...)
== Royale will not have these things so you need to go about them in a
different way or forget about them (virtual renderers).

This would be an exercise in capturing the tribal knowledge of the Royale
development team and making some of it available to the Alinas out there
who are hovering on the edge of Royale.

Opinions?



On Tue, Feb 6, 2018 at 2:05 PM, Alex Harui  wrote:

> I don't think we have a list.  Some components are just missing (no
> Menu/MenuBar).  Some components are missing things (locked rows/columns,
> virtual renderers).  I don't really know how to manage such a list.  The
> Spark Button has over 100 public APIs.  Tracking all of that would be
> daunting.
>
> Some stuff may never happen (weak references).
>
> Some other stuff like PopUpManager can often just be done differently.
> Although if there is enough demand, we might create shims to ease
> migration pain.  I know people would love it if Royale eventually had 1:1
> parity with Flex, but that will take quite a while and I'm just not sure
> it is worth it.  We have a different pattern under-the-hood in Royale in
> order to best ensure performance in production.  IMO, it would be a
> mistake to make the port compilation easy but have the results not perform
> well enough.  We've opted for requiring a bit more work in porting code in
> order to try to ensure adequate performance in production.
>
> So, from Alina's emails today, some documentation around popups is needed.
>  We've seen that question several times already  Maybe a FAQ?  We've added
> some ASDoc tags in the Royale classes (@flexdocurl and @flexcomponent that
> could be added to a few more components that indicate what they can
> replace from Flex.  But there isn't a reverse search.  A volunteer could
> add that to the ASDoc app though.
>
> My 2 cents,
> -Alex
>
> On 2/6/18, 9:26 AM, "Andrew Wetmore"  wrote:
>
> >Do we have a list of Flex features not (yet) available in Royale, and
> >known
> >ways of getting to the desired result using Royale? Recent conversations
> >regarding Alina's product migration make me think that would be a useful
> >feature in the help documentation.
> >
> >a
> >
> >--
> >Andrew Wetmore
> >
> >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14
> .
> >blogspot.com%2F=02%7C01%7Caharui%40adobe.com%
> 7Cab1132be823a4a9550a908
> >d56d86b83a%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C636535347739075363
> >=9GmPciqGZmuYdFrUz12LS%2FIkMACatH4VwrMoEzLllcA%3D=0
>
>


-- 
Andrew Wetmore

http://cottage14.blogspot.com/

Re: Royale substitutes for Flex features

[Alex Harui]

I don't think we have a list.  Some components are just missing (no
Menu/MenuBar).  Some components are missing things (locked rows/columns,
virtual renderers).  I don't really know how to manage such a list.  The
Spark Button has over 100 public APIs.  Tracking all of that would be
daunting.

Some stuff may never happen (weak references).

Some other stuff like PopUpManager can often just be done differently.
Although if there is enough demand, we might create shims to ease
migration pain.  I know people would love it if Royale eventually had 1:1
parity with Flex, but that will take quite a while and I'm just not sure
it is worth it.  We have a different pattern under-the-hood in Royale in
order to best ensure performance in production.  IMO, it would be a
mistake to make the port compilation easy but have the results not perform
well enough.  We've opted for requiring a bit more work in porting code in
order to try to ensure adequate performance in production.

So, from Alina's emails today, some documentation around popups is needed.
 We've seen that question several times already  Maybe a FAQ?  We've added
some ASDoc tags in the Royale classes (@flexdocurl and @flexcomponent that
could be added to a few more components that indicate what they can
replace from Flex.  But there isn't a reverse search.  A volunteer could
add that to the ASDoc app though.

My 2 cents,
-Alex

On 2/6/18, 9:26 AM, "Andrew Wetmore"  wrote:

>Do we have a list of Flex features not (yet) available in Royale, and
>known
>ways of getting to the desired result using Royale? Recent conversations
>regarding Alina's product migration make me think that would be a useful
>feature in the help documentation.
>
>a
>
>-- 
>Andrew Wetmore
>
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.
>blogspot.com%2F=02%7C01%7Caharui%40adobe.com%7Cab1132be823a4a9550a908
>d56d86b83a%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535347739075363
>=9GmPciqGZmuYdFrUz12LS%2FIkMACatH4VwrMoEzLllcA%3D=0

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=02%7C01%7Caharui%40adobe.com%7C924b22
>>9e4
>> 9b
>> 
>> 
>>b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63
>>653

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=02%7C01%7Caharui%40adobe.com
> %7C924b229e4
> > 9b
> >
> > b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C63653
> > 51
> >
> > 16172815360=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=02%7C01%7Caharui%40adobe.com
> %7C924b229e
> > 49
> >
> > bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C6365
> > 35
> >
> > 116172825365=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-
> >>
> >> 

Royale substitutes for Flex features

[Andrew Wetmore]

Do we have a list of Flex features not (yet) available in Royale, and known
ways of getting to the desired result using Royale? Recent conversations
regarding Alina's product migration make me think that would be a useful
feature in the help documentation.

a

-- 
Andrew Wetmore

http://cottage14.blogspot.com/

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=02%7C01%7Caharui%40adobe.com%7C924b229e4
> 9b
> 
> b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653
> 51
> 
> 16172815360=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D
> 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=02%7C01%7Caharui%40adobe.com%7C924b229e
> 49
> 
> bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365
> 35
> 
> 116172825365=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=02%7C01%7Caharui%40adobe.com%7C924b229e49bb44
>> 3d
>> 
>> dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535116
>> 17
>> 
>> 2825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
>> 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=02%7C01%7Caharui%40adobe.com%7C924b229e49bb4
>> 43
>> 
>> ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511
>> 61
>> 

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=02%7C01%7Caharui%40adobe.com%7C924b229e4
 9b
 
 b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653
 51
 
 16172815360=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D
 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=02%7C01%7Caharui%40adobe.com%7C924b229e49bb44
> 3d
> 
> dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535116
> 17
> 
> 2825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
> 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=02%7C01%7Caharui%40adobe.com%7C924b229e49bb4
> 43
> 
> ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511
> 61
> 
> 72825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
> es
> erved=0>
> 
> Shouldn’t the following code have trouble with minification?
> 
> {
> repos = configurator.json.repos;
> projectName = configurator.json.projectName;
> }
> 
> What’s 

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=02%7C01%7Caharui%40adobe.com%7C924b229e4
>>>9b
>>> 
>>>b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653
>>>51
>>> 
>>>16172815360=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D
>>>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=02%7C01%7Caharui%40adobe.com%7C924b229e
>>>49
>>> 
>>>bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365
>>>35
>>> 
>>>116172825365=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=02%7C01%7Caharui%40adobe.com%7C924b229e49bb44
3d
 
dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535116
17
 
2825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
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

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=02%7C01%7Caharui%40adobe.com%7C924b229e49b
>> b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351
>> 16172815360=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D
>> 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=02%7C01%7Caharui%40adobe.com%7C924b229e49
>> bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535
>> 116172825365=3m3kTW910JYWV8MaM4%2F%2B3v82l5EvxIqgRjqAtIC7N%2BU%3D
>> 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=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443d
>>> dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511617
>>> 2825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
>>> rved=0 
>>> >> yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flas
>>> tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication
>>> -tutorial%2Fdata.html=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443
>>> ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351161
>>> 72825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
>>> 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 

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=02%7C01%7Caharui%40adobe.com%7C924b229e49b
>b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351
>16172815360=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D
>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=02%7C01%7Caharui%40adobe.com%7C924b229e49
>bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535
>116172825365=3m3kTW910JYWV8MaM4%2F%2B3v82l5EvxIqgRjqAtIC7N%2BU%3D
>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=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443d
>>dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511617
>>2825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
>>rved=0 
>>>yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flas
>>tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication
>>-tutorial%2Fdata.html=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443
>>ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351161
>>72825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
>>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

Re: Website description

[OmPrakash Muppirala]

On Feb 5, 2018 11:39 PM, "Justin Mclean"  wrote:

Hi,

Or if you want to use slack for Royale then create a channel on the
“official” ASF slack group.

Thanks,
Justin

1. https://the-asf.slack.com


Justin,

Please don't invent issues when there are none.  If you stop for a moment
to understand what's going on in this thread, you will not make such
statements.

The issue here is that our website has junk text in the metadata tags.
Slack, Twitter etc pull that text to display a preview of the website when
you send the website link.

It does not matter if it is private or public. The problem is with our
website.  Which has been fixed, as per Carlos.

Let's please move on.

Thanks,
Om

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 

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

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 

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=02%7C01%7Caharui%40adobe.com%
> >> 7Cf2ee1b2fc0da463b8e8d08d5
> >> >6c7345fa%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> >> 7C636534164705226067
> >> >data=7lSe%2BtUKFNWRKCXKm8naElOEAwM17IUNNvjxHgGuAWU%3D=0
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7Ccf00eb48d20844c6c35508d5
> >6d3bd97b%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C636535026179637700
> >data=smCu4I6xnB4mrgiICwy9bHZnO%2BdvOijuFumzASoy1vI%3D=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 

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

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=02%7C01%7Caharui%40adobe.com%
> 7Cea3588c69d96467c165f08d
> 56cc01d3d%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C6365344947393196
> 87=wz0mlDPXSNb9R9uIL55hVuaRVCE1Qsxa5EN5XZoF1K4%3D=0>%
> 2Fg
> oogle-code-archive-downloads%2Fv2%2Fcode.google.com
>  http%3A%2F%2F2fcode
> .google.com%2F=02%7C01%7Caharui%40adobe.com%
> 7Cea3588c69d96467c165f
> 08d56cc01d3d%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C6365344947393
> 19687=kkKyUtW7yWmIlI2YaMM2084mFatUbp
> lmnr6PBa26PDU%3D=0>%
> 2Fc
>  losureidl%2Fsvg.js=02%7C01%7Caharui%40adobe.com
>  http%3A%2F%2F40adob
> e.com%2F=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=NwzNAbDc3gdOLz94AJG1T8sf1%2FYeEzPZIjxsLLCCN68%3D&
> reserved=0
> 
>  https%3A%2F%2Fstora
> ge
>  https%3A%2F%2Fstora
> ge>
>  .googleapis.com
>  http%3A%2F%2Fgoogle
> apis.com%2F=02%7C01%7Caharui%40adobe.com%
> 7Cea3588c69d96467c165f08d
> 56cc01d3d%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C6365344947393196
> 87=wz0mlDPXSNb9R9uIL55hVuaRVCE1Qsxa5EN5XZoF1K4%3D=0>%
> 2Fg
> oogle-code-archive-downloads%2Fv2%2Fcode.google.com
>  http%3A%2F%2F2fcode
> .google.com%2F=02%7C01%7Caharui%40adobe.com%
> 7Cea3588c69d96467c165f
> 

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=02%7C01%7Caharui%40adobe.com%
> 7Cf2ee1b2fc0da463b8e8d08d5
> >6c7345fa%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C636534164705226067
> >data=7lSe%2BtUKFNWRKCXKm8naElOEAwM17IUNNvjxHgGuAWU%3D=0
>
>


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