openerp-expert-framework team mailing list archive

[sebastien beau <sebastien.beau@xxxxxxxxxxxx>]

Hi xrg,

What you did is complementary of what I do.
Let's explain. In magento we can have a lot of different attribut per kind
of product. For example if I sold camera , I will have 'number of pixel',
'zoom','screen size'.
As I don't want to store all of the value in 3 new column in my sql table I
will use a json field let's call him 'magerp'.

If I use you patch I will acces to the value of the field doing
product = self.browse(cr, uid, id, context=context)
my_number_of_pixel_is = product.magerp['number_of_pixel']

What I did is just complementary of what did. Indeed like you I store all
value in a json field (I think I will be good to base my module on your
patch) but I all add 'computed' fields for my attributs. So all of my
attributs are store in the json but can be read, write, create as a normal
field. Example :
product = self.browse(cr, uid, id, context=context)
my_number_of_pixel_is = product.magerp.number_of_pixel

It's very usefull for m2m, o2m, mo2 fields
so you can do for example : product.magerp.color.name

Moreover you don't need to build a new widget for editing the json (I don't
think it will be easy to do, we need to support, m2o, o2m, m2m, text, char,
select... also the option require or not)

Hope it's my explication are clear.

Have a nice day






2011/5/20 Raphael Valyi <rvalyi@xxxxxxxxx>

> xrg, something I don't really understand:
>
> You' often mention great changes you did in your branch.
> Well, of course this is cool, many people do great change in some branch,
> even Tryton did.
>
> Now, why are those change buried in your pg84* branch and not merged in
> trunk?
> Is that:
> - a lack of will from OpenERP SA, from you??
> - a lack of resource? If so, why don't you propose merge proposals so that
> the experts can comment and improve?
> I cannot understand how you can work for OpenERP SA and those change by
> buried in such a way that 99% of people potentially interested in them don't
> see them.
>
> Also let me recall you that just like many integrators around, Akretion is
> a small company and if we can afford maintaining some 5 patches or backport
> per customer deployment
> we cannot afford merging with a whole non official branch. It would be too
> much maintenance effort for us.
>
> Any explanation about that?
>
> 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).
>>
>
> Well, will double look. I should have missed something, buy my
> understanding is that is was complementary to what we did, not redundant.
> May be I should explain also better what we did.
>
>
> --
> Raphaël Valyi
> Founder and consultant
> +55 21 3010 9965
> www.akretion.com
>
>
>
>


-- 

BEAU Sébastien
skype : sebastien_beau
www.akretion.com