Erik Hatcher wrote:
> Regarding using a rich (i.e. not a String or simple type) object as a
> parameter in a DirectLink - this is not really recommended in the
> general sense. The URL is going to be hideous and perhaps even too long
> for some browsers to handle.
>
> A trick within Tapestry, though, would be to use a custom DataSqueezer
> that serialized only the primary key and a unique prefix, and then
> "deserialized" by fetching again using the facility Andrus describes
> below. I have not tried this route - have others?
>
> Erik
>
So, I've tried this approach now. =)
There are three cases that need to be covered.
1) The most trivial: the object has been committed.
Store the pk and the object entity.
2) The object has been created but not registered with a data context.
Wrap the object in a serializable class and use
squeezer.squeeze(wrapper) to utilize SerializableAdaptor to
store the object. There's no data context in this case to begin
with, so no issues with data context "becoming" null.
3) The object has been created and registered with a data context, but
not yet committed. I would suggest that best practices dictate this use
case never be exercised, but reality suggests that it would be wise to
handle this case, anyway. This case, however, seems to be the most
difficult case to handle; I'm still struggling to find a viable
solution. I've toyed with serializing the objectid, deserializing it,
and then using dataContext.registeredObject(ObjectID). It /sorta/
works... you wind up with a correctly registered object, but not quite,
because I seem to lose any attributes that were set before (looking over
the cayenne code, it looks likely that the object is being newly
created). Any thoughts?
Robert Zeigler
This archive was generated by hypermail 2.0.0 : Mon Apr 04 2005 - 12:04:21 EDT