The values of these locale string state properties can be either string type (in the simple case) or function type (in the case of strings accepting inputs).

Represented as state properties, locale strings can be bound to the HTML using the same binding techniques used for binding other state properties.

In order to prevent state properties that represent locale strings from competing with other state properties, a naming convention can be used to put them in their own unique namespace.

For example, all locale string state properties could be put under a namespace prefix such as "$", "str_", "loc_", etc.

As an alternative to representing individual locale strings as separate state property, one could use a single object state property to represent all locale strings.

In order for this to be viable, it would be necessary to support more granular changed events and binding of properties of state property object values to HTML.

Whenever the value of the locale state property changes, a locale stirngs module should be loaded if necessary (i.e. not already loaded), and the values of the locale strings from the module should be used to set the corresponding locale string state properties on the instance.

The locale state property should be a tree-inherited property, so that a locale change on a widget is propagated to all its child widgets, which are set by default to inherit the value of the property from the parent. Optionally, any widget can choose to not inherit the parent's value and explicitly set their own.

Whenever the value of the locale state property changes, an optional locale-specific theme CSS module can be loaded.

In order to improve the user experience when the UI is rendered, locale string modules can be injected as implicit dependencies by the module system, based upon an environment setting for locale.

This will support both the dynamic loading of locale string modules as dependencies of the widget modules that need them, as well as packaging of the locale string modules along with the widget modules that use them.

EXAMPLE - ICU MESSAGE FORMAT

{gender_of_host, select,
  female {
    {num_guests, plural, offset:1
      =0 {{host} does not give a party.}
      =1 {{host} invites {guest} to her party.}
      =2 {{host} invites {guest} and one other person to her party.}
      other {{host} invites {guest} and # other people to her party.}
    }
  }
  male {
    {num_guests, plural, offset:1
      =0 {{host} does not give a party.}
      =1 {{host} invites {guest} to his party.}
      =2 {{host} invites {guest} and one other person to his party.}
      other {{host} invites {guest} and # other people to his party.}
    }
  }
  other {
    {num_guests, plural, offset:1
      =0 {{host} does not give a party.}
      =1 {{host} invites {guest} to their party.}
      =2 {{host} invites {guest} and one other person to their party.}
      other {{host} invites {guest} and # other people to their party.}
    }
  }
}

UIZE FORMAT

invitation
  host.gender == 'female'
    num_guests == 0: {host} does not give a party.
    num_guests == 1: {host} invites {guest} to her party.
    num_guests == 2: invites {guest} and one other person to her party.
    else: {host} invites {guest} and {num_guests - 1} other people to her party.
  host.gender == 'male'
    num_guests == 0: {host} does not give a party.
    num_guests == 1: {host} invites {guest} to his party.
    num_guests == 2: invites {guest} and one other person to his party.
    else: {host} invites {guest} and {num_guests - 1} other people to his party.
  else
    num_guests == 0: {host} does not give a party.
    num_guests == 1: {host} invites {guest} to their party.
    num_guests == 2: invites {guest} and one other person to their party.
    else: {host} invites {guest} and {num_guests - 1} other people to their party.

UIZE FORMAT - ALTERNATE

invitation
  host.gender == 'female' && num_guests == 0: {host} does not give a party.
  host.gender == 'female' && num_guests == 1: {host} invites {guest} to her party.
  host.gender == 'female' && num_guests == 2: invites {guest} and one other person to her party.
  host.gender == 'female': {host} invites {guest} and {num_guests - 1} other people to her party.
  host.gender == 'male' && num_guests == 0: {host} does not give a party.
  host.gender == 'male' && num_guests == 1: {host} invites {guest} to his party.
  host.gender == 'male' && num_guests == 2: invites {guest} and one other person to his party.
  host.gender == 'male': {host} invites {guest} and {num_guests - 1} other people to his party.
  num_guests == 0: {host} does not give a party.
  num_guests == 1: {host} invites {guest} to their party.
  num_guests == 2: invites {guest} and one other person to their party.
  else: {host} invites {guest} and {num_guests - 1} other people to their party.

The code inside the UI wirer function would not need to be wrapped inside a if (m.isWired) safety check, since this would be taken care of by the wireUI implementation in the base class.

The UI wirer function would not need to call the UI wirer for the superclass, since this would be taken care of by the wireUI implementation in the base class.

An added benefit of the UI wirer declarative approach is that it would enforce the additive subclassing pattern, so every wirer would count on the fact that the wirers for all shallower classes along the inheritance chain have already been executed by the time that the UI wirer for the current subclass is executed.

As an enhancement, the instance reference is passed to the wirer functions as the first argument.

This means that the value of this doesn't need to be captured with an additional statement to assign it to a local variable, thereby reducing code size and making coding easier.

EXAMPLE

_superclass.subclass ({
  uiWirer:function (m) {
    // wiring logic here
  }
});

The wirer functions would still be called with the instance as context, so the old approach would still be supported as well...

STILL SUPPORTED

_superclass.subclass ({
  uiWirer:function () {
    var m = this;
    // wiring logic here
  }
});

OLD APPROACH...

_superclass.subclass ({
  wireUi:function () {
    var m = this;
    if (!m.isWired) {
      // wiring logic here
      _superclass.doMy (m,'wireUi');
    }
  }
});

NEW APPROACH...

_superclass.subclass ({
  uiWirer:function (m) {
    // wiring logic here
  }
});

Perhaps bindings to the style object could be treated as bindings on the style of a child widget's root node, but this could be quite complicated for rendering of HTML, since the HTML generation for a child widget is opaque to the template for a widget and cannot be easily co-compiled.

Perhaps a more reasonable approach would be to treat bindings to the style object of a child widget as bindings to a style state property that is implemented in the Uize.Widget.V2 base class and that is bound to the style object of the widget's root node. Then, bindings to a child widget's style object would be propagated through the style state property of the child widget to its root node's style property.