The Uize.substituteInto static method, implemented in the Uize base class has been improved to be more robust. Because of the way it was previously implemented, the Uize.substituteInto method would perform further substitutions into values previously substituted into the source string. This could result in some odd and unexpected behaviors in the unlikely event that the value for one substitution contained the token name for another substitution. In addition to this improvement, the Uize.substituteInto method is also now fully unit tested, and its documentation has been updated to be more comprehensive and accurate.

The new Animate Position in JavaScript example shows how to animate the position of an HTML element and how to apply amazingly realistic motion effects like easing, elasticity, bounce, and many more. In the example, the Uize.Fx.fadeStyle method of the Uize.Fx module is animating the position of a silver sphere. You can click anywhere on a brushed metal square and the sphere will move to that position. How the sphere moves is decided by the curve(s) used by the Uize.Fx.fadeStyle method. You can change the curve(s) by selecting one of the many presets from the "PRESETS" tab. Upon choosing a preset, a random target position is chosen for the sphere, and the sphere is then animated to that position using the newly selected curve(s). The animation can be repeated by clicking a preset link repeatedly, or by clicking the "PREVIEW ANIMATION" button repeatedly, or by clicking anywhere on the metal square. The settings for a preset can be edited in the "PARAMS" tab, and the edited settings can be previewed by clicking on the "PREVIEW ANIMATION" button.

The built-in module loader in the Uize base class has been improved to make updating the version of the UIZE JavaScript Framework used on a particular Web site easier. It has been updated so that it now retains the query parameters from the URL that is used when sourcing in the Uize. These query parameters make their way into the default value that is set for the Uize.moduleUrlTemplate static property when loading in the Uize base class in a Web page. As such, they are then used when forming the URLs for requesting subsequent modules that need to be dynamically loaded in. This means that if you're adding a build number query parameter onto the URL when loading in the Uize base class in a script tag, then that same build number will appear in URLs for dynamically loaded modules. By using a build version query param when loading the Uize base class, one can ensure that the browser's cache will be defeated for all dynamically loaded modules, which guarantees that the browser won't continue using an old cached copy for one module while potentially using a new fresh copy of some other module (which could produce errors if the different modules from different versions of the framework are not compatible with one another). The Uize.getPathToLibrary static method has been improved to now support an optional moduleTokenSTR parameter. When the optional moduleTokenSTR parameter is specified, then the value returned by this method will be the value of the src property for the script tag that sources in the module specified by the moduleFilenameSTR parameter, but with the module filename replaced by the substitution token specified by the moduleTokenSTR parameter.

The new Animated Buttons with Box Shadow example demonstrates the UIZE JavaScript Framework's ability to animate values for the box-shadow CSS3 style property. In this example, an instance of the Uize.Widget.HoverFader widget class is being used to add a JavaScript animation effect to a set of navigation buttons. With help from the Uize.Fx.xShadows extension module, the instance manages fading of values for the box-shadow, margin-left, margin-top, color, and border-color CSS style properties for the buttons. For browsers that support the CSS3 box-shadow style property, the buttons appear to "leap" out of the page when they are moused over. To add more realism, the Uize.Curve.Rubber module is used to add a bounce quality to the fade back from a button's hover state to its resting state, which makes the buttons bounce as they sink back in and "hit the page surface".

The new Uize.Fx.xShadows extension module implements support for fading / animating the values of both the text-shadow and box-shadow CSS3 style properties. This new module takes over from the now deprecated Uize.Fx.xTextShadow module. When the Uize.Fx.xShadows module is loaded, the Uize.Fx.fadeStyle method can be used to animate text shadow and box shadow along with all other supported CSS style properties.

The Uize.Template module has been improved in a number of ways: 1) The new Uize.Template.encodings static property, which is an object, allows custom encodings to be registered by assigning encoding profile objects as properties on it. 2) The new Uize.Template.defineStandardEncoding static method provides a convenient way to define new standard encodings. 3) Three new encodings have been added: iso8601, tagAttributes, and tagAttributeValue. 4) When building up the canonical list of modules required by a template being compiled, the @required directive now makes sure to ignore any duplicate instances of required modules. 5) The Uize.Template.encode and Uize.Template.decode static methods have been improved to now both support encoding chains, in the same format as can be used in assignment expressions in template code (eg. 'json -> urlPiece'). 6) The reference documentation for the Uize.Template module has been improved in a number of ways. 7) With the introduction of the new Uize.Template.encodings static property, the Uize.Template.encoders and Uize.Template.decoders static properties have been deprecated. 8) With the introduction of the new Uize.Template.encodings static property, the way that encodings imply dependencies upon code execution has changed.

The Uize.Date module has been improved, with fixes for a number of issues, improvements to a number of static methods, and the addition of a thorough set of unit tests in the new Uize.Test.Uize.Date unit tests module. FIXES: 1) The Uize.Date.inRange static method has been fixed to correctly support date range objects where the value of the minValue property is undefined, null, or not specified. 2) A rounding bug in the Uize.Date.isRecent static method, that would cause this method to produce the incorrect result under certain conditions, has been fixed. 3) A bug with the Uize.Date.toIso8601 static method, where the month would always be off by one, has been fixed. IMPROVEMENTS: 1) The Uize.Date.format static method has been improved with the addition of support for invalid dates for all substitution tokens (eg. Uize.Date.format (new Date (NaN),'{YYYY}-{MM}-{DD}') now produces the result '????-??-??'). 2) The Uize.Date.resolve static method has been improved with the addition of support for dates specified as a milliseconds integer number. UNIT TESTS: The Uize.Date module is now thoroughly unit tested by the newly created Uize.Test.Uize.Date unit tests module.

The recently released wardtog.com Web site is an excellent showcase of the UIZE JavaScript Framework. Wardtog.com really is the long tail of location based products, offering products that represent hundreds upon hundreds of cities across the entire globe. Let's say, hypothetically, that you were born and raised in the city of Cape Town, South Africa. Then, let's say further that you were at some point transplanted to San Francisco, California. Now, as an expatriate of Cape Town, South Africa, you might be moved to buy a shirt declaring your undying love for your city of birth. At Wardtog.com, this hypothetical expatriate can do just that by going to the Cape Town Designs page. With wardtog.com, transplants from all around the globe can step up and represent. Each city has numerous products with numerous design themes. The wardtog.com Web site is an impressive showcase of what can be accomplished using the UIZE JavaScript Framework. The designs for the many cities represented on the site are generated dynamically in Adobe Photoshop, with some help from the host-neutral modules of UIZE. Then, build scripts running in Windows Script Host are responsible for building the thousands of HTML pages, utilizing UIZE and its JavaScript templates functionality, thereby reducing server load by not requiring large amounts of dynamic processing and database access when pages of the site are viewed. Then, the entire site, consisting of thousands of static pages, is packaged and deployed to the server, once again utilizing scripts running in Windows Script Host and employing the host-neutral features of UIZE. Finally, the UIZE JavaScript Framework is used on the client-side to provide zoom previews in product grids, and for other client-side interactivity. All in all, wardtog.com really flexes the muscles of the UIZE JavaScript Framework and puts its robust features to good use.

The new Creating A New Uize Module explainer provides guidelines and advice for the development of new UIZE modules, to be followed by developers of the UIZE JavaScript Framework. Among other things, this document discusses: 1) choosing an appropriate namespace and name for your new module, 2) requirements for the module info, scruncher settings, and module meta data comment blocks of your new module, 3) guidelines on implementing the functionality for your new module, 4) implementing a companion unit test module for your new module, 5) documenting your new module, and 6) creating one or more examples for your new module.

The new Get Tree from Page example demonstrates how the Uize.Node.Tree.getTreeFromPage static method of the Uize.Node.Tree module can be used to build a tree data object respresenting the structure of the document, by analyzing the occurrence of different CSS classes for section headings at different depths of the document (in this case, the CSS classes level1Header, level2Header, and level3Header). A tree data object like this can be supplied to a tree menu widget, or can otherwise be used to build UI for navigating to different sections of the document (a contents tree, for example).

he Uize.Fx.xTextShadow extension module has been deprecated in favor of the new and more powerful Uize.Fx.xShadows module. As its name implies, the Uize.Fx.xTextShadow module provided support specifically for fading / animating values of the text-shadow CSS3 style property. The new Uize.Fx.xShadows module provides support for animating both the text-shadow and box-shadow style properties. Because the Uize.Fx.xTextShadow module has only been deprecated and has not yet been eliminated, code currently using it should continue to work. However, relying on the backwards compatibility provision will not be as efficient as directly using the new Uize.Fx.xShadows module. Therefore, code that was previously using the Uize.Fx.xTextShadow module should be updated to use the new Uize.Fx.xShadows module.

The date picker widget, implemented in the Uize.Widget.Picker.Date module, has been improved to correctly support date entry in a wide variety of different formats. Previously, dates selected by the user in the date picker dialog could be formatted in the date picker widget's text input field using a configurable date format, as specified in the Uize.Widget.Picker.Date class' displayFormat set-get property. However, the date picker dialog could only parse dates specified in a format that could be recognized by the Uize.Date.resolve method. The new implementation uses the Uize.Date.Formatter.parse method of the new Uize.Date.Formatter module to parse dates in any format specified by the displayFormat property. This change also involves improvements to the Uize.Widget.Calendar, Uize.Widget.Dialog.Picker, Uize.Widget.Dialog.Picker.Date, and Uize.Widget.Picker modules.

A number of instance and static event management methods of the Uize base class that were deprecated back in early June of 2009 have finally been killed. In keeping with the policy of one year backwards compatibility transition periods, the deprecated forms of these methods were kept in place for a year and are now ready to expire. Specifically, the addEventHandler, addEventHandlers, fireEvent, removeEventHandler, and removeEventHandlers instance methods have been killed, and the Uize.addEventHandler, Uize.addEventHandlers, Uize.wire, Uize.fireEvent, Uize.removeEventHandler, and Uize.removeEventHandlers static methods have been killed.

The new Get Tree from List example demonstrates how the Uize.Node.Tree.getTreeFromList static method of the Uize.Node.Tree module can be used to build a tree data object by analyzing the structure of a nested list defined by an HTML ul tag. A tree data object like this can be supplied to a tree menu widget, or can otherwise be used to build UI for navigating to different sections of the document (a contents tree, for example).

The new Uize.Node.Tree module provides convenience methods for generating a tree data object by analyzing HTML on a page. A tree data object is an array, where each element of the array is a Tree Item. Because a Tree Item may itself contain a child Tree Data Object, specified by its items property, a Tree Data Object can be used to represent an arbitrarily complex, hierarchical structure for information. A Tree Data Object can be used in any number of ways, but is commonly used for building tree-based user interface elements such as contents lists, structured dropdown menus, etc. A number of widget class support data in the Tree Data Object format, such as the Uize.Widget.Tree.List, Uize.Widget.Tree.Menu, and Uize.Widget.Tree.Select classes. Outside of widgets, tree data objects can be used to drive the generation of HTML, in build scripts or Web applications, using JavaScript Templates.

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.