MochiKit Google Group

Google Closure includes MochiKit

fblomqv...@gmail.com (Fredrik) — Thu, 05 Nov 2009 23:54:32 UT

Hi,

Google recently announced their core javascript library - Closure.
[link]

When browsing the code I noticed it uses parts of MochiKit:
[link]
[link]

Re: [mochikit] Re: MochiKit.DOM.getElementsByTagAndClassName performance

a...@dojotoolkit.org (Alex Russell) — Thu, 05 Nov 2009 21:42:41 UT

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

Re: MochiKit.DOM.getElementsByTagAndClassName performance

fblomqv...@gmail.com (Fredrik) — Thu, 05 Nov 2009 09:32:21 UT

I created a getElementsByClassName based on this code:
[link]
[link]

Pending a full selector integration something like this should be an
easy drop-in
solution to optimize getElementsByTagAndClassName.

Re: MochiKit.DOM.getElementsByTagAndClassName performance

mendapara.a...@gmail.com (Amit Mendapara) — Thu, 05 Nov 2009 06:45:39 UT

Look at my mochikit-ext project at [link].
I have implemented a jQuery style API in MochiKit.Query module (http://
bazaar.launchpad.net/~amit-men dapara/mochikit-ext/trunk/file s) which
is based on Sizzle.js ([link]).

MochiKit.DOM.getElementsByTagA ndClassName("div", "some-class")

Re: [mochikit] Re: MochiKit.DOM.getElementsByTagAndClassName performance

b...@redivi.com (Bob Ippolito) — Wed, 04 Nov 2009 16:22:12 UT

At least with recent browsers there are better ways to speed this up,
e.g. by leveraging more native code (getElementsByClassName and/or
XPath). None of them did this when the code was written in 2005 but I
think all of them do now (except maybe IE).

Re: [mochikit] MochiKit.DOM.getElementsByTagAndClassName performance

cederb...@gmail.com (Per Cederberg) — Wed, 04 Nov 2009 07:14:04 UT

Generally, I think some of these optimizations make sense. Like using
"===" instead of "==" in code like this:

typeof(x) === "string"

But I think the optimizations where variables are moved outside code
blocks and where array lengths are stored to variables should be used
with extreme caution. These are the type of things that people used to

MochiKit.DOM.getElementsByTagAndClassName performance

bea...@gmail.com (takashi mizohata) — Tue, 03 Nov 2009 22:23:09 UT

Hi All,
Forgive me, if this is a recurring argument.
Today I was looking at Firebug profiler and I realize that
getElementsByTagAndClassName takes certain percentages of processing
time. And I took a look at the code, and I did a little bit of hand
optimization. It doesn't change any semantics of code, but just

Re: MochiTAL

bkcleme...@gmail.com (bkc) — Sat, 01 Aug 2009 19:22:15 UT

I can't answer the question directly about MochiTAL, but when I saw
MochiTAL more than a year ago I decided to write a more complete
implementation of TAL in javascript called jstal.

I have combined jstal with an XSLT implementation (tal2xslt) into a
single package ATALi (Alternate TAL Implementations) which you can

MochiTAL

silas.sant...@orange.fr (ss) — Thu, 30 Jul 2009 15:55:31 UT

Hi,

I am new to JavaScript and to Mochikit, but I've seen enough of it
(Mochikit) to get very much interested about it. I am currently
looking into the Ajax Tables example from the Mochikit web site, and I
have to confess that I am a little bit confused about the MochiTAL
processing. So, I thought I'd drop a line to check if anyone is kind

Re: [mochikit] Re: Defered.setFinal

giulio.ces...@gmail.com (Giulio Cesare Solaroli) — Sat, 25 Jul 2009 22:51:59 UT

Hello all,
In order to handle this case, we have overwrote the 'callback' method
in our subclass of the Deferred class, to add a default Errback that
at least logs the error.
A similar solution could be probably used also in MochiKit, allowing
the user to optionally specify a specific error handler / finalizer.

Ticket #352: Adding MochiKit.DateTime.toISOTime arguments to the API

cederb...@gmail.com (Per Cederberg) — Tue, 21 Jul 2009 07:41:22 UT

In ticket #352 the realISO parameter in the
MochiKit.DateTime.toISOTime() function is discussed:
[link]
It was introduced by Bob in r377 (some 4 years ago), but never added
to the documentation or the official API:
[link]
Is it time that we now add it? Or is it just one of those hacks that

Re: Defered.setFinal

mendapara.a...@gmail.com (Amit Mendapara) — Mon, 20 Jul 2009 10:03:55 UT

Hi Per,

I have just tested the changes with the Ajax extension module and it
works as expected. Thanks for considering adding this feature. This
would help me creating jQuery compatible Ajax module for Mochikit
extensions project.

Currently, I'm quite busy with some another work but supposed to come

Re: [mochikit] Re: Defered.setFinal

cederb...@gmail.com (Per Cederberg) — Mon, 20 Jul 2009 09:26:12 UT

Slow response here, but I finally got around to committing this to
Subversion (r1533):

[link]

Modified the patch a bit further to account for some additional cases.
Also added tests and documentation.

@Bob: Can you please review this change? I have the feeling that I've

Re: Base.js unescape reassignment and intrusion protection systems

mstras...@gmail.com (Michael) — Mon, 20 Jul 2009 01:59:27 UT

Thanks Per for your analysis. I think your suggestion will work. Who
will try it? I am not a MochiKit user directly. I'm a MarkMail user
who investigated why he can't view articles at work.

At work I am getting an exception made to allow JavaScript from
markmail.org. But that doesn't help anyone else wanting to use a site

Re: [mochikit] Re: Base.js unescape reassignment and intrusion protection systems

cederb...@gmail.com (Per Cederberg) — Fri, 17 Jul 2009 06:07:12 UT

Now that I'm awake, it strikes me that this might be the obvious solution:

function decode(text) {
if (typeof(decodeURIComponent) != "undefined") {
return decodeURIComponent(text);
} else {
return unescape(text);
}
}

Try to patch it in a repackage the source code and let us know how it