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