On Friday 16 December 2005 18:45, Bob Ippolito wrote:
>
> 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); });
>
Excellent ideas.
> 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.
>
For events where you might want to do something before the event, Qt usually
specifies an "beforeEvent" and "afterEvent" signals. It's not too common
where someone wants to do something right before an event, but when it is
needed it's simple enough to add the event and document it.
> 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
>
The Key-Value observing stuff is pretty cool, but I think it is overkill (too
much complexity with too little gain in simplicity). For most widgets, there
are only a few attributes worth watching closely. Around these attributes,
there are usually several events that are worth watching. A look at a simple
DOM element like a text input box (which only has one attribute worth
watching) shows that you may want to attach your code onKeyDown or onKeyUp or
onChange or onBlur. Providing more signals is easy, and each are easily
documented.
> 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.
>
I was thinking of replacing the DOM event model. Users of the event system
wouldn't call addEventHandler or anything like that. They would just use
"connect".
> 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.
>
Yes, s/AOO/AOP/g.
One more thing I forgot to mention: The signal-slot system handles circular
signals gracefully. That is, if a signal triggers a slot that triggers a
signal already being triggered, it won't call itself recursively, but it will
call the other slots. It's a bit of a pain to implement, but it's useful.
--
Jonathan Gardner
[EMAIL PROTECTED]
