[whatwg] More thoughts about custom widgets

[Olav Junker Kjær]

I thought a little bit more about custom widgets.

Two audiences are involved. People writing custom widgets, and people 
using custom widgets developed by others. The first group have at least 
some experience with javascript. The last group might not understand 
javascript at all, but may have used some cut-and-paste scripts.

I should be as easy as possible to use a custom widget (developed by 
someone else) on a WF2, preferable it should be done without any javascript.

Using a color picker in a form should be as easy as

1) include <script src="customcolorpicker.js"></script> in the header
2) writing: <input type="text" widget="colorpicker"> in the form.

On the other hand, in a platform specific environment, is should be just 
as easy to use some advanced extension mechanism:

<input type="text" widget="colorpicker1">
<cyberwidgets:colorpicker id=colorpicker1>
</cyberwidgets:colorpicker>

The widget probably need to execute some code at initialization time, to 
generate its initial html representation. If the widget is implemented 
as a xbl or something like this, the widget element can handle this on 
its own. However, if the widget is implemented in a javascript file, 
some initialization method must be called from the WF2 field.

I imagine something like: a field has a widget attribute which is either 
the ID of an element or the name of a globally defined javascript 
function. Or it could be a javascript expression which evaluates to a 
function or object/element reference.
If the property is sat through the DOM, the value might be a reference 
rather than a name or expression.

When the field is initialized, the widget attribute is checked. If it is 
present, the default widget is hidden and the value is evaluated.
- If it evaluates to a javascript function, the function is executed 
with the field as parameter.
- If it evaluates to an element (or javascript object), and that object 
has a method 'initializeWidget()', that method it is called with the 
field as parameter.

The function (which might be a constructor) or method initializes the 
widget, generates additional HTML in the document, and keeps a reference 
to the underlying field for tracking and updating its value.

This is a bit fuzzy I know, but I think the important part is that it 
should be very easy for casual HTML authors to connect a 3rd party 
widget to a WF2 field. The API for custom widget should be simple, but 
not at the expense of making it more complicated to integrate the widget 
in a form.

Olav Junker Kjær