If you're not yet familiar with MiddleKit, you can skip this update.
If you write code with MiddleKit, please read:
1. There is no more "Store" module level variable in ObjectStore that
points to the first store ever created in your process (but not the
second, third, etc.)
2. There is no more "store" argument to be passed to your middle
objects' __init__()s. As usual, when you want an object to go into the
store do this:
3. When a MiddleKit model is loaded, the Python classes for it must be
available. That's the normal mode of operation and most users won't
think about this much. But if you ever need the MK model to be loaded
when the Python classes aren't around (like MK's own Generate.py does),
pass "havePythonClasses=0" to the model constructor. This will be rare.
4. Some test suite clean up that probably only I care about. :-)
1. You can now have 2 WebKit contexts that use different MiddleKit
models and stores. That problem is what drove these changes.
Previously, the second context would be ruined such that it couldn't be
used because its objects would think they belonged to the first store.
2. Less confusion about the API. The ObjectStore.Store and the "store"
arg to __init__() were ill conceived ideas. Please forget them.
1. If you immediately ask objects for their obj.store() after creating
them your app will probably break:
user = User()
store = user.store()
# do something with store
This used to return the first store ever created (pointed to by
ObjectStore.Store), but now will return None. As a developer, you need
to track your store(s). If you always have just one in your process,
then feel free to refer to it with a module level variable.
2. If you use self.store() in an override of initFromRow(), for similar
reasons. However, I will be fixing this one as initFromRow(row) should
really be readStoreData(store, row) anyway.
I think few users will experience breakage or have to change how they
think about MiddleKit. As always, ask questions if you have them.