Publicidad [cerrar]

Setting Up Elements

Written By , on Thursday, June 10th 2010, 11:16pm

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.

MooTools Core 1.3 beta 2

Written By Christoph Pojer, on Thursday, June 3rd 2010, 10:46pm

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

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.

A Magical Journey into the Base Fx Class

Written By , on Tuesday, May 18th 2010, 11:46am

Fx 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.

Announcing: MooTools in Real Life

Written By Michelle Steigerwalt, on Wednesday, May 5th 2010, 12:52pm

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:

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!

More than Meets the Eye: Form Validator

Written By Aaron Newton, on Friday, April 30th 2010, 3:09pm

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).

Publicidad [cerrar]
[ botanical | internet directory | motos motor españa | furgonetas motor españa | mootools code ]
horoscopos diseño grafico valencia