Re: AMF and class aliases
Thanks all - some useful information there. Yes I think sending as a typed
class would be better but we're not touching the server-side... so we have to
have these workarounds. I can see the benefit of the minification for sure, but
yes when there's an object being created with the property name coming from an
AMF data stream, it then doesn't match the minified version!
Working now anyway, thanks!
Andrew
-Original Message-
From: Greg Dove
Sent: 23 July 2019 05:58
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases
Andrew, you mentioned this was being 'deserialized', so I assume this is coming
from the server as an untyped (plain) Object?
In that case, it will be deserialized with the correct original field name from
the server ('RESULT_CODE' in this case), but there is no typed reference to
that in your local code, so as Alex says the release build is renaming it, and
as suggested there needs to be more 'clues' to prevent the renaming. I believe
Alex knows more about the rules for that than I do.
It seems that you have a way to make it work now, which is probably all you
want.
But for completeness: another option is to send it as a typed class using
public vars (not using any manual-coded getter/setter pair or Bindable).
class ResultCode { public var RESULT_CODE:String; } You could then cast the
result in the same way you mentioned in your first post.
The difference here is that this will also likely rename the field access in
the release build in the same way that you saw with the original problem, but
amf deserialization will support that and it should therefore match up with the
renamed field name used in your release-build local code.
So it's probably an 'in-between' option to consider, for the future.
On Tue, Jul 23, 2019 at 4:11 PM Alex Harui wrote:
> FWIW, AIUI, the property names of plain Objects and public vars will
> be renamed unless a quoted string of that property name is used
> "somewhere" in the JS code.
>
> It might have worked just to use JSON-style:
> {"RESULT_CODE": "OK"}
>
> Creating a class definition causes the compiler to generate an
> Object.defineProperties structure with the property name as a key in
> the object structure, thus preventing the rename.
>
> If you scan the js-debug output for RESULT_CODE, you should see where
> that string showed up and how having a variable "nc" would save bytes,
> but the name to use for a renamable property is independent of that,
> and I think properties are renamed before figuring out whether a local
> variable would further save bytes.
>
> So, that's roughly the answer to #1. For #2, you "should" use classes
> with getter/setters instead of [Bindable] unless you need property
> change detection at runtime in order to get code-completion and compile-time
> checking that you didn't mis-type "RESULTCODE". There is probably a
> trade-off of how many times you'll make mistakes like that vs the time
> to create the classes and the additional time to load the class definitions.
> It should be smaller to use [brackets] than load the classes.
>
> The new IDEs should consider a wizard to help generate those classes.
>
> HTH,
> -Alex
>
>
> On 7/22/19, 2:18 AM, "Frost, Andrew" wrote:
>
> Hi again
>
> One extra question here: we have the AMF connection working fine
> now in Debug mode, but in Release mode the minifier is changing the
> property names of our JavaScript (compiled from ActionScript), but
> these are not being reflected in the objects that are deserialised.
>
> So for example, we are receiving an ArrayCollection, and accessing
> one element's property directly e.g.:
> var results : ArrayCollection = resultEvt.result as ArrayCollection;
> for (var i : uint = 0; i < results.length; i++)
> {
> var resultCode : String =
> results[i].outputArray.source[0].RESULT_CODE;
> ...
>
> There are a couple of things going on:
> (a) each element in the main ArrayCollection has an "outputArray"
> property which is itself an ArrayCollection. We could cast it into an
> ArrayCollection variable I guess, but instead have just added "source"
> so that the JavaScript doesn't try adding the [] operator to the
> ArrayCollection object directly...
> (b) the contents of this ArrayCollection, in this particular case,
> is a simple object {RESULT_CODE: "OK"} - which I can see in the
> console when we add some trace. The js-debug file has the same
> structure as the ActionScript; but the js-release file has a mapping
> at the start "nc='RESULT_CODE'" and then accesses the data with "
> a.L(c).outputData.source[0].tP" (and that's even weir
Re: AMF and class aliases
Andrew, you mentioned this was being 'deserialized', so I assume this is
coming from the server as an untyped (plain) Object?
In that case, it will be deserialized with the correct original field name
from the server ('RESULT_CODE' in this case), but there is no typed
reference to that in your local code, so as Alex says the release build is
renaming it, and as suggested there needs to be more 'clues' to prevent the
renaming. I believe Alex knows more about the rules for that than I do.
It seems that you have a way to make it work now, which is probably all you
want.
But for completeness: another option is to send it as a typed class using
public vars (not using any manual-coded getter/setter pair or Bindable).
class ResultCode { public var RESULT_CODE:String; }
You could then cast the result in the same way you mentioned in your first
post.
The difference here is that this will also likely rename the field access
in the release build in the same way that you saw with the original
problem, but amf deserialization will support that and it should therefore
match up with the renamed field name used in your release-build local code.
So it's probably an 'in-between' option to consider, for the future.
On Tue, Jul 23, 2019 at 4:11 PM Alex Harui wrote:
> FWIW, AIUI, the property names of plain Objects and public vars will be
> renamed unless a quoted string of that property name is used "somewhere" in
> the JS code.
>
> It might have worked just to use JSON-style:
> {"RESULT_CODE": "OK"}
>
> Creating a class definition causes the compiler to generate an
> Object.defineProperties structure with the property name as a key in the
> object structure, thus preventing the rename.
>
> If you scan the js-debug output for RESULT_CODE, you should see where that
> string showed up and how having a variable "nc" would save bytes, but the
> name to use for a renamable property is independent of that, and I think
> properties are renamed before figuring out whether a local variable would
> further save bytes.
>
> So, that's roughly the answer to #1. For #2, you "should" use classes
> with getter/setters instead of [Bindable] unless you need property change
> detection at runtime in order to get code-completion and compile-time
> checking that you didn't mis-type "RESULTCODE". There is probably a
> trade-off of how many times you'll make mistakes like that vs the time to
> create the classes and the additional time to load the class definitions.
> It should be smaller to use [brackets] than load the classes.
>
> The new IDEs should consider a wizard to help generate those classes.
>
> HTH,
> -Alex
>
>
> On 7/22/19, 2:18 AM, "Frost, Andrew" wrote:
>
> Hi again
>
> One extra question here: we have the AMF connection working fine now
> in Debug mode, but in Release mode the minifier is changing the property
> names of our JavaScript (compiled from ActionScript), but these are not
> being reflected in the objects that are deserialised.
>
> So for example, we are receiving an ArrayCollection, and accessing one
> element's property directly e.g.:
> var results : ArrayCollection = resultEvt.result as ArrayCollection;
> for (var i : uint = 0; i < results.length; i++)
> {
> var resultCode : String =
> results[i].outputArray.source[0].RESULT_CODE;
> ...
>
> There are a couple of things going on:
> (a) each element in the main ArrayCollection has an "outputArray"
> property which is itself an ArrayCollection. We could cast it into an
> ArrayCollection variable I guess, but instead have just added "source" so
> that the JavaScript doesn't try adding the [] operator to the
> ArrayCollection object directly...
> (b) the contents of this ArrayCollection, in this particular case, is
> a simple object {RESULT_CODE: "OK"} - which I can see in the console when
> we add some trace. The js-debug file has the same structure as the
> ActionScript; but the js-release file has a mapping at the start
> "nc='RESULT_CODE'" and then accesses the data with "
> a.L(c).outputData.source[0].tP" (and that's even weirder as why is it 'tP'
> rather than 'nc'?!)
>
>
> I guess the questions I have are:
>
> 1) Is there a way to prevent the Google closure compiler from
> minifying a particular property name/string?
> or
> 2) Are we going to have to just declare classes for all of these and
> do a typecast e.g. along the lines of:
> class ResultCode { [Bindable]public var RESULT_CODE; }
> and then
> var resultCodeObj : ResultCode = results[i].outputArray.source[0];
> var resultCode : String = resultCodeObj.RESULT_CODE;
>
>
&
Re: AMF and class aliases
FWIW, AIUI, the property names of plain Objects and public vars will be renamed
unless a quoted string of that property name is used "somewhere" in the JS code.
It might have worked just to use JSON-style:
{"RESULT_CODE": "OK"}
Creating a class definition causes the compiler to generate an
Object.defineProperties structure with the property name as a key in the object
structure, thus preventing the rename.
If you scan the js-debug output for RESULT_CODE, you should see where that
string showed up and how having a variable "nc" would save bytes, but the name
to use for a renamable property is independent of that, and I think properties
are renamed before figuring out whether a local variable would further save
bytes.
So, that's roughly the answer to #1. For #2, you "should" use classes with
getter/setters instead of [Bindable] unless you need property change detection
at runtime in order to get code-completion and compile-time checking that you
didn't mis-type "RESULTCODE". There is probably a trade-off of how many times
you'll make mistakes like that vs the time to create the classes and the
additional time to load the class definitions. It should be smaller to use
[brackets] than load the classes.
The new IDEs should consider a wizard to help generate those classes.
HTH,
-Alex
On 7/22/19, 2:18 AM, "Frost, Andrew" wrote:
Hi again
One extra question here: we have the AMF connection working fine now in
Debug mode, but in Release mode the minifier is changing the property names of
our JavaScript (compiled from ActionScript), but these are not being reflected
in the objects that are deserialised.
So for example, we are receiving an ArrayCollection, and accessing one
element's property directly e.g.:
var results : ArrayCollection = resultEvt.result as ArrayCollection;
for (var i : uint = 0; i < results.length; i++)
{
var resultCode : String = results[i].outputArray.source[0].RESULT_CODE;
...
There are a couple of things going on:
(a) each element in the main ArrayCollection has an "outputArray" property
which is itself an ArrayCollection. We could cast it into an ArrayCollection
variable I guess, but instead have just added "source" so that the JavaScript
doesn't try adding the [] operator to the ArrayCollection object directly...
(b) the contents of this ArrayCollection, in this particular case, is a
simple object {RESULT_CODE: "OK"} - which I can see in the console when we add
some trace. The js-debug file has the same structure as the ActionScript; but
the js-release file has a mapping at the start "nc='RESULT_CODE'" and then
accesses the data with " a.L(c).outputData.source[0].tP" (and that's even
weirder as why is it 'tP' rather than 'nc'?!)
I guess the questions I have are:
1) Is there a way to prevent the Google closure compiler from minifying a
particular property name/string?
or
2) Are we going to have to just declare classes for all of these and do a
typecast e.g. along the lines of:
class ResultCode { [Bindable]public var RESULT_CODE; }
and then
var resultCodeObj : ResultCode = results[i].outputArray.source[0];
var resultCode : String = resultCodeObj.RESULT_CODE;
thanks
Andrew
-Original Message-
From: Greg Dove
Sent: 15 July 2019 21:40
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases
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 fe
Re: AMF and class aliases
Great to hear that Andrew! :)
although, maybe others will have some more clues about how to get release
mode work too. I think is amazing to see a royale app working in release
mode since is blazing fast, and customers use to be impressed by the
amazing performance ;)
El lun., 22 jul. 2019 a las 17:04, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:
> Hi Andrew,
>
> Congrats! Customer's happiness is all about what we wanted for this project
> :)
>
> Thanks,
> Piotr
>
> pon., 22 lip 2019 o 17:01 Frost, Andrew
> napisał(a):
>
> > Perfect, thanks! With a bit of a mixture of typing and then of using that
> > format with the accessing, it worked.. I didn't want to have to create
> > class definitions for all of these various options but just using the
> > ["RESULT_CODE"] notification in ActionScript means that the generated
> (and
> > minified) JavaScript creates it as .RESULT_CODE and this then works with
> > the dynamically recreated data.
> >
> > Thanks for the support, one step closer as now our release builds are
> > picking up the database connection (makes our customer happier as they
> > don't like the slow loading time for all the .js files in a debug
> build...)
> >
> > cheers
> >
> >
> >
> > -----Original Message-
> > From: Carlos Rovira
> > Sent: 22 July 2019 14:52
> > To: dev@royale.apache.org
> > Subject: [EXTERNAL] Re: AMF and class aliases
> >
> > Hi Andrew,
> >
> > first of all if you are using ArrayCollection and not ArrayList you must
> > configure that. In my code I'm using this to configure ArrayList as the
> > type royale must use when send and receive java ArrayCollection:
> >
> > registerClassAlias("flex.messaging.io.ArrayCollection", ArrayList);
> >
> > (don't remember if Greg made it default to ArrayCollection)
> >
> > about serialization/deserialization issues, maybe other could give you
> > better clues than me, since all our objects are strongly typed so objects
> > in collections are classes and if that classes has collections then the
> sub
> > objects will be typed as well.
> >
> > I found that when I have problems when something runs in debug mode but
> > not in release mode for deserialization issues the object bracket access
> > use to work always, so I think is what you need to do, so for example in
> > you case I think this should work:
> >
> > results[I]["outputArray"]["source"][0][RESULT_CODE]
> >
> > HTH
> >
> > Carlos
> >
> > El lun., 22 jul. 2019 a las 11:17, Frost, Andrew (<
> andrew.fr...@harman.com
> > >)
> > escribió:
> >
> > > Hi again
> > >
> > > One extra question here: we have the AMF connection working fine now
> > > in Debug mode, but in Release mode the minifier is changing the
> > > property names of our JavaScript (compiled from ActionScript), but
> > > these are not being reflected in the objects that are deserialised.
> > >
> > > So for example, we are receiving an ArrayCollection, and accessing one
> > > element's property directly e.g.:
> > > var results : ArrayCollection = resultEvt.result as ArrayCollection;
> > > for (var i : uint = 0; i < results.length; i++) {
> > > var resultCode : String =
> > > results[i].outputArray.source[0].RESULT_CODE;
> > > ...
> > >
> > > There are a couple of things going on:
> > > (a) each element in the main ArrayCollection has an "outputArray"
> > > property which is itself an ArrayCollection. We could cast it into an
> > > ArrayCollection variable I guess, but instead have just added "source"
> > > so that the JavaScript doesn't try adding the [] operator to the
> > > ArrayCollection object directly...
> > > (b) the contents of this ArrayCollection, in this particular case, is
> > > a simple object {RESULT_CODE: "OK"} - which I can see in the console
> > > when we add some trace. The js-debug file has the same structure as
> > > the ActionScript; but the js-release file has a mapping at the start
> > > "nc='RESULT_CODE'" and then accesses the data with "
> > > a.L(c).outputData.source[0].tP" (and that's even weirder as why is it
> > 'tP'
> > > rather than 'nc'?!)
> > >
> > >
> > > I guess the questions I have are:
> > >
> > > 1) Is there a way to prevent the Google closure compiler from
> > > minifying a particular property name/string?
> > > or
> > > 2) Are we going to have to just declare classes for all of these and
> > > do a typecast e.g. along the lines of:
> > > class ResultCode { [Bindable]public var RESULT_CODE; } and then var
> > > resultCodeObj : ResultCode = results[i].outputArray.source[0]; var
> > > resultCode : String = resultCodeObj.RESULT_CODE;
> > >
> > >
> > > thanks
> > >
> > >Andrew
> > >
> > >
> > > --
> > > Carlos Rovira
> > > https://clicktime.symantec.com/3R6MVFpF7GfH9MBneA8xfU97Vc?u=http%3A%2F
> > > %2Fabout.me%2Fcarlosrovira
> > >
> > >
> > >
> > >
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: AMF and class aliases
Hi Andrew,
Congrats! Customer's happiness is all about what we wanted for this project
:)
Thanks,
Piotr
pon., 22 lip 2019 o 17:01 Frost, Andrew
napisał(a):
> Perfect, thanks! With a bit of a mixture of typing and then of using that
> format with the accessing, it worked.. I didn't want to have to create
> class definitions for all of these various options but just using the
> ["RESULT_CODE"] notification in ActionScript means that the generated (and
> minified) JavaScript creates it as .RESULT_CODE and this then works with
> the dynamically recreated data.
>
> Thanks for the support, one step closer as now our release builds are
> picking up the database connection (makes our customer happier as they
> don't like the slow loading time for all the .js files in a debug build...)
>
> cheers
>
>
>
> -Original Message-
> From: Carlos Rovira
> Sent: 22 July 2019 14:52
> To: dev@royale.apache.org
> Subject: [EXTERNAL] Re: AMF and class aliases
>
> Hi Andrew,
>
> first of all if you are using ArrayCollection and not ArrayList you must
> configure that. In my code I'm using this to configure ArrayList as the
> type royale must use when send and receive java ArrayCollection:
>
> registerClassAlias("flex.messaging.io.ArrayCollection", ArrayList);
>
> (don't remember if Greg made it default to ArrayCollection)
>
> about serialization/deserialization issues, maybe other could give you
> better clues than me, since all our objects are strongly typed so objects
> in collections are classes and if that classes has collections then the sub
> objects will be typed as well.
>
> I found that when I have problems when something runs in debug mode but
> not in release mode for deserialization issues the object bracket access
> use to work always, so I think is what you need to do, so for example in
> you case I think this should work:
>
> results[I]["outputArray"]["source"][0][RESULT_CODE]
>
> HTH
>
> Carlos
>
> El lun., 22 jul. 2019 a las 11:17, Frost, Andrew ( >)
> escribió:
>
> > Hi again
> >
> > One extra question here: we have the AMF connection working fine now
> > in Debug mode, but in Release mode the minifier is changing the
> > property names of our JavaScript (compiled from ActionScript), but
> > these are not being reflected in the objects that are deserialised.
> >
> > So for example, we are receiving an ArrayCollection, and accessing one
> > element's property directly e.g.:
> > var results : ArrayCollection = resultEvt.result as ArrayCollection;
> > for (var i : uint = 0; i < results.length; i++) {
> > var resultCode : String =
> > results[i].outputArray.source[0].RESULT_CODE;
> > ...
> >
> > There are a couple of things going on:
> > (a) each element in the main ArrayCollection has an "outputArray"
> > property which is itself an ArrayCollection. We could cast it into an
> > ArrayCollection variable I guess, but instead have just added "source"
> > so that the JavaScript doesn't try adding the [] operator to the
> > ArrayCollection object directly...
> > (b) the contents of this ArrayCollection, in this particular case, is
> > a simple object {RESULT_CODE: "OK"} - which I can see in the console
> > when we add some trace. The js-debug file has the same structure as
> > the ActionScript; but the js-release file has a mapping at the start
> > "nc='RESULT_CODE'" and then accesses the data with "
> > a.L(c).outputData.source[0].tP" (and that's even weirder as why is it
> 'tP'
> > rather than 'nc'?!)
> >
> >
> > I guess the questions I have are:
> >
> > 1) Is there a way to prevent the Google closure compiler from
> > minifying a particular property name/string?
> > or
> > 2) Are we going to have to just declare classes for all of these and
> > do a typecast e.g. along the lines of:
> > class ResultCode { [Bindable]public var RESULT_CODE; } and then var
> > resultCodeObj : ResultCode = results[i].outputArray.source[0]; var
> > resultCode : String = resultCodeObj.RESULT_CODE;
> >
> >
> > thanks
> >
> >Andrew
> >
> >
> > --
> > Carlos Rovira
> > https://clicktime.symantec.com/3R6MVFpF7GfH9MBneA8xfU97Vc?u=http%3A%2F
> > %2Fabout.me%2Fcarlosrovira
> >
> >
> >
> >
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: AMF and class aliases
Perfect, thanks! With a bit of a mixture of typing and then of using that
format with the accessing, it worked.. I didn't want to have to create class
definitions for all of these various options but just using the ["RESULT_CODE"]
notification in ActionScript means that the generated (and minified) JavaScript
creates it as .RESULT_CODE and this then works with the dynamically recreated
data.
Thanks for the support, one step closer as now our release builds are picking
up the database connection (makes our customer happier as they don't like the
slow loading time for all the .js files in a debug build...)
cheers
-Original Message-
From: Carlos Rovira
Sent: 22 July 2019 14:52
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases
Hi Andrew,
first of all if you are using ArrayCollection and not ArrayList you must
configure that. In my code I'm using this to configure ArrayList as the type
royale must use when send and receive java ArrayCollection:
registerClassAlias("flex.messaging.io.ArrayCollection", ArrayList);
(don't remember if Greg made it default to ArrayCollection)
about serialization/deserialization issues, maybe other could give you better
clues than me, since all our objects are strongly typed so objects in
collections are classes and if that classes has collections then the sub
objects will be typed as well.
I found that when I have problems when something runs in debug mode but not in
release mode for deserialization issues the object bracket access use to work
always, so I think is what you need to do, so for example in you case I think
this should work:
results[I]["outputArray"]["source"][0][RESULT_CODE]
HTH
Carlos
El lun., 22 jul. 2019 a las 11:17, Frost, Andrew ()
escribió:
> Hi again
>
> One extra question here: we have the AMF connection working fine now
> in Debug mode, but in Release mode the minifier is changing the
> property names of our JavaScript (compiled from ActionScript), but
> these are not being reflected in the objects that are deserialised.
>
> So for example, we are receiving an ArrayCollection, and accessing one
> element's property directly e.g.:
> var results : ArrayCollection = resultEvt.result as ArrayCollection;
> for (var i : uint = 0; i < results.length; i++) {
> var resultCode : String =
> results[i].outputArray.source[0].RESULT_CODE;
> ...
>
> There are a couple of things going on:
> (a) each element in the main ArrayCollection has an "outputArray"
> property which is itself an ArrayCollection. We could cast it into an
> ArrayCollection variable I guess, but instead have just added "source"
> so that the JavaScript doesn't try adding the [] operator to the
> ArrayCollection object directly...
> (b) the contents of this ArrayCollection, in this particular case, is
> a simple object {RESULT_CODE: "OK"} - which I can see in the console
> when we add some trace. The js-debug file has the same structure as
> the ActionScript; but the js-release file has a mapping at the start
> "nc='RESULT_CODE'" and then accesses the data with "
> a.L(c).outputData.source[0].tP" (and that's even weirder as why is it 'tP'
> rather than 'nc'?!)
>
>
> I guess the questions I have are:
>
> 1) Is there a way to prevent the Google closure compiler from
> minifying a particular property name/string?
> or
> 2) Are we going to have to just declare classes for all of these and
> do a typecast e.g. along the lines of:
> class ResultCode { [Bindable]public var RESULT_CODE; } and then var
> resultCodeObj : ResultCode = results[i].outputArray.source[0]; var
> resultCode : String = resultCodeObj.RESULT_CODE;
>
>
> thanks
>
>Andrew
>
>
> --
> Carlos Rovira
> https://clicktime.symantec.com/3R6MVFpF7GfH9MBneA8xfU97Vc?u=http%3A%2F
> %2Fabout.me%2Fcarlosrovira
>
>
>
>
Re: AMF and class aliases
Hi Andrew,
first of all if you are using ArrayCollection and not ArrayList you must
configure that. In my code I'm using this to configure ArrayList as the
type royale must use when send and receive java ArrayCollection:
registerClassAlias("flex.messaging.io.ArrayCollection", ArrayList);
(don't remember if Greg made it default to ArrayCollection)
about serialization/deserialization issues, maybe other could give you
better clues than me, since all our objects are strongly typed so objects
in collections are classes and if that classes has collections then the sub
objects will be typed as well.
I found that when I have problems when something runs in debug mode but not
in release mode for deserialization issues the object bracket access use to
work always, so I think is what you need to do, so for example in you case
I think this should work:
results[I]["outputArray"]["source"][0][RESULT_CODE]
HTH
Carlos
El lun., 22 jul. 2019 a las 11:17, Frost, Andrew ()
escribió:
> Hi again
>
> One extra question here: we have the AMF connection working fine now in
> Debug mode, but in Release mode the minifier is changing the property names
> of our JavaScript (compiled from ActionScript), but these are not being
> reflected in the objects that are deserialised.
>
> So for example, we are receiving an ArrayCollection, and accessing one
> element's property directly e.g.:
> var results : ArrayCollection = resultEvt.result as ArrayCollection;
> for (var i : uint = 0; i < results.length; i++)
> {
> var resultCode : String = results[i].outputArray.source[0].RESULT_CODE;
> ...
>
> There are a couple of things going on:
> (a) each element in the main ArrayCollection has an "outputArray" property
> which is itself an ArrayCollection. We could cast it into an
> ArrayCollection variable I guess, but instead have just added "source" so
> that the JavaScript doesn't try adding the [] operator to the
> ArrayCollection object directly...
> (b) the contents of this ArrayCollection, in this particular case, is a
> simple object {RESULT_CODE: "OK"} - which I can see in the console when we
> add some trace. The js-debug file has the same structure as the
> ActionScript; but the js-release file has a mapping at the start
> "nc='RESULT_CODE'" and then accesses the data with "
> a.L(c).outputData.source[0].tP" (and that's even weirder as why is it 'tP'
> rather than 'nc'?!)
>
>
> I guess the questions I have are:
>
> 1) Is there a way to prevent the Google closure compiler from minifying a
> particular property name/string?
> or
> 2) Are we going to have to just declare classes for all of these and do a
> typecast e.g. along the lines of:
> class ResultCode { [Bindable]public var RESULT_CODE; }
> and then
> var resultCodeObj : ResultCode = results[i].outputArray.source[0];
> var resultCode : String = resultCodeObj.RESULT_CODE;
>
>
> thanks
>
>Andrew
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
>
>
Re: AMF and class aliases
Hi again
One extra question here: we have the AMF connection working fine now in Debug
mode, but in Release mode the minifier is changing the property names of our
JavaScript (compiled from ActionScript), but these are not being reflected in
the objects that are deserialised.
So for example, we are receiving an ArrayCollection, and accessing one
element's property directly e.g.:
var results : ArrayCollection = resultEvt.result as ArrayCollection;
for (var i : uint = 0; i < results.length; i++)
{
var resultCode : String = results[i].outputArray.source[0].RESULT_CODE;
...
There are a couple of things going on:
(a) each element in the main ArrayCollection has an "outputArray" property
which is itself an ArrayCollection. We could cast it into an ArrayCollection
variable I guess, but instead have just added "source" so that the JavaScript
doesn't try adding the [] operator to the ArrayCollection object directly...
(b) the contents of this ArrayCollection, in this particular case, is a simple
object {RESULT_CODE: "OK"} - which I can see in the console when we add some
trace. The js-debug file has the same structure as the ActionScript; but the
js-release file has a mapping at the start "nc='RESULT_CODE'" and then accesses
the data with " a.L(c).outputData.source[0].tP" (and that's even weirder as why
is it 'tP' rather than 'nc'?!)
I guess the questions I have are:
1) Is there a way to prevent the Google closure compiler from minifying a
particular property name/string?
or
2) Are we going to have to just declare classes for all of these and do a
typecast e.g. along the lines of:
class ResultCode { [Bindable]public var RESULT_CODE; }
and then
var resultCodeObj : ResultCode = results[i].outputArray.source[0];
var resultCode : String = resultCodeObj.RESULT_CODE;
thanks
Andrew
-Original Message-
From: Greg Dove
Sent: 15 July 2019 21:40
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases
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://clicktime.symantec.com/32sUM74kfapE27MaABaGjUj7Vc?u=https%3A%2
> F%2Fapache.github.io%2Froyale-docs%2Fcreate-an-application%2Foptimizat
> ions%2Fdoc-comment-directives.html%23royalesuppresspublicvarwarning
>
> 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&g
Re: AMF and class aliases
Thanks Carlos & Greg, we'll take a look..
-Original Message-
From: Greg Dove
Sent: 15 July 2019 21:40
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases
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://clicktime.symantec.com/32sUM74kfapE27MaABaGjUj7Vc?u=https%3A%2
> F%2Fapache.github.io%2Froyale-docs%2Fcreate-an-application%2Foptimizat
> ions%2Fdoc-comment-directives.html%23royalesuppresspublicvarwarning
>
> 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.
>
Re: AMF and class aliases
lex 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, states....but 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
Re: AMF and class aliases
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-
> &
Re: AMF and class aliases
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 wor
RE: AMF and class aliases
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-
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,
> > 'but I can't see anywhere that this list is accessed/used.'
> >
> > I think you need ClassAliasBead on your Application level, which
> > will process all the definitions.
> >
> >
> >
> >
> >
> >
> > On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew
> >
> > wrote:
> >
> > > Hi all
> > >
> > > We're trying to get a connection to work from our Royale-based
> > > code to a LiveCycle back-end, and having to debug why the AMF
> > > message is different between the Flex version and the Royale
> > > version (and trying to work out why the server is rejecting our
> > > initial ping message..)
> > >
> > > One thing that's cropped up is that Flex embeds the name of the
> > > class
> > > - or rather, the alias of this - when it writes the object:
> > > [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
> > >
> > > In Royale, this capability exists in the
> > > AMFBinaryData.writeObjectVariant() method where it's using the
> > > "localTraits", and we have:
Re: AMF and class aliases
Yeah I was heavy touching binding beads long time ago - I did couple of
fixes as well, but at that time I wasn't using so heavy that part. That was
fun ;)
On Fri, Jul 12, 2019, 7:31 PM Carlos Rovira wrote:
> Hi Andrew,
>
> I think the hardest thing when we did our migration was about bindings. I
> think it was great to team with Greg Dove since he was able to detect and
> fix many binding things through our way (I highly recommend others to hire
> Greg, or others here like Josh, Piotr, Yshay, etc... since they know
> perfectly the technology and can fix things on the fly and prioritize work
> and improvements on demand). Some months has past since we migrated and in
> that time more fixes was done, so hopefully you should get less problems
> that we fount in our way.
>
>
>
> El vie., 12 jul. 2019 a las 18:12, Frost, Andrew ( >)
> escribió:
>
> > 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,
> > > > 'but I can't see anywhere that this list is accessed/used.'
> > > >
> > > > I think you need ClassAliasBead on your Application level, which
> > > > will process all the definitions.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew
> > > >
> >
Re: AMF and class aliases
Hi Andrew,
I think the hardest thing when we did our migration was about bindings. I
think it was great to team with Greg Dove since he was able to detect and
fix many binding things through our way (I highly recommend others to hire
Greg, or others here like Josh, Piotr, Yshay, etc... since they know
perfectly the technology and can fix things on the fly and prioritize work
and improvements on demand). Some months has past since we migrated and in
that time more fixes was done, so hopefully you should get less problems
that we fount in our way.
El vie., 12 jul. 2019 a las 18:12, Frost, Andrew ()
escribió:
> 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,
> > > 'but I can't see anywhere that this list is accessed/used.'
> > >
> > > I think you need ClassAliasBead on your Application level, which
> > > will process all the definitions.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew
> > >
> > > wrote:
> > >
> > > > Hi all
> > > >
> > > > We're trying to get a connection to work from our Royale-based
> > > > code to a LiveCycle back-end, and having to debug why the AMF
> > > > message is different between the Flex version and the Royale
> > > > version (and trying to work out why the server is rejecting our
> > > > initial ping message..)
> > > >
> > > > One thing that's cropped up is that Flex embeds the name of the
> > > > class
> > > > - or rather, the alias of this - when it writes the object:
> > > > [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
> > > >
> > > > In Royale, this capabi
Re: AMF and class aliases
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,
> > 'but I can't see anywhere that this list is accessed/used.'
> >
> > I think you need ClassAliasBead on your Application level, which
> > will process all the definitions.
> >
> >
> >
> >
> >
> >
> > On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew
> >
> > wrote:
> >
> > > Hi all
> > >
> > > We're trying to get a connection to work from our Royale-based
> > > code to a LiveCycle back-end, and having to debug why the AMF
> > > message is different between the Flex version and the Royale
> > > version (and trying to work out why the server is rejecting our
> > > initial ping message..)
> > >
> > > One thing that's cropped up is that Flex embeds the name of the
> > > class
> > > - or rather, the alias of this - when it writes the object:
> > > [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
> > >
> > > In Royale, this capability exists in the
> > > AMFBinaryData.writeObjectVariant() method where it's using the
> > > "localTraits", and we have:
> > > var alias:String = classInfo.alias;//
> > > getAliasByClass(instance.constructor
> > > as Class); //<- @todo possible optimization: registerClassAlias
> > > implementation stores in the classInfo Object, access directly
> > >
> > > The commented-out code does exactly what the new code does, which
> > > is that it accesses the ROYALE_CLASS_INFO structure:
> > > var classInfo:Object =
> > > instance.ROYALE_CLASS_INFO; so to make this work, we've added an
> > > extra section at the end of the ROYALE_CLASS_INFO for the
> > > CommandMessage (in the generated JavaScript, so this is not a proper
> > > solution!):
> > >
> > > mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO =
> > > {
> > > names: [{ name: 'CommandMessage', qName:
> > > 'mx.messa
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,
> > 'but I can't see anywhere that this list is accessed/used.'
> >
> > I think you need ClassAliasBead on your Application level, which will
> > process all the definitions.
> >
> >
> >
> >
> >
> >
> > On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew
> > wrote:
> >
> > > Hi all
> > >
> > > We're trying to get a connection to work from our Royale-based code to
> > > a LiveCycle back-end, and having to debug why the AMF message is
> > > different between the Flex version and the Royale version (and trying
> > > to work out why the server is rejecting our initial ping message..)
> > >
> > > One thing that's cropped up is that Flex embeds the name of the class
> > > - or rather, the alias of this - when it writes the object:
> > > [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
> > >
> > > In Royale, this capability exists in the
> > > AMFBinaryData.writeObjectVariant() method where it's using the
> > > "localTraits", and we have:
> > > var alias:String = classInfo.alias;//
> > > getAliasByClass(instance.constructor
> > > as Class); //<- @todo possible optimization: registerClassAlias
> > > implementation stores in the classInfo Object, access directly
> > >
> > > The commented-out code does exactly what the new code does, which is
> > > that it accesses the ROYALE_CLASS_INFO structure:
> > > var classInfo:Object =
> > > instance.ROYALE_CLASS_INFO; so to make this work, we've added an extra
> > > section at the end of the ROYALE_CLASS_INFO for the CommandMessage (in
> > > the generated JavaScript, so this is not a proper solution!):
> > >
> > > mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO = {
> > > names: [{ name: 'CommandMessage', qName:
> > > 'mx.messaging.messages.CommandMessage', kind: 'class' }] , alias:
> > > 'flex.messaging.messages.CommandMessage' };
> > >
> > >
> > > Interestingly, the compiler looks at all the [RemoteClass(alias="")]
> > > tags, and outputs a list of these in the main application's .js file:
> > > TestBackend.prototype.info = function() {
> > > return { "mixins": [mx.messaging.config.LoaderConfig,
> > > mx.styles.StyleManagerImpl],
> > > "remoteClassAliases": {"mx.messaging.messages.CommandMessage":
> > > "flex.messaging.messages.CommandMessage", "org.apache.royale.net
> > .remoting.messages.ActionMessage":
> > > "flex.messaging.io.amf.ActionMessage", ... etc },
> > > "compiledLocales": ["en_US"]}};
> > >
> > > but I can't see anywhere that this list is accessed/used.
> > >
> > >
> > > So it looks to me like there's a discrepancy between how the compiler
> > > is trying to make this work, and how the framework is expecting it to
> > > be set up by the compiler. I was wondering if anyone know what had
> > > been going on here and whether we should go for one way or another ..
> > > and by preference I think, getting the compiler to add the alias
> > > directly into the ROYALE_CLASS_INFO as that seems to be a better way of
> > doing it I think..?
> > >
> > >
> > > thanks
> > >
> > >Andrew
> > >
> > > p.s. we've had a few other issues with the AMF format, e.g. using
> > > 'unknown length' and having this as +1 rather than -1; plus a single
> > > message was being packaged as an array, whereas Flex/Flash Player
> > > doesn't do that.. I'm wondering whether anyone has a problem if we try
> > > to make the AMF messages generated from a Royale app to be as similar
> > > as possible to how the Flash Player does it..?!
> > >
> > >
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: AMF and class aliases
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,
> 'but I can't see anywhere that this list is accessed/used.'
>
> I think you need ClassAliasBead on your Application level, which will
> process all the definitions.
>
>
>
>
>
>
> On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew
> wrote:
>
> > Hi all
> >
> > We're trying to get a connection to work from our Royale-based code to
> > a LiveCycle back-end, and having to debug why the AMF message is
> > different between the Flex version and the Royale version (and trying
> > to work out why the server is rejecting our initial ping message..)
> >
> > One thing that's cropped up is that Flex embeds the name of the class
> > - or rather, the alias of this - when it writes the object:
> > [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
> >
> > In Royale, this capability exists in the
> > AMFBinaryData.writeObjectVariant() method where it's using the
> > "localTraits", and we have:
> > var alias:String = classInfo.alias;//
> > getAliasByClass(instance.constructor
> > as Class); //<- @todo possible optimization: registerClassAlias
> > implementation stores in the classInfo Object, access directly
> >
> > The commented-out code does exactly what the new code does, which is
> > that it accesses the ROYALE_CLASS_INFO structure:
> > var classInfo:Object =
> > instance.ROYALE_CLASS_INFO; so to make this work, we've added an extra
> > section at the end of the ROYALE_CLASS_INFO for the CommandMessage (in
> > the generated JavaScript, so this is not a proper solution!):
> >
> > mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO = {
> > names: [{ name: 'CommandMessage', qName:
> > 'mx.messaging.messages.CommandMessage', kind: 'class' }] , alias:
> > 'flex.messaging.messages.CommandMessage' };
> >
> >
> > Interestingly, the compiler looks at all the [RemoteClass(alias="")]
> > tags, and outputs a list of these in the main application's .js file:
> > TestBackend.prototype.info = function() {
> > return { "mixins": [mx.messaging.config.LoaderConfig,
> > mx.styles.StyleManagerImpl],
> > "remoteClassAliases": {"mx.messaging.messages.CommandMessage":
> > "flex.messaging.messages.CommandMessage", "org.apache.royale.net
> .remoting.messages.ActionMessage":
> > "flex.messaging.io.amf.ActionMessage", ... etc },
> > "compiledLocales": ["en_US"]}};
> >
> > but I can't see anywhere that this list is accessed/used.
> >
> >
> > So it looks to me like there's a discrepancy between how the compiler
> > is trying to make this work, and how the framework is expecting it to
> > be set up by the compiler. I was wondering if anyone know what had
> > been going on here and whether we should go for one way or another ..
> > and by preference I think, getting the compiler to add the alias
> > directly into the ROYALE_CLASS_INFO as that seems to be a better way of
> doing it I think..?
> >
> >
> > thanks
> >
> >Andrew
> >
> > p.s. we've had a few other issues with the AMF format, e.g. using
> > 'unknown length' and having this as +1 rather than -1; plus a single
> > message was being packaged as an array, whereas Flex/Flash Player
> > doesn't do that.. I'm wondering whether anyone has a problem if we try
> > to make the AMF messages generated from a Royale app to be as similar
> > as possible to how the Flash Player does it..?!
> >
> >
>
Re: AMF and class aliases
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,
'but I can't see anywhere that this list is accessed/used.'
I think you need ClassAliasBead on your Application level, which will process
all the definitions.
On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew
wrote:
> Hi all
>
> We're trying to get a connection to work from our Royale-based code to
> a LiveCycle back-end, and having to debug why the AMF message is
> different between the Flex version and the Royale version (and trying
> to work out why the server is rejecting our initial ping message..)
>
> One thing that's cropped up is that Flex embeds the name of the class
> - or rather, the alias of this - when it writes the object:
> [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
>
> In Royale, this capability exists in the
> AMFBinaryData.writeObjectVariant() method where it's using the
> "localTraits", and we have:
> var alias:String = classInfo.alias;//
> getAliasByClass(instance.constructor
> as Class); //<- @todo possible optimization: registerClassAlias
> implementation stores in the classInfo Object, access directly
>
> The commented-out code does exactly what the new code does, which is
> that it accesses the ROYALE_CLASS_INFO structure:
> var classInfo:Object =
> instance.ROYALE_CLASS_INFO; so to make this work, we've added an extra
> section at the end of the ROYALE_CLASS_INFO for the CommandMessage (in
> the generated JavaScript, so this is not a proper solution!):
>
> mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO = {
> names: [{ name: 'CommandMessage', qName:
> 'mx.messaging.messages.CommandMessage', kind: 'class' }] , alias:
> 'flex.messaging.messages.CommandMessage' };
>
>
> Interestingly, the compiler looks at all the [RemoteClass(alias="")]
> tags, and outputs a list of these in the main application's .js file:
> TestBackend.prototype.info = function() {
> return { "mixins": [mx.messaging.config.LoaderConfig,
> mx.styles.StyleManagerImpl],
> "remoteClassAliases": {"mx.messaging.messages.CommandMessage":
> "flex.messaging.messages.CommandMessage",
> "org.apache.royale.net.remoting.messages.ActionMessage":
> "flex.messaging.io.amf.ActionMessage", ... etc },
> "compiledLocales": ["en_US"]}};
>
> but I can't see anywhere that this list is accessed/used.
>
>
> So it looks to me like there's a discrepancy between how the compiler
> is trying to make this work, and how the framework is expecting it to
> be set up by the compiler. I was wondering if anyone know what had
> been going on here and whether we should go for one way or another ..
> and by preference I think, getting the compiler to add the alias
> directly into the ROYALE_CLASS_INFO as that seems to be a better way of doing
> it I think..?
>
>
> thanks
>
>Andrew
>
> p.s. we've had a few other issues with the AMF format, e.g. using
> 'unknown length' and having this as +1 rather than -1; plus a single
> message was being packaged as an array, whereas Flex/Flash Player
> doesn't do that.. I'm wondering whether anyone has a problem if we try
> to make the AMF messages generated from a Royale app to be as similar
> as possible to how the Flash Player does it..?!
>
>
Re: AMF and class aliases
Hi Andrew,
'but I can't see anywhere that this list is accessed/used.'
I think you need ClassAliasBead on your Application level, which will
process all the definitions.
On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew
wrote:
> Hi all
>
> We're trying to get a connection to work from our Royale-based code to a
> LiveCycle back-end, and having to debug why the AMF message is different
> between the Flex version and the Royale version (and trying to work out why
> the server is rejecting our initial ping message..)
>
> One thing that's cropped up is that Flex embeds the name of the class - or
> rather, the alias of this - when it writes the object:
> [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
>
> In Royale, this capability exists in the
> AMFBinaryData.writeObjectVariant() method where it's using the
> "localTraits", and we have:
> var alias:String = classInfo.alias;// getAliasByClass(instance.constructor
> as Class); //<- @todo possible optimization: registerClassAlias
> implementation stores in the classInfo Object, access directly
>
> The commented-out code does exactly what the new code does, which is that
> it accesses the ROYALE_CLASS_INFO structure:
> var classInfo:Object =
> instance.ROYALE_CLASS_INFO;
> so to make this work, we've added an extra section at the end of the
> ROYALE_CLASS_INFO for the CommandMessage (in the generated JavaScript, so
> this is not a proper solution!):
>
> mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO = {
> names: [{ name: 'CommandMessage', qName:
> 'mx.messaging.messages.CommandMessage', kind: 'class' }] , alias:
> 'flex.messaging.messages.CommandMessage' };
>
>
> Interestingly, the compiler looks at all the [RemoteClass(alias="")] tags,
> and outputs a list of these in the main application's .js file:
> TestBackend.prototype.info = function() {
> return { "mixins": [mx.messaging.config.LoaderConfig,
> mx.styles.StyleManagerImpl],
> "remoteClassAliases": {"mx.messaging.messages.CommandMessage":
> "flex.messaging.messages.CommandMessage",
> "org.apache.royale.net.remoting.messages.ActionMessage":
> "flex.messaging.io.amf.ActionMessage", ... etc },
> "compiledLocales": ["en_US"]}};
>
> but I can't see anywhere that this list is accessed/used.
>
>
> So it looks to me like there's a discrepancy between how the compiler is
> trying to make this work, and how the framework is expecting it to be set
> up by the compiler. I was wondering if anyone know what had been going on
> here and whether we should go for one way or another .. and by preference I
> think, getting the compiler to add the alias directly into the
> ROYALE_CLASS_INFO as that seems to be a better way of doing it I think..?
>
>
> thanks
>
>Andrew
>
> p.s. we've had a few other issues with the AMF format, e.g. using 'unknown
> length' and having this as +1 rather than -1; plus a single message was
> being packaged as an array, whereas Flex/Flash Player doesn't do that.. I'm
> wondering whether anyone has a problem if we try to make the AMF messages
> generated from a Royale app to be as similar as possible to how the Flash
> Player does it..?!
>
>
