Widgets: Posts

A while ago I authored a FormValidator class for Mootools and I just spent a few hours adding a lot more functionality to it. In a nutshell:

• Warnings - you can now author warnings for the user that won’t prevent the form from being submitted.
• Ignore Fields - if the context changes, you can ignore entire fields (for instance, if they are hidden)
• Stop/Start - you can toggle the validator on and off.
• Serialization - by default only one error is shown unless the user explicitly changes a value. This means that if a user tabs past a required field and it produces an error, when they back up to fill in that field, the field they just tabbed into won’t produce an error. If the user actually changes a value, the validation will produce an error if the field fails validation, regardless of the state of other errors. This is all configurable, and is just there to make the form a little less annoying.
• Instance Validators - previously, the only way to add a Validator was to add it to all the instances of FormValidator. Now you can add instance-specific validators. You can also extend FormValidator and add validators to all its instances. This way, you can add global validators (FormValidator.add), semi-global validators for Classes based on FormValidator (MyFormValidator.add) and specific instance validators (thisFormsValidator.add).

You can see this in action in the Wikitorial and dig into the options in the docs.

I've refactored stickyWinHTML (see this previous post) a bit more to allow for as many buttons as you like.

Here's a quick code example:

PLAIN TEXT

JavaScript:

var simpleLayoutExample = stickyWinHTML('the caption', 'this is the body', {
  width: '400px',
  buttons: [
    {
      text: 'close',
      onClick: function(){alert('closed!')}
    },
    {
      text: 'okey-dokey',
      onClick: function(){alert('ok!')}
    }
  ]
});
$('layoutExample').adopt(simpleLayoutExample);

var simpleLayoutExample = stickyWinHTML('the caption', 'this is the body', {
width: '400px',
buttons: [
{
text: 'close',
onClick: function(){alert('closed!')}
},
{
text: 'okey-dokey',
onClick: function(){alert('ok!')}
}
]
});
$('layoutExample').adopt(simpleLayoutExample);

The buttons array allows for as many buttons as you like. You can see more detail in the wikitorial on this topic.

Note: the old options (closeTxt, onClose, confirmTxt, and onConfirm) are still supported, though deprecated.

I added large close and confirm buttons to the default stickyWinHTML layout. You can make them read whatever you want and you can assign callback functions to them getting clicked. They are optional, and not visible by default. Note the section in the link above about how the onClose event is NOT the same as the onClose event for StickyWin.

That little "x" for closing the StickyWin is pretty small, and on pages like in our CMS, I think an easier to click close button would make it easier to deal with these things, especially if you end up opening them often. If you don't specify a closeTxt or confirmTxt value, the buttons are not there. The callbacks are not required. Example:

PLAIN TEXT

JavaScript:

new StickyWin({
  content: stickyWinHTML('the caption', 'this is the body', {
    width: '400px',
    closeTxt: 'close',
    confirmTxt: 'okey-dokey',
    onClose: function(){alert('closed!')},
    onConfirm: function(){alert('confirmed')}
})});

new StickyWin({
content: stickyWinHTML('the caption', 'this is the body', {
width: '400px',
closeTxt: 'close',
confirmTxt: 'okey-dokey',
onClose: function(){alert('closed!')},
onConfirm: function(){alert('confirmed')}
})});

Helping out our CMS group today I hacked out a new little widget class called "Confirmer" that handles notifying the user when something they've done on the page requires some sort of notice. An auto-save, or the failure to auto-save, or any other sort of message.

It's designed to be unobtrusive so it doesn't annoy the user too much if it happens a lot. You can have the prompt inline in the page or floating over it. The message just fades in and then back out. It comes with default styles that can easily be overridden, the message displayed can be changed every time you call it, and its easy to position it relative to an element or at the edge of the screen.

Quick example:

PLAIN TEXT

JavaScript:

new Confirmer().prompt(); //watch the upper right of your screen

new Confirmer().prompt(); //watch the upper right of your screen

More examples and details in the wikitorial.

Over at Ajaxian today they have a post on miniajax.com which describes itself as "a showroom of nice looking simple downloadable DHTML and Ajax scripts".

I'm not sure if they authored these scripts or if they just collected them all into slick looking examples. Some of the items link to other sites, but some they seem to host.

Some of these things I think would do well to write as plugins for the Mootools library but if Valerio (the gatekeeper for Mootools) doesn't want it I think some of them would do well to be added to the CNET Library.

This goes hand-in-hand with the patterns project that we're trying to kick off here. I think this page could really help inform that work...

There are several new goodies in the most recent release of the CNET libraries. I've got examples and details in the wikitorial, but here's a quick list:

• JsonP - handles grabbing Json from a foreign domain; works a lot like Ajax
• Element.smoothShow/smoothHide - a height/opacity transition for an element to add it to the page smoothly.
• Element.setPosition - position an element relative to another (the window or another dom element)
• ProductPicker - a generic "picker" to allow users (typically in a CMS) to choose an item from a data source.
• stickyWinHTML - a default html block for in-page popups
• SimpleSlideShow - a very, very simple slideshow for dom elements or images

Have fun.

Continuing in my current project of rewriting all the javascript on Download.com (pity me), I encountered the functions on the screenshots page. A quick rewrite and here's my SimpleGallery class. It's not super-duper fancy but it's not meant to be. | Read the rest »

I thought about the form validator that I refactored and posted about the other day for a bit and decided I wasn't happy with all it did. Specifically, I wanted to be able to do more with the validation and more with the messaging. I also thought I could improve on the core functionality a little.

So I rewrote it entirely and borrowed heavily from it to come up with my own version. This version works almost the same way as the previous one with a few differences:

• the transition is smoother
• error messages have access to more information about the element they evaluate
• tests can have conditions specific to individual elements

It still uses css class names, now you can give each field some specific conditions.

You can now see this in action, download the script, and see the docs in our wikitorial.