Slow response here, but I finally got around to committing this to Subversion (r1533):
http://trac.mochikit.com/changeset/1533 Modified the patch a bit further to account for some additional cases. Also added tests and documentation. @Bob: Can you please review this change? I have the feeling that I've still missed one or two corner cases... Also, the mochikit.com and trac.mochikit.com site seems slow from here... High server load recently? @Amit: Please check that my additional controls doesn't break you use case. Cheers, /Per On Wed, Feb 11, 2009 at 14:52, Amit Mendapara<mendapara.a...@gmail.com> wrote: > > Even better... > > if (this.chain.length == 0 && this._finalizer) { > this._finalized = this._finalizer(res); > } > > This will allow us to finalize the deferred based on some > conditions... > > - Amit > > On Feb 11, 12:52 am, Per Cederberg <cederb...@gmail.com> wrote: >> You mean like this? >> >> setFinalizer: function(cb) { >> this._finalizer = cb; >> } >> >> ... >> >> if (this.chain.length == 0 && this._finalizer) { >> this.finalized = true; >> if (res instanceof Error) { >> this._finalizer(res); >> } >> } >> >> Would that be acceptable to Amit as well? In that case we would add a >> default error handler (called a "finalizer"), which would also be what >> I'm planning to use this for. >> >> Other opinions? >> >> /Per >> >> On Tue, Feb 10, 2009 at 5:48 PM, Bob Ippolito <b...@redivi.com> wrote: >> > Finalizing a Deferred should ensure that no further callback/errbacks >> > are registered and it should attach a default error handler (success >> > should be no-op). The most common problem I've seen with Deferreds is >> > that an error occurs but nobody attached an error handler that far >> > down the stack. In Python they work around this by having a finalizer >> > so that you see the error when the object gets GC'ed, but that's not >> > really possible in JS since you don't have finalizers or weak >> > references. >> >> > On Tue, Feb 10, 2009 at 8:04 AM, Per Cederberg <cederb...@gmail.com> wrote: >> >> >> I think this is a good idea. I needed something similar too, so I >> >> ended up writing an ugly hack that worked most of the time... >> >> >> d.addBoth(function (res) {d.addBoth(finalFunc); return res; }); >> >> >> It adds new callback once the first deferred result drops in, >> >> hopefully after all the other callbacks have been added... >> >> >> But a more formally correct solution would probably be a good idea. >> >> >> Cheers, >> >> >> /Per >> >> >> On Tue, Feb 10, 2009 at 2:30 PM, Amit Mendapara >> >> <mendapara.a...@gmail.com> wrote: >> >>> Hi Per, >> >> >>> I have just started again improving the MochiKit Extensions. While >> >>> creating tests for the Ajax module, I found one problem (not bug, but >> >>> specific to the feature I'm trying to implement). I registered a >> >>> callback which should be fired at the end of all registered callbacks. >> >> >>> I achieved by modifying Async.js with a new method `setFinal` (not >> >>> addFinal as there should be only one finalizer) which gets fired when >> >>> `chain.length == 0`. It's simple. I would we happy if you add one such >> >>> function in MochiKit.Async.Defered... >> >> >>> Regards >> >>> -- >> >>> Amit > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~---
