Yep, it should be documented, sorry about that.
I can't find the post I was looking for but the short version is that
this deserialization order is by design (I want to reiterate that this
wasn't designed for Flex, it's a long standing Flash Player feature)
because you can't send constructor arguments in AMF instances. The
Player constructs a basic "shell" of the registered type, sets the
properties, then calls the real constructor. From the constructor you
initialize your object by making use of the preset properties (which
came from the server).
The thing to watch out for is if your registered type has constructor
arguments:
public class MyType
{
public var p1:String;
public var p2:Object;
public function MyType(prop1:String, prop2:Object)
{
p1 = prop1; //Deserialization will override this to
undefined!
p2 = prop2; //Deserialization will override this to
undefined!
}
}
The above constructor is dangerous because it doesn't take into account
the player's deserialization order... it should be written like this:
public function MyType(prop1:String, prop2:Object)
{
if (prop1 !== undefined)
{
p1 = prop1;
p2 = prop2;
}
}
Also note that the current player doesn't take getter/setter functions
into account when serializing and deserializing objects... something we
obviously want to address in time for the next release of Flex.
Pete
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On
Behalf Of Joe Berkovitz
Sent: Friday, May 20, 2005 2:12 PM
To: [email protected]
Subject: Re: [flexcoders] deserialization bug: constructor runs AFTER
properties are populated
Peter,
I am sure that it's not a bug if you say it's not, but it should be
clearly documented since it runs counter to the expectations of typical
OOP behavior. I read the Flex docs on object conversion back and forth
several times and I find no mention there.
It is very difficult and awkward to search the Yahoo Groups archives,
but I did actually search my own copy of the mailings which goes back a
few months to when I joined the mailing list. I guess the discussion
must have been prior to that point.
. . . . ...j
Peter Farland wrote:
> Actually, this is not a bug and is by design as per the Flash Player's
> handling of any object deserialization (LSO, AMF, etc).
>
> We discussed this on the list a few months ago... is it easy to search
> the archives for past messages (I admit I've not done it to date).
>
> Pete
>
>
>
> -----Original Message-----
> From: [email protected] [mailto:[EMAIL PROTECTED]
On
> Behalf Of Joe Berkovitz
> Sent: Friday, May 20, 2005 1:53 PM
> To: [email protected]
> Subject: [flexcoders] deserialization bug: constructor runs AFTER
> properties are populated
>
> I just found to my surprise and chagrin that when a typed AMF object
is
> deserialized on the client, the constructor for the object is run
> *after* the object's properties have been populated from the input
> stream. So if one innocently thinks that a constructor ought to be
able
>
> to initialize various properties of the new object, well, this
> initialization clobbers any deserialized values of those properties.
>
> Macromedia support is entering this into their bug DB, but I thought
> this was worth alerting folks to. Obviously there's an easy
workaround,
>
> which is to not do any initialization in constructors (or, if you do,
> make sure that the properties actually are undefined before setting
> them).
>
> . . . . ...j
>
> P.S. note that this is totally different from a prior thread that
> concerned constructors with arguments. That is unsafe because the
args
> will be undefined at deserialization time. Here the issue is the
> *timing* of the constructor call, not its argument values.
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
Yahoo! Groups Links
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
