Fred,
On Tue, Apr 12, 2011 at 5:24 AM, Fred Kiefer<address@hidden> wrote:
Greg send a bug report about the XIB loader code in gui not loading some XIB
files. It turned out that the XIB loading code used a random load order for
the objects (enumerating over the keys of a dictionary wont give you the
order in which you added the elements originally), where we need to stick to
the order given in the file to resolve references correctly. While working
on this (locally of course due to the ongoing code freeze), I decided to
change a few more bits in the code. The old code provided a virtual "root"
node for the XIB data, this was wrong and contrary to what our other keyed
unarchiver are doing. I removed that and now provide the actual root
elements of the file. This change will require some adoption in the Gorm XIB
loader. The problem now is that I don't want to risk our current release by
adding this mostly untested changes. But if we commit these changes right
after the release, Gorm wont work with the new XIB loader. Now the great
thing is that the current Gorm XIB loading code never actually worked. Even
with postponing this change things should never get worse than they are
already. Is this strategy acceptable for all?
This should be fine. While there is code in Gorm to load XIBs, I am
planning on disabling this functionality in Gorm for the next release.
Once the changes to fix XIB loading go into the trunk, I will start
fixing the XIB reader plugin in Gorm so that XIBs can, at least, be
read.
There is one other thing I would like to discuss. My changed code requires
that the caller of the XIB decoding (Currently the class GSXibLoader and the
corresponding wrapper class in Gorm) understand the order in which objects
need to be decoded. (First "IBDocument.RootObjects" followed by
"IBDocument.Objects") It would be a lot better to instantiate the objects in
the order they show up in the file and only return these pre-produced
objects when requested to decode them. But this may result in a few
irrelevant objects being decoded and in the decoding happening too early.
My original intention here was to properly implement reference decoding, so
that it works even when the referenced object hasn't already been decoded.
This was never needed when the objects where decoded in the correct order
and I was to lazy to add code that would never get executed. Maybe I will
have to rethink this position.
Theoretically, unarchiving IBDocument.RootObjects should get all of
the objects which are needed to run in a live application since the
archiver should walk down the object graph unarchiving each object
(node) as it goes along. The only reason the code would need to read
IBDocument.Objects is when/if there is an unreferenced object in the
graph someplace which the user added in IB/Gorm, but didn't do
anything with.