WHAT'S IN A NAME
The name "UIZE" is pronounced "you eyes". Think of it as "UI", with an "-ize" tacked onto the end - as in to turn something into a UI or to add a UI onto it. When you UIZE your Web application, you're giving it a user interface. The way UIZE is pronounced also makes it sound like the plural of "UI", which is also fine. Incidentally, the word "uize" is also a traditional Scottish spelling of the word "use", which is nice because the UIZE JavaScript Framework is all about users and providing interfaces to them.
WITH UIZE, YOU CAN...
| Start building high profile, solid, and scalable RIA-style Web sites - with rich interactivity and client-side refresh using AJAX. | |
| Manipulate the DOM to produce client updates and visual effects. | |
| Communicate with the server using XMLHttpRequest, in formats like JSON and XML. | |
| Learn how to code well designed application logic using State Oriented Programming. | |
| Build reusable widgets and modules of functionality, using object oriented JavaScript. |
WHERE IT'S USED
The UIZE JavaScript Framework has had the opportunity to mature "in the wild" and has been used to provide rich client functionality on the Zazzle Web site since 2005. Zazzle's Web site is a heavily trafficed, consumer facing e-commerce site where stability and performance of all aspects of the code have a direct impact on customer experience and conversion rates. The UIZE JavaScript Framework has been tested against these important criteria.
IT'S RAINING WIDGETS
The UIZE JavaScript Framework comes packed with a good number of ready-to-go widgets, like the slider, progress bar, color picker, date picker, draggable and resizable window, marquee / resizer, image wipe with advanced fades / transitions, tabs, table sorter, thumbnail zoom, tree list, tree menu / drop down menu, egg timer, button, collection, collection item, image port, options selection, stretchy, and more. The widgets are being added to all the time.
OBJECT ORIENTATION
The UIZE JavaScript Framework has been designed making full use of the object orientation features of the JavaScript language. The APIs of the various modules have been carefully thought out so that they are comprehensive, sensible and consistent.
SERVER AGNOSTIC
The UIZE JavaScript Framework is developed as a purely client framework and is, therefore, server language and server platform agnostic. Heck, you can even run the UIZE Web site without a Web server - just off the local file system! So, you keep complete control over your server side architecture. You can write your middle tier code and business logic in any server language you desire and you should be able to build on rich client functionality using UIZE.
The UIZE JavaScript Framework works with...
| Java (Apache TomCat) | |
| C# (IIS / ASP.NET) | |
| Visual Basic (IIS / ASP) | |
| C/C++ | |
| Perl (Perl / Apache) | |
| PHP | |
| Ruby (Ruby on Rails) | |
| Python | |
| etc., etc., etc. |
ACTIVE DEVELOPMENT
The UIZE project was started in April 2005 and is in ongoing active development. New functionality, documentation, and sample code examples are being added all the time.
The Uize base class provides the following key features that provide the foundation for the subclasses that make up the UIZE JavaScript Framework...
Subclassing is very easy in the UIZE JavaScript Framework. Creating a fresh subclass is as simple as the following statement...
var MySubclass = MySuperclass.subclass ();
Once you have a subclass, you can modify it by assigning values on its prototype object, adding static methods or properties to the subclass, and registering set-get properties or overriding the initial values of inherited set-get properties. Each class that you create using the framework inherits the subclass static method, so you can easily make further subclasses of them.
The Uize base class provides a mechanism for inheriting instance methods and properties assigned on a superclass' prototype, static and instance set-get properties registered on the superclass using the registerProperties static method, and static methods and properties assigned on the superclass. The inheritance system that is implemented in the Uize base class overcomes some of the weaknesses of a superficial prototype-based approach to inheritance.
For a more in-depth discussion on class inheritance, consult the explainer JavaScript Inheritance.
Events can easily be fired by any instance of any class created in the UIZE JavaScript Framework - at any arbitrary place in its code - by simply using the fireEvent instance method, as follows...
myInstance.fireEvent ('My Custom Event Name');
Code can add event handlers for events by using the addEventHandler method, as follows...
myInstance.addEventHandler (
'My Custom Event Name',
function () {/* do something here */}
);
The Uize base class provides a convenient infrastructure for supporting both static and instance events. Events can conveniently be fired for a class or an instance of a class, and methods are provided to every class that subclasses the Uize class to allow code to manage the registering and unregistering of event handlers for static and instance events. This provides all Uize subclasses with a consistent event model.
For a more in-depth discussion on events, consult the explainer JavaScript Event System.
UIZE provides a powerful widget framework to facilitate good design in the modularization and reuse of interaction logic for widgets.
For a more in-depth discussion on widgets, consult the explainer JavaScript Widgets.
Along with an Event Infrastructure, the Uize base class also provides a convenient system for managing set-get properties, providing easy ways for code to...
| set defaults for a class's set-get properties | |
| register code to handle changes in the values of set-get properties | |
| register code to conform values of set-get properties | |
| register aliases for set-get properties to ease backwards compatibility |
For a more in-depth discussion on set-get properties, consult the explainer Set-get Properties.
As part of the foundation for developing Uize subclasses, the Uize class provides all its subclasses with a set of useful static and instance utility methods and properties.
In the world of Web application development, there is a legitimate place for features that are implemented through the technique of progressive enhancement (sometimes referred to as unobtrusive JavaScript, or graceful degradation). The UIZE JavaScript Framework offers its fair share of features that can be "stitched on" to a page's markup, without the page's knowledge or deliberate consent.
Making tables sortable is a great example of how one can "stitch on" an enhanced user experience, without requiring much cooperation from the application development side of things. Other examples of progressive enhancement features provided in the framework are the lightweight image preview user interaction provided by the Uize.Widget.ThumbZoom widget class, and the ability of the Uize.Widget.Tree.Menu widget (and other subclasses of the Uize.Widget.Tree base class) to extract a hierarchical tree data structure from nested lists.
There are some key precepts that guide the design of the UIZE JavaScript Framework.
What's in a namespace? Everything, as it turns out. The UIZE JavaScript Framework tucks away its features into a single Uize namespace (and if you create your own namespace for your site, you should do the same). Global functions and properties are not provided, even though providing them might result in fewer keystrokes. UIZE has steered clear of the "battle of the dollar function". The holistic approach that the UIZE JavaScript Framework takes to the client code aspects of a Web application essentially discourages ad hoc access to the DOM by miscellaneous JavaScript shrapnel. Generally, if you're touching DOM nodes, they should belong to widgets.
A conscious decision was made early on to not rely upon non-standard extensions of the DOM for registering attributes that client code may want to use for qualifying its behavior. There are other ways to pipe data to a widget's corresponding client code that don't violate W3C standards and don't require custom DTD's in order for pages to validate.
JavaScript is a powerful interpreted scripting language, combining elements of object oriented languages and functional languages. There are some other cute and trendy languages out there, and we might become envious of their junk. UIZE is not preoccupied with trying to invent sexy new language constructs, purely for the sake of coolness.
For example, unless you're factoring out significant code, iterator methods that act merely as for loops and take a function reference as the code to execute on iteration can take away more than they give. Superficially, it seems tedious to declare counters over and over again, just so you can iterate through elements of an array. It's cool that you can use anonymous functions in JavaScript and pass them to iterator methods, but if you're just replacing a simple for loop, you're hardly saving much in code size and you're adding a performance penalty. Iterator methods are best left to those that do complex iteration, like queued asynchronous iteration, tree traversal, node blob recursion, etc.
UIZE does not seek to coerce JavaScript into taking on the form of some other language. UIZE leverages the intrinsic strengths of the language. Consequently, the UIZE JavaScript Framework does not extend any of JavaScript's built-in core objects, even though it's possible to do so, and even though it might seem cool to do so. There are no new methods of the String object, for example. Built-in JavaScript objects - along with their properties and methods - are also considered part of the global namespace, so adding custom methods would violate the Respect Global Namespace principle.
There are four primary facets to the implementation of a healthy Web site: structure, content, design, and interaction.
STRUCTURE
The structure of a document, its XHTML markup, is the glue that binds together the other three facets.
CONTENT
Content is kept separate, in the form of dynamic data held in databases, user provided assets held in network attached storage systems, and resource strings that aid in internationalization.
DESIGN
Design is kept separate from the structure of the document, in the form of assets and CSS files, in order to aid in workflow and facilitate reuse and to ease change in design over time.
INTERACTION
Interaction is kept separate, in the form of JavaScript framework class libraries and page code besides, in order to maintain clean HTML structure that can be modified by Web developers without having to deal with the complexity of scripting code and possibly breaking it.
The UIZE JavaScript Framework is inspired by the environment that gave birth to it - the Web. UIZE adopts several paradigms that are inspired by the world of HTML and CSS.
HTML doesn't care in which order tag attributes are specified. This has been a boon to the development of the Web as a platform, as it makes HTML source code human readable and understandable, without requiring a companion reference or IDE in order to make sense of tags. Imagine if tags were implemented using a syntax akin to the function syntax of programming language, where the tag's attributes weren't named, their order was critical, and defaulting required a complex tree of overload permutations and where certain attributes could only be defaulted by specifying null values for them. That would suck.
UIZE likes the idea of naming parameters in the calls to methods. This is accomplished by passing a "params" object hash in method calls. This is great in that it allows the signature of a method to evolve over time without being so disruptive to backwards compatilibilty. New parameters can be added with common sense defaults, and old code can continue on merrily. Defaulting allows parameters to be ommitted without having to worry about having to declare all possible permutations of presence/abscense of parameters in overloads. Not having to worry about order is also great, since the order that seems logical might change as parameters get added. Named parameters help readability and learnability of code.
In some ways it would be nice (at least consistent) if all functions took an object hash of named parameters. In reality, this would be cumbersome for methods with uncomplicated signatures, requiring more typing, adding to the code size, and - most importantly - incurring potentially a substantial performance penalty for heavily hit methods (since building an object hash comes at a price). There are some downsides to params hashes. UIZE takes a necessarily balanced approach, where methods with simple signatures use traditional params, but methods that may have complex param sets or that might likely change a lot over time will use a params hash, or sometimes params hashes for specific arguments.
An invaluable feature, when using JavaScript in the context of a Web document, is reflection. The reflection of an element node's attributes and style properties provides an intuitive and lightweight way to modify the state of the user interface, without understanding the inner working of how state change is managed by the browser's layout / rendering engine.
This is a huge load off the mind of a Web UI engineer, since undoubtedly there are any number of very clever ways in which handling state change is optimized for different scenarios, and undoubtedly there are any number of specific updater methods that are kicked off in carefully chosen order under different circumstances. The UI engineer doesn't have to care about what the browser has to do in order to synchronize the display to a changed state. The change could be minimal, or it could be very major.
The UIZE JavaScript Framework adopts a similar tack, providing a state interface through its Set-get Properties mechanism. In spirit, a widget class should expose its state through the set-get properties, and should register onChange handlers for these properties, as appropriate, in order to synchronize the UI to a changed state. The application developer using the widgets then does not have to worry about a suite of updater methods and understand why two should be used in a specific order in one case, but three should be used in any order in some other case (for example). We call this the "make it so" principle. You tell an instance what state it should be in, and it figures out how to get all its junk into that new state.
UIZE takes the approach that the value of static typing is overestimated and is not philosophically compatible with a dynamic language like JavaScript and the Web environment in which it primarily lives - an environment which emphasizes versatility. Take, for example, CSS, where values for style properties can be specified in any of a number of ways, using dramatically different types and units. Rather than providing multiple differently named methods to do similar things but with different function signatures, UIZE takes the approach of trying to minimize the number of different methods that are created, preferring instead to support common sense defaulting and type versatility for parameter values.
Widgets available in the UIZE JavaScript Framework have been designed using the GLUE paradigm.
"GLUE" stands for Glue Logic Upon Elements. At its heart, GLUE aims to aid the Web interface design process by decoupling the interface skin development from the interface functionality development.
When working on the user interface for a project, graphic designers and HTML coders should not have to wrestle with complicated JavaScript code while they are making aesthetic choices. And the coders wiring up a Web-based application should not have to wrestle with dependencies on graphic/layout designers in order to make progress with developing functionality.
With the GLUE approach, the JavaScript code supporting the functional logic of a user interface can be more cleanly separated from the HTML and CSS code. JavaScript code for interface logic that is tighly integrated into the HTML code results in an application that is more brittle and vulnerable to edits during the ongoing maintenance phase of an application. The GLUE approach is more robust because it more effectively encapsulates the JavaScript interface logic code and puts it out of the reach of casual page tweaks and routine content updates.
With the .NET framework, Microsoft introduced the concept of "code in front" and "code behind". UIZE goes one step further, to introduce the concept of "code beside", which is a recommended practice of separating out the static JavaScript control logic from a page's "code in front" and consolidating it into a single JavaScript library file that typically sits in the same directory as the page and is named the same except for the extension being ".js" (in the case of code beside that is shared across multiple pages, the file can be a module inside the central JavaScript directory).
The "code beside" file can then be separately scrunched (either dynamically or by a site build script) to reduce its size, and the browser can also cache it since it's static. Any dynamic data that should qualify its operation should be "piped" through a clear interface, in the same way that "code in front" and "code behind" should connect through a well defined (and, ideally, thin) interface.
The "code beside" practice is not a requirement in the UIZE JavaScript Framework, but it turns out to faciliate good Web application design. For example, a set of pages that share common interaction logic can implement that logic in a page widget class file that all the pages instantiate. Then, for pages that use that functionality but need to extend it to provide more, a subclass can be created. This is similar - in spirit, at least - to .NET's master pages. Of course, this concept of the "code beside" doesn't care about platform, so you can consolidate interaction logic in code besides with a LAMP driven site - or any other server platform - just as easily.
All of the JavaScript libraries that make up the UIZE JavaScript Framework are contained inside the "js" folder in this documentation bundle.
When developing Web content using the UIZE JavaScript Framework, you need to make sure to source in all the necessary JavaScript libraries for the features you will be using. This is not just the libraries that implement the classes or packages you will be using, but also any libraries that they may depend upon. You may be using multiple libraries that have common dependencies. In that case, make sure to source in each required library only once. Also, make sure to source in all required support libraries before any library that might depend upon them. To check which support libraries a particular library might require, you can look inside the header comment for that library. The required libraries will be listed alongside the comment field "REQUIRED".
If you wish to use the UIZE JavaScript Framework in a Web site, the safest way to make sure that all the necessary JavaScript libraries are available to your site's pages is to copy the entire "js" folder from this documentation bundle into your site. That way, you don't have to mess around with trying to handpick just the libraries that you need while running the risk of missing a library that's needed but where it's not obvious to you.
Of course, the obvious downside of the keeping-it-together approach is that you may have stuff on your server that's not being used. Now, the JavaScript libraries and their associated image and other resources don't take up all that much space. But, if server space is a big concern and you want to save every tiny little scrap of storage space, then you will have to manually pluck out the unnecessary files.
The libraries that make up the UIZE JavaScript Framework are scrunched. Don't be alarmed, don't be afraid, don't flee in terror. This reduces the load time for your Web content that uses the UIZE JavaScript Framework.
The documentation under the "Module Reference" section is generated automatically by a build script that runs through all the JavaScript modules and extracts documentation styled SimpleDoc comments. Because the documentation is still playing catch-up to the code development, you may stumble across many a sad looking module reference page - with nothing on it but a lonely heading. We are working to complete documentation for all the modules, so please be patient with this effort.
UIZE widgets can look very slick and elegant with appropriate design and styling, but the focus of the example pages is keeping the source code as clean and simple as possible, so that one can quickly cut through the fluff and get to the essence of how UIZE classes can be used in a page.
Similarly, UIZE widgets can be combined together in intricate ways to produce sophisticated applications. However, when trying to learn how to use a specific UIZE class, trying to get your head around a complex chunk of code when you just want to see how to use a single damned class can be quite frustrating and counterproductive.
So, the many example pages offered with the documentation are deliberately designed to be quite elemental in nature. Some demonstrate how code components can interact with one another. However, the examples are not necessarily designed to be compelling - they're designed to be instructive. We trust you will use your imagination in applying the UIZE JavaScript Framework towards the development of your own compelling applications.