> 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....
I second the motion. A while ago I tried the approach of creating and
registering a DataObject in my page's setup, but I never could get it to
work completely right. If the user changed his mind and back-buttoned to a
previous page, it left an uncommitted object in the DataContext. I think
the Refresh button wasn't too kind either. I finally gave up on that
approach.
----- Original Message -----
From: "Robert Zeigler" <rdzeigl...arizona.edu>
To: <cayenne-use..bjectstyle.org>
Sent: Monday, April 04, 2005 12:04 PM
Subject: Re: DataObject becomes hollow when passed through a tapestry
DirectLink
> 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 - 13:04:00 EDT