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 <[email protected]>
Sent: 15 July 2019 05:39
To: [email protected]
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" <[email protected]> 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 <[email protected]>
Sent: 12 July 2019 11:45
To: [email protected]
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 (<[email protected]>)
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
> <[email protected]>
> 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 <[email protected]>
> > Sent: 11 July 2019 23:27
> > To: [email protected]
> > 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
> > <[email protected]>
> > 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/37NTKRvY4SihEaeQcuw62t87Vc?u=https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Fabout.me%252Fcarlosrovira%26data%3D02%257C01%257Caharui%2540adobe.com%257C2d0cfe4c710640c1bd1308d706e3cbea%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C1%257C636985447764038851%26sdata%3Dt%252F7sthDzZx5FAxa5RdA0T6MXAl4SQcGoRg8iKvCTsY4%253D%26reserved%3D0
