> Overall, a bad practice... so, does anyone feel like it
> should be dealt
> with "nicely" in the SqueezeAdaptor implementation, or should I just
> throw an exception?
>
> Approaches that I've tried or thought about so far...
> 1) serialize the objectid; on reserialization, do
> dataContext.registeredObject(ObjectId).
> This doesn't work correctly, because the ObjectID is a
> TempObjectId,
> which means that "equals" is implemented by a strict "are these two
> objects at the same address" comparison.
> 2) thought about storing the ObjectId (or the object?) in a
> map; the key
> would be a randomly generated key, and the url would store the key.
> Reserialization would then fetch the object from the map (and remove
> it). I'm really not fond of this approach... it basically
> starts putting
> user-state information into an application-accessible
> context... I'm not
> real comfortable with that. =) I /could/ store the map in the
> session...
> but a) that requires a valid session and b) it requires
> getting at the
> session. In essence, using this approach, this adaptor would force an
> application to go stateful, something which tapestry is
> already far too
> eager to do. =)
>
We do a slight variation on this - I wrote a simple object holder that lets
you put objects into the session scope and retrieve them by their hashCode
(or the hashCode of the ObjectId in this case). This relies on DataObject
and its ObjectId To Do The Right Thing as far as unique hashCodes go, but it
hasn't been a problem yet. Then, we can just pass the hashCode in string
form via the request scope or however appropriate. I do prefer the hashCode
to a random key, as it adds a more consistent behavior.
Incidentally, I use the same object holder to register lists containing
DataObjects as well, and can pull back a specific DataObject as a
combonation of the list and object hashCodes. It's a cheap way to handle
dropdowns in wizards, etc.
The only downside to this method is the pollution of the session scope. The
reason I used an object holder was to add the ability to clean up via TTLs.
> 3) I've thought about deregistering the object, serializing
> it, and then
> reregistering the object on reserialization. As far as I can
> tell, this
> means that you would lose relationship-information, but
> retain attribute
> information.
I also do this occasionally, for simple objects. It doesn't work whenever
the interface needs to traverse the relationships, but for the simple cases,
its quick, clean, and very understandable. Unfortunately, there are quite a
few cases where you need to maintain those relationships. Usually if its
complex enough, I write a custom domain object that acts as a sort of
adapter to the DataObject. It results in annoying duplication of fields, but
then again, if "O" and "R" fit perfectly together, who would ever even think
about using an object database :) Besides, so far in my experience with
Cayenne, that has only been 1-2 times, and in situations that are so
intimate to the domain problem that the decoupling from the repository is
very desirable.
Just a word of caution.. for existing objects, I generally retrieve the
object back from its persistent state and then copy the properties (either
via reflection or write/readProperty or whatnot). This ensures that the
object stays unique.
> 4) Throw an exception informing the developer of their bad habits. =)
>
I think some solution to this problem, even if it doesn't solve every
possible case, is required. Otherwise, you end up duplicating what
effectively amounts to all of your domain objects, in some manner of
speaking.
Just my 2 cents though... obviously the solution depends, among other
things, very substantially on project-specific stuff like resource
contention, etc., so there is no "right" or "wrong" choice.
Cris
This archive was generated by hypermail 2.0.0 : Mon Apr 04 2005 - 17:14:28 EDT