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
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
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.