bob.ippoli.to
Bob Ippolito (@etrepum) on Haskell, Python, Erlang, JavaScript, etc.
«

MochiKit 0.60 Released

»

I went ahead and created a mailing list for development of and with MochiKit: Google Groups: MochiKit. No public Trac instance yet, but we're planning to have one soon.

MochiKit 0.60 was released yesterday (coincidentally, also my birthday, from which I'm still recovering). All of the changes are relatively minor; mostly just fixing distribution mistakes. For those of you that have the subversion repository checked out, you'll notice that the layout of the distribution zips is slightly different (namely that MochiKit is lib/MochiKit in the zip). That's because JSAN expects a certain distribution layout, and my repository is almost, but not quite, in that form. So, if you had downloaded the zip, I apologize that the examples and tests didn't run out of the box. I may rearrange the repository to match at some point, but for now, this works for me.

Aside from the obligatory bug fixes, there are two new features: a more general version of getElementsByTagAndClassName which doesn't assume you want to ask window.document for tags, plus a "packed" version of MochiKit.

The "packed" version of MochiKit lives at packed/MochiKit/MochiKit.js. It is the entirety of MochiKit concatenated together and comment-stripped. This is about 108k (24k with gzip compression) as-is, but run through a real whitespace-annihilating JavaScript packer it should get considerably smaller, since the coding conventions for MochiKit dictate lots of whitespace (with spaces instead of tabs, at that). While the style guide currently only resides somewhere between my brain and my fingers, it's more or less like what you'd get if PEP 7 and PEP 8 got drunk one night and a baby JavaScript style guide popped out several months later.

packed/MochiKit/MochiKit.js is API compatible with lib/MochiKit/MochiKit.js; meaning, you may refer to it directly with a <script> tag, or you may import it with JSAN.use("MochiKit.MochiKit") or dojo.require("MochiKit.MochiKit") ("MochiKit.* should work in svn, but not 0.60 because I forgot to add a __package__.js). The reason to use the packed MochiKit is that it's a single file and saves a couple round-trips to the server. The packed MochiKit is everything though. If you want an even smaller distribution consisting of a subset of MochiKit, you'll have to roll your own. I believe that Dojo Toolkit may already have this capability (though it's not documented so I don't know how to do it or what state it's in), and there's JavaScript::Librarian coming from the JSAN front. The current stupid packing script is just a temporary means to an end, I intend for it to be replaced by one of those two when they're ready and I've learned how to use them.

I recommend the following process for developing with MochiKit (if only because this is how we do it):

Development:
Use MochiKit unpacked, as-is, from the trunk of the repository or the latest distribution. You may even use svn:externals to do this (we do). Using your loading method of choice, load all of MochiKit (e.g. JSAN.use("MochiKit.MochiKit") or <script src="lib/MochiKit/MochiKit.js" type="text/javascript"></script>).
Production:
In your staging branch, replace the lib tree with the packed tree from the latest release distribution of MochiKit (or change the svn:externals to point to a release tag in the repo). Ensure that everything works as expected. Deploy!

2005-07-29 v0.60

  • Beefed up the MochiKit.DOM test suite
  • Fixed return value for MochiKit.DOM.swapElementClass, could return false unexpectedly before
  • Added an optional "parent" argument to MochiKit.DOM.getElementsByTagAndClassName
  • Added a "packed" version in packed/MochiKit/MochiKit.js
  • Changed build script to rewrite the URLs in tests to account for the JSAN-required reorganization
  • MochiKit.Compat to potentially work around IE 5.5 issues (5.0 still not supported). Test.Simple doesn't seem to work there, though.
  • Several minor documentation corrections