|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
|
|
Defered.setFinalHi 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@... To unsubscribe from this group, send email to mochikit+unsubscribe@... For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~--- Index: MochiKit/Async.js =================================================================== --- MochiKit/Async.js (revision 1525) +++ MochiKit/Async.js (working copy) @@ -136,6 +136,11 @@ return this; }, + setFinal: function(cb) { + this._final = cb; + return this; + }, + _fire: function () { /*** @@ -176,6 +181,11 @@ res = err; } } + + if (chain.length == 0 && this._final) { + res = this._final(res); + } + this.fired = fired; this.results[fired] = res; if (cb && this.paused) { |
|
|
Re: Defered.setFinalI 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.amit@...> 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@... To unsubscribe from this group, send email to mochikit+unsubscribe@... For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Defered.setFinalFinalizing 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 <cederberg@...> 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.amit@...> 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@... To unsubscribe from this group, send email to mochikit+unsubscribe@... For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Defered.setFinalPer,
Your hack won't work with my case as it would mark the deferred as `chained` so consecutive addCallback/addErrback won't work. Considering Bob's suggestion, I modified my patch to ensure no further callback/errbacks can be registered. Regards -- Amit Bob Ippolito 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 <cederberg@...> 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.amit@...> 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@... To unsubscribe from this group, send email to mochikit+unsubscribe@... For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~--- Index: MochiKit/Async.js =================================================================== --- MochiKit/Async.js (revision 1525) +++ MochiKit/Async.js (working copy) @@ -20,6 +20,7 @@ this.canceller = canceller; this.silentlyCancelled = false; this.chained = false; + this.finalized = false; }; MochiKit.Async.Deferred.prototype = { @@ -129,6 +130,9 @@ if (this.chained) { throw new Error("Chained Deferreds can not be re-used"); } + if (this.finalized) { + throw new Error("Finalized Deferreds can not be re-used"); + } this.chain.push([cb, eb]); if (this.fired >= 0) { this._fire(); @@ -136,6 +140,11 @@ return this; }, + setFinal: function(cb) { + this._final = cb; + return this; + }, + _fire: function () { /*** @@ -184,6 +193,10 @@ res.addBoth(cb); res.chained = true; } + if (this.chain.length == 0 && this._final) { + this.finalized = true; + this._final(); + } } }; |
|
|
Re: Defered.setFinalYou 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 <bob@...> 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 <cederberg@...> 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.amit@...> 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@... To unsubscribe from this group, send email to mochikit+unsubscribe@... For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Defered.setFinalIt's not just error handler, it should always be called at the end once result is available and all callbacks/errback (including default errback) are fired. setFinalizer: function(cb) { this._finalizer = cb; } if (this.chain.length == 0 && this._finalizer) { this.finalized = true; this._finalizer(res); } --Amit On Feb 11, 12:52 am, Per Cederberg <cederb...@...> 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...@...> 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...@...> 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...@...> 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@... To unsubscribe from this group, send email to mochikit+unsubscribe@... For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Defered.setFinalEven 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...@...> 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...@...> 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...@...> 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...@...> 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@... To unsubscribe from this group, send email to mochikit+unsubscribe@... For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Defered.setFinalSlow 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.amit@...> 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...@...> 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...@...> 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...@...> 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...@...> 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@... To unsubscribe from this group, send email to mochikit+unsubscribe@... For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Defered.setFinalHi Per, I have just tested the changes with the Ajax extension module and it works as expected. Thanks for considering adding this feature. This would help me creating jQuery compatible Ajax module for Mochikit extensions project. Currently, I'm quite busy with some another work but supposed to come back on MochiKit Extensions soon... Regards -- Amit Mendapara On Jul 20, 2:26 pm, Per Cederberg <cederb...@...> wrote: > 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...@...> 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...@...> 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...@...> 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...@...> 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...@...> 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@... To unsubscribe from this group, send email to mochikit+unsubscribe@... For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Defered.setFinalHello all, On Tue, Feb 10, 2009 at 6:48 PM, Bob Ippolito<bob@...> 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 order to handle this case, we have overwrote the 'callback' method in our subclass of the Deferred class, to add a default Errback that at least logs the error. A similar solution could be probably used also in MochiKit, allowing the user to optionally specify a specific error handler / finalizer. This will allow any further check, as once the Deferred is triggered it is already impossible to add further callback/errback. I will check anyway the fix added to the repository to see how to improve our current extension with the committed fix. Giulio Cesare --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@... To unsubscribe from this group, send email to mochikit+unsubscribe@... For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~--- |
| Free embeddable forum powered by Nabble | Forum Help |