openerp-expert-framework team mailing list archive

["P. Christeas" <p_christ@xxxxxx>]

On Thursday 19 May 2011, you wrote:
> Hello xrg,
> 
> I knew your patch since you shown me some 6 months ago. I think it could be
> contributed to improve the system we built. Notice there there is a
> difference:
> from what I understand this patch is only about having a new field able to
> store json with some control (and this is good).
> 
> Now, we needed something more in the Magento connector. Magento has an EAV
> prdouct attribute structure allowing to store many sparse attributes

This "struct" field is all about that: it allows a /structure/ of pythonic 
fields to come as a payload. It could be a list, a dict, whatever. Actually, 
the "serializable" field had the same behavior, wrt. to the client API. I just 
thought it would be better to use json-encoded storage instead of 
repr()/eval(). Especially in a period that nobody seems to use those fields (or 
know their existence).

In any case, the client will send/receive a pythonic struct, to the extent 
that each RPC protocol allows.

>... 
> Any reason why you didn't post that on the framework expert mailing list so
> that anybody can know about your patch and how it relates to our work?
> May I forward it there?
All this mail can go to that list, of course.

> 1) a more modular on_change....

> 2) a more extensible selection fields were adding values is possible 
Been there, done that. In pg84-next API you can write:
	fields.inherit(selection_extend=[('add3', 'Third option'), ('add4', 
'Fourth option')] )


> 3) a few fiscal requirement: tax included can be computed 2 ways, here in
> Brazil the tax is computed over the base + the tax value, it forces us to
> override many things currently. We need such an option than can fit with
> the cascading of 5 taxes per product lines on average.
> 4) we need the fiscal position to be order line base to make the number of
> mapping rule more manageable (else would need over 2000+ mapping rules
> here)...
> 5) we need localization to enforce standards rules. 
Some of these would be feasible with virtual functions, courtesy of pg84. See, 
you can alter the behavior of some fns(), but only for the records (say, the 
ones belong to Brazil partners) you're interested.

> We understand this work should be a huge priority for OpenERP SA because it
> could cut by 2 or more the entry barrier of OpenERP in Latin America and
> other exotic localizations. So it means more revenues for you instead of
> struggling with the sales of your services in those markets.
That's marketing stuff.. Not my speciality.  I only try to make sure the 
product works.


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