- From: Olav Junker Kjær <olav@olav.dk>
- Date: Mon, 22 Nov 2004 22:39:03 +0100
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
Received on Monday, 22 November 2004 13:39:03 UTC