On Thu, Jan 22, 2004 at 04:28:29AM -0600, Antonio Gallardo wrote:
> We have 2 positions:
>
> 1-booleanfield need to exist. It is a special handling case. If we need to
> render it in other ways: comboboxes, radio buttons, etc. We need to do it
> in a wi:styling.
>
> 2-We don't need a boolean field at all, since it is just a special case of
> wd:field. Let's rewrote the woody definition specification without
> booleanfield.
If we need the speed provided by having a special handling class,
then we could adapt the FieldDefinitionBuilder to choose to create
a FieldDefinition or a BooleanFieldDefinition based on the features
that are requested in the definition. This way we could have the
speed without having to provide wd:booleanfield as an exception to
the otherwise clean wd:field-with-wd:datatype model.
What if we introduce a new "null" attribute to the definition or
to the datatype (which place makes more sense?):
attr missing - null or missing parameter means null
null="null" - null or missing parameter means null
null="false" - null or missing parameter means "false"
null="true" - for balance, would this have a use?
This may be useful for other datatypes as well:
null="some-value" - null or missing parameter means "some-value"
<duck-and-run>
null="some-expression" - null or missing parameter causes
expression to be evaluated, possibly calculating a value
based on the values of other widgets. The duck-and-run
is because this kind of logic may belong elsewhere...
</duck-and-run>
Optionally, for HTML checkbox rendering we could have the template
generator/processor check to make sure that the "null" attribute
is not missing or set to equal "null" for boolean valued fields.
This would help prevent people from tripping over the mis-design
of the HTML spec's handling of checkboxes.
--Tim Larson
