Sylvain Wallez dijo:
<snip/>
See my answer to Vadim: this is the distinction between the boolean
primitive (2 states) and java.lang.Boolean (3 states). And we need to be
able to handle both cases depending on the application need.
I agree. But maybe an nullable attribute could be enough to us:
<wd:field nullable="true|false"> (default true).
How is it different from required="false|true" (default false) ?
So my current state of mind is that booleanfield can be avoided if we define what happens to a null value and if we provide something to handle both 2-states and 3-states booleans.
IMO, all this can be handled by convertors.
Not sure. I prefer to have just Boolean type (3states) and in case we need
an boolean the user must define what to do if he got a null value. In some
cases user will choose to got a true if it is null and in other cases it
can choose to got a false.
What you propose definitely looks like a default value, no?
If we allow the java boolean as a new datatype (because it does not allow null at all) then we can wait for new request for double, int, etc. All of them have the same characteristic: don't allow null at all. Here I see a problem and a overcomplicated situation that we need to avoid.
Also if we are going to refactor it, we don't need to forget to add the
"default value"
The default value looks like a good solution.
But I would still like to know how we will handle that damn HTML checkbox. Since "unchecked" translates to "null value", does this mean we'll have to specify default="false" on all 2-state boolean fields? This seems quite unnatural.
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
