RE: DataObject becomes hollow when passed through a tapestry DirectLink

From: Cris Daniluk (cris.danilu..laraview.com)
Date: Mon Apr 04 2005 - 17:14:26 EDT

  • Next message: Robert Zeigler: "Re: DataObject becomes hollow when passed through a tapestry DirectLink"

    > 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