cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [Woody] We need a booleanfield at all?
Date Thu, 22 Jan 2004 18:20:28 GMT wrote:

>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
>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"
>  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...

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.


>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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message