Also, before I forget:
If your legacy flex app includes [Transient] metadata anywhere, don't
forget to include that in the keep-as3-metadata as part of the
configuration for your royale app version as well.
AMFBinaryData will ignore those members with Transient metadata in the amf
serialization, as it does for ByteArray in swf.
On Tue, Jul 16, 2019 at 8:25 AM Greg Dove <greg.d...@gmail.com> wrote:
> Hi Andrew, to answer specifically about:
> > - 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..?
>
> It sounds to me like the issue here is that you are only creating public
> getters. This won't work (in swf or javascript) because AMF serialization
> requires matching public getter/setter pairs for the member to be included
> in the serialized amf representation of the class instance.
>
> You have a few options here:
> 1. If you are confident of the use of the (presumably VO ?) classes
> everywhere, you can suppress those warnings [1] (feel free to improve that
> documentation if you want, as it is preliminary)
> 2. If you want bindable classes, the easiest thing is to mark the class
> with [Bindable] metadata (note that this is 'easy' but because of the
> bindable support will create more code, and run slightly slower than (3)
> below.
> 3. You can manually create getter/setter support for each of the public
> vars.
>
> As another thing, if you ever want to test amf serialization, you can do
> that in the same way you do things with ByteArray in swf.
> var ba:AMFBinaryData = new AMFBinaryData();
> var instance:Object = {}; // try other things here, myVO etc )
> trace(instance); // inspect in browser console
> ba.writeObject(instance);
> ba.position = 0;
> instance = ba.readObject();
> trace(instance); // inspect in browser console
> The above should perform the same type of deep-clone that you get when
> you do it in swf (so long as all the class aliases are defined for the
> instance's object tree when it is not a plain 'Object' like above)
>
> 1.
> https://apache.github.io/royale-docs/create-an-application/optimizations/doc-comment-directives.html#royalesuppresspublicvarwarning
>
> On Tue, Jul 16, 2019 at 2:45 AM Carlos Rovira <carlosrov...@apache.org>
> wrote:
>
>> Hi Andrew,
>>
>> El lun., 15 jul. 2019 a las 16:18, Frost, Andrew (<
>> andrew.fr...@harman.com>)
>> 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 <aha...@adobe.com.INVALID>
>> > Sent: 15 July 2019 05:39
>> > To: dev@royale.apache.org
>> > 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" <andrew.fr...@harman.com> 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 <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/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
>>
>
