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 <carlosrov...@apache.org>
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 (<greg.d...@gmail.com>)
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
> <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..?!
> > >
> > >
> >
>
--
Carlos Rovira
https://clicktime.symantec.com/36g8TU72UowarYTy1s68wYX7Vc?u=http%3A%2F%2Fabout.me%2Fcarlosrovira
