On 15/12/11 16:32 +0100, Albert Cervera i Areny wrote: > A Dijous, 15 de desembre de 2011 14:32:36, Cédric Krier va escriure: > > Reviewing the issue2345 [1], I came to the conclusion that we must > > remove the Property fields. The design is wrong as Albert pointed and we > > can replace it by something more explicit and efficient. > > > > All the current Property fields are used for multi-company only. > > So my idea is to replace them by Function field that will use a table to > > store the value (with the company if needed). > > For the default value, I think depending of the cases we could use the > > same design as on product when it must use the category values, so > > simply a check box and store it on a Singleton. > > For the search, we will be able to reuse the ORM of Tryton and for now > > it will use a clause "id IN" (could be done with the SQL query). But I > > think once we will have python-sql intergrated we will use a python SQL > > clause. > > > > This work can be done incrementally by changing Property fields one by > > one. So if you plan to help on this, please fill an issue before > > starting and link it to issue2349 [2]. > > Don't know if I understood this correctly, but given how usual this need is > it > may be worth to create a new field type (inheriting Function, possibly) that > encapsulated that work? > > For example, I think translations should also be handled with the same > mechanism.
I don't think we can manage translation the same way or at least not for
all the translation that must ended in a po file.
But it is a topic we still need to think about.
> So you'd have a field type in which you say that the given value
> depends on the context:
>
> name = fields.Property(fields.Char('Translatable Name'), context_key='lang',
> model='ir.lang')
>
> or
>
> value = fields.Property(fields.Many2One('Company Dependant Value'...),
> context_key='company', model='company.company')
>
> I mean, we may end up with a hundred of those fields so it may be worth
> encapsulating that work somehow. What do you think?
I think it will not help a lot. Indeed we already have such fields it is
Function. An other one like Property (which inherit of Function) will
never be enough generic for all the usages.
I think that depending of the cases we could get better design. By
example, on product we could have one single table to manage all the
fields like list_price, cost_price, accounts etc.
I think it is also good to be able to override the getter method of one
field.
And finally, the management of a default value could be different.
So I don't think we will earn a lot by having a generic field.
It will be similar to such methods [1] which is similar to the Related
field of OE but we did not implement it because it is simple to write
and customizable.
[1] http://hg.tryton.org/modules/account/file/b3752b079778/move.py#l907
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: [email protected]
Website: http://www.b2ck.com/
pgp5NXTafF7xC.pgp
Description: PGP signature
