languagevalue

Once you know how much easier it is to get elements all around, you should take the time to learn how MooTools has provided a simple access API around the browser quirks for Elements. And on top of it, we’ve extended this API to things that you don’t normally find on Elements. And as cool as it is, you can easily add your own bits with ease.

Get Who? Set What?

On Elements, theres only 3 getters/setters that you need to worry yourself with: get/set, getStyle/setStyle, and store/retrieve (we’ll ignore getProperty for now).

Get/Set

The most commonly used are Element#get and Element#set. They will first check the Element.Properties object to see if a specific getter/setter exists, before defaulting to getProperty or setProperty. So for instance, you can get the href of a link, or you can get the text of an element, which will get the node value in a cross browser fashion.

<a id="myAnchor" href="/blog">Blog</a> <div>All my <span>text</span></div> $('myAnchor').get('href'); // '/blog' $('myDiv').get('text'); // 'All my text'

You can do as you would expect with the setters in the same way.

$('myAnchor').set('title', 'MooTools Blog'); //sets title attribute $('myDiv').set('text', 'other text'); //sets the innerHTML

For now, let’s just look at the other methods, and we’ll take a look at how this works later so you can add to it yourself.

Setting with Style

The other commonly used pair of methods are Element#getStyle and Element#setStyle. These should hopefully be self explanatory. Their benefit is that they normalize certain styles the browsers are inconsistent about, such as opacity.

Elemental Properties

Let’s take a look at an example that MooTools itself defines. The style property is easier to remember and read than using cssText, so that’s what MooTools does for us.

Element.Properties.style = { set: function(style){ this.style.cssText = style; }, get: function(){ return this.style.cssText; } };

Seeing how the style object is setup, you can easily create your own. Given a Person class, and the given HTML, we could decide it would beneficial to be able to get the instance of a Person from an element.

<div class="person person_3"> Sean </div> <p>Hello</p>

Say we were to want to get a Person instance when we have this element. We would define the property on Element.Properties.

Element.Properties.person = { get: function() { var id = this.className.match(/person_(\d+)/)[1]; if(id) return Person.getById(id); }, set: function(person) { this .addClass('person') .addClass('person_'+person.id) .set('html', person.name); } };

Now we can use our familiar get and set methods.

$('TestPerson').get('person'); // returns Person instance of ID 3. $('OtherTest').set('person', new Person('John')); //turns the paragraph into a person // <p class="person person_4">John</p> Let’s just Store that

The third pair of methods that MooTools defines for elements is Element#store and Element#retrieve. Woah woah woah. What? You’re telling me you can get properties, and you can retrieve them? What the heck guys?

Don’t worry, it’s pretty easy to know and understand the difference once I explain it. get and set are the most common methods, and default to element attributes, like I said. In many other places, such as when you use el.get('tween'), the MooTools teams made the getter call retrieve for you. You’ve been accessing it, without knowing it.

OK, great Sean. Why should I care how you give me the values?

I hear you. You see, most of the getters/setters are used to access attributes. But what happens you want to get at or set some other kind of property. What if you want to set an actual object, or a function to the Element. I guess you could JSON encode and create a custom attribute, but that’s not good practice. And you lose out on any class info of the object, in case it was an instance of something.

These methods also help with an issue that arises when you try to store something like an Event object or an instance of something else that refers to the Element in question. Certain browsers don’t handle the circular references that well if you were to set el.prop = { someEl: el }. It can leave nasty memory leaks.

If you really want to know, behind the scenes, MooTools keeps a storage object that is totally separate from any element. Every element created gets assigned a unique id, and that id is used as a key on the storage object.

Regardless, you don’t have to do anything special for store/retrieve to work. Using our above example, it would work like so:

$('TestPerson').store('person', new Person('Sean')); $('TestPerson').retrieve('person'); //returns the exact same Person instance

These two common pairs of methods actually have a third method that relates to each of them, which allows the destruction of each respective data location. These methods are Element#erase and Element#eliminate.

Apply this yourself

This all sounds great, I’m sure. Now when you’re writing your own classes and plugins, you can be sure to use the pre-packaged properties. However, it’s much more powerful when you can find a useful property to add that relates to your own plugins.

Sean McArthur is a software developer at Blazonco.com who is madly in love with MooTools. Most of his contributions involve sharing tips and information about MooTools (and programming in general) at his blog and on Twitter.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All Tips & Tricks ]
View original post|Add to del.icio.us | Share

languagevalue

Over the past couple of weeks we have got a lot of great responses over the initial beta of MooTools Core 1.3. We have since improved both the code and the documentation in order to release a second beta.

Most notably we have removed the dependency on Hash. If you build 1.3 without compatibility you won’t get the Hash object no more. But fear not, we have added Object.js which brings you all the Hash methods as generics. Everything else is really minor, has to do with stability or was meant to improve code quality (we really take this seriously).

We are trying hard to provide you with a consistent and meaningful API so we have decided to introduce one tiny tweeny minor breaking change. If you were setting tween, morph, load, or send options using the getter (element.get('tween', {...options here...})) that will not work anymore. You will have to use set(element.set('tween', {...options here...})), as get needs to be a pure getter.

All in all the new beta is faster, better, more stable - in a word - sexier. Tell us how it works for you.

Download

• Download the built 1.3 beta 2 release.
• Fork / clone MooTools 1.3 from github, and build it yourself with Packager.
• Read the commit logs to see what has changed.
• Wondering how those amazing new methods are called? You can browse our markdown documentation right on github.
• And don’t forget to report any issue you find with the beta, compatibility or not! The more reports we get, the fastest we’ll have a final release.

Thanks to everyone who helped polishing the 1.3 release. I would really like to thank Arian Stolwijk (@astolwijk) who has contributed significant improvements to the documentation.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All ]
View original post|Add to del.icio.us | Share

languagevalueFx is not just for animating elements

In a recent project I worked on with Thomas Aylott the page did some calculations and displayed the result after the user pulled some sliders around. Rather than just change the text from one number to another, the element would increment the number before the user’s very eyes. With a fun interface like that, they had no choice but to apply for a new credit card right then.

Admittedly, I may not have thought to extend Fx to do something like that. After all, the first line of the docs for Fx is: “This Class will rarely be used on its own, …” My first thought would be to use a periodical with a counter and then set the text until the counter was done. But Thomas extended Fx instead. Though it’s the base class for all animations (tween, morph, scroller, etc.) its methods can be used for all sorts of abstract “animations.”

For this article I’ve just come up with a few potentially useful extensions of Fx to get the idea across that you can use it for more than just element animations.

How Fx Works

Essentially Fx just calculates a sequence of values between two numbers. The options kick in to make those values more interesting. This class, Fx.Log, simply updates the text of an element every step of the effect. Notice that this class is essentially the base Fx class except for the tiny set method.

Here’s another demo that visualizes all the visible options of Fx. After you draw the effect, hover the dots to see the exact value calculated (or view source and see them all together.) Playing around with this demo might tell you more about how Fx works than anything else out there.

Fx.Diff

By default, Fx uses 50 fps. So every second it’ll kick out 50 different values and fire the set method 50 different times. For the next few demos I only wanted to do something if the rounded value is different than the last rounded value, so I came up with Fx.Diff. If the value is different, it’ll call the render method.

Fx.Diff = new Class({ Extends: Fx, count: 0, render: $empty, set: function(now){ now = now.round(); var diff = now - this.count; if (diff) { this.render(diff, now); this.count += diff; } return this; } }); Fx.Count

Since this appears to be no different than the very first demo, we’ll just look at the code. Note, the difference is that the first counting demo would change the text in the element every single frame (50 times a second), but this code would only change it if the new rounded value is different from the last.

Fx.Count = new Class({ Extends: Fx.Diff, initialize: function(element, options){ this.element = document.id(element); this.parent(options); }, render: function(){ this.element.set('text', this.count); return this; } }); Fx.Typewriter

I can actually see myself using this one somewhere:

Notice that Fx.Typewriter overwrites the start method of Fx. The Fx start method takes two arguments, from and to. The usage for Fx.Typewriter is to simply pass in a string of text like so: myFx.start('A whole bunch of text'). This new method knows the from argument is always 0, splits up the text into an array (one item per character) and then uses that length as the to argument. After that logic is done, it simply calls the parent start method. Then the render method takes over by figuring out how many characters to display, filtering out the tail end of the array, joining what matters, and finally setting the text of our element.

Fx.Text

There’s a very creative effect called Fx.Text on the forge. It’s an animated text replacement effect. I think it’s really cool and does a great job of extending Fx.

Fx.Cornify

This next script is far too magical to simply show you the code. You’ll need to view the source for this beauty.

How many? (caution, start with low numbers)

Duration:

Ryan Florence is a MooTools enthusiast and contributor. He maintains his JavaScript focused blog, MooDocs.net, and moo4q. Follow him on twitter or checkout his plugins on the Forge.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All ]
View original post|Add to del.icio.us | Share

languagevalue

If you’ve been paying attention for the past few years, you’ve probably noticed the growth of MooTools, both as a project and as a thriving community. Unfortunately, it has come to light that many so called “members” of the JavaScript community may, in fact, be automata.

To protect ourselves and the MooTools community, we’ve started two physical screening programs (or “meetups”), one in London and the other in the heart of Silicon Valley.

In a surprising turn of events, both groups have had very informative meetings in which actual people have shown up, allowing us to conclusively state that at least some of the members of the MooTools community are, in fact, human. Insightful discussions were had by all, new users and advanced developers alike.

If you’re in the Bay Area or London, it is imperative that you attend at least one of our screening sessions, to verify yourself as human. To be notified about future meetups, as well as voice your opinion on when/where they should be, you can join the Meetup.com group for your area:

• MooTools London
• MooTools Bay Area

Anything Interesting to Share?

If you have something insightful and MooTools-related to share, and think you can spin it into a fifteen minute presentation, please let us know.

Right now, we don’t have any formal communication set up, but it shouldn’t be to hard to get in touch with either Darren (London) or myself (Bay Area). Contact information can be found on the developers page.

Thanks for using MooTools, and we hope to see you there!

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All News ]
View original post|Add to del.icio.us | Share

languagevalue

Continuing with my “More than Meets the Eye” series, today I want to talk to you about the MooTools More Form.Validator. There was a comment left on my last post in this series (about Form.Request) specifically requesting that I cover this relatively complex plugin that’s useful for telling users about the validity of data they enter into forms before they send them.

Getting Started with Validators

The main class you need to concern yourself with is the Form.Valdiator class itself which provides methods that apply specific rules to inputs to see if they are valid. You can then choose how you want to inform your users that they need to address these problems, but that’s not the job to Form.Validator (though it is the job of Form.Validator.Inline, which we’ll cover in a bit).

Let’s talk little bit about the rules that are applied. Form.Validator allows you to define rules that test the state of an input and return true or false - true if the input passes the validation rule, and false if it doesn’t. Here’s a simple example:

Form.Validator.add('doesNotContainTheLetterQ', { errorMsg: 'This field cannot contain the letter Q!', test: function(field){ return !field.get('value').test(/q/,'i'); } });

The above code adds a global validator that allows you to assert that the input doesn’t use the letter Q. The arguments are the validators’ key and then an object that contains an error message to show the user should they encounter the error, and a function that is passed the input as an argument. This function inspects the value or, really, anything you like, and then returns true or false.

The key you give your validator is important. At any time you can validate a field against any validator by using this key as a reference by doing:

myFormValidator.test(key, input[, warnOnly]);

The first two arguments are the important ones here; the key of your validator and the input to test. Where things get interesting are when Form.Validator does this for you. By giving your input that key as a css class name, you tell Form.Validator to validate that field with this validator. In this manner you can quickly and unobtrusively decorate your inputs with the requirements and validate the form. If something goes wrong with your JavaScript, your form will submit as normal. Here’s a really simple example:

The alerts aren’t pretty, but you can see how our validator is now applied when you submit the form.

Form.Validator ships with several validators listed in the documentation. These include simple stuff like required that just validates that the user put something - anything - in the input. But there are also validators for email addresses, only letters, dates, urls, etc. The key is you can write your own - you don’t need to wait for us to release something for you to make use of it. There are an extended list of validators in Form.Validator.Extras that include some edge cases. Things like validating that two inputs have the same value (like an email verification for example).

Using Validators with Arguments

It’s also possible to configure validators with data unique to the input. For example, let’s say you want to have an input with a minimum length validator - the user must type in at least 5 characters. You could write a validator called minimum5 or whatever, but then you’d have to duplicate it for any other character length. For this purpose, Form.Validator allows you to assign values to the input, like so:

<input type="text" name="username" class="minLength:10" id="username"/>

These values - the 10 and 100 values in the example above - get passed along as JSON decoded values to the validator. Here’s what that looks like:

Form.Validator.add('minLength', { errorMsg: function(element, props){ return 'Please enter at least {minLength} characters (you entered {length} characters).'.substitute({minLength:props.minLength,length:element.get('value').length }); }, test: function(element, props){ if (props.minLength != null) return (element.get('value').length >= props.minLength; else return true; } });

As you can see, the error message (which in our previous validator was just a string - the message) can also be a function which is passed the input and then any properties defined in the HTML. The fact that the message can be a function allows you to include information not only about how the validator is configured but also other information, like some aspect of the value the user actually entered. The test is also passed along these p roperties of course which allows you to make the properties a condition of the test. We could, in theory, rewrite our doesNotContainTheLetterQ validator to accept an argument about the character (or, better yet, characters) that we want to disallow:

Form.Validator.add('doesNotContain', { errorMsg: function(field, props){ return 'The value you input cannot contain any of the following letters: ' + props.doesNotContain; }, test: function(field, props){ if (props.doesNotContain) return !field.get('value').match(new RegExp('[' + props.doesNotContain + ']', 'i')); else return true; } });

Note that the properties defined have to be JSON decodable, so you can’t have your input like this:

<input type="text" class="doesNotContain:qz"/>

Instead you’d have to quote the string:

<input type="text" class="doesNotContain:'qz'"/>

Here’s our example:

The base Form.Validator class comes with a plethora of options and events. You can configure it to validate inputs whenever they change (on blur), or to only show one error at a time (serial). You can tell it to ignore hidden fields (those that are not visible, there’s no point in validating inputs with type=”hidden”) and disabled inputs. There are numerous useful methods that let you run the entire validation routine on the form (.validate()), reset all the errors (.reset()) or validate / reset a specific field (.validateField() and .resetField()). You can pause the validator and resume it (.stop() and .start()) as well as ignore / un-ignore a specific field (.ignoreField() and .enforceField()) and more. There’s even an element method that lets you validate a form (Element.prototype.validate).

Form.Validator.Inline - the “Pretty” One

Now that we’ve covered the basics of how Form.Validator works, let’s consider the fact that our examples so far have been rather ugly (who wants alert messages?). MooTools More ships with a default implementation that smoothly displays messages inline, right after the input: Form.Validator.Inline. This class is the “pretty” version of Form.Validator but don’t think of it as the only game in town. You can easily implement your own “pretty” version without a lot of effort. If you want to put errors in a popup or fade them in over the entire screen or play a sound it doesn’t matter. The base Form.Validator class is there for you.

Looking at the Form.Validator.Inline implementation, you’ll find all the same options and methods from Form.Validator along with a few extras that control how your messages appear. For instance, by default, the validation rules show up immediately after the input. This requires a bit of forethought in how you structure your HTML. If your input is inline with something else (like a submit button), validation errors are going to change that when they appear (because they are divs, which by default are block level elements).

The only real option that Form.Validator.Inline has to offer is whether or not to scroll to errors (useful if your form is long and will likely cause the user to scroll to the submit button). Here’s a simple example, building on our previous one:

As you can see, the error message slides in, but it breaks our layout a bit. Let’s do some CSS work to make this look a little nicer.

It’s not The Sistine Chapel but it does look nicer. Our error doesn’t appear to break our layout anymore either.

As a final example, I’ll show you a version that extends Form.Validator.Inline to put the validation messages in tips that popup pointing at the input. Here’s a demo:

If you want you can check out the source on github and download it with its dependencies on Clientcide.

Go Forth and Validate

Overall the purpose of Form.Validator is not to be the only solution for displaying validation messages to your users, but rather a flexible solution for client side form validation on which to build. You can extend it and manipulate it to display messages in any way you choose - and you should!. The default “pretty” implementation - Form.Validator.Inline - is just one way to use the class. In my opinion Form.Validator is one of the classes in MooTools More that shows off the power of MooTools’ object oriented design, allowing for a great deal of flexibility and reuse.

Thanks to Lloyd for suggesting this edition’s topic. If there’s a plugin in MooTools More you’d like me to focus on next time, by all means, make a suggestion in the comments.

Aaron Newton is a contributor to MooTools and the principal developer of MooTools More. He is the author of the book MooTools Essentials as well as the Mootorial online MooTools tutorial. He posts (rarely these days) at his blog Clientcide.com and (much more often) on Twitter as anutron. He works for Cloudera, (which is hiring, by the way).

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[Features Tips & Tricks ]
View original post|Add to del.icio.us | Share

languagevalue

MooTools 1.3 beta 1 launches today. Lots of bug fixes and improvements, and all that jazz. Before presenting you with a random rundown of features, let me be clear about something: MooTools 1.3 is (or will be) 100% compatible with every public documented API of MooTools 1.2. So chill already.

Anyways, here’s what’s new:

Globals

MooTools 1.3 moves away from the $name functions. Most of the useless ones, such as $chk (god knows why I thought it was a good idea to have $chk), were completely nixed. Some of them moved to the proper object’s namespace ($merge » Object.merge, $pick » Array.prototype.pick). Some others were renamed without the stupid $ in front ($type » typeOf, $defined » nil). In the end, there are a lot less global variables now. You can refer to the 1.3 documentation to have a proper list of what’s changed. Keep in mind that the old version of the methods will still work, by default. There will be a way in the future to “compile” MooTools without the compatibility stuff, but the feature is not ready yet.

From types with love

Every native type has now a from method that will try to convert every object passed to that type. Array.from, for instance, replaces both $A and $splat. Function.from will return a function that returns the passed in value, if it wasn’t a function itself. String.from… well you know that at this point, don’t you? We also changed how we internally handle Native types, but that should be none of your concerns, since they were handled with private apis anyways.

Generating your own MooTools, from your own computer

It is now possible, easy, and even perhaps recommended to generate MooTools (and its plugins) yourself. Last few months I’ve been working, on and off, on a pretty advanced projects-builder. It’s called Packager, it supports multiple project dependancies and has a very similar syntax of what’s used in the Forge right now. It’s written in php and you can use it from your php webpages to dynamically include JavaScripts for development, or you can build a single .js for production from the command line.

If you care to build MooTools and MooTools projects for yourself, you should take these steps:

1. Clone MooTools 1.3b1.1 from github.
2. Clone whatever other Packager-ready MooTools project from github (color, table and touch, for instance, are my Packager-ready plugins).
3. Clone Packager itself from github.
4. Read Packager’s README. Pretty much everything you need to know is in there.

Ofcourse, Packager itself is not limited to MooTools, MooTools plugins or just javascript projects. A tutorial post on how to use Packager for development is coming soon (few years tops).

If you dislike php, worry not! There is also a Django builder, called Depender, written by our Aaron Newton, on github as well. I really don’t know how it works, as I don’t do python, but I do know it’s scope is way greater than that of Packager. Depender can, for instance, dynamically build your MooTools for production use, like that. But don’t take my word for it, go check it out on github.

Slick

The most notable new feature in 1.3 is Slick. Slick is our new, shiny, super fast, exhaustively tested, pure-javascript selector engine. There will probably be a dedicated Slick post in the following days (or months, given our relaxed release cycles), but here’s a few Slick-facts for those who haven’t checked it out already:

• Slick is a MooTools-family project by MooTools developers Thomas Aylott, Fabio Costa and yours truly. It can be forked from github, free of charge!
• Slick is an incredibly advanced evolution of our previous selector engine.
• Slick is written using only pure-javascript, none of the MooTools apis are required. It can be used in any project or framework, and it does not require MooTools to function (though the MooTools DOM components do require Slick).
• Slick is speedy, blows away the 1.2 selector engine by 50%, at least. We will give you detailed data in the post dedicated to Slick.
• Slick supports every selector you can think of. Seriously, every one of them. I promise you.
• Slick is customizable, you can make your own pseudo-selectors, your own attribute-selectors, and many more your-own kinds of things.
• Slick supports reversed combinators. You might not know what they are, but they are pretty darn cool.
• Slick has a detached parser. You can parse a css-style-selector string and get back a property-filled object.
• Slick perfectly supports XML documents.
• Slick is slick!

On another note, thanks to the Slick’s parser, you will be able to build an element using a css selector. Let me give you an example of this cool new feature (courtesy of our amazing Christoph Pojer):

Creating an element using an object (the 1.2 way): new Element("input", {"id": "someID", "class": "someClass1 someClass2", "disabled": true}); Creating an element using a selector string (the coolest way): new Element("input#someID.someClass1.someClass2[disabled=true]"); In conclusion

As I get back to work on an exciting number of totally amazing upcoming MooTools projects that you know nothing about because you don’t follow me on github, I’ll leave you with a few useful 1.3 links:

• Download the built 1.3 beta 1 release.
• Fork / clone MooTools 1.3 from github, and build it yourself with Packager, or Depender.
• If you want a full changelog, go read the git history, you lazy bastard. Changelogs are so 2001.
• Wondering how those amazing new methods are called? You can browse our markdown documentation right on github.
• And don’t forget to report any issue you find with the beta, compatibility or not! The more reports we get, the fastest we’ll have a final release.

UPDATE: There was a “merge” problem with beta1, so we quickly fixed it and re-tagged beta 1.1.

Have fun with 1.3! I know I will.

Valerio

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All ]
View original post|Add to del.icio.us | Share

languagevalue

Hey there MooToolers. I just returned from speaking at jQuery Conference 2010 in San Francisco on “Object Oriented jQuery with MooTools” and thought I’d share some notes on the experience.

My Talk

If you ask me how I did I’d say I missed a few connecting ideas but got the concept out there and got some people thinking. Several people came up to me afterward asking how to actually give this a shot on their web apps. Also, if you are reading this on a Mac, do this: command + option + control + 8 (⌃⌥⌘8). I think for the first time in the history of OSX this keyboard shortcut was useful. The projector had a hard time with my bright colored code on a black background so I inverted the the whole presentation!

Some of you have read my post Pigs take flight about using the Class module from MooTools to write modular code in a way we all love but use jQuery for DOM manipulation, effects, AJAX, etc. That was the basis of my talk. You can find the slides and a demo at my blog here.

The Demo is especially awesome.

Thoughts

It was very well attended, said to be the largest JavaScript conference ever. There were a lot of really talented people there and all of the speakers did great. I am humbled by the ability of the jQuery team to put together great events and market their library, I’d even say a bit jealous!

It seems at the user level people see frameworks as rivals or something, but at the framework developer level they generally feel like we’re on the same team, working to make the web better.

There was a lot of talk about organizing code, which is a problem that jQuery doesn’t try to solve. I don’t think any other framework can step in quite like MooTools to do it and yet keep the jQuery API in tact when writing an application’s code (thanks to mutators). Another testament that -core is rock solid and ridiculously versatile for JavaScript generally, not just the DOM. I also found that a lot of people didn’t know that you can create custom builds of MooTools to solve all sorts of JavaScript problems.

So, thanks jQuery for a great weekend!

• Slides and Demo
• Pigs Take Flight Blog Post
• jQuery Conference 2010 SFO

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[News ]
View original post|Add to del.icio.us | Share

languagevalue

Over the past several months we here at MooTools have been contemplating how much of what we do is duplicated effort. When we started this whole project years ago it was because we wanted to do things our own way, but as MooTools and JavaScript in general have progressed, we find ourselves facing the tedium of all the low lying code that has to be written to get Browsers to play nice, not to mention the richer things like our inheritance system and other utilities like effects, DomReady, etc. etc.

At FOSDEM we ended up hanging out with the Dojo crew. We like them; they are always doing interesting things and their framework is one that we’ve always looked at and said to ourselves, “If we ever needed feature X we’d probably just port it from them.” Anyway, at FOSDEM a group of their developers and ours got together and started brainstorming about closer ways to work together. Since then the discussion has gotten closer and closer to where we are now.

MooJo

Starting today the Dojo and MooTools projects will begin merging and joining forces. Part of this is to share resources - more hands coding makes more code, right? But part of it is, well, we’ll be frank, we’re kind of tired of reinventing the wheel. We love the solutions in MooTools, but at the end of the day, the API is all that matters. It doesn’t matter how you detect that the DOM is ready, so long as when it is your code runs. The same could be said for selector engines, XMLHttpRequest, and a whole host of other things. What this means in practical terms is that we just don’t have to do as much work and, to be frank, after 4 years of working on MooTools, we’re happy to cede some of the more tedious tasks to Dojo. Sure, their architecture isn’t quite the same (or maybe even as good) as ours, but it works. This will free our development team’s time to work on their own projects and maybe start getting paid for it, which brings us to the second point.

Making MooJo Profitable

For the past four years we’ve been writing code and releasing it for free. In our talks with the Dojo team we all agreed that all this free time donated to anyone who happened to want our work just wasn’t quite worth the hassle. Don’t get us wrong, writing the code is fun, but it’s all the other stuff. The bug reports, the hand-holding in the forums and on IRC, the constant demand to “compete” with other frameworks (whatever that means). It just sucks the pleasure right out of it. We find ourselves burning nights and weekends to write code for strangers to use and it gets old.

Going forward, the code base will continue to be free, but access to the documentation will require a small “donation” (we’ll probably set a really small minimum, like, say $.25) - frankly, the documentation has gotten too good to be free (we contemplated printing it and just selling it as a book, but micropayments is much more “Web 2.0”). Filing bugs will still be free of course. But we’re working on a system that lets our users put money towards the bugs they care about the most. The bug with the most money donated gets our time and gets in the next release. We think this will cut down on both the number of bugs we get but also help manage expectations. If you have a bug that you think is important, you either need a lot of people to agree with you (which they will if the bug is really broad) or you need to pay a lot (in which case it’s like you’re hiring us as freelancers).

What will we do with the money raised? We’ll probably start sponsoring more meet-ups and sending more people to conferences, but we’ll also be able to compensate the developers who bring you all this great stuff. Certainly no one can argue with that.

Compatiblity

As we begin merging functionality we’ll likely retire large portions of both frameworks. MooTools has a great effects library while Dojo has a lot of solid widgets. MooTools ART will likely get shelved in favor of dojo.gfx, Dojo will likely drop it’s effects libraries in favor of MooTools’ effects which are really nice, much of MooTools More will either be retired (in favor of existing Dojo widgets) or turned into Dojo widgets themselves, etc.

For backwards compatibility we’ll be implementing the “donation” system as well. For the portions of the MooTools and Dojo cores that are deprecated we’ll allow the users to prioritize which parts we offer compatibility for. Same goes for effects, plugins, etc. We hope this new model will encourage businesses that use our awesome frameworks to recognize the value we bring and to compensate us for our time.

If you have any questions, post them in the comments below. Comments are still free - we haven’t implemented the “donation” system for them yet, either.

Update: Yes, this was an April Fool’s joke. We love Dojo and that whole team… but not that much.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All ]
View original post|Add to del.icio.us | Share

languagevalue

Have you extended a Native lately? It’s an incredibly helpful thing. Often people write ugly functions that take a string or whatever as an argument and return some manipulation of the string. Extending natives is a great way to do the same thing, but it is much prettier (aka: explicit, readable, easier-to-debug.)

The Difference:

I’ve seen stuff like this:

fn1(fn2(10, fn3('house')));

Hard to figure out what’s happening. Instead you can write code like:

fn3('house').fn2(10).fn1(); A Useful, Real Example, zeroPad

I’ve used this in a couple scripts, it takes a number and returns a string with zeros padded in front: 123 becomes ‘000123’. Really handy for filenames and the like. Here’s the ugly version:

Functionally Based Example function zeroPad(num, zeros){ zeros = zeros || 3; var str = '' + num; zeros.times(function(){ str = '0'+str; }); return str; }; // usage doSomething(zeroPad(document.getElementById('myInput').value, 3)); Native Extentions Based Example Number.implement({ zeroPad: function(zeros){ var str = '' + this; zeros.times(function(){ str = '0'+str; }); return str; } }); // so that it works on both numbers and strings String.implement({ zeroPad: function(zeros){ return this.toInt().zeroPad(zeros); } }); // usage $('myInput').get('value').zeroPad(3).doSomething(); Side by Side: doSomething(zeroPad(document.getElementById('myInput').value, 3)); // vs $('myInput').get('value').zeroPad(3).doSomething();

Awesome? Yes. You can do the same thing to:

• Array
• Function
• Number
• String
• Hash

Some say extending natives is a bad idea. Personally, I think it’s awesome—but this topic is a sore spot for some. Extending natives is a feature of javascript itself that any general application framework like MooTools is entitled to use. There could be an entire article dedicated to this topic but this article isn’t it. This article is simply here to show how to use this handy feature.

Flippin’ Sweet Array methods

Arian Stolwijk created this amazing gem: Array.Math. Code samples often tell the story faster:

[2,5,1,6].sum(); // 14 [2,5,6,2].product(3); // [6,15,18,6] [9,12,15].quotient(3) // [3,4,5]

This is all made possible by extending the Array native, see?

Array.implement({ sum: function(start,length){ var sum = 0, start = start ? start : 0, length = length ? length : this.count()-start; length = start ? length + 2 : length; for(var i=start;i&lt;length;i++) sum += this[i]; return sum; }, product: function(p){ var arr = $type(p) == 'array'; return this.map(function(entity,i){ return arr ? (entity * p[i]) : (entity * p); }); }, quotient: function(q){ var arr = $type(q) == 'array'; return this.map(function(entity,i){ return arr ? (entity / q[i]) : (entity / q); }); }, // and a whole lot more awesome ... }); Quick Tips

• this is the number or string, or whatever, when inside the method.
• Return something that makes sense (usually this).
• You can implement several methods all in the same code block.

This is just one more great tool to help keep your code organized and readable.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All Tips & Tricks ]
View original post|Add to del.icio.us | Share

languagevalue

Javascript development in the browser is all about the Elements. Manipulating the DOM happens every few lines of code. It’s important enough that some libraries provide little more than DOM enhancements. Not to worry though, MooTools provides greatly in this area as well.

$ and $$

Most of you probably know the two document methods getElementById and querySelectorAll; because if you do, you understand how we select elements with MooTools methods. For those of you that don’t, you provide an ID string of an element in to getElementById, and a CSS selector string to querySelectorAll. The functions $ (which is an alias to document.id, see this post on Dollar Safe Mode for details) and $$ are basically equivalent to getElementById and querySelectorAll, respectively. Of course, since it’s MooTools, they’re more than that.

The dollar function, if given a string, will basically call getElementById on the document. If passed an element, it will just return the element, and if you pass an object with a toElement method, it will try to convert it to an element (we’ll explore that more a couple sections down). A key difference you’ll find between MooTools’ dollar function and jQuery’s is this: MooTools’ $() will only ever return 1 Element, and it will return null if no matching element is found. This means unless you’re absolutely 110% certain the element will exist, you’ll need to check the returned value before starting to call Element methods on it.

var loginEl = $('Login'); if (loginEl) { loginEl.fade('in'); }

The MooTools Team prefers two separate methods for the selecting elements; to remove any doubt about what a certain function call may be returning, we have one method for individual elements and another for multiple elements. In this case, it’s preferable to be explicit, instead of relying to ambiguous auto-magic. When we see $, we expect an element if it exists. When we see $$, we expect an array of elements (which, as you know, an array can always be empty). The double dollar function has some neat tricks that are explained in its own section below.

All this talk about Elements, but only about how to select them. MooTools also provides an excellent Element construction API.

new Element()

With vanilla JS (mmm, vanilla…), you’d use document.createElement whenever you wanted to create and add a new element to the DOM. MooTools tries to make the JavaScript API more pleasant to use; part of that is a more consistent and easy to use syntax and part of it is using more Object-Oriented programming practices. It feels a lot more OO when creating objects using the new keyword, whereas the standard way is more procedural.

It turns out that every element you could create inherits from the Element prototype. Specifically, the elements you create through document.createElement would be HTMLDivElement, or HTMLParagraphElement, or whichever element you create. Like I said, they all inherit from the base Element prototype, and then HTMLElement, and so on. MooTools extends the base Element class, so that all elements receive some MooTools love.

MooTools augments the Element native, providing a super-duper sweet constructor. You can provide the tag name, and then an object of properties to set on the new element. The returned object is of the same type as the $ method mentioned above. The properties you can set are fairly extensive, so check out the documentation to learn more about them, but here’s a demonstration.

toElement

The dollar method provides another function: converting the instance of class into an element(-al?) form. This is similar to a toString function, which converts objects into strings when needed. You can define a method in a class called toElement, and return an element to “represent” the instance. Let’s take a look at a snippet from a Person Class:

Several extensions in MooTools More take advantage of this, like Form.Request, Form.Validator, HtmlTable, and others. And many plugins in the Forge use this approach as well. This means that after creating an instance of one of these classes, you can just hold on to the instance in your code. Whenever you want to affect the element that the instance is controlling, you just use $(instance) to retrieve it.

Aaron even cooked up a ToElement mixin, and wrote a bit more about this over here.

Elements

I pointed out earlier that $$ returns an array-like object containing Elements. It actually returns an object called exactly that: Elements. Behind the scenes, MooTools gets an array of all the elements that meet the selector (so it’s still an array), and then extends the array with all the Elements methods. Why would we want that?

All the methods that MooTools adds to the Element native are added to the Elements class as well. You can do some pretty nifty chaining because of this. First of all, you don’t have to check that it didn’t return null. This is because any method you call on Elements, will loop through the array and try to call the method on each individual element. Even with an empty array, the loop won’t cause an error. And any method you call that would normally return a value, will return an array of the values from each element. An example should make this clearer:

//assigns a click event to all A tags $$('a').addEvent('click', function(e) { e.preventDefault(); alert(this.href); }); //gets all divs with an id set, and then returns //an array of the IDs sorted alphabetically var ids = $$('div[id]').get('id').sort(); //gets all divs with a UL immediately inside //and assigns a class name to the divs $$('div &gt; ul').getParent().addClass('has-list');

While you could put together long chains acting on all the elements you’ve selected, I’d advise against this. It certainly looks cool, and will work fine one or 2 methods out on the chain. But every method call will cause another loop through all the elements. If you’re doing a lot of things to every element, you might as well do it all in a single pass. I’ll show you what I mean.

//this would loop through each time at addEvent, addClass, and fade $$('li a').addEvent('click', function(e) {}).addClass('alertable').fade('in'); //whereas this will only cause 1 loop $$('li a').each(function(link) { link.addEvent('click', function(e) { alert(this.title); }); link.addClass('alertable'); link.fade('in'); });

Still, when doing something simple, you can skip the each call, since Elements will handle that for you.

Concluding

MooTools provides a lot of expressive power when working with the DOM. It’s consistent API makes it a snap to add events, change styles, create elements and more. The object oriented nature of its implementation makes it so that you can extend Elements for your own purposes. Look forward to my next post where I’ll talk about extending Elements in various ways and cover best practices for when you decide to bend Elements to your own will.

Sean McArthur is a software developer at Blazonco.com who is madly in love with MooTools. Most of his contributions involve sharing tips and information about MooTools (and programming in general) at his blog and on Twitter.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All ]
View original post|Add to del.icio.us | Share

languagevalue

The foundation of every great open source project is its community. The MooTools Team creates the base framework code but it’s all of you that take the framework and build outstanding plugins. These are just some of the new developments floating around the MooTools community.

12 Steps to MooTools Mastery

Jacob Thornton’s NetTuts article, 12 Steps to MooTools Master, is a high-level introduction to the MooTools JavaScript framework. The informative article touches on such MooTools topics as Mutators, Prototypal Inheritance, custom events, binding, and more. This tutorial probably isn’t for the complete beginner, but is a good place to start for people still relatively new to MooTools and those considering it for the first time.

http://net.tutsplus.com/tutorials/javascript-ajax/12-steps-to-mootools-mastery/

Meio.Autocomplete

Meio.Autocomplete is the latest plugin from MooTools Contributor Fábio M. Costa. Fábio’s class is packed full of options and events, making it one of the most flexible MooTools Autocomplete plugin available. Great work Fábio!

http://mootools.net/forge/p/meio_autocomplete

DynamicTextarea

DynamicTextarea is a MooTools class that resizes TEXTAREA elements as the user types. DynamicTextarea boasts numerous options and events for maximum control over chosen TEXTAREAs.

http://mootools.net/forge/p/dynamictextarea

Array.Math

Array.Math is an outstanding set of Math methods you can add to JavaScript’s native Array object. Need to find the sum of numbers in an array? Need to normalize elements in an array? Need to get the vector length of an array of numbers? Be sure to download Array.Math! Kudos to Arian Stolwijk for his excellent work!

http://mootools.net/forge/p/array_math

LazyLoader

LazyLoader is a unique MooTools plugin created by David Chan which allows you to defer loading of MooTools classes until they are needed. This is especially helpful when building large web applications. LazyLoader is very easy to use and implement.

http://mootools.net/forge/p/lazyloader

Locate

Locate is a Geolocation plugin authored by Christopher Beloch. Christopher’s plugin taps into the power of HTML5 and offers a few useful options and events to control the Locate instance.

http://mootools.net/forge/p/locate

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your plugins in future posts!

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[Roundup ]
View original post|Add to del.icio.us | Share

languagevalue

MooTools More features a diverse, powerful collection of Classes (60 plugins!!) and some are my favorite tools that I use over and over again. I thought I’d take some time to dig into some of the plugins in MooTools More that I think are interesting and really useful that maybe you haven’t had time to really sink your teeth into (or, perhaps, you haven’t found a reason to). So I’m going to take some time to talk about some of the plugins in More each month, sharing not only how they work, but how they work together and maybe even why you’d use them. Today I’m going to talk about the Form.Request plugin.

Request and Request.HTML

MooTools Core ships with three AJAX modules, two of which include element methods (Request.JSON, the third module, doesn’t alter the Element prototype). Request.js provides the Element prototype with a send method that lets you post a form (as in, $('myFormElement').send([request options go here])), and Request.HTML.js provides the Element prototype with a load method that lets you replace the contents of any DOM element with text returned from a server request (as in $('myElement').load([request options go here])). I use these fairly often, though I probably use the Request and Request.HTML constructors just as much if not more. But in my own work I found myself needing the combination of these two things; I want to submit the form and load the response into a DOM element. Turns out, I do this all the time.

Part of writing idiomatic MooTools code is encapsulating functionality into Classes. As I’ve posted before, I do this with almost all the code that I write. The only code that I author that isn’t a class (or a static object) is a DomReady statement that instantiates classes. So when I have a pattern as clear as this - submitting a form and updating the DOM with the response - it’s time to write a class.

Form.Request

Form.Request, unlike Request.HTML, is not an extension of the Request class (that’s why it’s not Request.Form). Because it is not a Request.HTML instance, it has a reference to an instance of Request in it. Form.Request’s options include a requestOptions object that gets passed along to this instance so you can configure it however you like. By default, Form.Request derives as much as it can from the form element itself. It gets its URL from the action property and the method from the method property. The user submits the form and it cancels the submit event. Form.Request inspects that event to see if the user clicked a button and, if so, sends the name/value of that button along with the data like a regular form submission. Finally, it provides an extraData option so you an send along key/values with the form in addition to those in the inputs that the user fills out.

When the form returns a response, it handles it pretty much how Request.HTML handles any other response. It injects the HTML and evaluates any scripts in the response (this is an option, too).

And what about what we set out to do? To provide a method for Element that is the combo of load and send? The plugin provides the Element prototype with a formUpdate method that works just like those two methods combined (as in $('myForm').formUpdate({ update: $('myTarget') }), which sends the form and updates $('myTarget')).

Demo Time!

Here’s a simple demo to play with. Note how our html is plain old vanilla web 1.0 form stuff. Nothing fancy. And our JavaScript is dead simple (to get the default behavior).

Getting Fancy

Hmmm. Well, our behavior here leaves a little to be desired. The main thing that seems to be missing is any indication that something is changing - that the form has been submitted and we’re waiting for a response from the server (MooShell provides a 2 second delay on the response to simulate normal web latency). We could add an event to our instance to tell the user that something is going on, like so:

Getting Fancier

Here’s where the fact that this plugin is part of MooTools More comes into play. MooTools More includes a plugin called Spinner. I’ll talk about it in depth some other time, but in a nutshell, it puts an Ajax indicator over an element that’s being updated. It integrates with Request.HTML and Form.Request configures it for us. This happens automatically (unless you disable it in the options) and all we have to do is skin it. In this example, I’ve moved our message (that we’re sending the submission) into the Spinner options.

This magic happens without much effort for us so long as we have Spinner.js in our page. This is the default behavior. We don’t even have to specify the message text if we’re content with just the spinner image.

Even More Integration

One other thing Form.Request integrates with (also in the MooTools More library, naturally) is Form.Validator. That’s another plugin I’m not going to spend a ton of time describing in today’s post - we’ll save it for a later post as it has lots of nifty things in it. But, basically, Form.Validator (and its subclasses) provide instructions for users who are filling out a form on the fly. Form.Request integrates with it so that you don’t have to do anything to make them play nice together. Both intercept the submit event and both prevent its default behavior (i.e. sending the form), except that the Form.Validator class only stops it if the form is invalid. If Form.Request didn’t respect this privilege, it would send our form even if the Form.Validator stopped the default submission event. To get them to cooperate, all you have to do is create an instance of Form.Validator on the form. Example:

In this example, we set a minLength value for our form (50 characters). The default html in the textarea is only about 45 characters, so if you just hit submit you’ll see a red error message show up. Add some more text to our example, hit submit, and the error winks out and our form sends just as before.

Appending Results

One last trick up our sleeves here; you can append results instead of overwriting the contents of our target. Think of a to-do list kind of interface, where adding a value adds a new item to a list. To get this behavior, we just substitute Form.Request.Append into our example. There are some additional options; by default it uses another MooTools More plugin, Fx.Reveal, to smoothly transition elements into view. You can also specify if the item is appended to the top or the bottom of the container. Example:

THEND

So that pretty much covers Form.Request. I hope you find it as useful as I do. If you find it useful and fun, post a link in the comments showing off what you’ve done with it. In my next post I’ll pick another plugin (or plugins) to dig into and show off their capabilities. If there’s one you’d like to learn more about, post a suggestion for my next post in the comments.

Aaron Newton is a contributor to MooTools and the principal developer of MooTools More. He is the author of the book MooTools Essentials as well as the Mootorial online MooTools tutorial. He posts (rarely these days) at his blog Clientcide.com and (much more often) on Twitter as anutron.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All ]
View original post|Add to del.icio.us | Share

languagevalue

Hello everyone,

I’m really excited and pleased to announce that my presentation “MooTools as a General Purpose Application Framework” which I delivered at the FOSDEM is now available on YouTube.

If you are not able to watch the HD-Version you can download the slides here.

Thanks again to the FOSDEM team for inviting me and for giving us such a big platform to present the MooTools project. If I could name one thing that I miss already about Brussels I would certainly say the waffles…

If you enjoyed this presentation and you want me or another developer from the MooTools Core Team to present at your conference feel free to contact us.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All News ]
View original post|Add to del.icio.us | Share

languagevalue

The foundation of every great open source project is its community. The MooTools Team creates the base framework code but it’s all of you that take the framework and build outstanding plugins. Here are some great plugins and tutorials that have been released recently.

MooTools Driver for Rails 3 Helpers

Rails 3 has been recently been released with the new capability to create your own javascript helpers; no longer will you need to use PrototypeJS. Kevin Valdek has created a MooTools helper so that you can use your favorite javascript framework with your chosen Ruby application. Kevin mentioned that his release isn’t complete at this point so feel free to contribute! Great work Kevin!

http://kevinvaldek.com/mootools-driver-for-rails-3-helpers

Moodit

MooTools now has its own Reddit topic. Be sure to share your favorite MooTools posts with all of your friends via Reddit!

http://www.reddit.com/r/mootools/

Moodoco

Moodoco is a purely web-based client-side MooTools documentation generator with HTML5 offline capabilities created by Lim Chee Aun. It uses the GitHub API to fetch all the Markdown documentation files from the repository and stores them offline in localStorage.

http://github.com/cheeaun/moodoco

MultiSelect

MultiSelect is a MooTools plugin from Blaž Maležič that turns your checkbox set into one single multi-select dropdown menu. This highly inventive plugin is a great way to make your select boxes much more appealing.

http://mootools.net/forge/p/mutiselect

Mif.Tree

Mif.Tree is a flexible tree-generation plugin that loads trees of information from javascript objects. You could, for example, output a JSON representation of a directory and view your server via HTML/javascript trees.

http://mootools.net/forge/p/mif_tree

Featured Blog: Ryan Florence

Ryan Florence’s blog has been doing an outstanding job of explaining complex MooTools concepts. Be sure to check out his blog!

http://ryanflorence.com/

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your plugins in future posts!

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[Roundup ]
View original post|Add to del.icio.us | Share

languagevalue

UPDATE: 1.2.4.4 is also released; there was a new bug in Tips introduced in 1.2.4.3 that was immediately patched.

This is mostly a bug fix release.

• Nearly 50 bug fixes (see the milestone for 1.2.4.3 in Lighthouse).
• Keyboard:
  • Added some support for just pressing ‘shift’, ‘control’, or ‘alt’
  • Added a bunch of keycodes for Mac compatibility
• Keyboard.Extras:
  • Support for “shortcuts” which are keyboard entries that have names and descriptions.
  • Also provides methods for listing all the active shortcuts as well as allowing a shortcut to be rebound (for instance, if you were to allow the user to choose a key for a shortcut).
  • Added a change event to Keyboard.manager whenever any keyboard is activated.
• Tips:
  • NEW Tips option “windowPadding” allows you to reduce or expand the virtual size of the window for tip positioning. Defaults to {x:0, y:0}. You can use that is a workaround for the scrollbars not being considered when calculating tip positions.
• HtmlTable:
  • fixed numerous bugs filed in Lighthouse
  • HtmlTable can no longer apply it’s click behavior more than once.
  • HtmlTable now pushes headers defined in the options.
  • Reworked HtmlTable’s DOM a bit to allow for positioning of the sort icon
  • Added new set method for headers and footers.
  • Fixed error in HtmlTable.Parsers when sorting by date. format(‘db’) was being applied to the text and not the date object.
• Array:
  • Added Array.shuffle
• Request.JSONP:
  • Made JSONP pass all arguments, not just the first, to its complete/success methods; see this discussion on the google group.
• Fx.Slide:
  • Added an option to specify the wrapper element for Fx.Slide. Was already present in the docs but could not be passed as an option.
• Mask:
  • Added options for the IframeShim for Mask

Download it with the MooTools More builder.

As usual, if you find any issues, file a ticket at lighthouse. There are already tickets open for 1.2.4.4 that we are not including fixes for in this release. Look for a release for these things in the next few weeks.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[Releases ]
View original post|Add to del.icio.us | Share

languagevalue

With the release of the Forge in December the way people contribute to MooTools has changed. The quality, amount, and the variety of plugins has amazed all of us. There are already more than 100 plugins available. In addition to that, Jacob Gube (SixRevisions) and MooTools contributor Garrick Cheung (@garrickcheung) have co-authored a new MooTools book aimed at JavaScript beginners.

Aaron has written an extensive review about MooTools in 2009. I expect 2010 to be an even better year for our Framework. As a first step we would like to invite you to meet part of the MooTools Team at the FOSDEM in February in Brussels where I will do an interesting talk about MooTools as a General Purpose Application Framework.

The real strength of MooTools, however, is you — the community. Here are a few of the many great MooTools plugins that were released during the month of December.

PassShark

Created by MooTools contributors Luis Merino (@Rendez) and Nathan Querido (@nfq), PassShark duplicates the iPhone’s method of password masking. A great method for making your passworld fields a bit easier to use.

• PassShark on the Forge
• Blog-Entry

MooPix

MooPix is not only a MooTools slideshow function but a method for accessing your public Flickr photos. Though no server side scripting is required, MooPix remains very small.

• MooPix Website

Notimoo

Notimoo is a simple Mac Growl clone made with MooTools. At only 4KB Notimoo is a lightweight but still provides the right amount of customization.

• http://www.paquitosoft.com/notimoo/

MGFX.Tabs 1.1

Sean McArthur has recently updated his popular Tabs class by making it more efficient and more flexible.

• MGFX.Tabs 1.1 on the Forge
• Blog Post and Demo

Fx.TransMorph

This Plugin by Lim Chee Aun (@cheeaun) allows a different transition for every property that is being animated.

• Fx.TransMorph on the Forge

Other Stuff Worth Mentioning

• Webkit Gradient Creator (double click to create new pins!)
• Scroll Clock
• MooTools FormValidator Tutorial
• Offline MooTools Docs Generator
• HTML5 Audio Player with MooTools
• WTFramework? 2.0 (must-have bookmarklet)

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your plugins in future posts!

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All Roundup ]
View original post|Add to del.icio.us | Share

languagevalue

Users wishing to upgrade any large site from MooTools 1.1 to 1.2 can sometimes find it difficult. The API for 1.2 changed quite a bit, so without help upgrading your code can be fraught with danger.

Our solution is an upgrade helper that will allow you to replace your old MooTools 1.1 code with 1.2 code by logging deprecated methods to the console and telling you what needs to be changed.

The upgrade helper also attempts to automatically convert 1.1 calls to 1.2 calls. However, this helper is not really meant to be a compatibility script so much as a script designed to help you migrate your code. In almost all cases methods that have been deprecated or have had their API altered will provide feedback to the console when they are called. Ideally, developers will put this script into their environment with MooTools 1.2, use their application and change all the calls that throw warnings, then remove the upgrade helper from their environment.

Using the Upgrade Helper

You can download the upgrade helper on the MooTools Download Page along with current build of MooTools built for it. This companion library has all the functionality found in MooTools 1.1 (Drag, Accordion, etc. - some of these plugins moved out of MooTools Core and into MooTools More in 1.2).

Simply replace MooTools 1.1 with MooTools 1.2, include the upgrade helper, then include your site’s code. Browse your site with a browser that provides a console API (we recommend Firefox with Firebug) and take note of the warnings thrown (note, you can adjust the logging; see the readme). Address these in your code base until you cannot find any more, then remove the upgrade helper. You have now an upgraded website, and you can use the plugins in the Forge!

If you still have warnings after you have finished converting your code, have a look at the documentation for 1.1 and 1.2 and also the source code in the upgrade helper. Most changes are simple, but may require a change of arguments. There are a few breaking changes but in the vast majority of cases these should not affect you. A complete list of the changes between 1.1 and 1.2 can be found in the readme of the github upgrade-helper repository.

Feedback, Help, and Resources

The upgrade helper is being released as a beta for now. We’ve written and run tests against the browsers we support but the real world usage of MooTools will be the real test. As such, we hope that you, the MooTools community, will help us polish this script, by letting us know what features on your sites don’t work. Bugs can be filed using the github issues for the repository.

Arguably, this is something we should have provided long ago. Going forward, we’ve pledged to make all releases 100% backwards compatible for all documented methods and features.

Should you require any guidance or assistance, you can, as always, find us in the #mootools IRC channel or post in the MooTools Google Group.

Last of all, massive thanks to Nathan White and David Isaacson, for their early work on this. In the last few weeks the MooTools Dev team has spent a lot of time making and testing this upgrade helper, but these guys kicked this off with their contributions and they are most appreciated.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[Releases Tips & Tricks ]
View original post|Add to del.icio.us | Share

languagevalue

If I was to highlight the single most important thing for MooTools in 2009, I would say without a doubt it’s been its community. This year has seen the involvement of many individuals from all over the world that have contributed their time, expertise, talent and charm. Our San Francisco & London hackathons are clear confirmation of this.

Today we’re introducing a tool that has been in the works for the past few months that we believe will change how our community collaborates forever. Meet the MooTools Forge.

The Problem

As a framework, you probably expect MooTools to be compact and provide you with the tools that solve most of your JavaScript problems easily and elegantly and that’s been our goal all along. But for all the other specific needs that your projects have, no matter what framework, you’ve probably found yourself googling for plugins or snippets before. No one wants to reinvent the wheel.

That Google search will probably return thousands and thousands of results. Many people have even approached the same problem in many different ways (try searching for a mootools slideshow plugin!). This distributed model, although relatively effective, represents problems for both users and developers.

For the users, it becomes hard to establish comparisons between the plugins as every developer will represent them differently on their websites. Sometimes it’s hard to find a demo, sometimes you just don’t know how to use the thing. Other times the website will be offline for a couple hours, or maybe you don’t know on what other components the plugin might depends to function.

But can we blame developers? Creating a plugin that you can distribute to people takes work. And for some of us, experience shows that writing documentation, uploading it to our cumbersome blog systems, preparing screenshots (and then upgrading them upon a new release!) can sometimes be even more difficult than writing the plugin itself. Still, there are some good reasons to consider releasing your code.

The Solution: for users

For people trying to find plugins, we wanted a simple interface with visual focus on what’s available. Going through lists of plugins whose names are not always that intuitive or descriptive is both boring and inefficient. You might find yourself opening dozens of tabs just to see what the plugin can potentially offer. We want to try and put all the information you need to make a choice right in one place.

While each plugin can have tags that you can browse, we also came up with a concise list of categories that group the most recurrent functions: Effects, Forms, Interface, Media, Native, Realtime, Request, Utilities, Widgets.

For plugins themselves, we wanted to make three basic tasks easy: seeing a demo, downloading, learning how to use. This is the result:

We believe it’s important as well to know who is behind the scenes. To see who is that guy or girl that spent the time to create that amazing piece of functionality that impressed your clients or boosted your website usability. As such, the MooTools Plugins repository comes with simple to tools support to allow you to stay in touch.

The solution: for developers

We’re very proud of how straightforward and efficient we’ve made it for developers to add plugins that:

• look great
• specify dependencies
• have descriptions with syntax highlighting
• are easy to maintain

We decided to integrate with GitHub, the social coding website, to enable developers to focus on the code and nothing else. By following a few simple guidelines, you’ll be able to deploy code to the source control repository (git), and then only click one button in our website: either the one to add it, or the one to update it.

In the following video, I’ll show you how I create an account, upload my plugin, and then update it in 30 seconds.

Conclusion

We hope you like this new website feature as much as we do, and we look forward to your involvement and contributions.

As an user of the system, if you see something off or have a suggestion, please drop us a note.

As the developer and maintainer of the project, I want to give my special thanks to Chris (for his help with Markdown parsing), Oskar (for his design help) and the Symfony project, for providing us with a great framework to build on, as well as the entire MooTools development team who helped find bugs and provided countless suggestions on how to make it better before we launched it.

But the plugin repository itself wouldn’t be anything without you - the MooTools Community. As much as the plugins catalog is for you, it must by definition be by you, too. As excited as we are to have this finally online, it doesn’t compare to our excitement to see what our awesome community comes up with every day.

On another note, the technology that empowers the Forge has been opensourced, for the use of any other open source project.

Happy hacking!

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[News ]
View original post|Add to del.icio.us | Share

languagevalue

Anyone that follows any MooTools Core Developer or Contributor on Twitter may have seen us talking about a ‘hackathon’. Last weekend a large number of the dev team met up in London to work on various parts of the framework. We thought we’d share with you what we got up to, some pictures, and give you a quick update on what to expect over the coming months.

Significant progress was made on MooTools 2.0. Additionally, we will be releasing a 1.3 version shortly, which will include some of the awesome stuff from MooTools 2.0, so you can get your hands on it a bit quicker.

MooTools ART also was given some love. One sticking point has been that Internet Explorer does not support the <canvas> tag but now thanks to Simo Kinnunen (sorccu) we have a VML adapter so we can push on with this development. We can now combine this with the work Aaron Newton has done with Cloudera and we should be able to launch a beta in the coming months. We’re really excited by ART and hope you are too.

Another way we want to improve the MooTools experience is by adding demos to the documentation, particularly for some of the UI components in More. The Mootorial has always been a fantastic resource and thanks to Piotr Zalewa (zalun) and the awesome MooShell we are now beginning to prepare embedded examples in our documentation. We’re writing some great snippets and demos and you can expect to see these appearing on our documentation pages over the coming weeks. We really love MooShell and the team have some great improvements to this valuable tool almost ready, including user accounts and versioning. Keep your ears peeled for a blog post with more details soon!

Next year we hope we can organize similar meet-ups that you, the users, can attend. We certainly intend to hold one in London in the spring, and are discussing other venues across the world. We’re really excited by the prospect of being able to meet people face-to-face and hope that some talks and workshops are something that the community want.

We also want to give a big thank-you to Abacus e-Media for hosting the event. Here are some pictures of the dev team at work:

• http://www.nathanquerido.com/
• http://picasaweb.google.com/christoph.pojer/LondonHackathon
• http://www.flickr.com/photos/zalun/sets/72157622853461134/show/

Look forward to an exciting announcement about the Forge which is currently in private beta — your treasure trove of MooTools plugins will be here in time for Christmas.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[News ]
View original post|Add to del.icio.us | Share

languagevalue

As mentioned in the new features in MooTools More in 1.2.4.1, there’s a new plugin called Depender which uses MooTools dependency mappings to allow you to lazy load additional scripts on the fly based on what you need. Rather than list every single file you depend on, you just list the features you want to use and it computes all the specific files needed and each of the files that they need (and so on), excludes the files you already have, and then injects the remaining scripts into the document, providing a callback.

Unfortunately this method is rather slow. The JavaScript plugin must inject each individual script in the dependency list and all these requests can only go as fast as your browser can make them. As a companion to this plugin, we have also authored a stand alone server side application.

New Server-Side Depender

The new server-side depender companion app ships in two forms: a PHP version and a Django version. They each have their own positives and negatives. The PHP version ships with a web-based interface — a builder you can use to check off the things you want in your download (similar to what you see on MooTools.net). On the other hand, the Django version is faster. The Django app caches everything to memory but the PHP version caches results to disk.

Depending on your needs, you can also use these server-side applications to lazy load chunks of functionality on the fly. This obviously requires your application to talk directly to the server when it needs more code. These apps aren’t designed for enterprise scale.

The server side applications are available on github. We still consider the state of this project to be beta, but we want to get the tools into your hands now. If you have any feedback or find any bugs, we want to hear about it. Check out the documentation to see how it all works, including the Depender Client(docs), which gives you this nifty interface:

Depender.require({ scripts: ['DatePicker', 'Logger'], //array or single string for one item callback: function() { //your code that needs DatePicker and Logger } }); //later, you need to load more dependencies... Depender.require({ scripts: 'Fx.Reveal', //array or single string for one item callback: function(){ //if, for some reason, Fx.Reveal is available already, //then this function will execute immediately, otherwise it will //wait for the requirements to load $('someElement').reveal(); } });

Libraries that you download with Depender will all have a standard header that looks something like this:

//MooTools, <http://mootools.net>, My Object Oriented (JavaScript) Tools. Copyright (c) 2006-2009 Valerio Proietti, <http://mad4milk.net>, MIT Style License. //MooTools More, <http://mootools.net/more>. Copyright (c) 2006-2009 Aaron Newton <http://clientcide.com/>, Valerio Proietti <http://mad4milk.net> & the MooTools team <http://mootools.net/developers>, MIT Style License. //Contents: Core, Browser, Array, Function, Number, String, Hash, Event, Class, Class.Extras, Element, Element.Event, Element.Style, Element.Dimensions, Selectors, DomReady, JSON, Cookie, Swiff, Fx, Fx.CSS, Fx.Tween, Fx.Morph, Fx.Transitions, Request, Request.HTML, Request.JSON, More, Element.Shortcuts, Element.Measure, Fx.Reveal //This lib: http://clientcide.com/js/build.php?requireLibs=mootools-core&require=Fx.Reveal&compression=none

This header includes, among other things, a manifest of the contents of the file and a url that can be used to retrieve it again. This is especially useful if you want to come and download the file again for the latest version.

The builder on MooTools.net does not use Depender yet but we will deploy it there soon. You can see it live on the Clientcide builder.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[Releases ]
View original post|Add to del.icio.us | Share

languagevalue

The foundation of every great open source project is its community. The MooTools Team creates the base framework code but it’s all of you that take the framework and build outstanding plugins. Here are some great plugins and tutorials that have been released recently.

MooShell

MooShell, created by Piotr Zalewa (zalun), is the best code pasting tool since Pastebin. MooShell allows you to paste your HTML, CSS, and MooTools javascript into the page and test. MooShell is an excellent utility for troubleshooting an issue or demonstrating your code.

http://mooshell.net/

Up The Moo Herd IV: There’s A Class For This

MooTools contributor Mark Obcena keeto continued his excellent series of “Up the Moo Herd” tutorials with “There’s a Class For This.” This post discusses Class Mutators, Mixins, and MooTools’ inheritance model. Consider this post a must-read for novice and expert MooTools developers.

http://keetology.com/blog/2009/10/27/up-the-moo-herd-iv-theres-a-class-for-this

MooRTE: The Mootools Rich Text Editor

MooRTE is a great MooTools rich text editor. MooRTE is lightweight, customizable, and very easily skinnable. Try MooRTE out in your CMS!

http://siteroller.net/projects/moorte/

Call to Upgrade: MooTools 1.1.2 and MooTools 1.2.4

Remember to upgrade your MooTools 1.1 and MooTools 1.2 builds to 1.1.2 and 1.2.4 respectively. Firefox 3.6 has removed document.getBoxObjectFor which will impact Gecko detection.

http://mootools.net/blog/2009/11/02/upgrade-mootools/

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your plugins in future posts!

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All ]
View original post|Add to del.icio.us | Share

languagevalue

You’ve probably noticed a flurry of MooTools 1.2 updates recently, including updates to both MooTools Core and More. We’re happy to give them to you and hope you continue to upgrade your existing MooTools 1.2.x builds. We would like to bring to you attention an upgrade to the MooTools 1.1.2 build and MooTools 1.2.4 build which should be considered a mandatory upgrade for developers still using MooTools 1.1 and MooTools < 1.2.4.

Firefox 3.6 and document.getBoxObjectFor

The reason we stress the upgrade to MooTools 1.2.4 and MooTools 1.1.2 is the removal of the document.getBoxObjectFor method in the upcoming Mozilla Firefox 3.6 release. Within the browser detection code of MooTools 1.1 and earlier versions of 1.2, MooTools attempts to identify the Gecko engine by checking for the existence of document.getBoxObjectFor. Mozilla’s removal of this method in Firefox 3.6 effectively breaks Gecko detection in MooTools 1.1 and MooTools 1.2.3 down.

“What Effect Does This Have on My MooTools Build?”

Gecko detection is used within MooTools only twice — both times for event handling:

• Event.relatedTarget - Identifies the related target of any given event. This property is used in multiple places throughout the framework.
• The mousewheel event - Firefox identifies mousewheel events using “DOMMouseScroll” instead of “mousewheel.”

These items are at risk to break without upgrading your MooTools build.

The Solution Moving Forward

We have overhauled our browser detection to be based on the user agent string. This has become the standard practice among JavaScript libraries because of potential issues as Firefox 3.6 demonstrates. As browsers grow closer together, looking at “features” to separate them will become more difficult and risky. From this point forward, browser detection will only be used where it would be impossible not to, in order to give the consistent experience across browsers that one would expect from a world-class JavaScript framework.

“Where Can I Download Upgrades?”

You may download the updated MooTools 1.1.2 build on the MooTools 1.1.2 download page. You may also grab MooTools 1.1.2 from GitHub.

You may download the updated MooTools 1.2.4 build on the MooTools 1.2.4 download page. You may also grab MooTools 1.2.4 from GitHub.

Thank you for upgrading. We look forward to continued success with the MooTools javascript framework!

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[News ]
View original post|Add to del.icio.us | Share

languagevalue

There’s nothing like releasing code to uncover glitches. Since last week’s release of MooTools Core 1.2.4 and MooTools More 1.2.4.1, there have been a few bugs reported and we wanted to get the fixes out to you as quickly as possible. Most of these are minor. We have unit tests for all the classes we release, but writing a test for every possible configuration is tough, and it’s the real world that sees these features used in ways we can’t imagine.

Today’s release offers no new features, a lot of very minor fixes (to docs and the like), and the restoration of a few changes to the API that weren’t intended (Tips and Fx.Slide, in particular).

Here’s what’s in 1.2.4.2:

• roughly a dozen issues fixed or closed (in lighthouse)
• Numerous documentation updates
• Spinner: Adding a getSpinner method to Request in Spinner’s refactoring of that Class
• Spinner: Fixing default styles
• Form.Validator, Date: Added Ukrainian translations
• Date: Added new Date parser (parses “Thu Oct 22 08:11:23 +0000 2009”)
• Fx.Accordion: handling the alwaysHide option so you can still have returnHeightToAuto set to true (see this discussion)
• Tips: Restoring arguments to the show/hide events; tip no longer defaults to display:none (this restores the previous behavior)
• Fx.Reveal: stores cssText whenever it starts a transition and restores it when it finishes or is canceled, leaving the element without a bunch of inline styles, as if you’d just done setStyle(‘display’, ‘block’/’none’)
• Fx.SmoothScroll: adding a “scrolledTo” event
• Drag: added new ‘stopPropagation’ option
• HtmlTable.Select: ensuring that instances only delegates to immediate children (for nested tables)
• HtmlTable.Sort.js: detects and sorts date columns more accurately, handles negative integers and floats
• Reorganized scripts json so Depender can implement Log

As always, if you find any issues, file tickets and we’ll get on it.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All ]
View original post|Add to del.icio.us | Share

languagevalue

It’s been three months to the day since the last point release of MooTools and we’re excited about all the goodness packed into this release. At this point, the 1.2 codebase has a very stable API, and our current plan is to release these point releases every three months or so until the 2.0 codebase is online. If we find any serious bugs, though, we’ll be sure to get fixes into your hands as fast as we can.

Non-breaking Changes

Before we get started telling you all the yummy stuff we’ve got for you, let us first assure you that the code we released today is 100% backwards compatible with the previous versions. Upgrading should be as simple as dropping the new files in place.

MooTools Core - 1.2.4

This version of the MooTools Core is one of the most tested and refined we’ve ever released. We’ve fixed numerous small bugs, but the ones you may notice most of all are:

• Added Trident 6 (IE8) detection
• Request can take an instance of URI as a url
• JSON.stringify and JSON.parse native methods are now accessible
• DomReady always fires before load event
• Fix for creating a Request in early versions of IE6
• Fixes and optimizations for Element.getOffsets

This short list doesn’t do it justice, there have been roughly 70 commits to the core since 1.2.3, but most of these fixes are minor including adding to documentation, adding more tests, etc. The point here is that the 1.2 branch is increasingly stable, which is why we release it so infrequently.

Gecko (Firefox) Detection in 1.2.4, 1.1.2

MooTools has always used object sniffing to detect rendering engines, and while not perfect, this method has proved very reliable in recent years. However, the upcoming Firefox 3.6 marks a shift in our thinking on this subject because Gecko detection will no longer work on it without an update. We recognize the significance of this, and therefore are releasing updates for both 1.2 and 1.1 because we understand that 1.1 is still in widespread use.

Looking towards 2.0, we have overhauled our browser detection to be based on the user agent string. We realize that this is not without its forward compatibility risks, however it is the standard practice among JavaScript libraries because of potential issues as Firefox 3.6 demonstrates. As browsers grow closer together, looking at “features” to separate them will become more difficult and risky. User agent strings, on the other hand, have remained very consistent in recent years with the exceptions being in mobile browsers and with Google Chrome coming on stage. With 2.0, browser detection will only be used where it would be impossible not to, in order to give the consistent experience across browsers that one would expect from a world-class JavaScript framework.

For those of you still running 1.1, it is imperative that you update to 1.1.2. When we get 1.1.2 up on Google’s JavaScript CDN service, those of you requesting 1.0 or 1.1 from that service should see the upgrade without doing anything. If you do not update your 1.1 scripts, users visiting in Firefox 3.6 and beyond will likely encounter issues.

MooTools More - 1.2.4.1

While MooTools Core has remained pretty much the same since the original 1.2 release, MooTools More continues to add new features that should make building sites even easier. This release is jam-packed with bug fixes and new plugins, and we’re excited to see what the community will do with them. Here’s a quick list:

• over 30 issues fixed or closed (in lighthouse)
• New feature: Element.Delegation - a partial port of event delegation from MooTools 2.0 (does not support custom events or blur/focus)
• New feature: Elements.From converts html strings to DOM elements
• New feature: Depender - a client side MooTools dependency loader ** Related: Depender App - a server side implementation (that’s much faster) - more on this in a later post
• New feature: Mask - masks elements (including the window) with a semi-opaque overlay
• New feature: Spinner - automates the creation of ajax spinners over DOM elements being updated (previously known as Waiter on Clientcide.com)
• New feature: Form.Request, Form.Request.Append - automates creating ajax forms that update HTML in DOM elements (previously Fupdate on Clientcide.com)
• New feature: HtmlTable, HtmlTable.Zebra, HtmlTable.Sort, HtmlTable.Select - interactive and auto-generated html table elements
• New feature: Keyboard - a robust event manager for keyboard groupings
• Added new option to Fx.Accordion: returnHeightToAuto
• FormValidator is now Form.Validator ** Added credit card number validator to FormValidator
• MooTools Lang is now a part of MooTools More (again)
• Added timeDiff method to Date.Extras
• Added ability to ignore scroll position with Element.Position
• Element.setPosition is now Element.position (non-breaking change)
• Added hideAll and showAll methods for OverText
• Added Element.isVisible method
• URI’s get method no longer returns null for missing parts; it returns an empty string.
• Various other tweaks and bug fixes

Get Coding!

This release has a lot of good stuff in it, but it’s worth noting we have a LOT of other things in the oven right now.

The MooTools development team continues to grow and the more people involved with the creation of the framework, the more cool things we can release. If you want to get involved with making MooTools, all you have to do… is start writing code. Get involved on github, in the mailing list, and start getting your own plugins ready for the upcoming release of the MooTools Forge.

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All ]
View original post|Add to del.icio.us | Share

languagevalue

The MooTools team would like to announce the launch of an enhanced MooTools web search:

MooTools Search Beta: http://mootools.net/search

This enhanced search has been integrated with the MooTools documentation and will help you easily navigate and identify information in the documentation better than the previous documentation search. The new search system also searches multiple domains — this will allow you to find MooTools demos, forum posts, tutorials, screencasts, and anything MooTools-related. Initial supporting domains include MooTools.net, Clientcide, The MooTorial, David Walsh Blog, etc. We will also pay attention to most-searched terms and aim to ensure the search feature is providing sufficient, quality results.

This enhanced search release is considered beta. We will soon be adding further enhancements based on team goals (including full site search, etc.) and feedback provided by our most valued asset: the MooTools community.

Special thanks to Darren Waddell (fakedarren) for all of his hard work in implementing and maintaining the new search system!

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All ]
View original post|Add to del.icio.us | Share

languagevalue

The foundation of every great open source project is its community. The MooTools Team creates the base framework code but it’s all of you that take the framework and build outstanding plugins. Here are some great plugins and tutorials that have been released recently.

MilkChart

MilkChart is an outstanding set of MooTools classes that create robust charts from your static data. Chart types include column, bar, line, scatter, and pie. MilkChart uses the HTML5 <canvas> tag and is only supported on browsers other than IE.

http://code.google.com/p/milkchart/

MooTools Tree Component

MooTools Core Developer Christoph Pojer (cpojer) released Tree Component, an advanced tree structure plugin which allows for drag and drop organization, cookie tree saving, and collapsible branches.

http://cpojer.net/blog/MooTools_Tree_Components

MTMultiSelect

Authored by Justin Donato, MTMultiSelect is a great plugin that allows you to select multiple items from a paginated list. You may also search the list of items to quickly identify the items you’d like to select.

http://www.justindonato.com/demo/mtmultiselect/

MultipleLinks

MultipleLinks is a MooTools class created by Merrick Christensen. MultipleLinks is a tooltip-like plugin that provides the user a list of possible destinations to click to. MutipleLinks is also highly skinnable.

http://thejavascriptblog.com/mootools-multiple-links-class/

Request.Twitter

MooTools Core Developer Scott Kyle (appden) created Request.Twitter, a very small MooTools class to retrieve tweets from Twitter. The class is flexible in that you may define the URL to query so you may retrieve user statuses, search terms, etc. Request.Twitter is an extension of the Request.JSONP class in MooTools More, showing the power MooTools’ valuable inheritance system.

http://appden.com/javascript/get-tweets-with-mootools/

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your future plugins in upcoming posts!

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All ]
View original post|Add to del.icio.us | Share

languagevalue

There’s always a lot going on behind the scenes with the MooTools javascript framework. And how could there not be? Here’s a look at what’s coming in the next few months.

MooTools Core 1.2.4 and 1.1.2

As we turn our attentions towards MooTools 2.0, version 1.2 will not receive any significant upgrades. However, until MooTools 2.0 is released we will continue to support the current version with bug fixes. To that end we’re releasing MooTools Core 1.2.4 which fixes several small bugs and addresses a change coming in the next release of Firefox. Because of this inconvenient Firefox change, we’ll also be releasing MooTools Core 1.1.2, an update to the 1.1.1 release. Sites using 1.1.1 will be able to drop in 1.1.2 without it affecting anything. We’ll post more details on this when we release these two updates.

MooTools More 1.2.4.1

While the 1.2 version of MooTools Core no longer accepts additions, MooTools More, the official plugins collection, continues to be iterated upon constantly. Included in the next version of MooTools More (1.2.4.1) are numerous bug fixes and performance enhancements, along with new widgets, classes, and extensions for you to play with. Here are a few:

• Mask - An overlay class that allows you to put a semi-transparent layer above any element, including the window.
• Spinner - This class automates putting an AJAX indicator over any element.
• Form.Request - This class makes any form element into an AJAX form.
• HtmlTable - This suite of classes let you create HTML tables on the fly, update and alter their contents, make them zebra striped, selectable, and sortable.
• Keyboard - The Keyboard class provides the tools necessary to manage a complex user interface with different keyboard enhancements.

Depender

Another plugin coming in MooTools More 1.2.4.1 is a client side dependency manager. This class allows you to lazy-load files from the MooTools libraries and any other libraries that use similar organization (i.e. those that map their dependencies with the same mechanisms).

In addition to this client side implementation of the dependency loader is a server side version that greatly improves performance. The server side implementation concatenates and (optionally) compresses the files together so that there’s only one request and is far more efficient.

MooTools ART

MooTools ART has been under development off and on for nearly a year now and for the most part has been under wraps. MooTools ART is the foundation for MooTools’ upcoming UI library. Using canvas and VML, it features support for dynamic illustrations, allowing complex UI elements that have numerous interactive states. When released, will come with numerous plugins for stylable windows, buttons, and more.

One of the most interesting ART features is its support for themes using CSS-like syntax in javascript. In conjunction with the default widgets that come with ART we hope to see the MooTools community create numerous interfaces using the system that allows for a fully themable UI by the end of the year.

Forge

Anyone who has been around the MooTools forums or IRC channel has heard that the user plugin catalog (which we call the Forge) is always “coming soon”. Well, this time, we mean it. The MooTools Forge is a new application which will act as a central repository for MooTools plugins created by, well, by you. The Forge will pull your code directly from GitHub, taking into account versioning and dependencies, and providing plugin usage details.

The Forge is currently in the last stages of testing. Look forward to seeing the MooTools forge by the end of October at the latest.

MooShell

MooShell is an outstanding interactive shell editor for debugging your MooTools code created by Piotr Zalewa. Instead of pasting your CSS, javascript, and HTML into static PasteBins, you may use MooShell to show others the issues you are experiencing with your code. You may also quickly experiment with different techniques and share your ideas with others.

MooTools 2.0

Your favorite javascript framework is about to become 1.612903225806452 times as awesome. MooTools 2.0 will feature an optimized Fx library, an improved Class class (one of the foundations of the entire framework) and inheritance model, blazing fast selector engine (Slick), numerous speed optimizations, and many more goodies. Look forward to a more detailed post soon!

typetext/htmlbasehttp://feeds.feedburner.com/mootools-blog?format=xml
[All ]
View original post|Add to del.icio.us | Share

languagetypetext/htmlvalue

The foundation of every great open source project is its community. The MooTools Team creates the base framework code but it’s all of you that take the framework and build outstanding plugins. Here are some great plugins and tutorials that have been released recently.

MooTools Dependencies Checker

The MooTools Dependency Checker by Arian Stolwijk parses you javascript files to determine which MooTools classes you need to make the file’s javascript code work. Arian’s dependency checker is a great tool for those looking to implement a MooTools plugin or use minified code.

http://www.aryweb.nl/projects/mooDeps/

MooTools InputMask

InputMask is a useful MooTools plugin by Core Developer Christoph Pojer. InputMask allows you to set a template or “mask” for which a string should be formatted like. This plugin is great for date, time, or phone number formatting.

http://cpojer.net/blog/InputMask_Class_for_MooTools

MooTools DatePicker

DatePicker is a great plugin by MonkeyPhysics. DatePicker allows you to provide your users with a calendar to choose dates from instead of making users type in the date. DatePicker is very customizable and allows for easy styling/theming.

http://www.monkeyphysics.com/mootools/script/2/datepicker

MooModernizr

MooModernizr tests the browser’s CSS capabilities — specifically CSS3 feature detection. MooModernizr extends MooTools’ Browser.Features object. MooModernizr is a port of the original Modernizr.

http://www.aryweb.nl/voorbeelden/mooModernizr/

Speed Up Your Moo Part 1: Selectors

MooTools Core Developer Christoph Pojer shares methods for speeding up your applications through the use of optimized CSS selectors. Consider this article a must-read if you use Selectors frequently in your large web applications.

http://cpojer.net/blog/Speed_Up_Your_Moo_Part_1_Selectors

JSCocoaLoader

JSCocoaLoader allows you to develop Espresso.app code editor extensions using MooTools and JSCocoa. JSCocoaLoader’s utility classes are all powered by Mootools, and as a happy side effect your Javascripts can easily take advantage of Mootools many improvements over vanilla Javascript either by requiring a JSCocoaLoader utility class, or by requiring Mootools directly.

http://wiki.github.com/onecrayon/JSCocoaLoader-sugar/mootools-server

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your future plugins in upcoming posts!

basehttp://feeds.feedburner.com/mootools-blog?format=xml
[Roundup ]
View original post|Add to del.icio.us | Share

languagetypetext/htmlvalue

The foundation of every great open source project is its community. The MooTools Team creates the base framework code but it’s all of you that take the framework and build outstanding plugins. Here are some great plugins and tutorials that have been released recently.

MooEditable

MooEditable is a WYSIWYG editor created by Lim Chee Aun (cheeaun). MooEditable features the usual bold, italic, strikethrough, and underline controls as well as the ability to add images, links, and lists.

http://cheeaun.github.com/mooeditable/

MooTools Intellisense

The problem: Visual Studio 2008 doesn’t provide Intellisense for MooTools. The solution: Darren Waddell (fakedarren). Darren has created Intellisense for our favorite javascript framework. Grab this package to increase your productivity within Visual Studio!

http://code.google.com/p/mootoolsintellisense/

PageZoom

Lim Chee Aun (cheeaun) also blessed the MooTools community with PageZoom, a flexible zooming widget that allows you to zoom in on any element within the page. The plugin is especially valuable for zooming in on photos.

http://cheeaun.github.com/pagezoom/

Notification Message Dispatch for MooTools

Tobias Svensson has created NotificationCenter, a simple implementation of a notification center for MooTools which is heavily inspired by NSNotificationCenter from Apple’s Cocoa framework.

http://return42.blogspot.com/2009/07/notification-message-dispatch-for.html

PyCow

As the description says: PyCow translates Python code to JavaScript code with the “MooTools way of class declaration”. Examples of PyCow’s mindblowing functionality can be seen at the PygoWave Server Google Code site.

http://code.google.com/p/pygowave-server/wiki/PythonToJavaScriptTranslator

Up the Moo Herd: MooTools Tips and Tricks

MooTools contributor Mark Obcena (Keeto) examines and explains the finer points of the MooTools Core. His articles are detailed, accurate, and must-reads for MooTools developers. Three posts have been published thus far: The DOM Fetcher Functions, Natives, Generics and Extending the Language, Classes: Constructors, Singletons and Privates.

Why You Shouldn’t Return False in MooTools Event Handlers

MooTools Core Developer Sebastian Markbåge explains why returning false in event handlers can cause you problems. Check out Sebastian’s tutorial to learn more about event bubbling and the proper way of handling events.

http://blog.calyptus.eu/seb/2009/07/why-you-shouldnt-return-false-in-mootools-event-handlers/

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your future plugins in upcoming posts!

basehttp://feeds.feedburner.com/mootools-blog?format=xml
[Roundup ]
View original post|Add to del.icio.us | Share

languagetypetext/htmlvalue

The foundation of every great open source project is its community. The MooTools Team creates the base framework code but its all of you that take the framework and build outstanding plugins. Here are some great plugins that have been released recently.

Slideshow 2

Slideshow 2 by Aeron Glemann is an outstanding photo / slideshow plugin that offers a plethora of options and features — many more than you’d find with the average slideshow or lightbox. Slideshow 2 features Robert Penner easing transitions, photo delays, duration settings, the ability to make Slideshow 2 a lightbox, and an on-photo control panel.

http://www.electricprism.com/aeron/slideshow/

MooTools FileManager

Created by MooTools Core Developer Christoph Pojer, MooTools FileManager is a MooTools-driven file manager that allows for drag and drop file management, Ajax directory loading, file content previews, and much more.

http://og5.net/christoph/article/MooTools_based_FileManager

Moousture

Moousture is a MooTools Mouse Gesture library created by Zohaib Sibt-e-Hassan. Moousture allows you to create multiple geture patterns and assign them to any number of elements. http://neofreeman.freepgs.com/Moousture/

Fancy Upload 3

Fancy Upload 3 is the newest iteration of Harlad Kirschner’s popular Flash/MooTools upload tool. Fancy Upload 3 features file-specific options, an additional IFrame-based uploader, Flash 9 and 10 compatibility, and the same base features that made Fancy Upload a must-have plugin.

http://digitarald.de/project/fancyupload/

MooTools.Mode For Coda

If you spend hours with MooTools and the Coda text editor, you’ll love the MooTools.Mode Syntax Mode add-in. This package created by José Prado is free and easy to install.

http://pradador.com/code/coda/moomode.html

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your future plugins in upcoming posts!

basehttp://feeds.feedburner.com/mootools-blog?format=xml
[Roundup ]
View original post|Add to del.icio.us | Share