Sylvain Wallez dijo: > Antonio Gallardo wrote: > >>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) ?
Yep. They are equal. Sorry for the noise. :-( > >>>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? No. Because it is up to the user to choose how manage it. But you are true, the "damn" HTML checkbox is a PITA! The idea of a default value is outside of how to manage the Boolean datatype. Also it can be generic or a "function" that fills the default value. Example: Suppose we need to set as default value: 1-the next date from a table in the database. 2-The next serial of a invoice. This cases can only be done using a Java or flow function that will retrieve the data from a database. Also the binding framework can already take care of that? The answer is: not for all cases. This is the idea of the default value I have in mind. >>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. Yep. But, what else with can do? How to recognize when it is null or false? In this case I think we can handle the HTML checkbox as a special case: only true and false. Of course the user that choose to use a checkbox must be aware of this. In this way, maybe the another boolean representation can be with 3 states. Best Regards, Antonio Gallardo
