[whatwg] Extensibility of WF2

[Olav Junker Kjær]

The first thing people are going to do with WF2 is to try to extend it 
with new widgets, because widgets are fun. Therefore extensibility is 
critical for adoption.

I see too ways people will want to extend:

1) Replacing an existing widget. For example, the default widget for a 
slider will typically have a boring native look. Designers will want to 
replace this widget with their own cool animated slider.

2) Add a new widget for a new data type. For example some forms might 
want a color as a input, and a color picker widget could be supplied.

Authors would still want these widgets to hook seamlessly into the WF2 
infrastructure with validation, encoding, submission, events etc.

WF2 need a few additions to make this possible.

In HTML form controls, the value and the UI widget are tightly coupled, 
because its all in the same element. WF2 does not change that, it just 
introduces new types with new tightly coupled UI widgets. This is good 
because its simple.

However to enable extensibility we have to separate the "model" (the 
field data type and value, and constraints) from the "widget" (the user 
interface used to change the value). The widgets used now should be 
considered default widgets. For example a text box is the default widget 
for a text model, a check box is the default widget for a "boolean" 
model (confusingly called a "checkbox" type in HTML :-)) Of course, this 
is the stuff XForms are made of, but in WF2 the seperation of model and 
widget should be an extensibility option, not the default.

While the default widgets is platform and implementation dependent, 
custom widgets will probably be written in a platform independent 
manner. It should be possible to develop custom widgets in ordinary 
javascript and dhtml, without the use of htc, xbl or other platform 
dependent extensibility models.

Form controls could have a "widget" attribute. When this attribute is 
sat to "false", the default widget should not be shown. Instead a custom 
widget would take charge of the user interface (including responsibility 
for ui related properties like "autofocus").

When the user have changed a value through the widget, the widget should 
change the model. This can be done with the current API, if the widget 
sets the value property and thereafter calls changed().

However, I think it would be cleaner if there was methods 
inputValue(newValue) and changeValue(newValue) on the model, which 
changes the current value and fire input or change events respectively. 
This guarantees that the events will be fired, otherwise the widget 
might forget to call changed() and other dependent values might get out 
of sync.

If, on the other hand, some other script changes the value of the model, 
  the widget has to be updated. This is not possible to detect with the 
current API (because scripted changes to value should not trigger input 
or change events to prevent loops), so I propose the addition of a 
valuechanged event. The widget could listen to this event, and update 
the UI accordingly. Of course, the widget must not call changed() as a 
result of this! The last bit is a bit dangerous, since authors will 
confuse onchange and onvaluechanged and cause loops - I dont have a 
solution for this. Maybe the widget would have to explicitly register 
itself with the model, and the model will call a valuechanged method on 
the widget, rather that firing an event?

Another problem is if the widgets themselves contain other form 
controls. These should be "invisible" to the WF2 form. If they dont have 
a name they wont be submitted, but they would still show up in the 
elements collection, and this might cause confusion. I dont know if this 
is a problem but I dont have an obvious solution.

Anyway, I think the issues should be considered.

Olav Junker Kjær