Hi Sylvain: To many nested threads confuse me and your position now is not clear to me. ;-D
Lets try resume the thread: 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 bolleanfield. Based on this here are my arguments: I guess the 2nd is the best. I also understand the problem behind the checkbox in HTML: http://www.w3.org/TR/html4/interact/forms.html#checkbox But I think in fact there must exist 3-states: 1- true (true, 1, yes, etc.) 2- false (false, 0, no, etc.) 3- undefined (the user don't answer the question). Is this correct? Now I have another question: Given the limitations of a checkbox in HTML, is correct to limit CForms definition implementation based on HTML checkboxes? Are the checkboxes the correct way to render the boolean field? Forms often are used to as the interface of Database data and the the boolean field in a database often can have 3 states (yes, no and null). Even Java allow this using the Boolean class. In XForms specs: http://www.w3.org/TR/2002/CR-xforms-20021112/slice8.html#ui-input I read: <snip> Implementation Requirements: Must allow entry of a lexical value for the bound datatype. Implementations should provide a convenient means for entry of datatypes and take into account localization and internationalization issues such as representation of numbers. For example, an input bound to an instance data node of type xsd:date might provide a calendar control to enter dates; similarly, an input control bound to of type boolean might be rendered as a checkbox. </snip> In the last sentence said about boolean type. Please note I am not trying to attack nobody. I think this is a very important decision and I am seriously thinking in the best way we can choose to define boolean values in our future CForms. Sooner or later other people trying to use database with CForms will point to this issue. So is better discuss about this now when we can freely make changes in CForms specs and avoid future problems with back compatibility. WDYT? Best Regards, Antonio Gallardo
