On Mon, Feb 7, 2011 at 10:20 AM, MRoderick <[email protected]> wrote: > On Feb 4, 1:16 pm, Diego Perini <[email protected]> wrote: >> >> Using a "setTimeout()" for a pubsub implementation will work most of >> the time if the requirements are not too complex. > > I agree, and because of this, my implementation allows for both > styles. > > Clearly, it could do with better documentation :-) > >> However using real event dispatching instead is better and will yield >> an easier debugging environment for developers. > > How would you go about using event dispatching without using the DOM? >
I don't think it is possible possible to dispatch events without using the DOM in the browser ! Still relying on DOM events (maybe on disconnected nodes) gives some real advantage for "pubsub" in the browser. I believe I found an optimal way to spawn new execution contexts through DOM events with almost no impact on performances. Obviously if you are developing for "headless" systems this is not the solution for that environment. > I agree that with async anonymous passing of messages, debugging > without modifying any code is damn near impossible. In fact by using events the callback are not shielded behind a try/catch block, so the errors maintain their precedence and (as in your "pubsub" but not others) the processing cannot be interrupted by errors thrown in other execution contexts. For example I see this useful when having independent widgets in the same page. Errors form any widget will not affect other widgets and will not prevent their finalization. > But, anyone able to build loosely coupled systems with pubsub and > javascript, should be able to reach into the pubsub module and add > debugging code. > If that is too difficult, then I would advise against using pubsub > messaging at all. > > Pubsub has always been an unwieldy beast, and should only be applied > when it's actually needed, and should NOT be the first tool we reach > for. In my case this "pubsub" implementation is part of a bigger event library were other tools are already available. It is a complimentary add-on and I will probably make it an external addition when finished/debugged so the user can load it only if necessary. > Once we do choose to use it, we should understand the consequences of > it. > I've tried to highlight some of the issues, one might encounter, and > have tried to fix some of them. > I also have a blog post on the horizon, that compares different > options of notifications, hopefully that can also adress some of the > issues mentioned in this thread :) > > /Morgan > Look forward for the blog about this or for other info on the subject. -- Diego > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
