openerp-expert-framework team mailing list archive

["P. Christeas" <xrg@xxxxxxxx>]

On Tuesday 26 July 2011, Ovnicraft wrote:
> Hello, many times i found this necessary in action definition put in
> context this:
> 
> {'field':object.my_method()}
> 
> 
> I was reading the implementation of expr_eval in clients i dont see a big
> change and it could be implemented on trunk. (i will work on )
> 
> I hope your feedbacks and know if you find this a nice_to_have.


There is a few reasons why (IMHO) this shouldn't happen.

First, it would be a security risk to allow such an operation. We have worked 
hard to have restricted eval(), allowing again arbitrary functions would be a 
step back.

Second, the execution mode of the context expressions is a question. Some 
expressions are evaluated at the client side, others at the server side.

Third, most ORM functions have to take the (cr, uid, ids,...) arguments. This 
would both make your proposed API difficult to write, and totally insecure 
(client side would then be able to override the arguments).

Last, the point (in time) of context evaluation would then matter. So far we 
have had static context values. If we make it dynamic (through function 
execution), the order of evaluation (at loading the form, pre-loading or 
lazily at some point later) would complicate things.


Alternatively, you might be able to do operations through the on_change() 
callbacks, or even through function fields of the objects.

Can you give us a scenario where the current API is not enough and you need 
this functions-in-context feature?


-- 
Say NO to spam and viruses. Stop using Microsoft Windows!