Anyone need the MooTools docs in Japanese?
Archive for the ‘MooTools’ Category
Domo arigato
November 3rd, 2008 by Aaron N.An Open Invitation for MooTools Plugins
October 27th, 2008 by Aaron N.As many of you know, the MooTools team is hard at work on a plugin repository that will allow developers to share their date pickers, form validators, effects, and other widgets with anyone. This project is being pursued as fast as possible, but this means it’s up to a few people who are burning their spare time to work on it as they can.
As a stop-gap solution, I’m going to open up the Clientcide repositories now that I’ve thrown off my corporate bonds. Anyone that wants to release a plugin here is welcome to do so. They’ll be included as additional download options on the Clientcide builder page.
To submit a plugin you need to have the following:
- A svn repository for your work that anyone can pull from – I suggest Google Code.
- A directory organization that mirrors the MooTools repository. This means a Source directory with a scripts.json file, a Docs directory, a Compatibility directory (even if it’s empty), and a Specs directory (unless your plugin has no use for it).
- Your scripts.json file should reference by name any dependencies your script has. It can reference other scripts available here on Clientcide. So, for example, if you extended my FormValidator class and create, say, FormValidator.Foo. You would list in your scripts.json that your file depended on “FormValidator”. This allows the download page to include the files yours needs.
- Your plugin must have a unique file name – this has to do with the dependency mapping, which, at the moment, doesn’t respect the differences between libraries – they all work in the same namespace, so if there’s a plugin on Clientcide already that has the name you want, you’ll have to pick another.
- Your plugin must include tests. You can use either the Clientcide Test Framework or the JSSPec test runner that comes with MooTools. Look at the Clientcide repository for examples as it contains both.
- I must be able to contribute to your svn repository. I’ll only do so if there’s a pressing bug and you are unavailable to address it.
- Optionally, you can author a page in the Clientside wikitorials that demonstrates how your plugin works.
- Your plugin must not have any errors and must work well when compressed (i.e. watch those semi-colons!).
- Your plugin must not produce any JavaScript warnings.
Any plugin is fair game. The only requirements are that they be open source and that they be well written. Which plugins are accepted will be up to me for now.
To get started, just drop me a line.
MooTools 1.2.1 released
October 16th, 2008 by Aaron N.To quote the MooTools blog:
In keeping with our new pledge to release more often, we’ve been working hard lately to get 1.2.1 ready for release, and we’re finally happy with it. This release brings a ton of bug fixes, and is a drop in replacement for 1.2.0. (That’s right, no breaking changes!)
What’s new?
Element.Properties.html (
element.set('html', html);) now works even with select and table element’s in Internet Explorer. Element:clone is also now faster than ever, and retains the values of form elements being cloned. A lot of work has also been done to fix some bugs in Class.js, and Safari 2 support is now back. With the help of Daniel Steigerwald, we’ve also cleaned up quite a few memory leaks in IE related to events and Element storage, and destroyed elements are now more effectively destroyed.For a complete list of changes, see the changelog on GitHub…
Links:
I’ll be regressing all the Clientside code to verify that everything still works and will release 1.2.1 into our svn soon. Hopefully I can knock this out today.
MooTools cheat-sheets and offline documentation
October 13th, 2008 by Aaron N.MooTools 1.11 used to have a doc viewer in the svn repository that isn’t there for MooTools 1.2 (I’ve still got it in our repository if you want it). Well, some industrious soul created a chmox file for the 1.2 docs.
There’s also a PDF cheat sheet for both the MooTools core and the plugins.
How Many Flavors of Linux Are There?
October 8th, 2008 by Aaron N.It’s hard to write about what you like about an open source project that that solves (or at least attempts to solve) a problem that other open source projects are also trying to solve (using different methods). It looks like you’re competing with each other, but really all that’s going on is that two groups of people share a problem and are the kind of people who enjoy solving that kind of problem and have their own specific ideas about how to do it. How many flavors of Linux are there?
Read the rest of this entry »
jQuery, MooTools, the Ajax Experience, Programming to the Pattern, and What Really Makes One Framework Different From Another
October 3rd, 2008 by Aaron N.I just got back from the Ajax Experience in Boston and I’ve had a lot of stuff on my mind.
jQuery Has A Posse
First, I must first attest that hands down, jQuery was the most popular and well represented framework there. They ruled the roost. John Resig (creator of jQuery) spoke 7 times in 3 days, Microsoft demonstrated how jQuery is included in its SDK, and the crowd attending was definitely there to talk about the framework. More than anything, this made it clear to me that jQuery is doing something right.
Part of the task I set for myself in attending the conference was to attend as many of these jQuery sessions as I could both to learn as much of jQuery as I could (I have, in the past, dug into it, but I wanted to soak up as much as I could from the development team and John) and also to see if I could pick up on what accounts for the popularity of the framework.
Read the rest of this entry »
Clientside Relaunch, Updated WikiTorials, and a Book!
August 13th, 2008 by Aaron N.Greetings all.
It’s taken far longer than I originally had hoped, but we’ve finally managed to tackle a few big changes here at clientside.
Redesign
First, there’s a new design. It’s not really much different than the old one, but it’s a bit cleaner and crisper. You should really notice the change in the wikitorials.
Mootorial.com; Updated Wikitorials
Speaking of the wikitorials, we’ve relaunched those, too. You’ll find that all our code for MooTools 1.2, which we relaunched in June, now has tutorials and demos. We released the code when it was ready, but only just now managed to re-author all the tutorials, which were sadly out of date.
Then there’s the MooTorial – the MooTools tutorial that has drawn so many of you here. It’s now moved, officially, to www.mootorial.com. It’s still a part of Clientside and brought to you by CNET, but now it’s seperate from our code and much better organized (and updated for MooTools 1.2, of course).
The MooTools Book!
Well, it took waayyy longer than I would have suspected, but the MooTools book is finally here! You can purchase and download the PDF of the book immediately, or order the paper version, which comes out in the next day or so. You can get the PDF from Apress (the publisher) or order the paperback from Amazon.
The book is over 250 pages of step-by-step instructions on how to use MooTools. It’s similar to the Mootorial in that it covers every class and method in the library, but it’s far more detailed and designed for both advanced programmers and beginners. Hopefully you’ll find it a useful reference and an easy read.
CNET Clientside MooTools Plugins 1.2 Release
June 19th, 2008 by Aaron N.Last week saw the final release of MooTools 1.2. The difference between MooTools 1.11 and 1.2 is tremendous and I encourage you to read up on the posts there about all the new goodies to be found in the latest release.
Hot on the heals of that release is our release of CNET’s plugin repository refactored for 1.2. I’ve posted about what’s new before but I’ll give a quick overview of what’s on offer and what’s new:
- The library has been cleaned up and reorganized with
- Browser fixes,
- Native extensions (like our Date Native, Element.Forms and Element.Position extensions),
- Effects (like Fx.Reveal – formerly Fx.SmoothShow – which transitions an element from display:none to display:block),
- Request (our JsonP class which handles cross-domain requests)
- UI classes (like our StickyWin popup handler family of classes, our Waiter class which automates ajax indicators, our IconMenu class and more),
- Layout classes (carousels, slideshows, tabs and more)
- Form helpers (validation, date pickers, inline hint-text, and more)
- iPhone (our iPhone UI class inspired by iUI)
- and more…
- Numerous bug fixes and improvements
- (Finally) A fancy download builder (http://clientside.cnet.com/js)
- SVN is still here: http://cnetjavascript.googlecode.com (note: the branch/1-2 directory is no longer there as all this has moved into /trunk)
- Unit Tests that you can use to test our code and even your own (http://clientside.cnet.com/tests/)
- Specs Runner tests (just like MooTools) that you can run against your browsers
- Fancy new Docs (http://clientside.cnet.com/docs)
We’ve done a fair amount of QA (with the above listed test suites) and officially support Safari, Firefox (we haven’t done much testing in FF3 just yet but don’t expect any issues), IE 6, 7, and 8. We’ve tested in Opera and have found one or two small issues that we’ll address.
Still on the to-do list:
- Update the Mootorial for 1.2
- Update the wikitorial for CNET’s plugins for 1.2
As always, if you find any bugs you can contact us and we’ll address them as quickly as we can.
Clientside Libraries 1.2 RC2
April 28th, 2008 by Aaron N.After a lot of start and stop work I’m happy to announce that CNET’s javascript libraries are now nearing final release for MooTools 1.2 compatibility. We announced our RC1 release of the libraries. We’ve spent the time since then writing lots and lots of tests to validate the codebase. At this point we’ve spent all our time writing the tests, but we haven’t actually put everything through QA yet. Still, we’re much more confident in the current state of the code and have started using the code in our live environments in a limited fashion.
Unit Tests and Specs Tests
MooTools itself comes with a specs runner from JSSpec. We’ve made use of this to write specs tests for the portion of our libraries that can be tested this way. You can see and run these tests here: http://clientside.cnet.com/cnet.gf/svn/Specs.
Because a lot of our work is more interactive, these specs tests won’t work to verify that our code works well, so we’ve written a unit tester suite. You can run through all the unit tests, which require you to start a test, perform some action, and then verify that it worked correctly (for instance, if you were testing our DatePicker class, you’d start a test, then click on an icon and choose a date and verify that the resulting date was the one you selected). You can view the unit tests here: href=”http://clientside.cnet.com/tests/
What’s New?
Here’s what’s new in our 1.2 conversion:
- New docs: http://clientside.cnet.com/docs
- New download page: http://clientside.cnet.com/js
- Everything has been refactored, in some cases just minor tweaks to work with 1.2, while in other cases things were completely rewritten. The interface to most of our classes and methods has been unchanged.
- New file organization mirrors MooTools. This means you can get a compatibility layer for 1.11 code.
- Some things have been renamed and cleaned up. Most notably Fx.SmoothShow is now Fx.Reveal, Fx.SmoothMove is now just Fx.Move, and stickyWinDefaultHTML is now StickyWin.ui.
How You Can Help
Our codebase is ready for consumption but it’s possible you’ll find errors. Run through the specs tests and unit tests in the browsers you use and let us know if any fail.
We haven’t tested our compatibility layers very thoroughly yet. If you have some pages that use our libraries already, see what happens when you include MooTools 1.2 and our current code with the compatibility layers enabled for both.
If you find any bugs, you can post comments here or contact us directly.
$merge, $extend, Class.extend, Class.implement, Native.implement
March 28th, 2008 by Aaron N.So I was asked yesterday the following:
Why does Browser use merge but Element use implement?
And after composing a lengthy reply, I thought it might be useful to post it for others: Read the rest of this entry »