I think I'd prefer to do nothing to the finder if a delete is done through a
viewer. We can still fire the listener so it knows that it has changed, so
the next time they interact with the page we know it has stale data. The
worst case scenario is that the select a deleted row, we call the viewer
again, and they get a error message. Based on the fact they just deleted it,
it would seem an acceptable thing to get an error.
However in the above case if the listener was fired, the go update another
row, cancel and return, it would then refresh, based on the earlier delete
trigger, as canceling an update screen would not fire anything.
Do you see an issue with that approach?
PS: please cc: any jaffa based technical issues to the Jaffa-development
"What people really want is a high-quality system that implements everything
they want, at no cost, right now. Everything else is a trade-off" - Watts
From: Jolly, Gautam
Sent: Thursday, July 21, 2005 6:42 AM
To: Extance, Paul
Subject: update/delete buttons to the related-object in the Viewer pattern
Many usecases require update/delete buttons on the related-object in the
Viewer pattern. Currently we provide a view button only. If you got no
objections, then I'll make the enhancement to the pattern.. It shouldn't
take more than half day.
Another common requirement in the Viewer component is a delete button for
the main record. We can provide this functionality quite easily, however it
may not be easily possible to refresh the data in the calling finder
component, since it exists on a different browser. We can however return a
JSP which'll invoke a refresh action on the parent browser.. but the
implications could be unpredictable if they've moved on from the finder
component to some other component in the other browser. Any thoughts?