cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [Woody] We need a booleanfield at all?
Date Thu, 22 Jan 2004 18:20:28 GMT
tim@keow.org 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
>>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



Mime
View raw message