I've noticed that for () in ... object keys are listed a completely
different order for flash and dhtml. Anything that's depending on
hashtable ordering like this is likely to break.
This could be the root cause of a lot of problems!
It seems like earlySetters needs prioritization. Perhaps it should
become an array?
-Max
Henry Minsky wrote:
I put a print statement in the early setters handling in applyArgs, and
they
execute in a different order in trunk vs legals.
That seems to be the cause of the bug where the replicator gets replaced by
the original view. The list of earlysetters is
var earlySetters ={
name : true ,
id : true ,
$events : true ,
$delegates : true ,
$classrootdepth : true ,
$datapath : true
};
So the question is are there any other subtle bugs due to interactions from
the order these things get executed?
trunk:
early setter name entry [VIEW]
early setter $datapath {attrs: [object Object], name: LzDatapath}
early setter name entry [REPLICATOR]
early setter id «undefined»
legals:
early setter $datapath {attrs: [object Object], name: datapath}
early setter name entry [ REPLICATOR ]
early setter id «undefined»
early setter name entry [ VIEW ]
WARNING: Redefining #outer.entry from «LzReplicationManager#3#2|
ReplicationManager in LzView name: outer id: outer » to «LzView#5#4»
