cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject [Woody] We need a booleanfield at all? (was: [Woody] Boolean widget as a combobox)
Date Thu, 22 Jan 2004 10:28:29 GMT
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

Based on this here are my arguments:

I guess the 2nd is the best.

I also understand the problem behind the checkbox in HTML:

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

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:

I read:

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.

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.


Best Regards,

Antonio Gallardo

View raw message