AW: Re: cancel button in canvas

Lukas,

seems I am getting things wrong and I can learn an important lesson here.

>As far as I understand the use of a cancel-callback means:
>
>- you directly commit changes from the input-field callbacks to the model.
>
>- you don't validate changes before committing to the model.

That is exactly what I don't want to do: neither validate nor commit to the model, just leave the page without any validation errors or even worse some of my erronous data saved into the model.

My understanding to this point was that registering a cancel callback provides exactly that: the page can be left, no data is validated or committed. Just go out of this dialog and let me do something else.

Under WAHtmlRenderer our application reacted exactly like that. Does your comment imply that we need to change something here? First tests show that this is not the case: everything seems to work as before...

>A cancel-button should never allow any side-effects, and the use of a

Exact. No side-effects wanted.

>cancel-callback cannot grantee that: side-effects do easily happen
>during validation (the form has to be redisplayed again), when picking
>a date from a date-picker (the form is submitted), input-fields are
>serialized trough ajax-actions, etc.

Are you sure about this? My observation in old-style WAHtmlRenderer was that using a cancel-callback can easily avoid all this.

Cheers

Joachim
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Most PC users are pretty used to having the choice between accepting changes they did on a page and to throw away what they did. A cancel button is kind of a logical rollback to my changes on a dialog/page. This has nothing to do with a code smell but with user interfaces and workflows. You might be speaking of design smells and present another idea of what would be a good way to give your user a means of throwing away their last changes to business data combined with a secure feeling of not having done any harm to the system. A cancel button has done a good job in this for quite some years now, at least this is what my experience tells me...

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 ;-)

> Are you sure about this? My observation in old-style WAHtmlRenderer was that using a cancel-callback can easily avoid all this.

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.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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.

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

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi,

I'm returning to Seaside after a brief period of inactivity.

I just tried merging Seaside2.6a3-pmm.65 and Scriptaculous-pmm.71, but the
Scriptaculous examples from the Seaside config page die with:

MessageNotUnderstood: SUJavascript class>>readStream

Last time I checked out Seaside, the bleeding edge versions were fairly
stable.  Is it common to have Monticello versions not work out-of-the-box?

In general it would be helpful to have more instructions about "bleeding
edge development versions" on http://seaside.st, like "load Scriptaculous
and Seaside2.6-a3", and maybe a "blessed" Monticello version.

Jeremy

GPG PUBLIC KEY: 0xA2B36CE5

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Use Seaside2.6a3-lr.59 and Scriptaculous-lr.70, they both work on my
machine. The changes of Philippe to the Seaside package are rather
drastic, are untested and might break code and also sort of break
backward compatibility, I guess we have to rework trough all those
changes.

It would be better to do small changes and not big-bang changes ;-)

Lukas

On 4/23/06, Jeremy Shute <[hidden email]> wrote:

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Oups, re-reading your mail shows me that I missed two points and that
I should try to express myself more clear:

> Use Seaside2.6a3-lr.59 and Scriptaculous-lr.70, they both work on my

1. Jeremy, I guess this has nothing to do with Monticello, it is
obviously a problem of the scriptaculous and/or the seaside-package.

> machine. The changes of Philippe to the Seaside package are rather
> drastic, are untested and might break code and also sort of break
> backward compatibility, I guess we have to rework trough all those
> changes.

2. Philippe, I didn't intend to smash your changes, I really
appreciate your efforts. However it is rather worrying to see 100
methods of critical classes changing all at once, this is simply
impossible to do without introducing bugs and there are no automated
tests to verify the correct behavior. There are a couple of people
always using the latest version for their development, including me,
and they all want the latest features, a stable version and not to
primarily fix bugs but to work on their own projects. I would suggest
that we pair-review all those changes and try to eliminate the
problems as soon as possible, however I cannot contribute before the
end of this week.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sure. I never made any claims about these versions. But somewhere
experimental bleeding edge alpha code has to go. As noone at anytime
made any claims about the stability of a3 (does a mean alpha?) I
thought I put it there.
Scriptaculous-pmm.71 is even marked as experimental.
So if a3 is not the place to put such code, please tell where else to put it.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside