|
||||
 |
|
|||
The frontend ZZ javascript framework may be used independently of the backend ZZ php framework – the predominant part of ZZ javascript's features are generic.
ZZ javascript frontend establishes an overlay over the major browser's idiosyncracies when it comes to bugs and (failing) W3C compliance. The event module, for instance, hides Internet Explorers non-standard event model – effectively eliminating the need to write conditional event statements once and for all.
The event module also ensures that all event listeners are listed in a searchable registry, and that the related function calls are executed in correct order (or an alternative order specified by you).
Javascript's native error handling is very limited, bordering on non-existing. Lot's of errors are suppressed, or treated like "value x doesn't make sense, we assume they meant y". And when you actually detect an error it's usually pretty hard to trace it.
ZZ javascript framework, on the over hand, anticipates that the programmer makes errors (and doesn't try to outguess her) and that other things may (will) go wrong.
Arguments for complex/sensitive functions of ZZ javascript are typically checked thoroughly for type and value – make an error, and you get an exception (and an exhaustive identification of who/where/what).
And all variables and objects may be type checked unambiguously, plus inspected via various dump methods.
Inheritance in ZZ javascript does – despite using prototypes – resemble inheritance of classical object oriented languages like Java:
• properties of Child override same-named properties of Parent
• hierarchical inheritance; Child extends Parent, who by itself extends Ancestor
• multiple inheritance; Child extends Parent, Aunt and Uncle
• parent constructor(s) are called during Child instantiation
• Child extends Parent directly, not via an instance of Parent
ZZ's user interface module is based on classical inheritance. The base classes of ZZ.ui are used as building blocks for creating higher level classes like dialogue boxes.
That said, ZZ doesn't preclude the use a plain prototypal inheritance – if you don't care about lost constructors etc. you just use unmediated javascript inheritance.
Javascript supports a lot of exotic patterns. But some types of expressions tend to result
in fairly
illegible code (and the speed/overhead savings of the exotics are overrated).
Illegible code spells errors and (later) a lot of wasted time when modifying the code.
In ZZ javascript the exotics are limited, i.e. ZZ uses closures extensively, but the use of stuff like callbacks is somewhat restrained. Lots of people will disagree on this point, but the objectives of ZZ are safety and manageability, not fancy code.
Check the Javadoc style JsDoc documentation for a full and detailed overview of the framework.
The framework is most likely Ecmascript 5 Script compliant, though cannot be tested for it before one of the browsers implements the strict mode.
And it's continuously tested against Douglas Crockfords wonderful JSLint code quality validator (using Yahoo's convenient widget).
Some modules of ZZ javascript frontend – like the ui, com (XMLHttpRequest) and state modules – are not fully implemented, and the integration with the backend is not fully evolved.
However, most of the currently existing modules are fully usable and fairly well tested.