cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agsoftware.dnsalias.com>
Subject Re: [Woody] We need a booleanfield at all?
Date Thu, 22 Jan 2004 17:57:21 GMT
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

Mime
View raw message