Sylvain Wallez dijo: > Antonio Gallardo wrote: > >>Hi Sylvain: >> >>To many nested threads confuse me and your position now is not clear to >> me. ;-D >> >> > > Actually, I slowly changed my mind while writing the previous post ;-)
3rd time? lol. I know it is not an easy decision. We must discuss this further. To be honest I am not sure what is the best to do too! ;-DD Exchanging ideas I think we can find the best solution. See below: > >>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). >> >> > > 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). > 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. 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" Best Regards, Antonio Gallardo
