[mochikit] Re: MochiKit.DOM.getElementsByTagAndClassName performance
On Nov 5, 2009, at 1:32 AM, Fredrik wrote: I created a getElementsByClassName based on this code: http://robertnyman.com/2008/05/27/the-ultimate-getelementsbyclassname-anno-2008/ http://code.google.com/p/getelementsbyclassname/ Pending a full selector integration something like this should be an easy drop-in solution to optimize getElementsByTagAndClassName. (IE really needs some speedup here..) // Fredrik Blomqvist On Nov 5, 7:45 am, Amit Mendapara mendapara.a...@gmail.com wrote: Look at my mochikit-ext project athttps://launchpad.net/mochikit-ext. I have implemented a jQuery style API in MochiKit.Query module (http:// bazaar.launchpad.net/~amit-mendapara/mochikit-ext/trunk/files) which is based on Sizzle.js (http://github.com/jeresig/sizzle). MochiKit.DOM.getElementsByTagAndClassName(div, some-class) can be replaced with MochiKit.Query(div.some-class).get() The Sizzle.js is the fastest selector engine out there. Seehttp://www.hvergi.net/arnar/public/sizzle/speed/#for the speed tests. Actually, it's not. The Acme engine in Dojo beats it by a fair bit on most real-world selectors. It's stand-alone and can be easily imported (like Sizzle). Regards --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Dojo (javascript toolkit)
Not sure why you'd be asking Dojo questions on the MochiKit list, but that said... On Tuesday 11 July 2006 10:05 am, MAria wrote: Hello, I'm trying to do something with dojo, but there is no way! The first question is: I have dojo-0.3.1-ajax version, is it the last one?? Yes. This is just a folder, I haven't installed anything else. And to use it, I just include this line at the top of my .html document: script type=text/javascript src=../DOJO/dojo-0.3.1-ajax/dojo.js /script script type=text/javascript dojo.require(dojo.widget.*); dojo.require(dojo.widget.Toolbar); /script And the problem is, an error occurs, in mozilla console appears: dojo is not defined. It probably means that the dojo.js file isn't actually located at ../DOJO/dojo-0.3.1-ajax/. You'll need to fix that first. Regards -- Alex Russell [EMAIL PROTECTED] A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876 [EMAIL PROTECTED] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 pgp0VhLcwyng3.pgp Description: PGP signature
[mochikit] Re: Practical javascript size limit
Workarounds I've seen for this include gzip systems adding 2K of whitespace before compression and/or setting headers to dissalow caching of gzipped script files on IE. It's almost always worth it since gzip is one of the best ways to reduce page loading latency. Regards On Tuesday 17 January 2006 8:10 pm, Bob Ippolito wrote: On Jan 17, 2006, at 7:49 PM, Bob Ippolito wrote: On Jan 17, 2006, at 7:43 PM, Yehuda Katz wrote: IE doesn't support gzip compression, right? In general, it does not support it correctly for JavaScript. Something about truncating or corrupting the first 5k if it comes out of cache, IIRC. Here's one of the bugs, sounds like it's fixed in IE 6.0 SP1 though. Perhaps you could detect the patch level of IE on the server and gzip conditionally. I didn't find any definitive reference for IE gzip quirks on first google, so there might be other bugs that come into play here. http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496 -bob -- Alex Russell [EMAIL PROTECTED] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 [EMAIL PROTECTED] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
[mochikit] Re: Is MochiKit Production?
On Friday 06 January 2006 4:57 pm, Mike wrote: Bob, Thanks for the quick and elaborate response. Dojo's lack of proper documentation bothers me. I think MochiKit is what I will use. Lack of proper documentation? You mean like: http://manual.dojotoolkit.org/index.html ? Regards -- Alex Russell [EMAIL PROTECTED] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 [EMAIL PROTECTED] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
[mochikit] scoping error in MochiKit.Base.counter()
I think we found a bug while porting Mochi's excellent Deferred class
into Dojo:
The current code in MochiKit.Base.counter contains:
if( arguments.length == 0) {
n = 1;
}
In the common case where it's called to return a new counter, this
creates a global variable with the name n, as can be seen from this
command-line session:
obelisk:~ alex$ js
js function foo(){ if(arguments.length == 0){ n = 1; } }
js foo();
js print(n);
1
Multiple counter instances may then over-write the other's value of n.
This can be fixed by adding the var keyword to the definition of n
so as to make it closure-local.
Regards
PS: it's refreshing to have bugs like this be the only issues you find
in a chunk of JS code. Great work.
--
Alex Russell
[EMAIL PROTECTED] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
[EMAIL PROTECTED] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
[mochikit] Re: scoping error in MochiKit.Base.counter()
On Friday 06 January 2006 12:10 pm, Bob Ippolito wrote: This can be fixed by adding the var keyword to the definition of n so as to make it closure-local. Read the call signature of counter. /me smacks forhead Sorry for the spam folks. Regards -- Alex Russell [EMAIL PROTECTED] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 [EMAIL PROTECTED] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
[mochikit] Re: Signals/AOO/Event handlers
So just to be extra clear about this: this module explicitly requires you to call signal(...) in order to have the event dispatched? Why? This is a significant backslide in end-user ease-of-use from either the Dojo AOP event system or the netWindows sigslot system, and I'm having a hard time seeing what gain there is to requiring the developer to do more work. Regards On Monday 19 December 2005 4:46 pm, Jonathan Gardner wrote: On Friday 16 December 2005 18:45, Bob Ippolito wrote: 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. I've attached a diff (made from 'svn diff') of my stuff. I don't know how google groups will handle it... I don't know if the docs are formatted correctly. My experience with ReST began today. I couldn't build the docs because I couldn't get a good version of docutils. I'm going to start using this 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. -- Alex Russell [EMAIL PROTECTED] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 [EMAIL PROTECTED] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
