Fri, 1 Feb 2013 12:56:05 +0100
Cédric Krier <cedric.kr...@b2ck.com>:
>On 01/02/13 12:31 +0100, Udo Spallek wrote:
>>Fri, 1 Feb 2013 11:42:58 +0100
>>Cédric Krier <cedric.kr...@b2ck.com>:
>>>I think the concept of inherits is buggy as each time we try to use
>>>it on large scale (cf. expense module [1]) it fails because of the
>>>complexity and the impossibility to get a generic behavior that fits
>>>all the needs.
>>IMHO it is good to collect what exactly are 'all the needs' related
>>to inherits?
>>* My most important need for inherits is the possibility of easy
>>  specialization of a view.
>Don't try this at home :-)
>First, you can now in almost all the cases define which view must be
>shown (ex: on the act_window, the view_ids attribute in the view etc.)
Yes, I understand that we can choose different views in many places.
But what I mean is maybe better explained by an example.

Let us have a setup with party module and company module.
The company view is based on company.company model[1] and 'inherits' the
party view[2] and tweak some fields[3]. With the actual '_inherits'[4]
in the company.company model, fields coming from the party model[5]
in this view are shown as they would be defined in model
company.company.

When we now install a module like party_siret, all the fields defined on
party.party[6] coming from this module are shown in the company view,
too. 
The fields are shown on company views, even the company module is not a
dependency of party_siret module. 
This is what I mean with specialization.
How can we catch a similar result without _inherits?

>>* The specialization of the model is not important for me, since it
>>  can be replaced by many2one.
>At least, in the current modules, it is the case.
Do you have constellations in mind which would not work?

>>* The shorter name space is not important to me. E.g. Writing 
>>  'company.addresses' instead of using the full
>>  name space 'company.party.addresses'.
>Strange idea but perhaps it is linked to "custom access right".
I don't understand what you mean with custom access right in this
context.
What I mean is, with _inherits we use a shorter name space.
IIUC, like in [7] where:

    '[' + self.code + '] ' + self.name

without _inherits would look like:
    
    '[' + self.code + '] ' + self.template.name

And IMHO this is no important feature of _inherits, which could be
dropped.

>>Which other needs we have related to inherits?
No other needs?

>>>So as a result, it is almost never used:
>>>...
>>>    - company:
>>>        Idem as carrier and it could even perhaps improve the
>>>        understanding.
>>Here the specialization of party view is very handy. The company
>>view is like '90%' identical to the party view plus some special
>>fields. Is it possible to rebuild this view without inherits?
>The view yes if we keep the inherit behavior of the view (but I don't
>think it is needed).
How would you replace it?

>>Or is the only way to rebuild the view with function fields that
>>collect data from other models?
>It is a possibility but I think it should be avoided as much as
>possible because I think one of the flaw of inherits is that user can
>not make easily a mental map of the objects.
Yes, that is another point. Inherits is hard to understand for user and
developer, too.

I have two ideas in mind about the features of the view part of '_inherits':

* Actually with _inherits, company module has a view, which is able to
  show fields of different models. This sounds very close to the
  approach of board views in Tryton.

* Why not having a many2one widget, which is able to embed a form view
  of its target model, inside the enveloping original view. There is no
  switching between form and list view, because list view is not needed.
  With this we could have a company view with a tab party which
  includes the complete party form view.

Cheers
Udo Spallek

[1]
http://hg.tryton.org/modules/company/file/c5587a3d9b71/company.xml#l7
[2]
http://hg.tryton.org/modules/company/file/c5587a3d9b71/company.xml#l9
[3]
http://hg.tryton.org/modules/company/file/c5587a3d9b71/company.xml#l13
[4] 
http://hg.tryton.org/modules/company/file/c5587a3d9b71/company.py#l20
[5]
http://hg.tryton.org/modules/party/file/fc0862209992/party.py#l30
[6]
http://hg.tryton.org/modules/party_siret/file/d80a05451633/party.py#l15
[7]
http://hg.tryton.org/modules/product/file/69944d370cf3/product.py#l130
-- 
_____________________________
virtual things
Preisler & Spallek GbR
München - Aachen

Windeckstr. 77
81375 München
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56

i...@virtual-things.biz
http://www.virtual-things.biz

Attachment: signature.asc
Description: PGP signature

Reply via email to