* Cédric Krier [2011-05-12 11:54 +0200]:
On 12/05/11 11:35 +0200, Nicolas Évrard wrote:
* Cédric Krier [2011-05-12 11:03 +0200]:
>There is many more type of fields where the "unknown" value is not
>supported.
>
>So for me, there is no problem to implement the "unknown" value in
>Float fields but we need to keep the "not zero" mechanism and perhaps
>keep the default value for required True.
I don't think this is a good idea. If a numeric field is required then
people have to input a value. There might be a good default defined in
the module but we don't know which value this is and we should not
choose one from one of the א0 value available in integer or (א1 if
we're talking about floats).
You did not understand.
I mean the current "required" parameter on Float fields means "!= 0".
And in this possible migration we will replace the meaning of "required" by a
new parameter "nonzero". And I think it will be a good idea to have as default
value for the new "required" parameter "True" like that we keep the same
behavior by default.
You're not clear. What do you mean ?
You want to rename "required" to "nonzero" for numerical fields ?
If so then this will no settle the situation.
Or maybe you want to add a nonzero parameter. Which does not seems
useful to me.
>But as we already need to keep the "unknow" information about a many
>other kind of fields into an other field. For me I don't see the need
>to make this change. We can always fix the (not so often) cases of
>"unknown" value for Float with a Boolean field that will show/hide
>the field.
The unknown value is problematic only when the field is required. In
this case we must have a way to discriminate between "unkwown" values
and any other valid values, otherwise not knowing the value of a field
is not problem.
Choosing not to reduce the ambiguity is in my opinion more error prone
than the other way around
In the explicit case of the sale line, there is no unknown value possible.
The user must enter a value in the field and when I write the module I was
thinking that it is good the prevent the user to forget to enter a price.
Yes there is no unknown value allowed, thus the field should be
required. If the user want this value to be 0, so be it. Right now
this use case does not work.
By having the unit_price field required with a default value of
unknow (thus leaving the field empty) would have trigger validation of
the form and the user would then have the opportunity to insert the
right value.
Adding a checkbox so that the user agree to let the value to zero is
another problem.
For me, there is no ambiguity once you accept that a Float field will always
have a float value.
A Float field should only have a numerical value if it is required to
do so. Do you expect Date Field to always have a date value so that
you can do all kind of date operation on them ? Do you expect Many2One
field to have a non NULL value ? No, unless those fields are required.
I think that it should work the same way for numerical fields.
Indeed I remember to have to fix a lot of error in OpenERP
where this is not the case (but the GUI doesn't allow "unknown" values) and
most of the time the fix was simply "value or 0.0". So I think I prefer a
framework where the common cases are handle by default.
Invoking the big bad wolf ;).
I am more incline to think that those fixes displayed more a bad
design in openerp modules than the need to always have numerical value
for numerical fields.
In the business application world, I really think there are few places where
we need to deal with "unknown" values.
Every non required field could be "unknownable". If you want them to
have a value (whatever it is) then the field must become required.
That is why I say that we could extend the Float behavior but the default
should stay as it is now.
This might be a compromise. But I prefer that we implement client side
validation (with the domain inversion like we talked about earlier)
and using this mechanism.
--
Nicolas Évrard
B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
E-mail/Jabber: [email protected]
Website: http://www.b2ck.com/
--
[email protected] mailing list
