Re: DataObject becomes hollow when passed through a tapestry DirectLink

From: Robert Zeigler (rdzeigl...arizona.edu)
Date: Mon Apr 04 2005 - 16:53:29 EDT

  • Next message: Cris Daniluk: "RE: DataObject becomes hollow when passed through a tapestry DirectLink"

    Cris Daniluk wrote:
    >>>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.
    >>
    >
    >
    > We had similar problems. To make it worse, it ended up creating a huge
    > coupling between the view and the service layer. This approach only seems
    > worthwhile to me when you have an established persistence layer (ala EJB,
    > etc) in your application.
    >
    > Cris
    >

    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. =)

    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.
    4) Throw an exception informing the developer of their bad habits. =)

    I'm leaning towards either 3 or 4 at the moment...

    Thoughts?

    Robert Zeigler



    This archive was generated by hypermail 2.0.0 : Mon Apr 04 2005 - 16:53:38 EDT