Allow to inherit views from an other model
Cédric Krier
Yesterday, I push a change in branch 1.1 that allows to inherit a view from
an other model.
This is usefull for model that uses "inherits" functionnality like
employee. An employee is also a party in Tryton.
So the main issue that we had, was when an other module add a required field
on party, it breaks the employee form.
So now, for the employee view, we take the standard party view with all
the fields from others module and we apply some xpath changes to looks better.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email: cedric...@b2ck.com
Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/
udono
this seems a very good improvement to the framework. Thank you for
this.
1. Unfortunately I am having problems with the new view inheritance in
combination with on_changes of fields. There is the following 'chain'
of inheritaces company --> party --> party_type The on_change is in
the party_type field, but Tryton searched it in the main model company
which inherits the other models.
The company shows all views I defined in party_type, thats nice, but
widgets have on_change methods defined in party_type. If I change one
widget in the company, I get the error:
Calling method on_change_type on object company.company is not
allowed.
Do you know what to do?
2. Another topic is the restrict handling of x-path expression. If I
don't like to show some widgets on the company views, I need x-path
expression which can fail without error. Failing means that Tryton
doesn't raise an error when it cant find a x-path experssion. But
seriously I do not understand the whole concept if xpath is run only
on installation of a module or anytime when I open an inherited view?
Is there a way to make x-path expressions less restrict?
3. On company there are some xpath too for 'clean up' the party view
for companys. These xpath seems to much oriented to the original party
view. But if the original party view is already changed by an addon
view, then I run into trouble on installation, because the x-path
expression is not found. If you would change them to something like:
<xpath expr="//*/label[@name="code"]" position="replace">
then it finds the labels and fields anywhere in the form.
Cheers Udo
Cédric Krier
>
> Hello Cédric,
>
> this seems a very good improvement to the framework. Thank you for
> this.
>
> 1. Unfortunately I am having problems with the new view inheritance in
> combination with on_changes of fields. There is the following 'chain'
> of inheritaces company --> party --> party_type The on_change is in
> the party_type field, but Tryton searched it in the main model company
> which inherits the other models.
> The company shows all views I defined in party_type, thats nice, but
> widgets have on_change methods defined in party_type. If I change one
> widget in the company, I get the error:
> Calling method on_change_type on object company.company is not
> allowed.
> Do you know what to do?
You must setup the method on the company, and let it call the right
methods.
>
> 2. Another topic is the restrict handling of x-path expression. If I
> don't like to show some widgets on the company views, I need x-path
> expression which can fail without error. Failing means that Tryton
> doesn't raise an error when it cant find a x-path experssion. But
> seriously I do not understand the whole concept if xpath is run only
> on installation of a module or anytime when I open an inherited view?
> Is there a way to make x-path expressions less restrict?
I don't understand your issue.
I will make one more change to be sure that the order of the xpath will
be determiste.
>
> 3. On company there are some xpath too for 'clean up' the party view
> for companys. These xpath seems to much oriented to the original party
> view. But if the original party view is already changed by an addon
> view, then I run into trouble on installation, because the x-path
> expression is not found. If you would change them to something like:
> <xpath expr="//*/label[@name="code"]" position="replace">
> then it finds the labels and fields anywhere in the form.
>
I don't think it is a valid xpath expression.
And this is an issue with inherits object. The best is to also care of
the other modules that inherits the same model, and perhaps to setup
some invisible states instead of view inherited because view inherited
must be principally used to add fields, not to remove them.
udono
> On 14/12/08 22:38 -0800, udono wrote:
> > 1. Unfortunately I am having problems with the new view inheritance in
> > combination with on_changes of fields. There is the following 'chain'
> > of inheritaces company --> party --> party_type The on_change is in
> > the party_type field, but Tryton searched it in the main model company
> > which inherits the other models.
> > The company shows all views I defined in party_type, thats nice, but
> > widgets have on_change methods defined in party_type. If I change one
> > widget in the company, I get the error:
> > Calling method on_change_type on object company.company is not
> > allowed.
> > Do you know what to do?
> You must setup the method on the company, and let it call the right
> methods.
class.
Yes this is the solution.
But in fact it means, I need to take care of all addon
modules written for party, when I write a party_type module. That's
hard to
maintain.
> > 2. Another topic is the restrict handling of x-path expression. If I
> > don't like to show some widgets on the company views, I need x-path
> > expression which can fail without error. Failing means that Tryton
> > doesn't raise an error when it cant find a x-path experssion. But
> > seriously I do not understand the whole concept if xpath is run only
> > on installation of a module or anytime when I open an inherited view?
> > Is there a way to make x-path expressions less restrict?
> I don't understand your issue.
> I will make one more change to be sure that the order of the xpath will
> be determiste.
> > 3. On company there are some xpath too for 'clean up' the party view
> > for companys. These xpath seems to much oriented to the original party
> > view. But if the original party view is already changed by an addon
> > view, then I run into trouble on installation, because the x-path
> > expression is not found. If you would change them to something like:
> > <xpath expr="//*/label[@name="code"]" position="replace">
> > then it finds the labels and fields anywhere in the form.
> I don't think it is a valid xpath expression.
http://www.zvon.org/xxl/XPathTutorial/Output/example3.html
> And this is an issue with inherits object. The best is to also care of
> the other modules that inherits the same model,
a
module for party_types. Or did I misunderstand?
> and perhaps to setup
> some invisible states instead of view inherited because view inherited
> must be principally used to add fields, not to remove them.
path to
replace items...
I need to think more about, but actually I don't see a way to extend
the party
model in the right way, without breaking the company.
Cédric Krier
>
> On 15 Dez., 08:57, Cédric Krier <cedric.kr...@b2ck.com> wrote:
> > On 14/12/08 22:38 -0800, udono wrote:
> > > 1. Unfortunately I am having problems with the new view inheritance in
> > > combination with on_changes of fields. There is the following 'chain'
> > > of inheritaces company --> party --> party_type The on_change is in
> > > the party_type field, but Tryton searched it in the main model company
> > > which inherits the other models.
> > > The company shows all views I defined in party_type, thats nice, but
> > > widgets have on_change methods defined in party_type. If I change one
> > > widget in the company, I get the error:
> > > Calling method on_change_type on object company.company is not
> > > allowed.
> > > Do you know what to do?
> > You must setup the method on the company, and let it call the right
> > methods.
> So I depend on the company module and need to inherit the Company
> class.
I don't understand because it seems that you say you make party inherits
from party_type, but this is not possible or must not be done.
So it must work. But personnaly, I will not use this because it can have
border effect.
Udono
> On 15/12/08 00:55 -0800, udono wrote:
> >
> > On 15 Dez., 08:57, Cédric Krier <cedric.kr...@b2ck.com> wrote:
> > > On 14/12/08 22:38 -0800, udono wrote:
> > > > 1. Unfortunately I am having problems with the new view inheritance in
> > > > combination with on_changes of fields. There is the following 'chain'
> > > > of inheritaces company --> party --> party_type The on_change is in
> > > > the party_type field, but Tryton searched it in the main model company
> > > > which inherits the other models.
> > > > The company shows all views I defined in party_type, thats nice, but
> > > > widgets have on_change methods defined in party_type. If I change one
> > > > widget in the company, I get the error:
> > > > Calling method on_change_type on object company.company is not
> > > > allowed.
> > > > Do you know what to do?
> > > You must setup the method on the company, and let it call the right
> > > methods.
> > So I depend on the company module and need to inherit the Company
> > class.
> I don't understand because it seems that you say you make party inherits
> from party_type, but this is not possible or must not be done.
Company --inherits from---> Party <---inherits from---Party_Type
So what it mean when you say: "setup the method on the company, and let
it call the right methods" ?
> > > > 2. Another topic is the restrict handling of x-path expression. If I
> > > > don't like to show some widgets on the company views, I need x-path
> > > > expression which can fail without error. Failing means that Tryton
> > > > doesn't raise an error when it cant find a x-path experssion. But
> > > > seriously I do not understand the whole concept if xpath is run only
> > > > on installation of a module or anytime when I open an inherited view?
> > > > Is there a way to make x-path expressions less restrict?
> > > I don't understand your issue.
> > > I will make one more change to be sure that the order of the xpath will
> > > be determiste.
When is the x-path evaluated? only on installing a module or everytime I
open the appropriate view?
> > > > 3. On company there are some xpath too for 'clean up' the party view
> > > > for companys. These xpath seems to much oriented to the original party
> > > > view. But if the original party view is already changed by an addon
> > > > view, then I run into trouble on installation, because the x-path
> > > > expression is not found. If you would change them to something like:
> > > > <xpath expr="//*/label[@name="code"]" position="replace">
> > > > then it finds the labels and fields anywhere in the form.
> > > I don't think it is a valid xpath expression.
> > But it is:
> > http://www.zvon.org/xxl/XPathTutorial/Output/example3.html
>
> So it must work. But personnaly, I will not use this because it can have
> border effect.
On which border effects you think?
Actually when you use the complete xpath - path in company for cleaning
up the view, its hard to modify the party view. Because the company
x-path find it only the way you hardcoded it.
Cédric Krier
So normally, what you define on party_type must not be on company.
> > > > > 2. Another topic is the restrict handling of x-path expression. If I
> > > > > don't like to show some widgets on the company views, I need x-path
> > > > > expression which can fail without error. Failing means that Tryton
> > > > > doesn't raise an error when it cant find a x-path experssion. But
> > > > > seriously I do not understand the whole concept if xpath is run only
> > > > > on installation of a module or anytime when I open an inherited view?
> > > > > Is there a way to make x-path expressions less restrict?
> > > > I don't understand your issue.
> > > > I will make one more change to be sure that the order of the xpath will
> > > > be determiste.
>
> When is the x-path evaluated? only on installing a module or everytime I
> open the appropriate view?
>
Each time the view is fetched (but there is some cache :-).
> > > > > 3. On company there are some xpath too for 'clean up' the party view
> > > > > for companys. These xpath seems to much oriented to the original party
> > > > > view. But if the original party view is already changed by an addon
> > > > > view, then I run into trouble on installation, because the x-path
> > > > > expression is not found. If you would change them to something like:
> > > > > <xpath expr="//*/label[@name="code"]" position="replace">
> > > > > then it finds the labels and fields anywhere in the form.
> > > > I don't think it is a valid xpath expression.
> > > But it is:
> > > http://www.zvon.org/xxl/XPathTutorial/Output/example3.html
> >
> > So it must work. But personnaly, I will not use this because it can have
> > border effect.
> On which border effects you think?
> Actually when you use the complete xpath - path in company for cleaning
> up the view, its hard to modify the party view. Because the company
> x-path find it only the way you hardcoded it.
>
It depends how you write the xpath. But I mean that the more determinist
it is, the less strange behavior you will have.
Udono
In my party type module I depended on company:
class Company(OSV):
_name = "company.company"
def __init__(self):
super(Company, self).__init__()
def on_change_party_type(self, cursor, user, ids, vals,
context=None):
# TODO: This method makes problems. It needed to be called on
# party_type object. But how to?
# Dont work:
# party = Party()
# res = party.on_change_party_type(party, cursor, user,
# ids, vals, context=None)
# print "res=", res
# return res
# Dont work:
# res = Party.on_change_party_type(party, cursor, user,
# ids, vals, context=None)
# print "res=", res
# return res
# Dont work:
# return super(Company, self).on_change_party_type(self,
# cursor, user, ids, vals, context=None)
Company()
The on_change_party_type is called in company, but I dont know to call
the right method to get the on_change_party_type in Class Party to work.
(S.a. http://mercurial.intuxication.org/hg/party_type )
Ay ideas?
Cheers Udo
Cédric Krier
party_obj = self.pool.get('party.party')
return party_obj.on_change_party_type(cursor, user, ids, vals,
context=context)
>
> Company()
>
> The on_change_party_type is called in company, but I dont know to call
> the right method to get the on_change_party_type in Class Party to work.
> (S.a. http://mercurial.intuxication.org/hg/party_type )
>
> Ay ideas?
>
> Cheers Udo
>
>
> --~--~---------~--~----~------------~-------~--~----~
> try...@googlegroups.com mailing list
> -~----------~----~----~----~------~----~------~--~---
Udono
> > In my party type module I depended on company:
> > class Company(OSV):
> > _name = "company.company"
> >
> > def __init__(self):
> > super(Company, self).__init__()
> >
> > def on_change_party_type(self, cursor, user, ids, vals,
> > context=None):
> return party_obj.on_change_party_type(cursor, user, ids, vals,
> context=context)
> > Company()
Udono
bertrand mentioned another topic on the IRC:
(http://www.tryton.org/~irclog/2008-12-26.log.html#t2008-12-26_14:00 )
...
> bechamel: i just saw your mail on the ml, did try to remove
> on_change_party_type on the company object (to see if this method is
> called on the party itself)
Yes, I did it the first time. But Tryton cannot find the
method. No such method on company.company.
For me it would be the best to avoid inheriting company, because this is
just the beginning of many modules depending on party.
Actually I needed to inherit all Models, which itself inherit party,
and this is worse. Because the party_type module needed to depend on
all the coming modules like party_bank (development from Korbinian)...
Do you think there is a possibility to overload the Party class with
the contents of the inherit class Party for party_types?
> bechamel: my point of view is that as you know company is a model
> that define companies that use the current tryton db, which turns out
> to inherit party (but it could have been a completely independant
> object), and that the party_type module is there to give type to
> parties (aka customer, supplier and so on).
There is a little misunderstanding in the concept of party_types.
Party types are only for general differences in types of partys aka
Person and Organisation. Party types also provides additional name
fields and a gender attribute for party_type == person.
Later when someone wanted to provide webservices, the value "cookie_id"
as a party_type also come into play.
The destingtion of customers or vendors you mentioned is better defined
in another module called party_roles.
> So my answer is that we
> don't need party_type on company, the same way we don't need it on
> the employee model (which is also a party)
I completely agree with you about this. For me party_types are a model
addition just for partys and not any derived models. But how can I
restrict them to sole party model and view?
The problem is the construction of the derived models like company and
party_bank (in development from Korbinian). Both modules catch the view
of party and show it up in their views. They re-arrange the party-view
on their own. I surely don't like to be dependend on every derived model
which uses party model and views. It is a bottomless pit to the
maintainance hell of the modules.
Solution 1:
For me the company and the party_bank modules needed to be connected to
the party model just via Many2One restricted to one record (aka One2One
we dont have). Additionally both modules should reconstruct their views
following the general party views without taking care of a party_type
module. It should be a similar connection like partys connected on
invoice model in Tryton.
With this all the modules can exist without problems side by side.
Solution 2:
Leaving party model and views completely untouched. I recreate my module
party_types similar to the company module and provide the types Persons
and Organizations in another model with own views. So when showing party
you will have the generic view on partys without any additionals like it
is defined in Module Party. On showing People&Organizations, then we
will have Party_types, later roles, and so on.
What do you think?
Cheers
Udo