As I mentioned in a previous post, Apress wants me to embiggen the MooTools book. It’s worth noting that the previous book was on their “firstPress” label which is intended to introduce people to an emerging technology. These books are supposed to be about 150 pages long (and I’ll point out the font for this imprint is HUGE). When I was about 50-60% through writing my book, I’d already passed that threshold and my deadline was rapidly approaching. Consequently, by the time I got to the good stuff – robust code examples of how to write classes and that sort of thing – I had to stop writing and hand it off to the publisher.

The book has done relatively well for their “firstPress” imprint – and, to be clear, I have no idea how many even sold. Apress says the few indicators they have imply that it’s doing well. Let’s just say the publishing industry doesn’t exactly give or generate real-time stats. Anyway, they asked me to go back and finish what I wanted to and add several more chapters to the book. The full Apress imprint means things like, oh, a font size aimed at readers under 60 and an index, which the current book suffers without.

I’ve been contemplating what I’d like to add to the book and decided that I want to answer a different question. The current book answers the question, “What is MooTools and how does one use it?” What I’d like to answer in this addition is, “How do I – me, Aaron Newton – use MooTools and what have I learned by writing a lot of code with it?” I want to share the ins and outs of how I build web sites that are heavily scripted.

So, with that in mind, here’s my current TOC draft. I’d greatly appreciate any input. What chapters here would you skim through or skip entirely? Which chapters would you be eager to turn to first?

I’ll note that the first section of chapters – those without descriptions – are basically the current book’s contents. I invision most of the new chapters as being relatively brief with a few exceptions.

Part 1: Learning MooTools
Chapter 1: Getting Started with MooTools
Chapter 2: Reviewing MooTools
Chapter 3: Shortcuts and Helpful Functions
Chapter 4: Native Objects
Chapter 5: Elements
Chapter 6: Utilities
Chapter 7: Classes and Inheritance
Chapter 8: Getting Started with Classes
Chapter 9: Fx
Chapter 10: Request
Chapter 11: Plug-Ins
Chapter 12: Third-Party Plug-Ins

Part 2: Using MooTools – Real World Examples
Chapter 13: A Simple Use Case
This is what Chapter 13 is now; an example of a simple page with a simple use case. From this we turn our use case into a class in chapters 14, 15, and 16.
Chapter 14: When to Write Classes – Programming to Patterns
This covers my perspective on when to write classes (i.e. as often as possible) and why.
Chapter 15: Writing a Tab Class
Applying the thinking from Chapter 14, we turn the use case in Chapter 13 into a class (this is basically what chapter 14 is now)
Chapter 16: Writing Flexible Classes
Here I cover extending classes (currently chapter 15).
Chapter 17: Using Mixin Classes with Implements
A deeper look at using Implements and how you can use it to reduce your work.
Chapter 18: Best Practices for Classes
Do’s and don’ts for classes.
Chapter 19: Integrating Your Work with MooTools
Extending MooTools classes (without altering the actual MooTools codebase) to add functionality to them.
Chapter 20: Extending Native Objects
When, in your own codebase, it makes sense to extend String, Element, etc.
Chapter 20: Avoiding Repetition
How to let your code do your work for you.
Chapter 21: Organizing and Extending Numerous Classes
Managing families of classes.
Chapter 22: Controller Classes and Global Methods
Writing super classes and static methods that will control numerous instances of other classes.
Chapter 23: Hidden Secrets in MooTools
Undocumented functionality in MooTools that you can tap into.
Chapter 24: Debugging and Solving Problems
Using Firebug and other debugging techniques to figure out what’s not working.
Chapter 25: Test Driven Development
Writing code against unit tests and their benefits.

Part 3: Building Your Site Well
Chapter 26: Organizing Your Site’s Code
Namespacing, anonymous closures, and other methods for making your codebase easier to manage.
Chapter 27: Defining The Defaults For Your Environment
Overwriting the default options and states for existing classes in your environment.
Chapter 28: Unobtrusive Designs
How to build your site to work when JavaScript doesn’t.
Chapter 29: Ajax Inside and Out
A closer look at writing applications that make heavy use of Ajax.
Chapter 30: Things to Avoid
A laundry list of pitfalls and tempting design patterns that can get you into trouble.

Chapter 31: Where to Learn More
This is what is currently in chapter 16.

Appendix: Core Concepts in JavaScript

From the I-don’t-know-why-I-didn’t-think-of-this-before department comes two  new goodies for FormValidator.

1. A new option stopOnFailure that will prevent the form from submitting if the validation fails. Previously you always had to do this yourself  in the onFormValidate event. No more! Note that this is sort of a breaking change in that if you were using FormValidator previously and you let forms that failed submit continue, you’ll run into this new option, as it defaults to true.
2. Thanks to Element Storage you could always retrieve the validator for a form by doing el.retrieve(‘validator’) but only if you’d created one already. Now you can use Element.get/set to access and create the validator for a form. Additionally, you can call the new Element method validate to get back a true/false value to see if it validates. Note that calling this shortcut will expose the validation errors (just as if the user submitted the form).

Just a quick FYI. I’ve been cleaning up references to CNET in my codebase now that Clientcide is on its own. So things like setCNETBaseHref is now Clientcide.setAssetLocation – the old method still works though.

I’ve also removed the CNETAPI class as I’m no longer maintaining it and I’m sure the API has changed in the last year (with new functionality). I also added the Clientcide namespace which, at the moment, only contains setAssetLocation and the svn version of your download from the download page.

Given that this was a big code change (a lot of things were touched, if only slightly), please do let me know if you spot anything that’s seems off.

David Walsh has a nice little effect featured in the footer of his blog. He writes of it:

Link nudging is the process of adjusting the padding on a link slightly to show a simple, tasteful “jump” when you place your mouse over a link. The effect is magnified when mousing on and off a link quickly.

Here’s the code:

$$('#footer-topics-1 a').each(function(el) {
	var fx = new Fx.Morph(el,{ duration:300, link:'cancel' });
	el.addEvents({
		'mouseenter': function() { fx.start({ 'padding-left': 20 }); },
		'mouseleave': function() { fx.start({ 'padding-left': 0 }); }
	});
}); 

Digging around on Nathan White’s blog, I found a link to some MooTools 1.2 plugins over on Chris Esler’s blog. Then I found this little gem.

Well I’ve been rather obsessed lately with getting mootools running in a server-side environment. I’ve had some minimal experience with Helma, but I decided to try and build my own. At this point its rather simple, but I have managed to initiate the jetty webserver with mootools and to write java handlers in javascript (again with mootools) to handle my requests. I looked at a few internet posts about doing your own javascript web frameworks, but most I had a hard time getting to work on my local environment as well as my server environment. So after about a month of diving into Rhino documentation and Jetty documentation I’ve got something fairly predictable working.

Nifty.