A number of instance and static methods of the Uize.Widget.Tree module have been deprecated and migrated into the new Uize.Node.Tree module. The getTreeFromList and getTreeFromPage instance methods, along with the Uize.Widget.Tree.getTreeFromList and Uize.Widget.Tree.getTreeFromPage static methods, have been deprecated and migrated into the Uize.Node.Tree module as Uize.Node.Tree.getTreeFromList and Uize.Node.Tree.getTreeFromPage. For backwards compatibility, the deprecated instance and static methods of the Uize.Widget.Tree class are all still supported, and will be supported for some time. All existing code using the deprecated methods should continue to work as normal. It would be wise to progressively migrate code over to using the static methods in the new Uize.Node.Tree module. In order to achieve backwards compatibility, the Uize.Widget.Tree base class now requires the new Uize.Node.Tree module. Other than that, the static methods in the new Uize.Node.Tree module have the same signature and behavior as the deprecated methods of the Uize.Node.Tree module.

The Uize.Population module has been migrated to under the Uize.Widget namespace as Uize.Widget.Population. For the most part, the interface is entirely the same and compatible with the old interface, with some very minor differences. As a widget class now, instances of the Uize.Widget.Population class must be wired (by calling the wireUi instance method) before changing the value of the items set-get property will result in an update of the contents of the instance's DOM node. Also, as a true widget class, instances of the Uize.Widget.Population class can be added as child widgets of other widget instances. Finally, the DOM node into which generated HTML is injeted can now be specified with either of the idPrefix, node, or container set-get properties. This change, which is not backwards compatible, has the benefit of further cleaning up the Uize root namespace. The two examples that were previously using the now defunct Uize.Population class, Populating Photo Details and Structured Record Population, have been updated to use the new Uize.Widget.Population class. If you were previously using the Uize.Population class, then you can use these two example pages as a reference when updating your own code.

ICEfaces 2.0 will include two component sets; the existing ICEfaces 1.x Component Suite components (aka ICEfaces "Compat" Components in ICEfaces 2.0), and the all-new ICEfaces 2.0 Components.

ICEfaces "Compat" Components

ICEfaces 2.0 includes the ICEfaces 1.x Component Suite components in a "Compatibility" (or "Compat") library (icefaces-compat.jar). The purpose of the compatibility library is two-fold:

1. Provide key ICEfaces 1.x APIs on top of ICEfaces 2.0 to make porting existing ICEfaces 1.x applications easier. ICEfaces 2.0 uses different packaging and APIs than 1.x and is not directly backwards compatible. The Compatibility APIs basically provide key 1.x APIs as wrappers for the new 2.0 APIs.

2. Provide the ICEfaces 1.x Component Suite for use on ICEfaces 2.0. Since the ICEfaces 1.x Components also rely on many of the ICEfaces 1.x APIs internally, they also require using the Compatibility APIs to function on ICEfaces 2.0.

Note that there is nothing JSF 1.2 about the Compatibility APIs and Components, they are meant to run only on JSF 2.0 on top of ICEfaces 2.0. The "Compatibility" term refers to ICEfaces 1.8 compatibility, not JSF 1.2.

New ICEfaces 2.0 Components

There is also a new generation of ICEfaces components under development for ICEfaces 2.0, based on a new Component Development Platform (CDP). The goal of the new CDP is to greatly ease the effort required to create and maintain new ICEfaces 2.0 components, providing a sophisticated set of features to reduce code replication and the amount of code that must be hand-crafted and maintained, resulting in improved developer productivity, and more efficient components at runtime.

These components will be delivered gradually, with the initial set of new components arriving along with the new CDP in the ICEfaces Beta2 release. The initial set of new components will include new File Upload, Slider, DateTimeSelector, and TabPanel components. When ICEfaces 2.0 ships final in the fall we expect to have 5 - 10 new components ready. More new components will be delivered after that in 2.1, etc. The ultimate goal is to provide replacement component functionality for virtually the complete ICEfaces 1.x Component Suite (not necessarily in a one-to-one relationship with existing components), but this is going to take some time to achieve.

Another aspect of the new component initiative is to invite and support community involvement and contributions by hosting an ICEfaces 2 Community Component Showcase and repository on the www.icefaces.org site, allowing ICEfaces Contributor's to submit their own CDP-based components for use and review by the community. This will be in place around the time of ICEfaces 2.0 final release.

We expect that most early ICEfaces 2.0 applications will take advantage of the 1.8 Compat Components alongside std. JSF components and the new ICEfaces 2.0 Components, as required.

One of the great aspects of ICEfaces is that it provides a comprehensive set of framework-level features that provide substantial benefits over using stock JSF 2, regardless of the component-sets being used.

Release Schedule Update

The good news is that ICEfaces 2.0 Beta 1 is out! In Beta 1 release, the following aspects of ICEfaces 2.0.0 are considered feature-complete:

• ICEfaces 2.0 Core (icefaces.jar)
• ICEfaces 2.0 Compatibility Libraries (icefaces-compat.jar)

The not-as-good news is that we've had to add a second Beta release to the schedule ("Beta 2"). This second Beta release will introduce:

• The new ICEfaces 2.0 Component Development Platform.
• The initial set of new ICEfaces 2.0 components (Tab, Slider, DateTimeSelector, FileInput, and possibly more).
• Support for Portlets via the PortletFacesBridge.

The planned timing for Beta 2 is late August / early September.

We would appreciate any feedback you may have with respect to success/issues/questions using the Beta 1 release!

Firefox 3.6.7 and Firefox 3.5.11 are now available as free downloads for Windows, Mac, and Linux from http://firefox.com. As always, we recommend that users keep up to date with the latest stability and support versions of Firefox, and encourage all our users to upgrade to the very latest version, Firefox 3.6.7.

Firefox 3.6.7: http://firefox.com
Firefox 3.5.11: http://www.mozilla.com/firefox/all-older.html

We strongly recommend that all Firefox users upgrade to these latest releases. If you already have Firefox, you will receive an automated update notification within 24 to 48 hours. This updates can also be applied manually by selecting “Check for Updates…” from the Help menu.

For a list of changes and more information, please review the Firefox release notes:

• Firefox 3.6.7 release notes
• Firefox 3.5.11 release notes

Note: All Firefox 3 and 3.5 users are strongly encouraged to upgrade to Firefox 3.6 by downloading it from http://firefox.com or by selecting “Check for Updates…” from the Help menu and clicking on “Get the New Version”, then checking for updates again once Firefox 3.6 is installed.

As part of Mozilla’s ongoing security and stability update process, Thunderbird 3.1.1 and Thunderbird 3.0.6 are now available as free downloads for Windows, Mac, and Linux from http://getthunderbird.com/. As always, we recommend that users keep up to date with the latest stability and support versions of Thunderbird.

• Thunderbird 3.1.1: http://getthunderbird.com/
• Thunderbird 3.0.6: http://www.mozillamessaging.com/en-US/thunderbird/all-older.html

We strongly recommend that all Thunderbird users upgrade to these latest releases. If you already have Thunderbird, you will receive an automated update notification within 24 to 48 hours. You can also manually fetch this update by selecting “Check for Updates…” from the Help menu.

For a list of changes and more information, please review the Thunderbird release notes:

• Thunderbird 3.1.1 release notes
• Thunderbird 3.0.6 release notes

We’d like to open up submissions for talks for our conferences in London and Boston.

The dates are currently being firmed up, but currently we’re eyeing these days: London: Sept 13-14 Sept 8-9th or the 22-23rd; Boston: Oct 16-17. Please fill out the form if you’re interested in speaking at either of these events.

We will be sharing more information about these two epic events in the coming weeks.

Here's another weekly status update, so let's go medias in res:

Developing API Documentation

Developing API documentation has been a bit tedious so far. Editing the JSDoc comments in class files was fine, but if you wanted to look at the result to check your changes you had to go through a complete build run of the Apiviewer. This was mitigated by a full cache, but still took considerable amounts of time. Making five subsequent changes to the comments with always a generate.py api in between was not exactly rapid development. Just fixing a typo or small formatting glitch became a major interrupt in your work flow.

This has been amended.  You can now re-generate API data for individual classes. To this end, a new generator job has been added, api-data. This job just generates the API data for the involved classes, which is also done as part of the more general api job. But in contrast to this it does not generate the viewer application itself. To speed up the generation process further you can add class names as command line arguments to the api-data job. This way you can specify the exact classes you want API data to be generated for. Just make sure you run the full generate.py api initially so that the viewer application is present. Then, on changes to individual classes, just re-generate the API data for those classes:

generate.py api-data my.ownClassA ...

After re-generating API data you still have to reload the Apiviewer to see the results, but this should be considerably faster than re-building the whole Apiviewer. Mind that if you generate individual API data the index information (what you see in Apiviewer's tree view in the left pane) is restricted to those classes (plus stubs for their ancestors for hierarchy resolution). But this should be fine for developing individual class documenation.

Tutorial Update

Certainly everyone has already heard of the qooxdoo tutorials that we keep continuing now and then. Unfortunately Twitter will change its API and will disable their current API, which we used in the tutorial for posting tweets. So we changed the tutorial a bit to get all pieces back into shape.

Real-life Example: VZAweb

Henner Kollmann of Software-Kontor Helmert let the community know about their real-live qooxdoo application called "VZAweb": This web-based traffic census data base is the successor to the previous access-based stationary software. The web application is completely based on open-source components and combines GeoInformation e.g. from OpenstreetMap (OSM) with voluminous filtering functions and a report generator. It combines qooxdoo with OpenLayers and BIRT. The backend is a Java servlet running on a Tomcat server. It can be used with different databases, e.g. Firebird, Postgres, Oracle or Microsoft SQL Server.

Bugfixes

Framework: You can now disable all application tooltips by using qx.ui.tooltip.Manager's showToolTips property. qx.util.StringSplit has been updated with the newest version of Steven Levithan's cross-browser split method.

Applications: The Playground's log window now supports real-time updates and it can also be cleared by using the new "Clear" button that was added to it.
The FeedReader application got a minor usability update: the "Add Feed" window can also be submitted by pressing the ENTER key on one of title or URL text fields.

For a complete list of bugs fixed during the last working week, use this bugzilla query.

Devel demos

Talking of the development versions of the apps that come with qooxdoo: do you remember that the current snapshots of the SVN trunk are always put online each Friday by us as public "devel" demos? That way you can pretty closely follow the development without generating those apps from trunk yourself. Despite being devel versions they should be fairly stable, so if you find any issues, please report them so they can be addressed.

EuroPython 2010

Thomas left today for Birmingham as he is Going to EuroPython 2010. Have a great time there, enjoy many interesting talks and chats, and good luck with your own presentation as a speaker.

That's it for today. Have a nice weekend.

Event Oriented Architectures (EOAs) are an emerging best practice when designing reusable JavaScript widgets. jQuery's trigger, triggerHandler, and jQuery.event.special[EVENT]._default methods have enabled widget authors to easily expose custom events to developers. However, these methods lack the scalability or expressiveness to enable powerful EOAs.

JavaScriptMVC's jquery.event.default plugin provides an easier and more scalable way of providing default events.

Download

jquery.event.default.js (minified 1.3kb) [works with latest jQuery on github]

Demo

Default tabs - a tabs widget that uses default events.

Event Oriented Architectures

EOAs are simply widgets that produce synthetic events that you can listen to similar to a native event. For example, jQuery UI's tabs widget produces events like tabselect that you can register event handlers on like:

$('#mytabs').bind('tabselect', function(){
  //called before a tab is selected
})

Why EOAs?

There are many other methods of exposing a widget's API.  The most common is taking a callback function when the widget is created.  jQuery.UI's tab widget also allows you to do this:

$("#mytabs").tabs({
  select : function(){
    //called when a tab is selected
  }
})

But, this only allows one responder!  It's possible that many objects want to know when something happens in your widget.

If you use Dojo, you might be lucky enough to use dojo.connect.  Connect allows you to bind to any other function.  By just exposing a function, any other object can be notified when that function is called.

//in the tabs widget
myTabsWidget = {
  select : function(){
     //tabs select functionality
  }
};
// somewhere in your code
dojo.connect(myTabs,"select",null, function(){
  //called when select is called on myTabs
})

Another multiple-callback solution is using a library like OpenAjax.hub. Hub allows you to publish and subscribe messages like:

//in your tabs widget
OpenAjax.hub.publish("tab.select",tab)

//in your code
OpenAjax.hub.subscribe("tab.select", function(called, tab){
 //do stuff!
})

But these options suck compared to synthetic events for UI widgets because:

• Developers already understand DOM events and how to listen to them.  
• Bubbling events naturally group related widgets. Ex: respond to all 'activate' events by listening on a parent element.

jQuery and EOAs

jQuery makes creating EOAs simple, if underpowered. Bind, delegate, and live can listen to arbitrary events on elements. Trigger creates synthetic events that bubble like a DOM events. The following shows the first hidden element in the page:

//listen for show events on the document
$(document).bind('show', function(ev){
  //show the target
  $(ev.target).show()
});

//trigger show on the first hidden element
$(':hidden:first').trigger("show")

Trigger makes it easy to create synthetic events and expose a callback API. But to make these callback functions more powerful and DOM-like, we need to provide default events.

Default Events

We're all familiar with default events in the DOM.  Here's a few examples:

• clicking a link -> Follows the link
• clicking submit in a form -> posts the form
• mousedown on text -> starts selecting text

And with jQuery, we are used to preventing default events by returning false or calling prevent default:

$('a').click(function(ev){
  ev.preventDefault();  //these 2 lines
  return false;         //do the same thing
})

What if we could set default behaviors for certain events on our widgets and let others prevent them in the same way? How awesome!

_default

In jQuery 1.4.3, a _default function can be set on special events. For more info check out jQuery's forum.  The _default function is called after all event handlers for an event type have been called. For example:

$.event.special.show ={
  _default : function(ev){
    $(ev.target).show()
  }
};
$(':hidden:first').trigger("show")

Underpowered?

jQuery doesn't go far enough in making default events practical for complex applications.  Consider the following problems:

•  What if multiple plugins define a show default event?
• What if there are multiple tabs plugins, each with its own default tabselect event?

JavaScriptMVC's jquery.event.default.js plugin makes using default events scalable and organized.

jQuery.Event.Default

The default plugin lets you add default functionality by binding a default event handler. Just prefix the event with "default.". The following provides default show behavior for '.tab' elements inside a '#tab' element:

$("#tabs").delegate('.tab','default.show',function(){
  $(this).show()
})

Of course, global default events are still supported, but without stomping on other code:

$(document).bind('default.show',function(ev){
  $(ev.target).show()
})

$(':hidden:first').trigger("show")

Use bind, delegate, or live to listen for default events. The default event handler only gets called if preventDefault is not called.

triggerDefault and triggerDefaults

The jquery.event.default.js file provides two useful helpers to trigger events and return if default events were triggered.

// synthetic event bubbles
$('#foo').triggerDefaults('show'); //-> true/false

// synthetic event does not bubble
$('#foo').triggerDefault('show'); //-> true/false

The Demo

The demo uses default events to provide a tabs widget. The default 'show' event is prevented on the second tab until the first tab's checkbox is checked. 

 Here's the code:

// create a tabs plugin
$.fn.tabs = function(){

  // finds the tab from the tab button
  var sub = function(el){
    return $(el.find("a").attr("href"))
  }
  
  this.each(function(){
    var tab = $(this);
    
    // set the first tab button as active
    tab.find("li:first").addClass('active')
    
    // hide all the other tabs
    tab.find(".tab:gt(0)").hide();
    
    // listen for a click on a tab button
    tab.delegate("li","click", function(ev){
      ev.preventDefault();
      var el = $(this);
        
      if( // not active button
	    !el.hasClass('active') && 
		// default wasn't prevented
        sub(el).triggerDefaults("show")){
			
        // remove active and hide old active	
        sub(tab.find(".active").removeClass("active"))
          .hide();
	  
        //mark as active
        el.addClass("active");
      }
  })
    
  // show a tab if default isn't prevented
  .delegate(".tab","default.show", function(ev){
    $(this).show();
  })
})
};

// create tabs widget
$("#tabs").tabs();

// listen on the second tab for show
$("#second").bind("show",function(ev){
  
  //if complete isn't checked
  if(! $("#complete")[0].checked ){
  	
	//prevent the default action!
    ev.preventDefault();
  }
});

Here's how the code works:

1. When an li in the tabs is clicked, it checks if it isn't active and uses sub to find the tab content for that li.
2. It triggers a show action on the tab content.  
3. It listens to show events on the #second tab, if the checkbox isn't checked, it prevent default events.
4. Assuming that default events are allowed, the ".tab" default "show" event will show the tab.
5. After the event has finished, control returns back to the original li click handler. If default events were allowed, it hides the old tab.

Conclusions

Default events and event oriented architecture is, to be sure, an advanced JavaScript technique.  However, the JavaScriptMVC default event plugin makes building sophisticated and extendable widgets slightly easier.  It's a powerful technique, use it with care.

Want to use live and delegate with hover events? Now you can! We are releasing JavaScriptMVC's delegate-able hover plugin. This plugin only works for the current 1.4.3 nightly release.

Download

jquery.event.hover.js (minified 3kb)

Features

• Listen to hover events with live, delegate, and bind
• Customize hover behavior locally or globally

Demo

jQuery.Hover

Documentation

jQuery.Hover

Use

Bind, delegate, or use live on any of the following events:

• hoverinit - called on mouseenter, use this event to customize delay and.distance
• hoverenter - an element is being hovered
• hovermove - the mouse moves on an element that has been hovered
• hoverleave - the mouse leaves the element that has been hovered

Example:

// listen for hover on 'option's in a menu
$('#menu').delegate(".option","hoverenter",function(){
  $(this).addClass("hovering");
})
// when the mouse leaves restore
.delegate(".option","hoverleave",function(){
  $(this).removeClass("hovering");
})

Configuring Distance and Delay

An element is hovered when the mouse moves less than a certain distance in specific time over the element. You can configure that distance and time by adjusting the distance and delay values.

You can set delay and distance globally by adjusting the static properties:

$.Hover.delay = 10
$.Hover.distance = 1

Or you can adjust delay and distance for an individual element in hoverenter:

$(".option").live("hoverinit", function(ev, hover){
//set the distance to 10px
hover.distance(10)
//set the delay to 200ms
hover.delay(10)
})

The Mozilla community is proud to announce that Firefox 4 Beta 1 is now available for download on Mac, Windows or Linux.

Firefox 4 Beta 1 includes dozens of major features and improvements – by testing them early we’ll be able to respond to your feedback for future versions of Firefox. Once you download Firefox 4 Beta 1, you’re part of our beta program and will receive regular updates as more features launch. We’ve included a Feedback Add-On that helps you let us know what you think about the new features and technologies in the beta. You can read more about this release on the Mozilla Blog, or at any of the following links:

• Read more about some of the major features in this beta
• Take a look at our big chart o’ technology that’s included in this beta
• Read the release notes for Firefox 4 Beta 1

We want to thank the Mozilla community of nightly testers for the amazing feedback that helped shaped Firefox 4 Beta 1. We appreciate your assistance in testing this preview of the next version of Firefox!

We are pleased to announce that OpenLaszlo 4.8.0 is available for download here.

OpenLaszlo 4.8.0 is an incremental release of OpenLaszlo 4, and contains 152 bug fixes (see the JIRA report 4.8 Release Notes for details). There are a wide range of bug fixes, including CSS stylable canvas, more dynamic CSS support, the promotion of tooltip to an official component, improved drawview support, simpler association of CSS properties with attributes and an ability to provide a fallback value for CSS-styled attributes.

OpenLaszlo continues to be grateful for the significant contributions by André Bargull, whose numerous bug fixes and exacting techical reviews make OpenLaszlo more robust. We also want to thank Alexander Pakhunov, Chen Ding, Clint Dickson, Gioacchino Mazzurco, John Olmstead, Justin Hunt, Pasqualino 'Titto' Assini, Raju Bitter, and Rami Ojares, who took the time to isolate and report important bugs for us to address in this release. Thank you! We would also like to thank the entire OpenLaszlo community for your support in so many ways, like submitting bug fixes, helping users on the OpenLaszlo forums, and participating in discussions to help make OpenLaszlo a better platform.

As part of Mozilla’s ongoing stability and security update process, Firefox 3.6.6 is now available as a free download for Windows, Mac, and Linux from http://www.firefox.com. This release makes a small change to the crash protection feature introduced in Firefox 3.6.4, increasing the amount of time that Firefox will allow a plugin to remain frozen before terminating it. For more information, see the Mozilla Blog announcement about the release.

We recommend that all Firefox users upgrade to this latest release. If you already have Firefox 3.6 you will receive an automated update notification within 24 to 48 hours. This update can also be applied manually by selecting “Check for Updates…” from the Help menu.

For a list of changes and more information, please review the Firefox 3.6.6 Release Notes.

All Firefox 3 and 3.5 users are strongly encouraged to upgrade to Firefox 3.6 by downloading it from http://firefox.com/ or by selecting “Check for Updates…” from the Help menu and clicking on “Get the New Version”, then checking for updates again once Firefox 3.6 is installed.

Mozilla Messaging is proud to announce that Thunderbird 3.1 is now available for download. Thunderbird 3.1, based on the Gecko 1.9.2 platform, was built by a community of passionate contributors, experienced developers, security experts, localization and support communities, and thousands of active testers.

Some of the new features:

• New Quick Filter toolbar
• New Migration Assistant
• Saved Files Manager
• Several fixes to improve upgrading from Thunderbird 2
• Several design improvements and corrections to the interface
• Stability, memory, and password handling improvements

As always Thunderbird 3.1 is available as a free download. Thunderbird 3.1 is also available in 46 languages – get your local version.

We encourage developers to read the Thunderbird 3.1 for Developers article on the Mozilla Developer Center.

Today, Mozilla is happy to release Firefox 3.6.4, the latest security and stability release for Firefox, used by nearly 400 million people around the world to browse the Web. This release provides crash protection for Windows and Linux users by isolating third-party plugins when they crash.

Results from our beta testing show Firefox 3.6.4 will significantly reduce the number of Firefox crashes experienced by users who are watching online videos or playing games. When a plugin crashes or freezes while using Firefox, users can enjoy uninterrupted browsing by simply refreshing the page.

Mozilla recognizes that third-party plugins provide important functionality in many of today’s websites. At the same time, plugins can lead to problems for users as they browse. With the ability to automatically alert users when they have out of date plugins, and now crash protection, Firefox 3.6.4 allows users to experience all the content they love without any of the hassles. (If you’re not running Firefox, Mozilla recommends that you make a habit of visiting the Plugin Check page to keep your plugins up to date.)

At this time Firefox offers crash protection for Adobe Flash, Apple Quicktime and Microsoft Silverlight on Windows and Linux computers. Support for other plugins and operating systems will become available in a future Firefox release.

All Firefox users are encouraged to upgrade for free by using the “Check for Updates” function in the Help menu, or by visiting www.firefox.com. For more information, please visit:

• Crash Protection FAQ
• Firefox 3.6.4 Release Notes
• Plugin Check

Thunderbird 3.0.5 is available for Windows, Mac, and Linux for free download.  We recommend that users keep up to date with the latest stability and security updates of Thunderbird, and encourage all our users to upgrade to the very latest version, Thunderbird 3.0.5.

Thunderbird 3.0.5: http://www.GetThunderbird.com

If you already have Thunderbird, you will receive an automated update notification within 24 to 48 hours.

We’re happy to announce the release of the fifth developer preview of the Mozilla 1.9.3 platform:

You can download it for Mac, Windows and Linux. Also, for the first time, we have 64 bit builds available for Mac and Linux, however these builds do not have support for 32 bit plugins and are considered highly experimental.

This build contains a number of changes since the previous Mozilla Developer Preview release. Here’s the list of changes available in this release, also available in the release notes:

User-facing changes

• Aero Glass is now enabled for Windows Vista and Windows 7.
• More parts of the new Windows theme have landed including new main button icons. Many more changes are coming in later releases.
• The new Add-ons manager has landed. The UI for the new Add-ons manager is not yet complete.
• You can now put tabs on top (View -> Toolbars -> Tabs on Top) although without most of the final UI this isn’t as useful as it could be.

Web-facing changes

• Support for WebM is included with this build. (Try an example video on Youtube.)
• When viewing HTML5 videos in full screen, we now use hardware acceleration for Windows (DX9) and Macs (OpenGL).
• This is the first release of any browser that has proper support for parsing HTML5 according to the specification.
• This build has early support for some HTML5 forms.
• We now support the FormData interface, part of XHR level 2 spec.
• We now support a Mozilla-specific CSS selector: -moz-any. Please see the post for examples, but this will be very useful in HTML5 contexts.
• We now do Lazy Frame Construction which can vastly improve the performance of complex pages that add large numbers of elements to a page.
• Lots of new JavaScript performance improvements have been made.

Platform Changes

• An updated about:memory page shows you how memory is being consumed in the browser. This will improve with later updates to give even more useful data and cover more internal memory pools.
• On the Mac we now support the Cocoa event model for NPAPI plugins. This is used by Flash 10.1 and the new Java plugin from Apple.
• ChromeWorkers with jscytpes is now supported.

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.

Please note: the Thunderbird 3.1 Release Candidate 2 is a public preview release intended for developer testing and community feedback. It includes several new features as well as improvements to performance, memory, password handling, and the upgrade process. We recommend that you read the release notes and known issues before installing this release candidate.

The Thunderbird 3.1 Release Candidate 2 is now available for download. This milestone is focused on providing a preview of the functionality provided by the new features and changes that will be included in Thunderbird 3.1.

New features in Thunderbird 3.1 that require feedback include:

• New Quick Filter toolbar
• New Migration Assistant
• Saved Files Manager
• Several fixes to improve upgrading from Thunderbird 2
• Several design improvements and corrections to the interface
• Stability, memory, and password handling improvements

Testers can download Thunderbird 3.1 Release Candidate 2 builds for Windows, Mac OS X, and Linux in 46 different languages. Developers should also read the Thunderbird 3.1 for Developers article on the Mozilla Developer Center.

Note: Please do not link directly to the download site. Instead we strongly encourage you to link to this Thunderbird 3.1 Release Candidate 2 milestone announcement so that everyone will know what this milestone is, what they should expect, and who should be downloading to participate in testing at this stage of development.

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.