Thanks Garrett for the link, I'm going to read over that tonight. Plus your explanation was really helpful
Thanks everyone for your input. M. Sent from my iPhone On 4 Jan 2011, at 22:51, Garrett Smith <[email protected]> wrote: > On 1/3/11, Mark McDonnell <[email protected]> wrote: >> I've been reading through Stoyan Stefanov's latest book "JavaScript >> Patterns" and was interested to know who here has used the Observer design >> pattern and could you provide some examples of how you had used it. >> >> >> Here is a link to the example provided in the book: >> https://gist.github.com/763762 >> >> >> At the moment it seems like I have 'a solution looking for a problem'. I can >> see that this pattern could be quite useful with a more advanced JavaScript >> application (being the event driven nature of JavaScript) but I'm not sure >> what scenario I would use or could use such a pattern? >> > > Sure. > > I use the pattern quite a bit. I learned the approach by Dan > Steinman's Dynamic Duo, before I knew the words "Observer" or > "pubsub". > > What Dan did is use a decorator or "wrapper" object: DynLayer. A > DynLayer object's prototype had adapter methods for IE DOM and NS dom, > as well as methods that weren't available on DIV or LAYER elements > (LAYER was an NS4 element that had many problems). > > The DynLayer object itself could be extended to such thins as the > famous draggable "Flower Pot". > > Custom events on the DynLayer were implemented as functions on the > prototype. ECMAScript "[[Put]]" works by adding or changing a property > to the instance, and [[Get]] works by looking on the instance and then > up the prototype chain. > > So the DynLayer prototype woul have something like: > > DynLayer.prototype.onshow = function(){}; > > And then when you called "show()", the onshow would be called. But you > could shadow that "onshow" by adding an "onshow" callback to the > object. > > myLayer.onshow = function() { > alert("I'm shown!"); > }; > > The downside there was that at most one function call would be > hard-wired to the event. > > This is fixable, of course, but with a lot more work. I explained my > own solution to the problem here: > > http://dhtmlkitchen.com/?category=/uncategorized/&date=2008/01/04/&entry=Event-Notification-System > > That explains how I copied the DOM events model for handling errors in > event callbacks. > > I use this for quite a lot of stuff. Most recently, TestReporter want > to know when TestRunner fires "oncomplete" so that it can show the > results. That design may change so that it logs things continually, > allowing for continuous communication. But the point is about > communication here. TestRunner just sends a message "I'm Done". > > comp.object poster H.S. Lahman has also good explanations about "I'm Done". > > [...] >> >> I know this is a bit of an odd request, but really I'm just interested to >> know what 'real world' examples there are using this pattern so I can get a >> better idea (when the time comes) how I can use it. >> > Panel onshow, For Ajax stuff I use it a lot. I create an Ajax request > wrapper and multiple subscribers may subscribe to "complete", > "success", "failure", etc. > -- > Garrett > > -- > 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]
