Hi James,

I see how my explanation might be unclear.

We have a main form for the agenda and a subform for an item, which is shown 
using Seaside call/answer. The save button of the subform is clicked, which 
adds the item to the underlying agenda model object, but the save button of the 
main form is not clicked by the user. The callback for the main save button 
sends the save message to the agenda object, causing the database to be updated.

So yes, the browser does submit the data on the subform, it's the main form 
component that doesn't receive the save button callback. I realize that this is 
in large part an issue with our design. However, the way object persistence 
seems to work in the image environment plays a large role.


Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com
On 8 Oct 2019, 15:41 +0200, James Foster <smallt...@jgfoster.net>, wrote:
>
> > On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren 
> > <jvalte...@objectguild.com> wrote:
> >
> > We've encountered an issue where a user makes changes to an agenda, but 
> > does not click the Save button. Instead, the user closes the browser or 
> > uses the navigation to go to a different part of the application. When 
> > navigating back to the original agenda, the changes made previously (e.g. 
> > items added) are still being displayed, even though they were never 
> > explicitly saved.
>
> Here is what I don’t understand: how did the change get from the user’s 
> client agent (browser) to the server? If you make a change to a field in a 
> form and then close the browser, who sent the change to the server? If you 
> show the save domain value in a different location, with a 
> dynamically-generated id and name (so it isn’t cached in the browser), or 
> written to the Pharo Transcript, does the value still change? That is, are 
> you sure that the change is in the reflected in the Smalltalk image and not 
> just somehow cached in the browser?
>
> James
>
>

Reply via email to