[Seaside] [Issue 553] #isolate: broken - any updates?
Boris Popov, DeepCove Labs (SNN)
boris at deepcovelabs.com
Tue Jul 20 12:21:01 UTC 2010
Can you give us a proto example of the payment processing task you're
talking about please? Here's roughly the version we hav...err...had here
for one of the applications (simplified),
[| ok |
ok := self isolate:
[self call: collect.
self call: (ok ifTrue: [approved] ifFalse: [declined])]
FYI, #whileFalse is there to retry when declined component answers.
DeepCove Labs Ltd.
+1 (604) 689-0322
4th floor, 595 Howe Street
Vancouver, British Columbia
Canada V6C 2T5
PacNet Services (Europe) Ltd.
+353 (0)61 714-360
Shannon Airport House, SFZ
County Clare, Ireland
This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.
From: seaside-bounces at lists.squeakfoundation.org
[mailto:seaside-bounces at lists.squeakfoundation.org] On Behalf Of Julian
Sent: 20 July 2010 09:16
To: Seaside - general discussion
Subject: Re: [Seaside] [Issue 553] #isolate: broken - any updates?
On Tue, Jul 20, 2010 at 8:36 AM, Reza Razavi <razavi at acm.org> wrote:
> At 07:45 20/07/2010, AA wrote:
>> Yes, it would certainly be useful to me.
>> It's a useful (arguably, essential) function: consider the processing
>> of credit card payments, or logging out of a session...
> Hello Julian, all,
> I share the above observations.
> PS: My apologies for the delayed response.
I agree that preventing a user from processing a credit card payment
twice or going "back" into a logged-out session are reasonable
requirements. That's not really the question, though, because
#isolate: is only one of a probably endless variety of possible
solutions to that problem.
For session logout, for example, you could simply unregister the session
or set whatever property was holding the current user to nil.
For the credit card case you could, for example, have a WAIsolatedTask
that only allowed itself to be run once and put the appropriate code in
a subclass of that. (actually... hmm.... that might be a way to
implement #isolate:... need to look into that)
The only reason you might need #isolate: is that you can use it to
*implicitly* protect just *part* of a Task #go method or a callback.
What I'm wondering is how important those two aspects of the solution
are. If only a half dozen out of thousands of users are asking for it,
it's hard to justify classifying it as "essential".
seaside mailing list
seaside at lists.squeakfoundation.org
More information about the seaside