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 (<andrew.fr...@harman.com>)
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 <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
>
--
Carlos Rovira
http://about.me/carlosrovira
