Hi Cédric, [...] > > I think I found a solution. > > The context parameter is only an issue for method callable by rpc. So I > > propose to create a decorator on these methods that will put the context > > dictionnary from parameter and put it in the transaction. [...] > So finally, I think it is simplier to force to have context as last argument > of each rpc call and then remove context from every methods.
this all sound very interesting and I am sure it will be a great improvement on the way to an easy to use, powerfull and stable API. No question, the context=context is ugly and could be replaced by a better implementation. But I get a little afraid about my understandings of the changes for the context. Some questions to clarify: 1. Will we loose any functionality with a new implementation of the context? 2. What does it exactly mean to have the context set in transaction? And what is the consequence of this change? 3. Will we gain more functionality/possibilities with a new implementation of the context? And at last there was an older discussion[1] about context. Maybe there is interesting input inside. [1] http://bugs.tryton.org/roundup/issue1074 Cheers -- Udo Spallek ------------------------------------ virtual things Preisler & Spallek GbR Munich - Aix-la-Chapelle Windeckstr. 77 81375 Munich - Germany Tel: +49 (89) 710 481 55 Fax: +49 (89) 710 481 56 [email protected] http://www.virtual-things.biz -- [email protected] mailing list
