Why does this work???

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Why does this work???

Richard Eng
I have a silly question...

I noticed that when I accidentally coded the following, it works...

session beginUnitOfWork.
anItem := session readOneOf: GRHistoryItem where: [...].
self call: (GROrderEditor new item: anItem).
session commitUnitOfWork.

...and in #GROrderEditor, I have a form that can modify the instance
variables of #item...

...
html textArea rows: 5; on: #notes of: item].
...
html submitButton callback: [self answer: item]; text: 'Save'.
html cancelButton callback: [self answer: nil]; text: 'Cancel'.

Now, if I modify #notes in #item and then click on the submitButton, the
changes are saved to the database.

If I modify #notes and then click on the cancelButton, the changes are NOT
saved.

But what mystifies me is how does the session distinguish between what was
returned in "answer: item" and what was returned in "answer: nil". Note that
I don't assign the result of "self call:" to anything. It seems to me that,
given how I coded the above, ANY modifications to #item (which is passed
from #anItem in the #call:) should always be saved to the database. I'm not
complaining, I'm glad that it works, but I want to understand why.

As I understand the call:/answer: mechanism, the above should NOT work.

Thanks.

Regards,
Richard

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Why does this work???

Lukas Renggli
>  As I understand the call:/answer: mechanism, the above should NOT work.

It has nothing to do with #call:/#answer:

The solution is here:

>  html submitButton callback: [self answer: item]; text: 'Save'.
>  html cancelButton callback: [self answer: nil]; text: 'Cancel'.

The #cancelButton causes all the callbacks in the form to be ignored,
as opposed to the #submitButton. This means none of your form
callbacks will be triggered and your object remains unmodified. And
then in your flow, you store an unmodified object.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Why does this work???

Randal L. Schwartz
>>>>> "Lukas" == Lukas Renggli <[hidden email]> writes:

Lukas> The #cancelButton causes all the callbacks in the form to be ignored,
Lukas> as opposed to the #submitButton. This means none of your form
Lukas> callbacks will be triggered and your object remains unmodified. And
Lukas> then in your flow, you store an unmodified object.

And then glorp notices that you haven't modified anything from its fetch
version of the rows, and stores nothing as well.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside