UIZE JavaScript Framework

TO DO - External Site Integration

This TO DO document is intended to capture all the requirements that need to be satisfied in order to make UIZE a widely acceptable framework that can be integrated into external sites as easily and cleanly as possible.

In order for using UIZE to be a viable option for external sites, the following needs will have to be addressed in UIZE...

1. Multiple Code Sources

External sites would want to keep their codebase separate from the UIZE codebase, so it would be necessary to provide a way for all modules - JS, CSS, images, HTML templates, etc. - to be able to be organized into separate external site and UIZE areas.

The dynamic loader system would need to support multiple sources, as well as the build processes.

2. Module Wrapping of Third Party JavaScript


3. Packaging

3.1. JS Packaging


3.2. CSS Packaging


3.3. Image Spritifying


3.4. HTML Template Compiling


4. Localization

To achieve the greatest flexibility, with regards to UIZE integration in external sites, the entire localization system should be configurable.

This argues in favor of implementing localization as a service.

4.1. Localization as a Service

To allow the entire localization system to be swapped out in favor of a localization system that may already be in place for an external site, localization should be implemented as a service.

4.1.1. Limitations of Current Localization Implementation

In the current implementation, the localization is implemented in a specific and somewhat restrictive way.

The current implementation has the following limitations / shortcomings...

a specific substitution token syntax is imposed
the localization system doesn't explicitly address quantities and gender of substitutions
localization is limited to widget instances
there's no way to swap out the entire localization system
no system is provided for storing locale strings and piping locale strings through a localization workflow

4.2. Design Requirements

For maximum flexibility, the localization system should meet the following requirements...

4.2.1. Dynamic Updating


4.2.2. Mixed Locales


4.2.3. Different Localization Workflows


4.2.4. A Viable Reference Implementation


5. MVC System

Base classes would need to be provided for the model, view, and controller aspects of an MVC code architecture.

6. jQuery Interoperability

A way would have to be provided to allow jQuery code to be used in conjunction with UIZE, which includes jQuery plugins.

6.1. jQuery Files as UIZE Modules

To satisfy the dependency management system, a way should be provided to allow jQuery files to be wrapped / expressed as UIZE modules.

This could potentially be achieved by a build handler for 3rd party files that does the wrapping as part of a build process.

7. Folder Organization of Code

Currently, UIZE is built around the assumption that all code exists in a flat js folder structure.

Ideally, in order to facilitate better management of code, UIZE would be adapted to support different code being able to exist in different folders.

8. Visual Unit Tests for Widgets

UIZE should provide a way that JavaScript visual widget unit tests can be developed, with a system for easily navigating and running those unit tests.

This system should also make it possible to provide fake data services setup, as needed, in order to view widgets divorced from live application dependencies.

9. CSS Class Namespacing


9.1. CSS Class Namespacing in CSS Files


9.2. CSS Class Name Expansion in HTML Templates