ssing 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]
his right away so any bugs that testing didn't
uncover should be revealed shortly.
Please rip this to pieces and I'll try to incorporate suggestions ASAP.
--
Jonathan Gardner
[EMAIL PROTECTED]
Index: MochiKit/Signal.js
===
---
On Friday December 23, 2005 04:17, Alex Russell wrote:
> So just to be extra clear about this: this module explicitly requires
> you to call signal(...) in order to have the event dispatched?
>
No, the built-in DOM events will be called as a signal. When you do something
like:
connect($('some
ssing docutils#egg=docutils
error: Couldn't find a setup script
in /tmp/easy_install-b0UEl_/docutils#egg=docutils
Do I need to get an account on berlios or something?
--
Jonathan Gardner
[EMAIL PROTECTED]
Those are two completely different animals though. I am looking for something
like:
isIn(5, [1, 3, 4]) -> false
isIn(3, [1, 3, 4]) -> true
Maybe since JS has two types of equality, there could be an "isIn" and
"isInExact" function.
We could also allow iterators instead of arrays. It would
x27;t have to guess which interface to use. Thoughts?
--
Jonathan Gardner
[EMAIL PROTECTED]
Index: doc/rst/MochiKit/index.rst
===
--- doc/rst/MochiKit/index.rst (revision 490)
+++ doc/rst/MochiKit/index.rst (working copy)
@@ -1
l be called .. right?
>
Yes.
My point was that there is no function named 'flash' and even if there was,
'flash' wouldn't get called.
Signalling isn't like function calling in that regard. You don't expect
'flash' to get executed, and you aren't looking for a return value.
--
Jonathan Gardner
[EMAIL PROTECTED]
and then later:
disconnect(elem, 'onkeyup', someFunc);
I figured one word for the same event should be used consistently.
The reason I liked the old-style was that it was more obvious than the new W3C
style. "onkeyup" sounds like an event, while "keyup" sound like an action.
--
Jonathan Gardner
[EMAIL PROTECTED]
his is really bad if you are
connecting a "toggle" type slot to a signal. You'd expect pressing the button
to call it exactly once, but instead, it gets called many times.
--
Jonathan Gardner
[EMAIL PROTECTED]
Aren't those equivalent?
On Monday 23 January 2006 11:49, Beau Hartshorne wrote:
> I think !== and === instead of cne and ce may work.
>
> On 23-Jan-06, at 11:15 AM, Jonathan Gardner wrote:
>
> > My concern is that slots will get called twice. This is really bad
> &
wo bits of code written by
different people. I would expect that even if one of the actions is broken,
the other still gets called.
--
Jonathan Gardner
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
ion isn't about failing loudly, because both of us are obviously for
it. It is whether we should trap the error, allow the other handlers a chance
at the signal, and then pass the error on later.
--
Jonathan Gardner
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You
succeeds or fails or throws an exception, the other handler
should still get called.
--
Jonathan Gardner
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this
On Wednesday 15 March 2006 14:36, Beau Hartshorne wrote:
> if (errors.length) {
> for (var i = 0; i < errors.length; i++) {
> throw errors[i];
> }
> }
>
> Works for me. Thoughts?
>
Other than the fact that only the first error is thrown...
, it would make sense to raise that without wrapping it to
> save the developer some time debugging it.
>
Ahh. That's a good idea.
--
Jonathan Gardner
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to th
that can be done about that. We could stick
everywhere, but then it would affect the layout negatively by keeping
too much space for the names when there needs to be room for other things. If
you're viewing the page with a really large font, then it would blow up the
table, t
sterSignals before we use
> them? Can't we do this out in connect()? Dojo's implementation seems
> cleaner:
> http://dojotoolkit.org/docs/dojo_event_system.html
>
--
Jonathan Gardner
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You rece
a previously declared (or assigned to) variable. Neither of these
should implicitly create the signal. The signal should be created by some
other process.
--
Jonathan Gardner
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are s
My opinion is that if you want to simulate a click, you're going to
have to create an event that looks like a click and pass that as a
parameter to the signal call.
On Sep 28, 4:05 am, hzlabs <[EMAIL PROTECTED]> wrote:
> Hi Beau,
>
> as i stated in the answer to Jeremy,
> i slightly missunderstoo
If you are willing to share your code, I am sure others would be as
well. It would be nice to have a calendar widget and other common
things, but I don't know that there is a good solution out there as
far as a framework or whatnot. Having developed a largish application
in MochiKit (http://www.am
20 matches
Mail list logo
