Andy/Blair,
The time has finally come for me to make STB changes to something that uses an STB proxy. It appears that I've solved the problem, but, it was easier than I expected, and I'd very much appreciate your reading the following and flagging anything that sounds like a possible problem in my approach. A particular STB-proxied class needs to add a couple of instance variables. Forgetting the class itself for the moment, my instinct is to bump the version number on the proxy class, add accessor methods, etc., and write STB converter methods for it, adding default or computed values for the instance variables, or at least inserting nils to signal that they need to be computed later. Somewhere in there, it's necessary to tweak either a factory method or the "real" class' #stbSaveOn: to save new stuff in the modified proxy. Then there's the problem of using the new aspects in the proxy, whether inserted by the STB conversion methods or placed there directly by a "modern" instance to fixup a working instance of the class. The class itself changes too (of course), to use the new instance variables. With that done, when an old STB file containing a (proxied) instance of the class, the proxy itself is actually in-filed, and then sent #stbFixup:at: to recreate the proxied object. Prior to #stbFixup:at:, the binary filer realizes the proxy class has changed STB version, and first converts the proxy it read from the file. Having done all of that, I'm able to read old instances of the class. Since instances of the "real" class are not directly serialized, they appear not to require any special attention other than the changes I'd have made without concern for STB versioning. Am I missing something? Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Bill
You wrote in message news:9aguih$2e2$[hidden email]... > > The time has finally come for me to make STB changes to something that uses > an STB proxy. It appears that I've solved the problem, but, it was easier > than I expected, and I'd very much appreciate your reading the following and > flagging anything that sounds like a possible problem in my approach. > ... A similar issue exists with Views, which are binary filed as STBViewProxy objects. You may remember that prior to 4.0 upgrading these was a pain because there was only a proxy version number and the particular View class did not get involved in the upgrade. Therefore one had to modify a system method (STBViewProxy>>stbConvertFrom:) to effect the conversion, and also STBViewProxy>>stbConvertFrom: had to switch-on-type (aaarrrggh!). STBViewProxy/View now employ a new approach where a version number is also held in the proxy itself, with this being the stbVersion of the view class that was saved. This is done from STBViewProxy>>stbFixup:at:, which sends a #stbConvertProxy: message to the View class if a conversion is needed. STBViewProxy delegates conversions of the proxy off to the View class if that version does not match the View class' current stbVersion. Of course STBViewProxy had to have a version instance variable added to support this, so its own stbVersion had to be bumped and a one-off conversion written for that. I'm afraid I didn't really understand all of the rest of your posting, but I think the simple pattern used by STBViewProxy/View is applicable to all STB proxies. Regards Blair |
Blair,
> STBViewProxy/View now employ a new approach where a version number is also > held in the proxy itself, with this being the stbVersion of the view class > that was saved. This is done from STBViewProxy>>stbFixup:at:, which sends a > #stbConvertProxy: message to the View class if a conversion is needed. > STBViewProxy delegates conversions of the proxy off to the View class if > that version does not match the View class' current stbVersion. Of course > STBViewProxy had to have a version instance variable added to support this, > so its own stbVersion had to be bumped and a one-off conversion written for > that. > > I'm afraid I didn't really understand all of the rest of your posting, but I > think the simple pattern used by STBViewProxy/View is applicable to all STB > proxies. The idea is to simply version the proxy instead of the object. Every time the "real" class changes layout, the proxy does too, and the normal STB conversion mechanism seems to work as one would hope. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Bill
You wrote in message news:9ahmr5$53rdf$[hidden email]... > > The idea is to simply version the proxy instead of the object. Every time > the "real" class changes layout, the proxy does too, and the normal STB > conversion mechanism seems to work as one would hope. Yes that is fine as long as there is a one-to-one mapping between your proxy classes and your actual classes. In the case of the View hierarchy that was very much not the case, and hence it was not a sufficiently flexible solution. If you should later find that your 1:1 becomes 1:M, and you want to independently version the actual classes, then at that point you can bump the proxy version for a last time and add a version instance variable to hold the actual class STB version. Regards Blair |
Blair,
> Yes that is fine as long as there is a one-to-one mapping between your proxy > classes and your actual classes. In the case of the View hierarchy that was > very much not the case, and hence it was not a sufficiently flexible > solution. If you should later find that your 1:1 becomes 1:M, and you want > to independently version the actual classes, then at that point you can bump > the proxy version for a last time and add a version instance variable to > hold the actual class STB version. Got it. The 1:1 approach should be fine for this situation; but, the 1:M solution is nice to keep in mind. Thanks!! Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Free forum by Nabble | Edit this page |