Yep - Matt's diagnosis is correct. Your
OgoPhoneVO constructor might look something like this to make sure it doesn't
override the initial states of the deserialized result
objects:
public function
OgoPhoneVO()
{ if (info === undefined) {
info =
"";
number = ""; telephoneId = null; type = ""; }
} This
is necessary for any VO that is expected to be populated from native Flash
Player object deserialization, e.g. instances of registered classes from
RemoteObject that are encoded using AMF.
It's
unfortunately that an example of this is not in the Flex 1.5 documentation - the
topic will be improved in Flex 2.0.
Note:
While it's taken me a while to come around on this issue, I personally
don't believe this functionality "sucks"... it is a deliberately
designed function of the Flash Player's native object deserialization (be
it from LSOs, AMF, RTMP). It allows you to get access to the remote variables
during object initialization (as you can't send constructor arguments via
AMF).
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Matt Chotin Sent: Wednesday, June 08, 2005 9:12 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] complex Remote Objects Hi
Christophe, I bet the bug is
because you have the constructor doing initial value assignment. Joe
Berkovitz posted a very detailed account of how Flex will screw you up if you do
this in your VOs because the constructor is actually called AFTER all the
variables have been assigned. Pete then gave an explanation as to why we
do this, which I forget. In any case, it sucks. So in your VO
objects make sure that you don’t assign default values to the properties in your
constructor (or if you must put checks in the constructor to make sure the value
hasn’t already been defined). HTH, Matt From: Hi Peter, Yahoo! Groups Links
|
- RE: [flexcoders] complex Remote Objects Peter Farland
- Re: [flexcoders] complex Remote Objects Christoph Guse
- RE: [flexcoders] complex Remote Objects Dirk Eismann
- RE: [flexcoders] complex Remote Objects Abdul Qabiz