[Seaside] cancel button in canvas

Jim Freeman jmf at tanstaafl.org
Thu Apr 20 12:19:11 UTC 2006


On Thu, Apr 20, 2006 at 09:34:31AM +0200, Lukas Renggli wrote:

Hello, this is my first post to the list... I used Seaside for a
project called FreeRM, which is a bit stalled at the moment, but has
potential and my be restarted for a second round of development... 

I worked on this last year for about four months.  I found Seaside and 
Smalltalk have opened up some new ideas for me.  Thank you to the
Seaside community for your innovative work.

<snip>

> I was not talking about design, only about implementation. I do agree
> that forms should always have a cancel-button, but how the
> cancel-button is implemented is another question ;-)

>From my experience, I would call this a design issue as well.

> Well, I don't know your application. Just to clear with my statement
> and to have something to discuss about, let me introduce the following
> scenario:
> 
> 1. the user fills a form and hits "save"
> 2. the form does not validate and is displayed again with the
> (invalid) data and an error message
> 3. the users decides not to save the form and hits "cancel"
> 
> I don't understand how a cancel-callback could fit into this scenario?
> Maybe you can clarify or give a better example?
> 
> - Without caching: at (1) the form gets submitted with the invalid
> data into the model, there is nothing that the cancel-callback in (3)
> can change about that.
> 
> - With caching: at (1) the form gets submitted into the cache, and in
> (3) there is no need for a cancel-callback because only (2) does
> commit the changes if valid.

I have some experience where at work we have created a custom user
interface technology in Java and we ran across this same design issue
with our dialogs.  In doing research for the problem, I ran across two
concepts that other people have used to address this area: buffered input 
and apply to copy.  What Lukas describes above is buffered input in
the jargon we ran across.

In the buffered input scenario, dialogs capture input as the user
enters it but no model updates occur until the submit/apply/ok
button is pressed.  At that point, the code is supposed to apply a
set of valid changes to the model and close the dialog.  If a user
presses cancel, nothing happens at the model level and there is no
rollback.

In the apply to copy scenario, a dialog will use a copy of the
model object and it will apply updates to the model as users supply
input.  This allows the model to validate the input and update any
cascaded state within the user interface (cross-computed fields,
etc.).  When the user submits the dialog change, the state of the
copy gets applied to the real object through a mechanism appropriate
to the code environment. 

If the data you are working with is complex, I favor the second
approach because I attempt to keep the logic expressed in the domain
layer if it is fundamental to the data being represented.  If the
input is simplistic, then the second approach may be more overhead
than it is worth.

There may be other ways to handle it, but I thought I would share
the two primary means we identified by researching what others had
already suggested.  I suppose using the Command pattern is probably
one approach that has a logical undo or rollback that we did not
focus on.  Obviously, Seaside may be able to offer solutions that
are not found in other lanaguage environments.  In fact, you may 
see some of the above as workarounds for missing functionality.  I
thought I would offer it up to support the "design" angle of the
thread.

Jim



More information about the Seaside mailing list