[Dojo-interest] event.disconnect not working help!
keith at allianceevents.com
Mon Feb 26 22:33:55 MST 2007
Hey Karl, I seemed to have kicked off some steam release but alas code is
still not working.
Per you comments I did read through the dojo book on the event.connect even
went so far as to try kwConnect and kwDisconnect. The current version of
the little test file I wrote at
http://dev.evententerprise.com/user/eventtest.htm does all the write things
but the disconnect calls simply do not disconnect.
So have a look and tell me I am doing wrong!
Karl Tiedt wrote:
> Inline..... and long winded as well, if you didnt read all of Rick's
> you probably can just skip this one.
> On 2/26/07, Rick Morrison <rickmorrison at gmail.com> wrote:
>> From what I've seen, disconnect is completely bork. What happens is that
>> dojo.event.connect() calls a lower-level function (can't remember the
>> right now -- dojo.browser.addEventListener?) .
>> Anyway, that lower-level function then wraps your given event handler
>> function in a function which "fixes" events. It then uses that new
>> function to actually call the browser's addListener flavor. Finally, it
>> returns that wrapped function. If you call disconnect with your original
>> function, nothing will happen.
> Completely irrelevant as you dont even need to worry about the lower level
> functions... and this is disconnect is pretty clearly described here:
> Disconnection and Multi-Connection
> Connecting is one thing, but what about when you want to stop listening?
> dojo.event.disconnect() will stop the listening arrangement between
> functions, but must be pass *exactly the same* arguments as were passed to
> connect in order to ensure successful disconnection. (note:
> was added by me to emphasize the sentence)
> If there's anything that can trip up new users of dojo.event.connect(),
> it's inadvertently connecting multiple times. Very often, a piece of code
> will get called multiple times, and it will contain a
> dojo.event.connect()call. The developer is then surprised when their
> listener function is called
> multiple times for every time the source function fires. What to do?
> I suppose the idea is that the caller is supposed to save that wrapped
>> function, and use THAT function, not your original event handler, to call
>> disconnect. The
>> problem is same old song you usually hear with dojo -- It doesn't SAY
>> that anywhere. The docs imply, perhaps outright state, that you're
>> supposed to use your original function. Now
>> I can't remember exactly what the docs
>> say, because I stopped reading the dojo docs a while ago for this very
>> reason. Bottom line you have to read the source code with dojo.
> See above comment and link.
> I just can't resist a couple of rants, here, because I've personally
>> dozens of hours of time chasing down nit details like this that could
>> been avoided with a few hours of time spent on docs.
>> Note that these are my personal opinion, nothing more, and they're WAY
>> off-topic for the first part of this message (so stop reading now if you
>> want), but as I was writing the reply, I realized that I've been
>> with the same issues over and over with dojo.
> Opinions and criticisms (particularly constructive) is always welcome, we
> want to know what the community's needs (and occasionally wants (as these
> are sometimes too personal -- ie maybe 2 people would use the desired
> offer (and somethings that it typically couldn't).
> One -- dojo is not so great at cleaning up after itself. Mostly this isn't
>> the fault of dojo itself, but misunderstandings of how things work in
>> innards -- this case here is a pretty good example of how dojo sometimes
>> makes it hard to do the Right Thing. This is only an impression, but it
>> seems to me that there is a lot of colloquial knowledge about how to make
>> widget, how to set an event handler, how to start an animation, etc, etc.
>> BUT precious little of how to destroy a widget, how to disconnect an
>> handler, and how to stop an animation. It's like it's great for the quick
>> demo, but the dirty little secret is that you need to dig, and dig hard
>> find how to undo some stuff, clean up and avoid leaks.
>> There are just too many place that seem to require arcane knowledge of
>> dojo's internals to do what ought to be simple things.
> Dojo cleans up everything it can... some browsers (IE from what I recall
> hearing Alex talk about) make cleaning up nearly impossible in some case
> (Alex would be the best person to further explain this)
> Destroying widgets... how hard is myWidget.destroy()? or
> Alot of Dojo is extremely intuitive, and we make it that way for a reason,
> so if you had to guess at something.... it just might work (depending on
> rational your thinking is).
> should I list more blatantly obvious methods of animations? or maybe you
> didnt clearly state what you mean by "start an animation" By the way, I do
> believe all of these were used in the test file for dojo.lfx so no digging
> through the dojo src is really required to find them (I could be wrong but
> I'm fairly certain they were used there).
>> -- there is WAY too much magic going on in some of the source to have it
>> serve as the primary source of docs. The argument mangling in
>> dojo.event.connect is a pretty good example of this.
>> To expect a dojo newbie (I'm not talking about a JS newbie, just a dojo
>> newbie) to wade through dojo.event.connect, or dojo.lang.curry, or any
>> of a dozen others to find out what's going on is to not just invite, but
>> practically to guarantee a case of frustration. Most of us just want to
>> dojo, not live in it. Another example: there are like a dozen functions
>> dojo.html for getting the size of a DOM node with various flavors of
>> borders, or padding, or box model, or whatever. There is nowhere that
>> explains the INTENT of those functions -- when you check with borders,
>> when without?
> There is a good document on the event system (see above link) so "newbies"
> don't have to see how Dojo handles the multiple function definitions for
> the event system... this doesnt make Dojo more difficult, it allows for
> newbies who dont need to know about "around/before/after advices" the
> benefit of not having to worry about that.... how is that a bad thing?
> I can use dojo.event.connect by just knowing
> 1) src function
> 3) target function
> .... where as if Dojo didnt "mangle" these arguments a newbie would have
> learn and know
> 1) advice type
> 2) src Object
> 3) src function
> 4) advice Object
> 5) advice function
> 6) around Object
> 7) around function
> 8) once
> 9) delay
> 10) rate
> 11) advice message
> I could see how not mangling the arguments would be appealing to the
> masses.... (note the very thick sarcasm), I dont even want to know the
> latter and I'm what many consider an "extremely knowledgeable" person when
> it comes to Dojo.
> As for curry, I believe it also has a pretty explanatory test file that is
> And for the dom measurement features in dojo.html.... knowing when to use
> them has absolutely nothing to do with Dojo... thats all Dom Box Model...
> you know how each browser "renders" (lightly used because it likely isnt
> best word to describe it) its padding, margins and borders (ie, which is
> inner most and which is outter most etc etc...) then you know when you
> to use which Dojo functions...
> Now it's great that dojo is being re factored and all, but does anyone
>> find it ironic that the main mechanism for a user from getting from 4.x
>> 9.x is going to be.........a doc? The very thing that dojo hasn't been
>> able to properly pull off yet is going to be the path from one
>> version to another undocumented version?
> Documents are constantly being worked on and one key point of this
> is that the Dojo developers (a large majority of them work for companies
> that either a) provide employees to work on Dojo or b) finance development
> of Dojo via Summer of Code or simply by picking up a developer as a part
> time Contractor to help expedite development of innovative new ideas (IE.
> the Dojo Offline Toolkit)... so with that being said, all these developers
> will have to make the same adjustments that everyone else has to make in
> order to transition from 0.4.2 to 0.9... the downside to that is they get
> do it first, and document it so that their co-workers and all these other
> developers that work for companies that use Dojo as well can do the same
> thing. And all of these people do this (work with Dojo) every day at their
> work, in order to make these things that much easier for you, the user.
> This document is something that has to be done, and done right, and it
> be. Documentation on "how to do X" can be mitigated (for a while,
> not indefinitely) by the support channels we provide, but something of
> magnitude will likely be way too indepth to provide such a band aid to.
> Bottom line: Dojo needs docs. Badly. Really badly. There will be an
>> answer of
>> "we know that". I know you know it. This has been bandied back-and-forth
>> for well nigh a year, and there are still no credible docs.
>> Why are questions like the OP's still coming up month after month?
> Yes we are aware of the need to finish our documentation and the large
> of that hinges on our API tool. The idea I remember hearing that the API
> tool would become was much like that of php.net's function references
> users from the PHP community can provide useful feedback to specific parts
> of the references that could either live on as comments, or if they
> out a flaw in the document be incorporated into the live documentation....
> Great work has been put into making this tool, I believe the only missing
> part is the comment/community contribution part of it... but that may very
> well be solved once the new Dojo website comes online.
> Thanks for taking the time to write up your critique, I hope my reply is
> useful or atleast entertaining reading :)
> -Karl Tiedt
> Dojo FAQ: http://dojo.jot.com/FAQ
> Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
> Dojo-interest at dojotoolkit.org
View this message in context: http://www.nabble.com/event.disconnect-not-working-help%21-tf3295213.html#a9175683
Sent from the Dojo mailing list archive at Nabble.com.
More information about the Dojo-interest