Yeah I was heavy touching binding beads long time ago - I did couple of fixes as well, but at that time I wasn't using so heavy that part. That was fun ;)
On Fri, Jul 12, 2019, 7:31 PM Carlos Rovira <[email protected]> wrote: > Hi Andrew, > > I think the hardest thing when we did our migration was about bindings. I > think it was great to team with Greg Dove since he was able to detect and > fix many binding things through our way (I highly recommend others to hire > Greg, or others here like Josh, Piotr, Yshay, etc... since they know > perfectly the technology and can fix things on the fly and prioritize work > and improvements on demand). Some months has past since we migrated and in > that time more fixes was done, so hopefully you should get less problems > that we fount in our way. > > > > El vie., 12 jul. 2019 a las 18:12, Frost, Andrew (<[email protected] > >) > escribió: > > > 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/36g8TU72UowarYTy1s68wYX7Vc?u=http%3A%2F%2Fabout.me%2Fcarlosrovira > > > > > -- > Carlos Rovira > http://about.me/carlosrovira >
