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