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
Looks nice. I’ll give it a shot. The use of xToY() notation in the Visual module caught my attention. I recently read an interesting idea from Joel: http://www.joelonsoftware.com/articles/Wrong.html (the section below “I’m Hungary”) - The point is made that, given the y = xToY( x ) format, perhaps y = yFromX( x ) is a more readable approach.
Comment by Troy Farrell — 2005-08-02 @ 1:45 pm
I don’t really see any reason to complain about the nomenclature of *two* functions which are essentially implementation details. If you read the docs, it says that they’re not exported by default.
The right way to say it is Color.fromX(…).toY() (which, surprisingly enough, looks just like the functions). In this case, I don’t agree that it’s more readable, understandable, or anything else to name the functions any other way.
Comment by Bob Ippolito — 2005-08-02 @ 2:13 pm
I’m hardly complaining. Color.fromX( x ).toY( y ) is quite readable given the temporary Color object created in the process. As you noted, I was referring to hslToRGB and its sibling rgbToHSL.
Thanks for pointing out the needed DTD fix for the sortable table demo. Some days I feel the need to spit on IE for not supporting application/xhtml+xml. Thanks for making this freely available.
Comment by Troy Farrell — 2005-08-02 @ 3:05 pm