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.
Honestly, I don't think speed is the real issue here...
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>
IMO, this concern belongs more to the convertor than the datatype, as the convertor sits between the request parameters and the datatype and is in charge of converting these parameters from/to the datatype.
Furthermore, the value of the "null" attribute has to be converted into the target datatype, and this is again a convertor job!
And more: the boolean datatype can have two convertors. The default one will consider null as false, which will automagically handle HTML checkboxes. A second one, will consider null... as null and can be used for tri-state booleans.
WDYT?
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.
Mmmh... I'm not sure this is so simple, as the template engine doesn't know what the final rendering will be. What about my proposal above?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
