Thanks all - some useful information there. Yes I think sending as a typed
class would be better but we're not touching the server-side... so we have to
have these workarounds. I can see the benefit of the minification for sure, but
yes when there's an object being created with the property name coming from an
AMF data stream, it then doesn't match the minified version!
Working now anyway, thanks!
Andrew
-----Original Message-----
From: Greg Dove <greg.d...@gmail.com>
Sent: 23 July 2019 05:58
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases
Andrew, you mentioned this was being 'deserialized', so I assume this is coming
from the server as an untyped (plain) Object?
In that case, it will be deserialized with the correct original field name from
the server ('RESULT_CODE' in this case), but there is no typed reference to
that in your local code, so as Alex says the release build is renaming it, and
as suggested there needs to be more 'clues' to prevent the renaming. I believe
Alex knows more about the rules for that than I do.
It seems that you have a way to make it work now, which is probably all you
want.
But for completeness: another option is to send it as a typed class using
public vars (not using any manual-coded getter/setter pair or Bindable).
class ResultCode { public var RESULT_CODE:String; } You could then cast the
result in the same way you mentioned in your first post.
The difference here is that this will also likely rename the field access in
the release build in the same way that you saw with the original problem, but
amf deserialization will support that and it should therefore match up with the
renamed field name used in your release-build local code.
So it's probably an 'in-between' option to consider, for the future.
On Tue, Jul 23, 2019 at 4:11 PM Alex Harui <aha...@adobe.com.invalid> wrote:
> FWIW, AIUI, the property names of plain Objects and public vars will
> be renamed unless a quoted string of that property name is used
> "somewhere" in the JS code.
>
> It might have worked just to use JSON-style:
> {"RESULT_CODE": "OK"}
>
> Creating a class definition causes the compiler to generate an
> Object.defineProperties structure with the property name as a key in
> the object structure, thus preventing the rename.
>
> If you scan the js-debug output for RESULT_CODE, you should see where
> that string showed up and how having a variable "nc" would save bytes,
> but the name to use for a renamable property is independent of that,
> and I think properties are renamed before figuring out whether a local
> variable would further save bytes.
>
> So, that's roughly the answer to #1. For #2, you "should" use classes
> with getter/setters instead of [Bindable] unless you need property
> change detection at runtime in order to get code-completion and compile-time
> checking that you didn't mis-type "RESULTCODE". There is probably a
> trade-off of how many times you'll make mistakes like that vs the time
> to create the classes and the additional time to load the class definitions.
> It should be smaller to use [brackets] than load the classes.
>
> The new IDEs should consider a wizard to help generate those classes.
>
> HTH,
> -Alex
>
>
> On 7/22/19, 2:18 AM, "Frost, Andrew" <andrew.fr...@harman.com> wrote:
>
> Hi again
>
> One extra question here: we have the AMF connection working fine
> now in Debug mode, but in Release mode the minifier is changing the
> property names of our JavaScript (compiled from ActionScript), but
> these are not being reflected in the objects that are deserialised.
>
> So for example, we are receiving an ArrayCollection, and accessing
> one element's property directly e.g.:
> var results : ArrayCollection = resultEvt.result as ArrayCollection;
> for (var i : uint = 0; i < results.length; i++)
> {
> var resultCode : String =
> results[i].outputArray.source[0].RESULT_CODE;
> ...
>
> There are a couple of things going on:
> (a) each element in the main ArrayCollection has an "outputArray"
> property which is itself an ArrayCollection. We could cast it into an
> ArrayCollection variable I guess, but instead have just added "source"
> so that the JavaScript doesn't try adding the [] operator to the
> ArrayCollection object directly...
> (b) the contents of this ArrayCollection, in this particular case,
> is a simple object {RESULT_CODE: "OK"} - which I can see in the
> console when we add some trace. The js-debug file has the same
> structure as the ActionScript; but the js-release file has a mapping
> at the start "nc='RESULT_CODE'" and then accesses the data with "
> a.L(c).outputData.source[0].tP" (and that's even weirder as why is it 'tP'
> rather than 'nc'?!)
>
>
> I guess the questions I have are:
>
> 1) Is there a way to prevent the Google closure compiler from
> minifying a particular property name/string?
> or
> 2) Are we going to have to just declare classes for all of these
> and do a typecast e.g. along the lines of:
> class ResultCode { [Bindable]public var RESULT_CODE; }
> and then
> var resultCodeObj : ResultCode = results[i].outputArray.source[0];
> var resultCode : String = resultCodeObj.RESULT_CODE;
>
>
> thanks
>
> Andrew
>
>
> -----Original Message-----
> From: Greg Dove <greg.d...@gmail.com>
> Sent: 15 July 2019 21:40
> To: dev@royale.apache.org
> Subject: [EXTERNAL] Re: AMF and class aliases
>
> 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://clicktime.symantec.com/39pjYP4z9QAF1fYHKKLwspK7Vc?u=https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%25252%26data%3D02%257C01%257Caharui%2540adobe.com%257C17c4bb9e45d24de093a708d70e857ecf%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636993838861305929%26sdata%3Dr6CJc%252FtuTSqd6OCblx0MG1DScJn3WSgOk%252BFG6U64Rhg%253D%26reserved%3D0
> > F%2Fapache.github.io
> %2Froyale-docs%2Fcreate-an-application%2Foptimizat
> > ions%2Fdoc-comment-directives.html%23royalesuppresspublicvarwarning
> >
> > 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/3PtV9FU4j3b1dgnWV4FZXCY7Vc?u=https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%2525%26data%3D02%257C01%257Caharui%2540adobe.com%257C17c4bb9e45d24de093a708d70e857ecf%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636993838861305929%26sdata%3DOHuavTMyR3ad2YqLXyEqBhzQR5x6Xu0k%252Fw7HTco%252FbnU%253D%26reserved%3D0
> >> 2F%2Fnam04.safelinks.protection.outlook.com
> %2F%3Furl%3Dhttp%253A%252F
> >>
> %252Fabout.me%252Fcarlosrovira%26data%3D02%257C01%257Caharui%2540adob
> >> e.com
> %257C2d0cfe4c710640c1bd1308d706e3cbea%257Cfa7b1b5a7b34438794aed2
> >>
> c178decee1%257C0%257C1%257C636985447764038851%26sdata%3Dt%252F7sthDzZ
> >> x5FAxa5RdA0T6MXAl4SQcGoRg8iKvCTsY4%253D%26reserved%3D0
> >> >
> >> >
> >> >
> >>
> >> --
> >> Carlos Rovira
> >>
> https://clicktime.symantec.com/3NUedw72iBaTBbjJTegR2847Vc?u=https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%25252%26data%3D02%257C01%257Caharui%2540adobe.com%257C17c4bb9e45d24de093a708d70e857ecf%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636993838861305929%26sdata%3D4uQ9TdDVPyIR94QUDduLmv8ma38R3qnY6Ww2PQ%252Beg3o%253D%26reserved%3D0
> >> F%2Fabout.me%2Fcarlosrovira
> >>
> >
>
>
>
