Hi Andrew, El lun., 15 jul. 2019 a las 16:18, Frost, Andrew (<[email protected]>) 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 <[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 > > > -- Carlos Rovira http://about.me/carlosrovira
