Andrus Adamchik wrote:
> Actually DataObject serialization mechanism is very efficient, so what you
> see is not a handicap, but a feature... The idea is that unless object is
> modified, there is no need to write its properties, as on deserialization
> it will attach to a DataContext/ObjectStore/underlying cache that will
> provide missing values on demand.
So... I have a question here. =)
From CayenneDataObject (1.2M2, lines 551-553, inside the "readObject"
function) comes the following comment:
// DataContext will be set *IF* the DataContext it came from is also
// deserialized. Setting of DataContext is handled by the DataContext
// itself
Which sounds as though the data context for the object being
deserialized will only be set if the data context is also being
deserialized.
The code and comments in the readObject method of DataContext.java,
suggest that this is the case, as well, and is intended.
Suppose you have a datacontext stored in a user session in a webapp, and
you're using tapestry. You render a a page, and tapestry serializes the
an objects into the form. The data context from which the objects come
is not serialized, and is therefore not /deserialized/, so when the form
is updated and the objects restored, they wind up with a null
dataContext... correct?
So, what is the best solution for this scenario? Should the developer
manually set the datacontext for the dataobject?
Robert
PS: I checked out the tapestry tutorial app; it circumvents this issue
by using persistent page properties.
This archive was generated by hypermail 2.0.0 : Tue Mar 08 2005 - 16:03:26 EST