Crux Branch

2019-07-15 Thread Piotr Zarzycki
Hi Guys,

Actually I resonate with Alex on that. If we use Swiz it will be more
catchy to Flex developers who wanted to port something.

+1 for having it.

Why actually renaming everything. We have renamed whole framework - I think
it's enough. ;)

Thanks,
Piotr

On Tue, Jul 16, 2019, 6:14 AM Alex Harui  wrote:

> Hi Carlos,
>
> I don't think you understood my point.  Probably every good name has been
> used on GitHub or soon will be.  Even Royale was.  The question is whether
> anyone would want to see some other 3rd-party Jewel or Basic library
> implemented in Royale.  I suspect it is unlikely.
>
> "Crux" for Java appears to be some sort of web-app productivity framework.
> http://www.cruxframework.org/?locale=en_US#!view=home
> So there is a higher probability that if Royale becomes very popular that
> someone might want to see Crux for Java APIs ported to JS, similar to Java
> Commons vs AS3 Commons.
>
> Regarding the use of "Swiz" as the name, I haven't looked at the code Greg
> did, but if the APIs are the same and the general principles of dependency
> injection are the same, then I don't understand why we want to say that
> "Swiz" is for Flex and "XXX is for Royale".  As every day ticks off the
> calendar towards 2020, I think we want to do what we can to reduce the
> amount of time/effort to migrate a Flex app to Royale, and renaming
> something just adds to the effort instead of reducing it, IMO.
>
> My 2 cents,
> -Alex
>
> On 7/15/19, 1:58 AM, "Carlos Rovira"  wrote:
>
> Hi Alex,
>
> your concerns about Crux name applies to the others like Basic or Jewel
> (just to name a few). If I search for "Jewel js" in google I get
> various
> Jewel libraries (same for Basic js). What makes Jewel appropriate for
> us is
> that is an internal name (internal branding) we use to refer to that
> concrete part of the entire Royale framework, so in then end is not
> about
> "jewel" for folks here their brain knows that we are talking all the
> time
> about "Apache Royale Jewel". One more thing we add using this kind of
> names
> is: 1) Names that has some marketing, and we can create icons, or more
> (it
> will be hard for me create a icon for FlexJS or SwizRoyale), 2) short
> names
> with some meaning inside the ecosystem and relation with a set of words
> that shares some meaning root. And moreover, since we changed to Royale
> name we are doing all the things in the same line of action what makes
> the
> naming decisions in Royale follow a strategy. It would be not
> consistent to
> come back to older name strategy like FlexJS or SwizRoyale. We should
> follow what we started and continue in that line.
>
> I must say I never thought in MXRoyale and SparkRoyale naming, since
> it was
> a work in progress that started to grow in Royale progressively and I
> was
> focused in other parts. For that cases, we could bring other names or
> not.
> I must say that I didn't take much time to think about it
> conceptually. We
> could do or not depending on what you want to do in that part.
>
> For Jewel, we didn't thought about it so much. I remember I started
> with
> other codename, but very soon I renamed and shared to Jewel explaining
> the
> motivations, thoughts, and meaning of that name. But, we didn't some
> king
> of name process for it
>
> In the case of Crux. I think it could not be "Crux",I like for the
> shortness and meaning, but could be other better options. What I don't
> like
> is bring as "Swiz" or "SwizRoyale". The first because is not Swiz (as I
> explained Swiz is for Flex) and SwizRoyale is for me very long and
> does not
> have a meaning inside of what we are doing with the rest of Royale
> naming
> decision and marketing (making it very difficult to brand along with
> the
> rest of Royale parts for marketing and web).
>
> just my 2
>
> Carlos
>
>
>
> El lun., 15 jul. 2019 a las 6:30, Alex Harui ( >)
> escribió:
>
> > Regarding naming, giving something a longer more descriptive name
> can also
> > make it harder to use and then folks start using the short name and
> then
> > there can be confusion again.
> >
> > AIUI, trademark issues are about confusion.  Names like "Basic" and
> > "Jewel" don't appear to have uses that could be confusing.  "Crux"
> appears
> > to be some sort of language thing for Java being brought over to JS,
> so my
> > concern is that someone may someday want Royale to support a Crux
> library
> > that is based on the Java thing.
> >
> > We are using MXRoyale and SparkRoyale as names for the emulations of
> > Flex's MX and Spark components.  "SwizRoyale" would be consistent,
> > especially if the goal is to emulate Swiz and potentially get more
> of the
> > Swiz code officially contributed to Apache Royale.  Having renamed
> lots of
> > FlexJS to Royale, I can tell you 

Re: Crux Branch

2019-07-15 Thread Alex Harui
Hi Carlos,

I don't think you understood my point.  Probably every good name has been used 
on GitHub or soon will be.  Even Royale was.  The question is whether anyone 
would want to see some other 3rd-party Jewel or Basic library implemented in 
Royale.  I suspect it is unlikely.

"Crux" for Java appears to be some sort of web-app productivity framework. 
http://www.cruxframework.org/?locale=en_US#!view=home
So there is a higher probability that if Royale becomes very popular that 
someone might want to see Crux for Java APIs ported to JS, similar to Java 
Commons vs AS3 Commons.

Regarding the use of "Swiz" as the name, I haven't looked at the code Greg did, 
but if the APIs are the same and the general principles of dependency injection 
are the same, then I don't understand why we want to say that "Swiz" is for 
Flex and "XXX is for Royale".  As every day ticks off the calendar towards 
2020, I think we want to do what we can to reduce the amount of time/effort to 
migrate a Flex app to Royale, and renaming something just adds to the effort 
instead of reducing it, IMO.

My 2 cents,
-Alex

On 7/15/19, 1:58 AM, "Carlos Rovira"  wrote:

Hi Alex,

your concerns about Crux name applies to the others like Basic or Jewel
(just to name a few). If I search for "Jewel js" in google I get various
Jewel libraries (same for Basic js). What makes Jewel appropriate for us is
that is an internal name (internal branding) we use to refer to that
concrete part of the entire Royale framework, so in then end is not about
"jewel" for folks here their brain knows that we are talking all the time
about "Apache Royale Jewel". One more thing we add using this kind of names
is: 1) Names that has some marketing, and we can create icons, or more (it
will be hard for me create a icon for FlexJS or SwizRoyale), 2) short names
with some meaning inside the ecosystem and relation with a set of words
that shares some meaning root. And moreover, since we changed to Royale
name we are doing all the things in the same line of action what makes the
naming decisions in Royale follow a strategy. It would be not consistent to
come back to older name strategy like FlexJS or SwizRoyale. We should
follow what we started and continue in that line.

I must say I never thought in MXRoyale and SparkRoyale naming, since it was
a work in progress that started to grow in Royale progressively and I was
focused in other parts. For that cases, we could bring other names or not.
I must say that I didn't take much time to think about it conceptually. We
could do or not depending on what you want to do in that part.

For Jewel, we didn't thought about it so much. I remember I started with
other codename, but very soon I renamed and shared to Jewel explaining the
motivations, thoughts, and meaning of that name. But, we didn't some king
of name process for it

In the case of Crux. I think it could not be "Crux",I like for the
shortness and meaning, but could be other better options. What I don't like
is bring as "Swiz" or "SwizRoyale". The first because is not Swiz (as I
explained Swiz is for Flex) and SwizRoyale is for me very long and does not
have a meaning inside of what we are doing with the rest of Royale naming
decision and marketing (making it very difficult to brand along with the
rest of Royale parts for marketing and web).

just my 2

Carlos



El lun., 15 jul. 2019 a las 6:30, Alex Harui ()
escribió:

> Regarding naming, giving something a longer more descriptive name can also
> make it harder to use and then folks start using the short name and then
> there can be confusion again.
>
> AIUI, trademark issues are about confusion.  Names like "Basic" and
> "Jewel" don't appear to have uses that could be confusing.  "Crux" appears
> to be some sort of language thing for Java being brought over to JS, so my
> concern is that someone may someday want Royale to support a Crux library
> that is based on the Java thing.
>
> We are using MXRoyale and SparkRoyale as names for the emulations of
> Flex's MX and Spark components.  "SwizRoyale" would be consistent,
> especially if the goal is to emulate Swiz and potentially get more of the
> Swiz code officially contributed to Apache Royale.  Having renamed lots of
> FlexJS to Royale, I can tell you that renaming still takes time.
>
> My 2 cents,
> -Alex
>
> On 7/12/19, 3:41 AM, "Carlos Rovira"  wrote:
>
> Hi Greg!
>
> great progress with the latest touches.
>
> My latest days was in Crux branch so for me is ok to do the merge I
> think
> we cover all the things needed like licensing and avoid name 
conflicts.
> Even we always can improve any of those things over time. So it's ok.
>
>

Re: library-path and external-library-path fixes

2019-07-15 Thread Josh Tynjala
The Maven royale-compiler build is fixed now. :)

--
Josh Tynjala
Bowler Hat LLC 


On Mon, Jul 15, 2019 at 1:19 PM Josh Tynjala 
wrote:

> FYI: Found an issue building royale-compiler with Maven. Working on the
> fix.
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Mon, Jul 15, 2019 at 12:32 PM Josh Tynjala 
> wrote:
>
>> Hey folks,
>>
>> I just pushed some commits to royale-compiler and royale-asjs, and I
>> wanted to add a little explanation, and some possible troubleshooting
>> advice if anything seems to have broken in your apps.
>>
>> My work over the last week has been to fix an issue related to specifying
>> dependencies when compiling libraries for JS. As you probably know, the
>> compiler supports two options for adding libraries as dependencies,
>> library-path and external-library-path. The library-path compiler option
>> basically says "include all classes that I use from this SWC in the final
>> output". It's typically what you use when compiling an app that uses a
>> library. The external-library-path compiler option basically says "if I use
>> anything from this SWC, check that I'm using the types correctly, but don't
>> include any of classes from this SWC in the final output".
>>
>> If you're compiling an app, you typically use library-path for
>> everything. You use external-library-path only for dependencies like
>> playerglobal.swc/airglobal.swc in Flash or typedef SWCs in JS. Basically,
>> for an app project, external-library-path is for classes that are provided
>> natively by the Flash runtime or a web browser, like Chrome or Firefox.
>>
>> When compiling libraries, external-library-path is also used to prevent
>> the compiler from creating a "fat" library that stuffs in all of the
>> dependencies. Let's say that you have a library, A.swc. It provides some
>> core functionality that is needed by both B.swc and C.swc. When we compile
>> B.swc and C.swc, we don't want the classes from A.swc duplicated in both of
>> them. So we add A.swc to the external-library-path when compiling B.swc or
>> C.swc. Then, if you use those SWCs when compiling an app, you need to add
>> A.swc, B.swc, and C.swc to the library-path.
>>
>> To put that in Royale terms, A.swc is something like LanguageJS.swc or
>> CoreJS.swc. They're some of our lowest-level SWCs in the framework. B.swc
>> and C.swc are more like BasicJS.swc or JewelJS.swc, and they tend to share
>> multiple classes from the lower-level stuff.
>>
>> Up until now, library-path and external-library-path were a little quirky
>> when compiling to JS. It was related to the goog.provide() and
>> goog.require() calls that you might have seen in the generated JS. These
>> are from the module system that we use in Royale. The compiler didn't know
>> how to differentiate between classes that had goog.provide() and classes
>> that were typedefs for JS libraries. It treated everything on the
>> external-library-path as a typedef, and this led to missing goog.require()
>> calls in the generated JS. To work around this, when we specified
>> dependencies in our framework SWCs, we used library-path to ensure that
>> goog.require() would be used.
>>
>> This workaround of using library-path led to "fat" SWCs that contained
>> all of their dependencies. Low-level classes in SWCs like CoreJS were
>> duplicated in higher-level SWCs. This led to the compiler getting confused
>> about exactly where a class was defined.
>>
>> This has resulted in some minor issues here and there, but nothing too
>> major until recently. However, Harbs noticed the other day that it caused
>> the compiler to copy extra default CSS into apps from SWCs that you may not
>> have been using. So, you might build an app with the Basic components, but
>> you'd get extra CSS from Jewel or MaterialDesignLite. This could mess up
>> your app's styling pretty dramatically.
>>
>> I updated the compiler to better detect when a class needs goog.require()
>> and when it's a typedef. If that class comes from a SWC, the compiler knows
>> to check for an included file like, js/out/com/example/MyClass.js. If the
>> generated JS is there, goog.require() is necessary. If it's missing, it's
>> treated as a typedef class instead. If the class is an .as source file
>> instead, the compiler looks for the @externs asdoc tag to determine if it's
>> a typedef class (and everything else needs goog.require() instead).
>>
>> By the way, if we ever support other module systems, it shouldn't be too
>> difficult to extend this code to detect different SWC layouts for each
>> module system.
>>
>> If your project is an app, this change should not cause any problems.
>> You're probably using library-path and external-library-path correctly.
>>
>> If you have a project that is a library, you should check your compiler
>> options to see if you are using library-path and external-library-path
>> correctly. If your library depends on another library, you probably should
>> be 

Re: AMF and class aliases

2019-07-15 Thread Greg Dove
Also, before I forget:

If your legacy flex app includes [Transient] metadata anywhere, don't
forget to include that in the keep-as3-metadata as part of the
configuration for your royale app version as well.
AMFBinaryData will ignore those members with Transient metadata in the amf
serialization, as it does for ByteArray in swf.



On Tue, Jul 16, 2019 at 8:25 AM Greg Dove  wrote:

> Hi Andrew, to answer specifically about:
> > - the AMF serialization for classes is taking their public properties. We
> > had removed the public properties and changed them into private
> properties
> > plus public get functions, in order to avoid the warning from the Google
> > Closure Compiler, but the serializer is only looking at traditional
> > properties rather than at accessors. Not sure whether this is something
> > that we should consider changing in the future within the framework..?
>
> It sounds to me like the issue here is that you are only creating public
> getters. This won't work (in swf or javascript) because AMF serialization
> requires matching public getter/setter pairs for the member to be included
> in the serialized amf representation of the class instance.
>
> You have a few options here:
> 1. If you are confident of the use of the (presumably VO ?) classes
> everywhere, you can suppress those warnings [1] (feel free to improve that
> documentation if you want, as it is preliminary)
> 2. If you want bindable classes, the easiest thing is to mark the class
> with [Bindable] metadata (note that this is 'easy' but because of the
> bindable support will create more code, and run slightly slower than (3)
> below.
> 3. You can manually create getter/setter support for each of the public
> vars.
>
> As another thing, if you ever want to test amf serialization, you can do
> that in the same way you do things with ByteArray in swf.
> var ba:AMFBinaryData = new AMFBinaryData();
> var instance:Object = {}; // try other things here, myVO etc )
> trace(instance); // inspect in browser console
> ba.writeObject(instance);
> ba.position = 0;
> instance = ba.readObject();
> trace(instance); // inspect in browser console
>  The above should perform the same type of deep-clone that you get when
> you do it in swf (so long as all the class aliases are defined for the
> instance's object tree when it is not a plain 'Object' like above)
>
> 1.
> https://apache.github.io/royale-docs/create-an-application/optimizations/doc-comment-directives.html#royalesuppresspublicvarwarning
>
> On Tue, Jul 16, 2019 at 2:45 AM Carlos Rovira 
> wrote:
>
>> Hi Andrew,
>>
>> El lun., 15 jul. 2019 a las 16:18, Frost, Andrew (<
>> andrew.fr...@harman.com>)
>> escribió:
>>
>> > Hi
>> >
>> > A custom bead for localization is a very good idea, yes. In this
>> instance,
>> > we're looking at a migration from Flex so trying to keep as much of the
>> > original code the same as possible; with a custom (albeit generic) bead
>> > we've managed to do this. Not sure whether their code was the most
>> > efficient form when looked at from a Flex perspective either..
>> >
>>
>> in jewel we are using Localization in Validator.as (through core
>> ILocalizedValuesImpl)
>> but the plan is remove that in the future since Alex pointed that we
>> should
>> not use localization in that way. In the future, validation should
>> separate
>> logic from view so the validation logic should check the VO, DTOs,
>> Pojos...
>> objects while the visuals could be changed from tooltips to static labels
>> or whatever the user wants to inject. And the same way for localizations
>>
>>
>> > In terms of the AMF stuff, we've found a few more gotchas:
>> > - not 100% sure if these are necessary, but we had been just setting the
>> > endpoint manually so that the connection could be made, but we also
>> need to
>> > have the 'destination' value set on the RemoteObject, and possibly the
>> ID
>> > as well. In Flex, it was only the 'destination' being set up, and the
>> > framework then went and got the ID and the endpoint from the
>> configuration
>> > file... we might look into adding support for that services
>> configuration
>> > file (in some form) to make this process a little simpler.
>> >
>>
>> in AMF/RO we have already are using "destination" (in fact we are setting
>> destination along with the ChannelSet), so if you're having problems maybe
>> it could be that you're using other RO implementation. I recommend you to
>> use MXRoyale RemoteObject implementation since is the closest to Flex and
>> supports almost all things (except for Vector and Dictionary) .
>>
>>
>> > - the AMF serialization for classes is taking their public properties.
>> We
>> > had removed the public properties and changed them into private
>> properties
>> > plus public get functions, in order to avoid the warning from the Google
>> > Closure Compiler, but the serializer is only looking at traditional
>> > properties rather than at accessors. Not sure whether this is something
>> > that we should 

Re: AMF and class aliases

2019-07-15 Thread Greg Dove
Hi Andrew, to answer specifically about:
> - the AMF serialization for classes is taking their public properties. We
> had removed the public properties and changed them into private properties
> plus public get functions, in order to avoid the warning from the Google
> Closure Compiler, but the serializer is only looking at traditional
> properties rather than at accessors. Not sure whether this is something
> that we should consider changing in the future within the framework..?

It sounds to me like the issue here is that you are only creating public
getters. This won't work (in swf or javascript) because AMF serialization
requires matching public getter/setter pairs for the member to be included
in the serialized amf representation of the class instance.

You have a few options here:
1. If you are confident of the use of the (presumably VO ?) classes
everywhere, you can suppress those warnings [1] (feel free to improve that
documentation if you want, as it is preliminary)
2. If you want bindable classes, the easiest thing is to mark the class
with [Bindable] metadata (note that this is 'easy' but because of the
bindable support will create more code, and run slightly slower than (3)
below.
3. You can manually create getter/setter support for each of the public
vars.

As another thing, if you ever want to test amf serialization, you can do
that in the same way you do things with ByteArray in swf.
var ba:AMFBinaryData = new AMFBinaryData();
var instance:Object = {}; // try other things here, myVO etc )
trace(instance); // inspect in browser console
ba.writeObject(instance);
ba.position = 0;
instance = ba.readObject();
trace(instance); // inspect in browser console
 The above should perform the same type of deep-clone that you get when you
do it in swf (so long as all the class aliases are defined for the
instance's object tree when it is not a plain 'Object' like above)

1.
https://apache.github.io/royale-docs/create-an-application/optimizations/doc-comment-directives.html#royalesuppresspublicvarwarning

On Tue, Jul 16, 2019 at 2:45 AM Carlos Rovira 
wrote:

> Hi Andrew,
>
> El lun., 15 jul. 2019 a las 16:18, Frost, Andrew ( >)
> escribió:
>
> > Hi
> >
> > A custom bead for localization is a very good idea, yes. In this
> instance,
> > we're looking at a migration from Flex so trying to keep as much of the
> > original code the same as possible; with a custom (albeit generic) bead
> > we've managed to do this. Not sure whether their code was the most
> > efficient form when looked at from a Flex perspective either..
> >
>
> in jewel we are using Localization in Validator.as (through core
> ILocalizedValuesImpl)
> but the plan is remove that in the future since Alex pointed that we should
> not use localization in that way. In the future, validation should separate
> logic from view so the validation logic should check the VO, DTOs, Pojos...
> objects while the visuals could be changed from tooltips to static labels
> or whatever the user wants to inject. And the same way for localizations
>
>
> > In terms of the AMF stuff, we've found a few more gotchas:
> > - not 100% sure if these are necessary, but we had been just setting the
> > endpoint manually so that the connection could be made, but we also need
> to
> > have the 'destination' value set on the RemoteObject, and possibly the ID
> > as well. In Flex, it was only the 'destination' being set up, and the
> > framework then went and got the ID and the endpoint from the
> configuration
> > file... we might look into adding support for that services configuration
> > file (in some form) to make this process a little simpler.
> >
>
> in AMF/RO we have already are using "destination" (in fact we are setting
> destination along with the ChannelSet), so if you're having problems maybe
> it could be that you're using other RO implementation. I recommend you to
> use MXRoyale RemoteObject implementation since is the closest to Flex and
> supports almost all things (except for Vector and Dictionary) .
>
>
> > - the AMF serialization for classes is taking their public properties. We
> > had removed the public properties and changed them into private
> properties
> > plus public get functions, in order to avoid the warning from the Google
> > Closure Compiler, but the serializer is only looking at traditional
> > properties rather than at accessors. Not sure whether this is something
> > that we should consider changing in the future within the framework..?
> >
>
> Maybe this would better be responded by others
>
>
> >
> > Will see whether this all works now..!
> >
> > thanks
> >
> > Andrew
> >
> >
> > -Original Message-
> > From: Alex Harui 
> > Sent: 15 July 2019 05:39
> > To: dev@royale.apache.org
> > Subject: [EXTERNAL] Re: AMF and class aliases
> >
> > IMO, localization may perform better with a custom bead or two.  Generic
> > binding must watch something for changes that might require that
> > getString() be called again, but in general, 

Re: library-path and external-library-path fixes

2019-07-15 Thread Josh Tynjala
FYI: Found an issue building royale-compiler with Maven. Working on the fix.

--
Josh Tynjala
Bowler Hat LLC 


On Mon, Jul 15, 2019 at 12:32 PM Josh Tynjala 
wrote:

> Hey folks,
>
> I just pushed some commits to royale-compiler and royale-asjs, and I
> wanted to add a little explanation, and some possible troubleshooting
> advice if anything seems to have broken in your apps.
>
> My work over the last week has been to fix an issue related to specifying
> dependencies when compiling libraries for JS. As you probably know, the
> compiler supports two options for adding libraries as dependencies,
> library-path and external-library-path. The library-path compiler option
> basically says "include all classes that I use from this SWC in the final
> output". It's typically what you use when compiling an app that uses a
> library. The external-library-path compiler option basically says "if I use
> anything from this SWC, check that I'm using the types correctly, but don't
> include any of classes from this SWC in the final output".
>
> If you're compiling an app, you typically use library-path for everything.
> You use external-library-path only for dependencies like
> playerglobal.swc/airglobal.swc in Flash or typedef SWCs in JS. Basically,
> for an app project, external-library-path is for classes that are provided
> natively by the Flash runtime or a web browser, like Chrome or Firefox.
>
> When compiling libraries, external-library-path is also used to prevent
> the compiler from creating a "fat" library that stuffs in all of the
> dependencies. Let's say that you have a library, A.swc. It provides some
> core functionality that is needed by both B.swc and C.swc. When we compile
> B.swc and C.swc, we don't want the classes from A.swc duplicated in both of
> them. So we add A.swc to the external-library-path when compiling B.swc or
> C.swc. Then, if you use those SWCs when compiling an app, you need to add
> A.swc, B.swc, and C.swc to the library-path.
>
> To put that in Royale terms, A.swc is something like LanguageJS.swc or
> CoreJS.swc. They're some of our lowest-level SWCs in the framework. B.swc
> and C.swc are more like BasicJS.swc or JewelJS.swc, and they tend to share
> multiple classes from the lower-level stuff.
>
> Up until now, library-path and external-library-path were a little quirky
> when compiling to JS. It was related to the goog.provide() and
> goog.require() calls that you might have seen in the generated JS. These
> are from the module system that we use in Royale. The compiler didn't know
> how to differentiate between classes that had goog.provide() and classes
> that were typedefs for JS libraries. It treated everything on the
> external-library-path as a typedef, and this led to missing goog.require()
> calls in the generated JS. To work around this, when we specified
> dependencies in our framework SWCs, we used library-path to ensure that
> goog.require() would be used.
>
> This workaround of using library-path led to "fat" SWCs that contained all
> of their dependencies. Low-level classes in SWCs like CoreJS were
> duplicated in higher-level SWCs. This led to the compiler getting confused
> about exactly where a class was defined.
>
> This has resulted in some minor issues here and there, but nothing too
> major until recently. However, Harbs noticed the other day that it caused
> the compiler to copy extra default CSS into apps from SWCs that you may not
> have been using. So, you might build an app with the Basic components, but
> you'd get extra CSS from Jewel or MaterialDesignLite. This could mess up
> your app's styling pretty dramatically.
>
> I updated the compiler to better detect when a class needs goog.require()
> and when it's a typedef. If that class comes from a SWC, the compiler knows
> to check for an included file like, js/out/com/example/MyClass.js. If the
> generated JS is there, goog.require() is necessary. If it's missing, it's
> treated as a typedef class instead. If the class is an .as source file
> instead, the compiler looks for the @externs asdoc tag to determine if it's
> a typedef class (and everything else needs goog.require() instead).
>
> By the way, if we ever support other module systems, it shouldn't be too
> difficult to extend this code to detect different SWC layouts for each
> module system.
>
> If your project is an app, this change should not cause any problems.
> You're probably using library-path and external-library-path correctly.
>
> If you have a project that is a library, you should check your compiler
> options to see if you are using library-path and external-library-path
> correctly. If your library depends on another library, you probably should
> be using external-library-path because you don't want a "fat" SWC. In other
> words, if you're using library-path in a library project, you probably need
> to change that to external-library-path.
>
> If you have any custom typedef SWCs, you may want to recompile 

Re: library-path and external-library-path fixes

2019-07-15 Thread Greg Dove
Hi Josh, that sounds fantastic! Thanks for your work on that!
This is also more how I would intuitively expect things to work. I had
'wondered' why we were using 'library-path' instead of
'extenal-library-path' everywhere at different times, but I just followed
the existing pattern

I guess this might mean that for some apps, if B.swc was currently being
used in the app's library-path, then its (now) 'external' A.swc dependency
would now need to be added to app's library-path if its only use was in
('fat swc') B.swc in the past (to follow your explanation examples). But
iiuc, I expect this is aligned with how things worked in the past with flex.

I will update the crux branch with these changes today - thanks again!


On Tue, Jul 16, 2019 at 7:32 AM Josh Tynjala 
wrote:

> Hey folks,
>
> I just pushed some commits to royale-compiler and royale-asjs, and I wanted
> to add a little explanation, and some possible troubleshooting advice if
> anything seems to have broken in your apps.
>
> My work over the last week has been to fix an issue related to specifying
> dependencies when compiling libraries for JS. As you probably know, the
> compiler supports two options for adding libraries as dependencies,
> library-path and external-library-path. The library-path compiler option
> basically says "include all classes that I use from this SWC in the final
> output". It's typically what you use when compiling an app that uses a
> library. The external-library-path compiler option basically says "if I use
> anything from this SWC, check that I'm using the types correctly, but don't
> include any of classes from this SWC in the final output".
>
> If you're compiling an app, you typically use library-path for everything.
> You use external-library-path only for dependencies like
> playerglobal.swc/airglobal.swc in Flash or typedef SWCs in JS. Basically,
> for an app project, external-library-path is for classes that are provided
> natively by the Flash runtime or a web browser, like Chrome or Firefox.
>
> When compiling libraries, external-library-path is also used to prevent the
> compiler from creating a "fat" library that stuffs in all of the
> dependencies. Let's say that you have a library, A.swc. It provides some
> core functionality that is needed by both B.swc and C.swc. When we compile
> B.swc and C.swc, we don't want the classes from A.swc duplicated in both of
> them. So we add A.swc to the external-library-path when compiling B.swc or
> C.swc. Then, if you use those SWCs when compiling an app, you need to add
> A.swc, B.swc, and C.swc to the library-path.
>
> To put that in Royale terms, A.swc is something like LanguageJS.swc or
> CoreJS.swc. They're some of our lowest-level SWCs in the framework. B.swc
> and C.swc are more like BasicJS.swc or JewelJS.swc, and they tend to share
> multiple classes from the lower-level stuff.
>
> Up until now, library-path and external-library-path were a little quirky
> when compiling to JS. It was related to the goog.provide() and
> goog.require() calls that you might have seen in the generated JS. These
> are from the module system that we use in Royale. The compiler didn't know
> how to differentiate between classes that had goog.provide() and classes
> that were typedefs for JS libraries. It treated everything on the
> external-library-path as a typedef, and this led to missing goog.require()
> calls in the generated JS. To work around this, when we specified
> dependencies in our framework SWCs, we used library-path to ensure that
> goog.require() would be used.
>
> This workaround of using library-path led to "fat" SWCs that contained all
> of their dependencies. Low-level classes in SWCs like CoreJS were
> duplicated in higher-level SWCs. This led to the compiler getting confused
> about exactly where a class was defined.
>
> This has resulted in some minor issues here and there, but nothing too
> major until recently. However, Harbs noticed the other day that it caused
> the compiler to copy extra default CSS into apps from SWCs that you may not
> have been using. So, you might build an app with the Basic components, but
> you'd get extra CSS from Jewel or MaterialDesignLite. This could mess up
> your app's styling pretty dramatically.
>
> I updated the compiler to better detect when a class needs goog.require()
> and when it's a typedef. If that class comes from a SWC, the compiler knows
> to check for an included file like, js/out/com/example/MyClass.js. If the
> generated JS is there, goog.require() is necessary. If it's missing, it's
> treated as a typedef class instead. If the class is an .as source file
> instead, the compiler looks for the @externs asdoc tag to determine if it's
> a typedef class (and everything else needs goog.require() instead).
>
> By the way, if we ever support other module systems, it shouldn't be too
> difficult to extend this code to detect different SWC layouts for each
> module system.
>
> If your project is an app, this change 

library-path and external-library-path fixes

2019-07-15 Thread Josh Tynjala
Hey folks,

I just pushed some commits to royale-compiler and royale-asjs, and I wanted
to add a little explanation, and some possible troubleshooting advice if
anything seems to have broken in your apps.

My work over the last week has been to fix an issue related to specifying
dependencies when compiling libraries for JS. As you probably know, the
compiler supports two options for adding libraries as dependencies,
library-path and external-library-path. The library-path compiler option
basically says "include all classes that I use from this SWC in the final
output". It's typically what you use when compiling an app that uses a
library. The external-library-path compiler option basically says "if I use
anything from this SWC, check that I'm using the types correctly, but don't
include any of classes from this SWC in the final output".

If you're compiling an app, you typically use library-path for everything.
You use external-library-path only for dependencies like
playerglobal.swc/airglobal.swc in Flash or typedef SWCs in JS. Basically,
for an app project, external-library-path is for classes that are provided
natively by the Flash runtime or a web browser, like Chrome or Firefox.

When compiling libraries, external-library-path is also used to prevent the
compiler from creating a "fat" library that stuffs in all of the
dependencies. Let's say that you have a library, A.swc. It provides some
core functionality that is needed by both B.swc and C.swc. When we compile
B.swc and C.swc, we don't want the classes from A.swc duplicated in both of
them. So we add A.swc to the external-library-path when compiling B.swc or
C.swc. Then, if you use those SWCs when compiling an app, you need to add
A.swc, B.swc, and C.swc to the library-path.

To put that in Royale terms, A.swc is something like LanguageJS.swc or
CoreJS.swc. They're some of our lowest-level SWCs in the framework. B.swc
and C.swc are more like BasicJS.swc or JewelJS.swc, and they tend to share
multiple classes from the lower-level stuff.

Up until now, library-path and external-library-path were a little quirky
when compiling to JS. It was related to the goog.provide() and
goog.require() calls that you might have seen in the generated JS. These
are from the module system that we use in Royale. The compiler didn't know
how to differentiate between classes that had goog.provide() and classes
that were typedefs for JS libraries. It treated everything on the
external-library-path as a typedef, and this led to missing goog.require()
calls in the generated JS. To work around this, when we specified
dependencies in our framework SWCs, we used library-path to ensure that
goog.require() would be used.

This workaround of using library-path led to "fat" SWCs that contained all
of their dependencies. Low-level classes in SWCs like CoreJS were
duplicated in higher-level SWCs. This led to the compiler getting confused
about exactly where a class was defined.

This has resulted in some minor issues here and there, but nothing too
major until recently. However, Harbs noticed the other day that it caused
the compiler to copy extra default CSS into apps from SWCs that you may not
have been using. So, you might build an app with the Basic components, but
you'd get extra CSS from Jewel or MaterialDesignLite. This could mess up
your app's styling pretty dramatically.

I updated the compiler to better detect when a class needs goog.require()
and when it's a typedef. If that class comes from a SWC, the compiler knows
to check for an included file like, js/out/com/example/MyClass.js. If the
generated JS is there, goog.require() is necessary. If it's missing, it's
treated as a typedef class instead. If the class is an .as source file
instead, the compiler looks for the @externs asdoc tag to determine if it's
a typedef class (and everything else needs goog.require() instead).

By the way, if we ever support other module systems, it shouldn't be too
difficult to extend this code to detect different SWC layouts for each
module system.

If your project is an app, this change should not cause any problems.
You're probably using library-path and external-library-path correctly.

If you have a project that is a library, you should check your compiler
options to see if you are using library-path and external-library-path
correctly. If your library depends on another library, you probably should
be using external-library-path because you don't want a "fat" SWC. In other
words, if you're using library-path in a library project, you probably need
to change that to external-library-path.

If you have any custom typedef SWCs, you may want to recompile them. At one
point, the compiler had a bug where classes in typedef SWCs were being
incorrectly added to the "js/out" folder in the SWC, but that was
incorrect. They should have been placed in an "externs" folder instead. The
compiler handles this correctly now, but old typedef SWCs may look like
goog.require() SWCs instead. To be sure, 

Re: AMF and class aliases

2019-07-15 Thread Carlos Rovira
Hi Andrew,

El lun., 15 jul. 2019 a las 16:18, Frost, Andrew ()
escribió:

> Hi
>
> A custom bead for localization is a very good idea, yes. In this instance,
> we're looking at a migration from Flex so trying to keep as much of the
> original code the same as possible; with a custom (albeit generic) bead
> we've managed to do this. Not sure whether their code was the most
> efficient form when looked at from a Flex perspective either..
>

in jewel we are using Localization in Validator.as (through core
ILocalizedValuesImpl)
but the plan is remove that in the future since Alex pointed that we should
not use localization in that way. In the future, validation should separate
logic from view so the validation logic should check the VO, DTOs, Pojos...
objects while the visuals could be changed from tooltips to static labels
or whatever the user wants to inject. And the same way for localizations


> In terms of the AMF stuff, we've found a few more gotchas:
> - not 100% sure if these are necessary, but we had been just setting the
> endpoint manually so that the connection could be made, but we also need to
> have the 'destination' value set on the RemoteObject, and possibly the ID
> as well. In Flex, it was only the 'destination' being set up, and the
> framework then went and got the ID and the endpoint from the configuration
> file... we might look into adding support for that services configuration
> file (in some form) to make this process a little simpler.
>

in AMF/RO we have already are using "destination" (in fact we are setting
destination along with the ChannelSet), so if you're having problems maybe
it could be that you're using other RO implementation. I recommend you to
use MXRoyale RemoteObject implementation since is the closest to Flex and
supports almost all things (except for Vector and Dictionary) .


> - the AMF serialization for classes is taking their public properties. We
> had removed the public properties and changed them into private properties
> plus public get functions, in order to avoid the warning from the Google
> Closure Compiler, but the serializer is only looking at traditional
> properties rather than at accessors. Not sure whether this is something
> that we should consider changing in the future within the framework..?
>

Maybe this would better be responded by others


>
> Will see whether this all works now..!
>
> thanks
>
> Andrew
>
>
> -Original Message-
> From: Alex Harui 
> Sent: 15 July 2019 05:39
> To: dev@royale.apache.org
> Subject: [EXTERNAL] Re: AMF and class aliases
>
> IMO, localization may perform better with a custom bead or two.  Generic
> binding must watch something for changes that might require that
> getString() be called again, but in general, either bindings to locales are
> set up early (so no change watcher is needed at all), or because of PAYG,
> you should pay more to watch something like the locale changing.  But a
> custom binding bead could know to watch whatever you are using to load
> localized strings instead of using the generic watching rules.
>
> HTH,
> -Alex
>
> On 7/12/19, 9:12 AM, "Frost, Andrew"  wrote:
>
> Thanks
>
> Yes, binding is one that we're definitely also having some fun with.
> Wrote our own little binding bead for now but at some point I'll get round
> to looking in depth to see if there's a way of doing this using the
> 'proper' beads. In case you're that interested: it's for localisation where
> we have an object assigned to the class and when a property of the object
> is updated, it fires a "changed" event which we need to listen out for and
> then re-load in all the bound details, which are function calls with
> parameters i.e. this.localised.getString('id'). Tried a couple of binding
> beads and investigated what was happening, they were able to detect when
> the 'localised' variable was being changed i.e. a new one being added to
> 'this', but that's not what we're looking for. I think the use of the basic
> "changed" event rather than "ValueChangedEvent" might be confusing it..
>
> Anyway. Getting there. There is a response coming from the server now
> although I'm not sure whether this is then getting handled properly and
> what the next event is that's going out to the server, it's not working
> fully yet. Trying to remotely debug without any access to this myself :-(
>
>
> thanks
>
>Andrew
>
>
>
> -Original Message-
> From: Carlos Rovira 
> Sent: 12 July 2019 11:45
> To: dev@royale.apache.org
> Subject: [EXTERNAL] Re: AMF and class aliases
>
> Yeah! we are in production with AMF for around 4 months without any
> issue!
> So RO works great for Royale ;)
>
> this kind of problems where something is not working and is about a
> missed bead are very typical to Royale.
> Is the same with binding, statesbut our brains ends taking that
> into account and soon you'll get to that process ;)
>
> Best
>
> Carlos
>
>
>
> El 

RE: AMF and class aliases

2019-07-15 Thread Frost, Andrew
Hi

A custom bead for localization is a very good idea, yes. In this instance, 
we're looking at a migration from Flex so trying to keep as much of the 
original code the same as possible; with a custom (albeit generic) bead we've 
managed to do this. Not sure whether their code was the most efficient form 
when looked at from a Flex perspective either..

In terms of the AMF stuff, we've found a few more gotchas:
- not 100% sure if these are necessary, but we had been just setting the 
endpoint manually so that the connection could be made, but we also need to 
have the 'destination' value set on the RemoteObject, and possibly the ID as 
well. In Flex, it was only the 'destination' being set up, and the framework 
then went and got the ID and the endpoint from the configuration file... we 
might look into adding support for that services configuration file (in some 
form) to make this process a little simpler.
- the AMF serialization for classes is taking their public properties. We had 
removed the public properties and changed them into private properties plus 
public get functions, in order to avoid the warning from the Google Closure 
Compiler, but the serializer is only looking at traditional properties rather 
than at accessors. Not sure whether this is something that we should consider 
changing in the future within the framework..?

Will see whether this all works now..!

thanks

Andrew


-Original Message-
From: Alex Harui  
Sent: 15 July 2019 05:39
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases

IMO, localization may perform better with a custom bead or two.  Generic 
binding must watch something for changes that might require that getString() be 
called again, but in general, either bindings to locales are set up early (so 
no change watcher is needed at all), or because of PAYG, you should pay more to 
watch something like the locale changing.  But a custom binding bead could know 
to watch whatever you are using to load localized strings instead of using the 
generic watching rules.

HTH,
-Alex

On 7/12/19, 9:12 AM, "Frost, Andrew"  wrote:

Thanks

Yes, binding is one that we're definitely also having some fun with. Wrote 
our own little binding bead for now but at some point I'll get round to looking 
in depth to see if there's a way of doing this using the 'proper' beads. In 
case you're that interested: it's for localisation where we have an object 
assigned to the class and when a property of the object is updated, it fires a 
"changed" event which we need to listen out for and then re-load in all the 
bound details, which are function calls with parameters i.e. 
this.localised.getString('id'). Tried a couple of binding beads and 
investigated what was happening, they were able to detect when the 'localised' 
variable was being changed i.e. a new one being added to 'this', but that's not 
what we're looking for. I think the use of the basic "changed" event rather 
than "ValueChangedEvent" might be confusing it..

Anyway. Getting there. There is a response coming from the server now 
although I'm not sure whether this is then getting handled properly and what 
the next event is that's going out to the server, it's not working fully yet. 
Trying to remotely debug without any access to this myself :-(


thanks

   Andrew



-Original Message-
From: Carlos Rovira  
Sent: 12 July 2019 11:45
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases

Yeah! we are in production with AMF for around 4 months without any issue!
So RO works great for Royale ;)

this kind of problems where something is not working and is about a missed 
bead are very typical to Royale.
Is the same with binding, statesbut our brains ends taking that into 
account and soon you'll get to that process ;)

Best

Carlos



El vie., 12 jul. 2019 a las 0:38, Greg Dove ()
escribió:

> Yes, it should just work. There is at least one working example in the 
> examples set, and it should work with CommandMessage etc, without any 
> of the tweaks that you mentioned.
>
> Carlos is using amf extensively and it is currently in use in a 
> production app.
>
> Let me know if you see any bugs.
>
> cheers,
> Greg
>
>
>
> On Fri, Jul 12, 2019 at 10:31 AM Frost, Andrew 
> 
> wrote:
>
> > Oh it's that simple!
> >
> > Yes I just took a look, that does appear to go through it all and 
> > set everything up...
> >
> > Thank you!  that saved us a bit of effort trying to update the 
> > compiler
> ;-)
> >
> >
> >
> >
> > -Original Message-
> > From: Greg Dove 
> > Sent: 11 July 2019 23:27
> > To: dev@royale.apache.org
> > Subject: [EXTERNAL] Re: AMF and class aliases
> >
> > Hi Andrew,
> > 

Re: Uploading files with parameters

2019-07-15 Thread Piotr Zarzycki
This is exactly what I'm saying in my previous email - It has to be
refactored here to apply FormData stuff.

Thanks for all suggestions! Very helpful!

Piotr

pon., 15 lip 2019 o 15:37 Yishay Weiss  napisał(a):

> It sounds right to me. Maybe this [1] code from URLStream will need
> refactoring one day but I’m not sure.
>
>
>
> [1]
>
>var requestData:Object = urlRequest.data is
> BinaryData ? (urlRequest.data as BinaryData).data :
> HTTPUtils.encodeUrlVariables(urlRequest.data);
>
>send(requestData);
>
>
>
> 
> From: Piotr Zarzycki 
> Sent: Monday, July 15, 2019 1:58:11 PM
> To: dev@royale.apache.org
> Subject: Re: Uploading files with parameters
>
> Hi Yishay,
>
> Yes that is a good plan - however I still have some questions to make sure
> that I will pursue this addition correctly.
>
> Then, FileModelWithParams would set the correct param in the FormData
>
>
> Do you agree on my idea have here params:FormData property as I understand
> ?
>
> I agree with the rest that blop should be read only, it will be set
> somewhere along the road in FileModel etc, but later when we comes to
> upload I will have to change URLStream to handle FormData. Cause it looks
> like that
>
> 1. FileUploader upload stuff trough URLBinaryLoader  [1]
> 2. URLBinaryLoader creates stream and send the data [2] using URLStream -
> Btw. in that place I don't know why we are not using URLBinaryUploader.
> 3. URLStream will need to handle what kind of data is being send BinaryData
> or FormData here [3] - Here we should have already filled FormData in
> ealier stages, so no validation or something what is in FormData.
>
> Let me know if you see that differently.
>
> [1]
>
> https://github.com/apache/royale-asjs/blob/51636852d1d791703cb74b011741fb1f003d5863/frameworks/projects/Network/src/main/royale/org/apache/royale/file/beads/FileUploader.as#L86
> [2]
>
> https://github.com/apache/royale-asjs/blob/51636852d1d791703cb74b011741fb1f003d5863/frameworks/projects/Network/src/main/royale/org/apache/royale/net/URLBinaryLoader.as#L162
> [3]
>
> https://github.com/apache/royale-asjs/blob/0a9a732845a5d90c615754c0f8078f7b2f649893/frameworks/projects/Network/src/main/royale/org/apache/royale/net/URLStream.as#L136
>
> Thanks,
> Piotr
>
>
> >
>
> pon., 15 lip 2019 o 11:01 Yishay Weiss 
> napisał(a):
>
> > Hi Piotr,
> >
> > It looks like IFileModel should have a
> >
> > set fileContent(content:BinaryData):void
> >
> > Then, FileModelWithParams would set the correct param in the FormData and
> > FileModel would simply set blob.
> >
> > IFileModel.blob should be read only.
> >
> > That way, you can still use the rest of the beads the same way, only
> > changing the model. How does that sound?
> >
> > From: Piotr Zarzycki
> > Sent: Sunday, July 14, 2019 10:21 PM
> > To: dev@royale.apache.org
> > Subject: Re: Uploading files with parameters
> >
> > This is great idea Yishay, but I see one scenario where having in model
> > blop property as FormData type will fail. If I would like to Load and
> > Upload later file blop has to be BinaryData. - This is actually what we
> are
> > trying to do. We need to use FileLoaderAndUploader.
> >
> > However if I create that new model with additional field called params:
> > FormData  it could use in following way with code [1]
> >
> > 1) File is being browsed and assigned to "file" property in IFileModel
> > 2) FileLoaderAndUploader - loads it cause "blop" property is empty
> > 3) "blop" property is being filled after loading and it's BinaryData
> > 4) Everything is happened in following line [2] when at the end when we
> > would like to upload stuff. Here we could use params (FormData), put File
> > in params and send. I don't know what should
> > be the name of the param actually for file, but maybe there is no
> official
> > default name. Here is some examples [3]
> >
> > [1] https://paste.apache.org/8mxx3
> > [2]
> >
> >
> https://github.com/apache/royale-asjs/blob/51636852d1d791703cb74b011741fb1f003d5863/frameworks/projects/Network/src/main/royale/org/apache/royale/net/URLStream.as#L136
> > [3]
> >
> >
> https://developer.mozilla.org/en-US/docs/Web/API/FormData/Using_FormData_Objects
> >
> > Thanks,
> > Piotr
> >
> > niedz., 14 lip 2019 o 14:10 Yishay Weiss 
> > napisał(a):
> >
> > > It could be enough to create a new model FileModelWithParams implements
> > > IFileModel which has blob() return FormData in JS. I don’t think you
> need
> > > FileUploaderWithParams because the present one reads the blob from the
> > > model anyway.
> > >
> > >
> > >
> > > 
> > > From: Piotr Zarzycki 
> > > Sent: Sunday, July 14, 2019 2:54:18 PM
> > > To: dev@royale.apache.org
> > > Subject: Re: Uploading files with parameters
> > >
> > > I just looked into  FileModel and IFileModel. FileUploader using
> > FileModel,
> > > but this is because 

RE: Uploading files with parameters

2019-07-15 Thread Yishay Weiss
It sounds right to me. Maybe this [1] code from URLStream will need refactoring 
one day but I’m not sure.



[1]

   var requestData:Object = urlRequest.data is 
BinaryData ? (urlRequest.data as BinaryData).data : 
HTTPUtils.encodeUrlVariables(urlRequest.data);

   send(requestData);




From: Piotr Zarzycki 
Sent: Monday, July 15, 2019 1:58:11 PM
To: dev@royale.apache.org
Subject: Re: Uploading files with parameters

Hi Yishay,

Yes that is a good plan - however I still have some questions to make sure
that I will pursue this addition correctly.

Then, FileModelWithParams would set the correct param in the FormData


Do you agree on my idea have here params:FormData property as I understand ?

I agree with the rest that blop should be read only, it will be set
somewhere along the road in FileModel etc, but later when we comes to
upload I will have to change URLStream to handle FormData. Cause it looks
like that

1. FileUploader upload stuff trough URLBinaryLoader  [1]
2. URLBinaryLoader creates stream and send the data [2] using URLStream -
Btw. in that place I don't know why we are not using URLBinaryUploader.
3. URLStream will need to handle what kind of data is being send BinaryData
or FormData here [3] - Here we should have already filled FormData in
ealier stages, so no validation or something what is in FormData.

Let me know if you see that differently.

[1]
https://github.com/apache/royale-asjs/blob/51636852d1d791703cb74b011741fb1f003d5863/frameworks/projects/Network/src/main/royale/org/apache/royale/file/beads/FileUploader.as#L86
[2]
https://github.com/apache/royale-asjs/blob/51636852d1d791703cb74b011741fb1f003d5863/frameworks/projects/Network/src/main/royale/org/apache/royale/net/URLBinaryLoader.as#L162
[3]
https://github.com/apache/royale-asjs/blob/0a9a732845a5d90c615754c0f8078f7b2f649893/frameworks/projects/Network/src/main/royale/org/apache/royale/net/URLStream.as#L136

Thanks,
Piotr


>

pon., 15 lip 2019 o 11:01 Yishay Weiss  napisał(a):

> Hi Piotr,
>
> It looks like IFileModel should have a
>
> set fileContent(content:BinaryData):void
>
> Then, FileModelWithParams would set the correct param in the FormData and
> FileModel would simply set blob.
>
> IFileModel.blob should be read only.
>
> That way, you can still use the rest of the beads the same way, only
> changing the model. How does that sound?
>
> From: Piotr Zarzycki
> Sent: Sunday, July 14, 2019 10:21 PM
> To: dev@royale.apache.org
> Subject: Re: Uploading files with parameters
>
> This is great idea Yishay, but I see one scenario where having in model
> blop property as FormData type will fail. If I would like to Load and
> Upload later file blop has to be BinaryData. - This is actually what we are
> trying to do. We need to use FileLoaderAndUploader.
>
> However if I create that new model with additional field called params:
> FormData  it could use in following way with code [1]
>
> 1) File is being browsed and assigned to "file" property in IFileModel
> 2) FileLoaderAndUploader - loads it cause "blop" property is empty
> 3) "blop" property is being filled after loading and it's BinaryData
> 4) Everything is happened in following line [2] when at the end when we
> would like to upload stuff. Here we could use params (FormData), put File
> in params and send. I don't know what should
> be the name of the param actually for file, but maybe there is no official
> default name. Here is some examples [3]
>
> [1] https://paste.apache.org/8mxx3
> [2]
>
> https://github.com/apache/royale-asjs/blob/51636852d1d791703cb74b011741fb1f003d5863/frameworks/projects/Network/src/main/royale/org/apache/royale/net/URLStream.as#L136
> [3]
>
> https://developer.mozilla.org/en-US/docs/Web/API/FormData/Using_FormData_Objects
>
> Thanks,
> Piotr
>
> niedz., 14 lip 2019 o 14:10 Yishay Weiss 
> napisał(a):
>
> > It could be enough to create a new model FileModelWithParams implements
> > IFileModel which has blob() return FormData in JS. I don’t think you need
> > FileUploaderWithParams because the present one reads the blob from the
> > model anyway.
> >
> >
> >
> > 
> > From: Piotr Zarzycki 
> > Sent: Sunday, July 14, 2019 2:54:18 PM
> > To: dev@royale.apache.org
> > Subject: Re: Uploading files with parameters
> >
> > I just looked into  FileModel and IFileModel. FileUploader using
> FileModel,
> > but this is because IFileModel doesn't contains "blop" property - I think
> > IFileModel should contains such.
> >
> > It is definitely worth to make FileUploader using IFileModel.
> >
> > Next I could create bead FileUploaderWithParams extends FileUploader
> which
> > could use new interface IFileModelWithParams extends IFileModel.
> >
> > Thoughts ?
> >
> > Thanks,
> > Piotr
> >
> > niedz., 14 lip 2019 o 13:41 Piotr Zarzycki 
> > napisał(a):
> >
> > > Hi Yishay,
> > >
> > > Some 

Re: Uploading files with parameters

2019-07-15 Thread Piotr Zarzycki
Hi Yishay,

Yes that is a good plan - however I still have some questions to make sure
that I will pursue this addition correctly.

Then, FileModelWithParams would set the correct param in the FormData


Do you agree on my idea have here params:FormData property as I understand ?

I agree with the rest that blop should be read only, it will be set
somewhere along the road in FileModel etc, but later when we comes to
upload I will have to change URLStream to handle FormData. Cause it looks
like that

1. FileUploader upload stuff trough URLBinaryLoader  [1]
2. URLBinaryLoader creates stream and send the data [2] using URLStream -
Btw. in that place I don't know why we are not using URLBinaryUploader.
3. URLStream will need to handle what kind of data is being send BinaryData
or FormData here [3] - Here we should have already filled FormData in
ealier stages, so no validation or something what is in FormData.

Let me know if you see that differently.

[1]
https://github.com/apache/royale-asjs/blob/51636852d1d791703cb74b011741fb1f003d5863/frameworks/projects/Network/src/main/royale/org/apache/royale/file/beads/FileUploader.as#L86
[2]
https://github.com/apache/royale-asjs/blob/51636852d1d791703cb74b011741fb1f003d5863/frameworks/projects/Network/src/main/royale/org/apache/royale/net/URLBinaryLoader.as#L162
[3]
https://github.com/apache/royale-asjs/blob/0a9a732845a5d90c615754c0f8078f7b2f649893/frameworks/projects/Network/src/main/royale/org/apache/royale/net/URLStream.as#L136

Thanks,
Piotr


>

pon., 15 lip 2019 o 11:01 Yishay Weiss  napisał(a):

> Hi Piotr,
>
> It looks like IFileModel should have a
>
> set fileContent(content:BinaryData):void
>
> Then, FileModelWithParams would set the correct param in the FormData and
> FileModel would simply set blob.
>
> IFileModel.blob should be read only.
>
> That way, you can still use the rest of the beads the same way, only
> changing the model. How does that sound?
>
> From: Piotr Zarzycki
> Sent: Sunday, July 14, 2019 10:21 PM
> To: dev@royale.apache.org
> Subject: Re: Uploading files with parameters
>
> This is great idea Yishay, but I see one scenario where having in model
> blop property as FormData type will fail. If I would like to Load and
> Upload later file blop has to be BinaryData. - This is actually what we are
> trying to do. We need to use FileLoaderAndUploader.
>
> However if I create that new model with additional field called params:
> FormData  it could use in following way with code [1]
>
> 1) File is being browsed and assigned to "file" property in IFileModel
> 2) FileLoaderAndUploader - loads it cause "blop" property is empty
> 3) "blop" property is being filled after loading and it's BinaryData
> 4) Everything is happened in following line [2] when at the end when we
> would like to upload stuff. Here we could use params (FormData), put File
> in params and send. I don't know what should
> be the name of the param actually for file, but maybe there is no official
> default name. Here is some examples [3]
>
> [1] https://paste.apache.org/8mxx3
> [2]
>
> https://github.com/apache/royale-asjs/blob/51636852d1d791703cb74b011741fb1f003d5863/frameworks/projects/Network/src/main/royale/org/apache/royale/net/URLStream.as#L136
> [3]
>
> https://developer.mozilla.org/en-US/docs/Web/API/FormData/Using_FormData_Objects
>
> Thanks,
> Piotr
>
> niedz., 14 lip 2019 o 14:10 Yishay Weiss 
> napisał(a):
>
> > It could be enough to create a new model FileModelWithParams implements
> > IFileModel which has blob() return FormData in JS. I don’t think you need
> > FileUploaderWithParams because the present one reads the blob from the
> > model anyway.
> >
> >
> >
> > 
> > From: Piotr Zarzycki 
> > Sent: Sunday, July 14, 2019 2:54:18 PM
> > To: dev@royale.apache.org
> > Subject: Re: Uploading files with parameters
> >
> > I just looked into  FileModel and IFileModel. FileUploader using
> FileModel,
> > but this is because IFileModel doesn't contains "blop" property - I think
> > IFileModel should contains such.
> >
> > It is definitely worth to make FileUploader using IFileModel.
> >
> > Next I could create bead FileUploaderWithParams extends FileUploader
> which
> > could use new interface IFileModelWithParams extends IFileModel.
> >
> > Thoughts ?
> >
> > Thanks,
> > Piotr
> >
> > niedz., 14 lip 2019 o 13:41 Piotr Zarzycki 
> > napisał(a):
> >
> > > Hi Yishay,
> > >
> > > Some comments inline.
> > >
> > > [1]  https://paste.apache.org/rk1ro
> > >
> > > sob., 13 lip 2019 o 14:06 Yishay Weiss 
> > > napisał(a):
> > >
> > >> Hi Piotr,
> > >>
> > >>
> > >>
> > >> The beads [1] you mentioned are supposed to implement FileReference
> > >> methods, that’s why I was asking about the flash way of doing it.
> > >>
> > >>
> > >>
> > > *We are doing it in following way [1].*
> > >
> > >
> > >>
> > >> Maybe this example [3] helps.
> > >>
> > >>
> > >>
> > > *Yes this example was very 

Re: Build failed in Jenkins: royale-asjs_jsonly #3219

2019-07-15 Thread Carlos Rovira
Hi Harbs,

I missed your message, sorry.
I just have a doubt here. Is that latest update in official GCC visible to
us? I mean, don't know if they need to do some publication or update in his
side (maybe this change is only in code but is not released yet). And I
think we was using a concrete version so in that case we'll need to update
it to grab the one with this change right?

Thanks

El sáb., 13 jul. 2019 a las 20:29, Harbs () escribió:

> web_animations.js needs to be added to extenrc-config.xml and the code can
> be removed from missing.js
>
> > On Jul 12, 2019, at 1:18 AM, Carlos Rovira 
> wrote:
> >
> > Seems they finally add officially Element.animate API [1]
> >
> > it's the same API I added to missing.js
> >
> > can I remove that from missing.js? or we need to do some GCC update?
> >
> > thanks
> >
> >
> > https://github.com/google/closure-compiler/issues/2134
> >
> > El mar., 9 jul. 2019 a las 11:02, Yishay Weiss ( >)
> > escribió:
> >
> >> There’s also a closure compiler issue [1]. Maybe we can get some
> direction
> >> there.
> >>
> >>
> >>
> >> [1] https://github.com/google/closure-compiler/issues/2134
> >>
> >>
> >>
> >> 
> >> From: Harbs 
> >> Sent: Tuesday, July 9, 2019 11:58:10 AM
> >> To: dev@royale.apache.org
> >> Subject: Re: Build failed in Jenkins: royale-asjs_jsonly #3219
> >>
> >> animate is not yet a standard and it doesn’t work in Edge or Safari.
> >>
> >> I’m not sure if it’s something we should be adding just yet...
> >>
> >>> On Jul 9, 2019, at 11:41 AM, Yishay Weiss 
> >> wrote:
> >>>
> >>> I’m not sure. Looking at the js build [1] I can see the externs file
> >> being read from that repo, so I’m assuming one of them would need to be
> >> modified in order for the type to be updated. Maybe Harbs can comment on
> >> this, as he set up the repo.
> >>>
> >>>
> >>>
> >>> [1]
> https://github.com/apache/royale-typedefs/blob/develop/js/build.xml
> >>>
> >>>
> >>>
> >>> 
> >>> From: Piotr Zarzycki 
> >>> Sent: Tuesday, July 9, 2019 11:19:06 AM
> >>> To: dev@royale.apache.org
> >>> Subject: Re: Build failed in Jenkins: royale-asjs_jsonly #3219
> >>>
> >>> Hi Yishay,
> >>>
> >>> Should I add also my stuff to make it work to Royale-Extras ?
> >>>
> >>> Thanks,
> >>> Piotr
> >>>
> >>> wt., 9 lip 2019 o 10:14 Yishay Weiss 
> >> napisał(a):
> >>>
>  Hi Carlos,
> 
> 
> 
>  It looks like [1] this is experimental technology, which is probably
> why
>  it’s missing from our typedefs [2]. Theoretically it can be added [2],
> >> but
>  I don’t know if this is a good idea if it’s not guaranteed to work in
> >> every
>  browser.
> 
> 
> 
>  Thoughts?
> 
> 
> 
> 
> 
>  [1] https://developer.mozilla.org/en-US/docs/Web/API/Element/animate
> 
>  [2]
> 
> >>
> https://github.com/royale-extras/closure-compiler/blob/master/externs/browser/w3c_css.js
> 
> 
> 
>  
>  From: Carlos Rovira 
>  Sent: Tuesday, July 9, 2019 9:50:44 AM
>  To: dev@royale.apache.org
>  Subject: Re: Build failed in Jenkins: royale-asjs_jsonly #3219
> 
>  I think the problem is we really don't have "animate" method in our
> >> Element
>  JS API. I think yesterday I made some kind of wrong compilation.
> 
>  Can we add this?
>  https://developer.mozilla.org/es/docs/Web/API/Element/animate
>  If so, where should this be done?
> 
>  thanks
> 
> 
> 
>  El mar., 9 jul. 2019 a las 8:45, Carlos Rovira (<
> >> carlosrov...@apache.org>)
>  escribió:
> 
> > Seems this change I did yesterday is failing as well in my daily
> build.
> > How is possible this compiled ok yesterday with Maven? but today is
>  failing?
> > I'll be looking at it this morning
> >
> > 641725 bytes written to
> >
> 
> >>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Jewel/target/Jewel-0.9.6-SNAPSHOT-swf.swc
> > in 0,701 seconds
> >
> > COMPCJSCRoyale
> >
> >
> 
> >>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Jewel/src/main/royale/org/apache/royale/jewel/itemRenderers/TabBarButtonItemRenderer.as(197):
> > col: 22 Call to a possibly undefined method animate through a
> reference
> > with static type HTMLSpanElement.
> >
> >
> > indicator_content.animate(
> >
> > ^
> >
> >
> > 1.469368519 seconds
> >
> >
> > El mar., 9 jul. 2019 a las 6:20, Apache Royale CI Server (<
> > apacheroyal...@gmail.com>) escribió:
> >
> >> See <
> >>
> 
> >>
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/3219/display/redirect
> >>>
> >>
> >> --
> >> [...truncated 1.71 MB...]
> >>[java] [getlocal0, pushscope, newcatch(0), dup, setlocal(5), 

Re: Maven Royale-compiler build

2019-07-15 Thread Carlos Rovira
Great Piotr! : )

El dom., 14 jul. 2019 a las 16:50, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:

> All build are again up and running!
>
> On Fri, Jul 12, 2019, 4:54 PM Piotr Zarzycki 
> wrote:
>
> > The same is with  https://builds.apache.org/job/Royale-asjs/1947/console
> >
> > pt., 12 lip 2019 o 16:52 Piotr Zarzycki 
> > napisał(a):
> >
> >> I stopped the build for now.
> >>
> >> pt., 12 lip 2019 o 16:18 Piotr Zarzycki 
> >> napisał(a):
> >>
> >>> Hi,
> >>>
> >>> I have finally get to the bottom of problems with Windows machines in
> >>> Apache. It turns out that the old one was removed and there are new
> boxes.
> >>> I have switched each of our build to new one and Compiler seems to
> stuck on
> >>> accepting license for playerglobal.swc. [1] - Anyone know how to make
> it
> >>> work ?
> >>>
> >>> [1]  https://builds.apache.org/job/Royale-compiler/966/console
> >>>
> >>> Thanks,
> >>> --
> >>>
> >>> Piotr Zarzycki
> >>>
> >>> Patreon: *https://www.patreon.com/piotrzarzycki
> >>> *
> >>>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon: *https://www.patreon.com/piotrzarzycki
> >> *
> >>
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > *
> >
>


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


RE: Uploading files with parameters

2019-07-15 Thread Yishay Weiss
Hi Piotr,

It looks like IFileModel should have a

set fileContent(content:BinaryData):void

Then, FileModelWithParams would set the correct param in the FormData and 
FileModel would simply set blob.

IFileModel.blob should be read only.

That way, you can still use the rest of the beads the same way, only changing 
the model. How does that sound?

From: Piotr Zarzycki
Sent: Sunday, July 14, 2019 10:21 PM
To: dev@royale.apache.org
Subject: Re: Uploading files with parameters

This is great idea Yishay, but I see one scenario where having in model
blop property as FormData type will fail. If I would like to Load and
Upload later file blop has to be BinaryData. - This is actually what we are
trying to do. We need to use FileLoaderAndUploader.

However if I create that new model with additional field called params:
FormData  it could use in following way with code [1]

1) File is being browsed and assigned to "file" property in IFileModel
2) FileLoaderAndUploader - loads it cause "blop" property is empty
3) "blop" property is being filled after loading and it's BinaryData
4) Everything is happened in following line [2] when at the end when we
would like to upload stuff. Here we could use params (FormData), put File
in params and send. I don't know what should
be the name of the param actually for file, but maybe there is no official
default name. Here is some examples [3]

[1] https://paste.apache.org/8mxx3
[2]
https://github.com/apache/royale-asjs/blob/51636852d1d791703cb74b011741fb1f003d5863/frameworks/projects/Network/src/main/royale/org/apache/royale/net/URLStream.as#L136
[3]
https://developer.mozilla.org/en-US/docs/Web/API/FormData/Using_FormData_Objects

Thanks,
Piotr

niedz., 14 lip 2019 o 14:10 Yishay Weiss 
napisał(a):

> It could be enough to create a new model FileModelWithParams implements
> IFileModel which has blob() return FormData in JS. I don’t think you need
> FileUploaderWithParams because the present one reads the blob from the
> model anyway.
>
>
>
> 
> From: Piotr Zarzycki 
> Sent: Sunday, July 14, 2019 2:54:18 PM
> To: dev@royale.apache.org
> Subject: Re: Uploading files with parameters
>
> I just looked into  FileModel and IFileModel. FileUploader using FileModel,
> but this is because IFileModel doesn't contains "blop" property - I think
> IFileModel should contains such.
>
> It is definitely worth to make FileUploader using IFileModel.
>
> Next I could create bead FileUploaderWithParams extends FileUploader which
> could use new interface IFileModelWithParams extends IFileModel.
>
> Thoughts ?
>
> Thanks,
> Piotr
>
> niedz., 14 lip 2019 o 13:41 Piotr Zarzycki 
> napisał(a):
>
> > Hi Yishay,
> >
> > Some comments inline.
> >
> > [1]  https://paste.apache.org/rk1ro
> >
> > sob., 13 lip 2019 o 14:06 Yishay Weiss 
> > napisał(a):
> >
> >> Hi Piotr,
> >>
> >>
> >>
> >> The beads [1] you mentioned are supposed to implement FileReference
> >> methods, that’s why I was asking about the flash way of doing it.
> >>
> >>
> >>
> > *We are doing it in following way [1].*
> >
> >
> >>
> >> Maybe this example [3] helps.
> >>
> >>
> >>
> > *Yes this example was very helpful and we are doing upload in exactly the
> > same way. *
> >
> >
> >>
> >> As I understand the SO answers [2], they’re suggesting to either send
> the
> >> params on the url or in a FormData.
> >>
> >>
> >>
> >> For the former solution you can add  bead
> >> to the file proxy and then on blobChangedHandler() you can make a call
> like:
> >>
> >>
> >>
> >> myUploader.upload(url?param1=1=2)
> >>
> >>
> >>
> > *As you can see in my link [1] we are doing that in a way as you are
> > suggesting in Flex. In Royale I would like to avoid completely such
> things
> > like concatenating string in order to build url. That's way I have
> started
> > this thread to make sure that I'm not missing some better way than this.
> It
> > looks like I need to implement it. Thanks for confirmation actually.*
> >
> >
> >>
> >> If you want the latter solution you can create a new IFileModel bead
> with
> >> params that would implement FormData on the JS side.
> >>
> >>
> >>
> >> It could be that FileUploader needs to be refacotred to read and
> >> IFileModel instead of an IModel, and that blob() should be part of the
> >> interface and return an Object.
> >>
> >>
> >>
> > *Once I jump into implementation I will take into account your
> > suggestions.*
> >
> >
> >>
> >> Hope you understand when you look at the code, otherwise ask.
> >>
> >>
> >>
> >> Thanks.
> >>
> >>
> >>
> >> [1]
> >>
> https://github.com/apache/royale-asjs/tree/develop/frameworks/projects/Network/src/main/royale/org/apache/royale/file/beads
> >>
> >> [2] https://stackoverflow.com/questions/15218292/xhr-sendfile-params
> >>
> >> [3] https://github.com/yishayw/Examples/blob/FileProxy/Examples.mxml
> >>
> >>
> >>
> >> 
> >> From: Piotr Zarzycki 
> >> Sent: 

Re: Crux Branch

2019-07-15 Thread Carlos Rovira
Hi Alex,

your concerns about Crux name applies to the others like Basic or Jewel
(just to name a few). If I search for "Jewel js" in google I get various
Jewel libraries (same for Basic js). What makes Jewel appropriate for us is
that is an internal name (internal branding) we use to refer to that
concrete part of the entire Royale framework, so in then end is not about
"jewel" for folks here their brain knows that we are talking all the time
about "Apache Royale Jewel". One more thing we add using this kind of names
is: 1) Names that has some marketing, and we can create icons, or more (it
will be hard for me create a icon for FlexJS or SwizRoyale), 2) short names
with some meaning inside the ecosystem and relation with a set of words
that shares some meaning root. And moreover, since we changed to Royale
name we are doing all the things in the same line of action what makes the
naming decisions in Royale follow a strategy. It would be not consistent to
come back to older name strategy like FlexJS or SwizRoyale. We should
follow what we started and continue in that line.

I must say I never thought in MXRoyale and SparkRoyale naming, since it was
a work in progress that started to grow in Royale progressively and I was
focused in other parts. For that cases, we could bring other names or not.
I must say that I didn't take much time to think about it conceptually. We
could do or not depending on what you want to do in that part.

For Jewel, we didn't thought about it so much. I remember I started with
other codename, but very soon I renamed and shared to Jewel explaining the
motivations, thoughts, and meaning of that name. But, we didn't some king
of name process for it

In the case of Crux. I think it could not be "Crux",I like for the
shortness and meaning, but could be other better options. What I don't like
is bring as "Swiz" or "SwizRoyale". The first because is not Swiz (as I
explained Swiz is for Flex) and SwizRoyale is for me very long and does not
have a meaning inside of what we are doing with the rest of Royale naming
decision and marketing (making it very difficult to brand along with the
rest of Royale parts for marketing and web).

just my 2

Carlos



El lun., 15 jul. 2019 a las 6:30, Alex Harui ()
escribió:

> Regarding naming, giving something a longer more descriptive name can also
> make it harder to use and then folks start using the short name and then
> there can be confusion again.
>
> AIUI, trademark issues are about confusion.  Names like "Basic" and
> "Jewel" don't appear to have uses that could be confusing.  "Crux" appears
> to be some sort of language thing for Java being brought over to JS, so my
> concern is that someone may someday want Royale to support a Crux library
> that is based on the Java thing.
>
> We are using MXRoyale and SparkRoyale as names for the emulations of
> Flex's MX and Spark components.  "SwizRoyale" would be consistent,
> especially if the goal is to emulate Swiz and potentially get more of the
> Swiz code officially contributed to Apache Royale.  Having renamed lots of
> FlexJS to Royale, I can tell you that renaming still takes time.
>
> My 2 cents,
> -Alex
>
> On 7/12/19, 3:41 AM, "Carlos Rovira"  wrote:
>
> Hi Greg!
>
> great progress with the latest touches.
>
> My latest days was in Crux branch so for me is ok to do the merge I
> think
> we cover all the things needed like licensing and avoid name conflicts.
> Even we always can improve any of those things over time. So it's ok.
>
> About the name: You're right, Apache Royale Crux is like other "parts"
> in
> Apache Royale, i.e Apache Royale Basic, Apache Royale Jewel,  just
> a
> convenient name to refer a concrete part of the Apache Royale ecosystem
> with a bit of meaning and other bit of marketing (I plan to create some
> icon for the web in the future as I did with Jewel, and we can do some
> graphics and more when we reach a good point with the actual
> documentation
> effort). One important thing for me with the name is to make it
> different
> to Swiz to avoid confusion on that part: Swiz is for Flex, while Crux
> is
> for Royale. So if people talks about Swiz it will be clear that is
> about
> the project for Apache Flex, while if talks about Crux is clear that
> is for
> Apache Royale. The same happens at major level with Apache Flex and
> Apache
> Royale project.
>
> So for me it's all ok.
>
> Thanks for the hard work in this regard Greg!
>
> Carlos
>
>
>
>
>
>
> El vie., 12 jul. 2019 a las 9:31, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>)
> escribió:
>
> > Hi Greg,
> >
> > Thanks for update. I'm having again more important tasks and that is
> why I
> > didn't start release process yet. It looks like I will have for sure
> 2 full
> > working days to start process on upcoming Wednesday. If you make it
> till
> > that time it would be great, if not let's stay on the