That makes sense. Is there any way to explicitly pass the surrounding
namespace to __setstate__ ?
The problem is this : my product is really a handle to methods that create or
update files on the local filesystem. Previously I have been building
filenames and paths within the product and then setting them as an attribute of
the object. However it is nicer for the path components to be acquired from
the current folder/container properties so that an object knows it's location
by way of the environment it is in. The reason for this ? I have almost got
my product to the state where is has no persistent attributes, it is instead a
rich set of functions that when instantiated, will use its current environment
to build the datafiles path and name, pick it up or make it, create some
volatile objects, and then allow the user to action one of the many functions
it provides. The reason for this, the volatile objects can be huge, and I
have thousands of these. The only thing that ever persists is the id.
So getting back to the first point, if __setstate__ could somehow access the
sorrounding namespace, then that would make it easier. For now I have a swtich
in the get_filename method, which is called both by __setstate__ and by other
functions in the product. The switch says : try finding these acquired
features, if you can't then use the local copy of where you last thought you
were. Then once the object is instantiated any updates that also call this
function will naturally find the new acquired attributes. This however forces
you to make sure a previous copy of a file still resides in the old location.
matt
Evan Simpson wrote:
From: "Matt" [EMAIL PROTECTED]
I am using __setstate__ to reload files into memory for objects of a
product I
have made. This all works nicely, as is it supposed to. The problem
though is
that the object seems not to know about its environment at that time
__setstate__ is called on the bare object, without any acquisition wrappers.
All you can do at that time is load state and set volatile attributes for
use later.
Cheers,
Evan @ digicool 4-am
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
