> MochiKit has kind of stood out from the pack (a) because it works and
> (b) because the code doesn't suck.
Cool
> Now, I've read three fat books on Javascript written in the past year.
> I've written some pretty extensive stuff using my own crappy libraries
> in Javascript. I've already learned Python, Perl, C, C++, and a few
> others I can't recall right now. I have extensive experience with
> Python and Qt. The other widget libraries--not so much. (I used to do
> Win32 and MFC back in the day... what a joke!) I have way too much
> experience with Perl.
Cocoa is something worth looking at, the way it handles things is awfully
elegant and simple. The only real question is if it should be applied to
the DOM, and the answer to that is I'm not sure.
> I would like to help extend MochiKit. Right now, the biggest weaknesses
> that I see are that it doesn't have a good event handling/signal/AOO
> system. I really like Qt's signal/slot mechanism, and I've already
> implemented a rought draft that works wonderfully but doesn't handle
> DOM objects. Dojo has a neat system that is more AOO--you "listen" to
> function calls, and can either get called before, after, or around the
> call. I like that, but dojo is largely undocumented.
I haven't thought too much about this particular issue, because it's not
something I currently need. I'm very open to ideas, but I'm going to just
jot down some of my thoughts below.
If you implement something that doesn't suck with docs and tests, and are
willing to contribute it under the same license terms of MochiKit, then
I'll take it.
The thing that I don't really like about the Dojo implementation is that
the AOP stuff is so tightly coupled to the rest of what they're doing with
events (like W3C normalization of the event object).
> My idea of the "perfect" system is:
> (1) Simplicity. One way to connect everything, and another way to
> disconnect. (I don't like dojo's AOO system because of this. Too
> complicated.)
> (2) DOM events are handled in the same way. That is:
> connect(MyObj, "signal", obj, "slot")
> connect($('id'), "onclick", obj, "slot")
> should work the same.
MochiKit convention would make these two equivalent (since it's
nonsensical to use a string as a signal source anyway):
connect("id", "onclick", obj, "slot")
connect($("id"), "onclick", obj, "slot")
I would probably also want a three argument form, which would give you a
sort of "raw" interface:
connect(source, "signal", callbackFunction)
the four argument version would then be equivalent to
connect(source, "signal", function () { obj[slot].apply(obj, arguments); });
One thing to consider is that technically "before" and "after" are just
special cases of "around" and they might not be that interesting... and of
course you could implement "around" on your own by simply querying the
current callback and creating a closure with that information. The
question then becomes: should there be a connectAround() that is smart
enough to call slot with two arguments (one argument as the event, the
other as the previous callback) or something of that sort. That's
irrelevant if signal:slot is inherently one-to-many, but would be useful
if it was one-to-one.
A quick glance at this documentation:
http://doc.trolltech.com/4.0/signalsandslots.html
Reminds me of something somewhere between Key-Value Observing and
Notifications in Cocoa:
http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueObserving/index.html
http://developer.apple.com/documentation/Cocoa/Conceptual/Notifications/index.html
> Before I go off and write a bunch of code, I wanted to ask: What are
> you people out there using right now? What is Bob's idea of the perfect
> system? What needs to be done and how can I help? I would rather have
> this thing written sooner rather than later (as in, in the next
> week...) I can't hold off my project manager for perhaps that long but
> not much longer.
I think the concensus is that the event system should mangle the event
object such that it follows the W3C model (Dojo does this well), and on
top of that I'm not sure what else everyone wants.
For the kinds of event handling I've needed to do in the context of
JavaScript, coding raw DOM stuff hasn't been an issue. It just doesn't
seem that common to want the complexity of Dojo-like AOP (I'm guessing you
meant Aspect Oriented, I've never heard AOO before). As long as you can
get/set the handler for a given event, then you could always implement AOP
style stuff on top.
-bob
