5.1.1. - generated pages

5.1.2. - links

.

This can be viewed as a configuration for the UIZE Web site project, and not a general configuration for UIZE.

.

5.4.1. Loading Modules in build.js

5.4.2. Folder Organized Namespaces

5.4.3. File Builders

5.4.4. Module Lists

5.4.5. Build Configuration of External Code

5.5.1. Implement as a File Service Configuration

5.5.2. Implement Using Symbolic Links

.

5.6.1. UIZE Version Compatibility

5.6.2. File Builder Compatibility

Static properties whose values are functions are regarded as static methods.

Perhaps in such cases such features should just get documented and referred to as static methods. In the future, however, it should be possible to register a feature as a static property, but where the type of the property can be function, through a formal feature declaration mechanism.

Documenting extension modules can mess things up.

Loading extension modules in the documentation build script in order to document them can have the side effect of modifying a class, and other modules that are subclasses of the modified class that are then documented later appear to have features that they really do not have, because they've inherited the features that were extended on their base class by loading and documenting the extension module.

State properties whose initial values are objects or arrays are incorrectly indicated as having been overridden in a module that inherits the feature.

This is simply because the initial value in the subclass is a clone of the initial value in the base class and not a shared reference. The initial value is a clone because the whole property definition is a clone. Not sure what the solution is.

12.1.1. - all pages

12.1.2. - example pages

12.1.3. - misc

alert (blah);            // displays "Hello"
alert (blah + 'Brian');  // displays "Hello, Brian"

define blah

var blah = {};
blah.toString = function () {return 'Hello'};
blah.valueOf = function () {return 'Hello, '};

or...

var blah = new String ('Hello');
blah.valueOf = function () {return 'Hello, '};

or...

var blah = new String ('Hello');
blah.valueOf = function () {return this.toString () + ', '};

optimize the following statement...

someCondition ? variableA - variableB : variableA
variableA - (someCondition ? variableB : 0)
variableA - someCondition * variableB        // works if someCondition is guaranteed to produce a boolean
variableA - !!someCondition * variableB      // works even if someCondition is not a boolean value

Finish loop optimization approaches performance test.

if (blah) doSomething ();   ==>  blah && doSomething ();
if (!blah) doSomething ();  ==>  blah || doSomething ();

.

.

if (!_param) _param = _lastValue;
if (_param) {
  // do stuff
}
_lastValue = _param;

if (_param || (_param = _lastValue)) {
  // do stuff
}
_lastValue = _param;

function hasLineExceedingMaxLength (sourceStr,maxLength) {
  return new RegExp ('^.{' + (maxLength + 1) + ',}$','m').test (sourceStr);
}

myArray.concat ();

myString.split ('');

myString.split ('').join (' ');

if (someInstance.constructor == SomeClass) {
  // ...
}

if (someInstance1.constructor == someInstance2.constructor) {
  // ...
}

someInstance2 = someInstance1.Class (someInstance1.get ());

22.1.1. General

22.1.2. Module References

resultTYPE = object.methodName (...);

object.methodName (...);

Add an Entry to the Site Map

22.2.1. Announce the New Guide

Create an guide to explain the approach UIZE takes to services.

Document the conditions system that is implemented in the Uize.Class base class.

Document the needs management system that is implemented in the Uize.Util.Needs class.

23.5.1. - UIZE works in smart phones and other mobile devices with Web browsers that support JavaScript and other Web standards

23.5.2. - emphasize that UIZE file size is compact, and that features better suited to devices with more real estate, processing power, or memory need not be loaded in

23.7.1. - progressive enhancement

23.10.1. - subclassing existing widget classes, or other classes

23.10.2. - extending color support

23.10.3. - extending Fx

23.10.4. - adding support for communication protocols

I read over the JavaScript Library Documentation and here are my suggestions:

Looking at all my suggestions, I think I understand now where my confusions lie. In some regards I'm a visual learner so I like to see things rather than just read or hear them. So for the more tricky explanation, an example of what you're talking about would clear things up for me. Towards the end of the guide it seems that you talked about some of the things I was mentioning earlier on the guide, so maybe some well-placed links to further in the document might help as well.

But overall after reading the guide, I think you really need to beat the developer over the head as to why library files are useful. There's all this explanation of how they were and some dancing you have to do, but only a little bit on why you would actually use them.

26.2.1. General:

26.2.2. Where They Live:

26.2.3. 3.1

26.2.4. 3.1.2.3

26.2.5. Real World Examples

26.2.6. 7.1

27.1.1. Order Unimportant

27.1.2. Requiring Extension Modules

You can have multiple consecutive module declarations that share common required modules and things will work correctly, rather than some of the required modules being loaded multiple times (which would cause all sorts of problems with modules stomping over themselves when re-declaring themselves and thereby crippling code).

EXAMPLE

Uize.module ({
  name:'MyNamespace.Module1',
  required:'Uize.Widget',
  builder:function () {
    alert ('build the first module');
  }
});

Uize.module ({
  name:'MyNamespace.Module1',
  required:'Uize.Widget',
  builder:function () {
    alert ('build the second module');
  }
});

The first module being declared requires the Uize.Widget module. If this module is not already loaded, then the module loader mechanism will load it asynchronously. The second module declaration occurs immediately after the first (because this code is synchronous), and it also requires the Uize.Widget module. A second request to load this required module externally is not made, because the module loader mechanism knows that loading of the module is already in progress.

You can have an inline module declaration that requires other external modules, and subsequent inline module declarations that require that first module will correctly wait until it is built - rather than trying to load it externally

EXAMPLE

Uize.module ({
  name:'Uize.MyInlineModule',
  required:'Uize.Widget',
  builder:function () {
    alert ('build Uize.MyInlineModule');
  }
});

Uize.module {{
  required:'Uize.MyInlineModule',
  builder:function () {
    alert ('build the anonymous module that requires Uize.MyInlineModule');
  }
});

The Uize.MyInlineModule module may not be built yet when the second, anonymous module is declared because Uize.MyInlineModule requires the module Uize.Widget that may not yet be defined and may have to be loaded asynchronously. Now, when the anonymous module is declared, the module loader mechanism doesn't try to load Uize.MyInlineModule externally even though it is not yet defined, because it knows that this required module is in the process of being defined.

Document the pattern of creating inner classes.

27.4.1. Private Inner Classes

Uize.module ({
  name:'MySite.MyClass',
  required:[
    'MySite.Widget',  // required as base class of inner class
    'Uize.Data'       // required for inner class
  ],
  builder:function () {
    /*** create the inner class ***/
      var _MyInnerClass = MySite.Widget.subclass ();
      // code here to further create the inner class

    /*** build the class ***/
      // code here to build the main class for the module
  }
});

27.4.2. Public Inner Classes

27.4.3. Can't Have Inner Subclasses

Uize.map (30,'key > 1 ? this [key - 2] + this [key - 1] : key')

Can't do this with JavaScript 1.6's map method (or the map methods in any other framework), because the map function can't reference the newly created target array.