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 <greg.d...@gmail.com>
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 <andrew.fr...@harman.com>
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..?!
>
>
