Here's a little plugin I wrote the other night for JQuery to implement a simple subscriber/publisher for arbitrary Javascript events http://github.com/weeksie/jquery_broadcaster
So you can do stuff like this:
$("#listeningelement").register("new_message", function(, data) { $(this).html(data); });
$.get("/url", { success: function(data) { $.broadcast("new_message", data); } });
So if you have a buttload of elements on a page that need to be updated when an Ajax call (or other event) returns you can handle them nice and seamlessly. And stuff.
I can't think of any slimmer way to do this. No other method allows you to bind individual elements to a single event type with a custom handler on each. This would be handy on an app with multiple changes across the ui with a single data model change. It allows for complete decoupling of a model change in ajax, which is pretty nifty.
Nice and tidy.
:grumpy:
Thanks 
It struck me as odd that there weren't any other libs around for that. I'm sure I'm missing something but this seemed like a nice and tight little implementation anyway so I figured I'd share (or at least get pointed in the direction of the standard method for doing this).
well $.event.trigger should work, since its global, but then, it's global. It's also jquery internal and not documented for us to use. So it might break? :P
$('#test1').bind('new_message', function(){ alert("ok1"); });
$('#test2').bind('new_message', function(){ alert("ok2"); });
$.get("/url", { success: function(data) { $.event.trigger('new_message', data); }});
I take that back, you also need to populate event with the variables you want to pass to the handler, so the example wouldn't work. You can only pass trigger a single param. :P
Yeah, it seems like I tried that route first but it wouldn't work for some reason.
I can only get it to work if i set up a document level container for the data. But then I don't know when to destroy it cause who knows who is listening and may still need it?
your method should be part of jquery. it makes beautiful sense. 
I wish I understood anything you two sexy beasts were saying.
I think they are talking about setting up listeners, or something... I would be interested in there thoughts on Pimm's HSL library, I believe being haXe it can be applied in javascript but don't really follow if its relvent to the above, but I am thinking about using it in haXe/as3 in the future, I am sure it is heavier but sometimes in software engineering you have to work with more abstract concepts to manage complexity and develop faster, I don't know maybe my belief in haXe is unfounded.
svn:http://hxhsl.googlecode.com/svn/branches/draft2/library/ previous docs:http://code.google.com/p/hxhsl/wiki/PrefaceAndIntroduction
Originally posted by: JLM I think they are talking about setting up listeners, or something...
Yes.
. . . it is heavier but sometimes in software engineering you have to work with more abstract concepts to manage complexity and develop faster
No.
Most of the time when you have something that is fascinatingly complex it can be done simpler. Do it that way.
Man, where was this 6 months ago! This could have saved me so much time on a super ajaxifidian contest page thing I built. ( i suck with the javascripts)
I've been playing around with webhooks the last few days and i think i can see myself making use of this.
Let me know if you have any problems with it 
Hey thanks for adding a license. makes it simpler to use here.
Sweet. :thumbsup:
Only problem I can see is the possibility of event name duplication -- potentially a problem if you were integrating, say, an external library that happened to use the same listener/broadcaster technique. Argues for namespacing your event names.
Good call, I added namespacing and some tests 
Hm, that sounds oddly useful.

Hmm..just tested it and I get an error when an event is broadcast that has no listeners (because $._subscribers[evt] is not defined).
Also, how do I set the namespace per event? So let's say I have two libraries, each broadcasting a 'save' message. I want to register a listener for the first library but not the second. So I need to specify the namespace when calling register(). Then I also need to set the namespace when calling broadcast(), so that only listeners to that namespace are triggered.
It might be simpler to forget explicit broadcaster functionality and just suggest that developers prepend the message name with a namespace (e.g. lib_1.save).
Apologies if I've missed something obvious.
Good catch with the bug there, I'll add a test case and a bugfix this afternoon 
Regarding namespacing, I just added that so it wouldn't conflict with other libraries or built in events. If you're registering your own you'll still want to namespace them manually.
Yeah, I pushed that fix up, yo.
I am trying to wrap my head around using a static like this.
I think you want:
(function($) {
$.extend ({ BroadCaster:{ namespace:"com.twelvestone" } });
...
I dunno if this even works. I am just trying to understand why we'd need to use extend instead of plopping something right on jquery.
?
anyways. e if plopping objects directly on $ isn't good.
$._GET = {};
You're totally right regarding the extend thing. I was just being retarded 
But in your knowledge, do you understand why this is best practice?
Like is jquery doing anything smart under the covers in terms of memory or garbage collection or?
I was half thinking about making a config function but then decided afterward that it made sense to just stick the namespace variable in a hash on jQuery. If it was a config function and I had more than one option it would have made sense to use the extend function so I could leave sensible defaults . . . Basically I was halfway through a thought and then scrapped it but forgot to clean up after myself 
So yeah, long story short there's no whackness at all around sticking something right onto jQuery in the context that you're doing it.
Hey Stinky...
On a tangential note, I notice you've specified the code as dual-licensed (MIT and GPL) and was wondering why. I've noticed other projects do this, and don't really understand the reasoning, since it doesn't seem to be to do with commercial/non-commercial usage.