| Thread Previous • Date Previous • Date Next • Thread Next |
Le 08/07/2011 03:04, Olivier Dony a écrit :
On 07/08/2011 12:09 AM, Albert Cervera i Areny wrote:Well, we use an osv.except_osv() instead of returning False.That works as a valid alternative, good point!I think the API should simply not include the possibility of adding a static text and force the developer to always use the exception. The possibility that comments Olivier seems to complex to me, compared to how easy it is to raise an insightful exception._constraints offer a SQL-like way to perform business-level validation checks. Hence the API is based on the result of a boolean test, exactly like SQL constraints, and the user notification is handled elsewhere. To me, this is good and simple, and you have the other, more complicated options when needed (such as explicitly raising). The static messages also save you the trouble of repeated boilerplate code (raising, translating, coming up with a yet another meaningful exception title, etc.), for the many cases where a static message is sufficient.
The osv.except_osv solution is good for me. I didn't know that we would use a method for the message since 6.0, but here I can't use it because I need data used into the constraint method.
Moreover, I agree with Raphael. I thought about it yesterday writing a module which should show a warning if an employee work more than X hours per day/week. The total work time is a sum of the duration of the tasks he worked on for the period.
The problem is that I can't show a warning : all the tasks doesn't have a duration. So doing an on_change on the user_id of the task object is not reliable because if the date is set after the user it won't work. One way could be to add an on_change on all the fields : date and user. But isn't this a hack ?
Currently we have two level of validation : DB Validation (_sql_constraints), Field validation (_constraints). I think we miss a model-level validation. Yes, we can override write(), but I'm not sure it's the best way.
We should be able to show a warning at both field-level and model-level validation, without using on_change.
A possible implementation could be to add a is_valid() method that is called before the object is saved. The method could return True, raise and except_osv exception or a WarningException (or anything else) depending on what you want to do.
| Thread Previous • Date Previous • Date Next • Thread Next |
