refactorize of trytond
Cédric Krier
Here is how I see the refactorisation of trytond:
trytond
|- protocols
| |- netrpc
| |- xmlrpc
| |- webdav
|
|- services
| |- model
| |- wizard
| |- report
| |- common
| |- db
| |- security
|
|- config
|- backend
| |- postgresql
|
|- version
|- log
|- server
|- pooler
|- model
| |- modeldb
| | |- modelexport
| | |- modelimport
| |
| |- modelview
| |- cacheable
| |- browserecord
|
|- report
| |- odt
|
|- wizard
|- workflow
|- ir
|- res
|- webdav
What do you think about?
--
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
Am Montag, den 22.12.2008, 10:36 +0100 schrieb Cédric Krier:
> Here is how I see the refactorisation of trytond:
> trytond
> |- protocols
> | |- netrpc
> | |- xmlrpc
> | |- webdav
> |
> |- services
> | |- model
> | |- wizard
> | |- report
> | |- common
> | |- db
> | |- security
> |
> |- config
> |- backend
> | |- postgresql
> |
> |- version
> |- log
> |- server
> |- pooler
> |- model
> | |- modeldb
> | | |- modelexport
> | | |- modelimport
> | |
> | |- modelview
> | |- cacheable
> | |- browserecord
> |
> |- report
> | |- odt
> |
> |- wizard
> |- workflow
> |- ir
> |- res
> |- webdav
>
>
> What do you think about?
It looks not bad for me, but in detail I don't understand the benefit?
Maybe just some more words about why this structure.
Benefit I see in having a backend/postgres. Its a first step for
providing other databases later.
report/odt is very nice too. This could avoid to duplicate code on
module side for other report parsers then odt.
Cédric Krier
It is a split of the ORM object
modeldb for all the access to database
modelexport and modelimport is just to define the two import/export by
csv.
> > | |
> > | |- modelview
> > | |- cacheable
> > | |- browserecord
> > |
> > |- report
> > | |- odt
> ... and here is report again...
> > |
> > |- wizard
> > |- workflow
> > |- ir
> > |- res
> > |- webdav
> ... and here is webdav again. Why webdav and report is double?
Because it is on different level: Services and python object.
> >
> >
> > What do you think about?
> These all is a folders structure without files?
It is just the structure. I don't know yet what will be file or
directory.
>
> It looks not bad for me, but in detail I don't understand the benefit?
> Maybe just some more words about why this structure.
>
It is to have a better structure that will be more readable for new
users.
> Benefit I see in having a backend/postgres. Its a first step for
> providing other databases later.
> report/odt is very nice too. This could avoid to duplicate code on
> module side for other report parsers then odt.
>
--
Cédric Krier
> Hi,
>
> Here is how I see the refactorisation of trytond:
>
I just push one big step in the refectoring process.
I have removed the Service and LocalService object and put the workflow
function in ModelWorkflow.
http://hg.tryton.org/hgwebdir.cgi/trytond/file/26703187368d/trytond/model/modelworkflow.py
So now to have a workflow on a Model, you must inherit of ModelWorkflow
in first place.
http://hg.tryton.org/hgwebdir.cgi/modules/account_invoice/file/aea6b9d76e81/invoice.py#l31
All the functions that run the workflow are now stored in the workflow module on
workflow.xxx models and start with "workflow_".
http://hg.tryton.org/hgwebdir.cgi/trytond/file/26703187368d/trytond/workflow/workflow.py
I change the netrpc/xmlrpc syntax to use directly the name of the
function like:
XML-RPC:
uri: http://localhost:8069/database/model/account.invoice
method: read(user, session, ids)
netrpc:
socket.send((database, user, session, 'model', 'account.invoice',
'read', ids))
I also merge all the pool into one. So the get method take now a new
argument "type" (by default 'model') which specify the type of object
you want like 'model', 'report', 'wizard'.
So thanks to check if it always runs for you.
Carlos Perelló Marín
> All the big changes have been done, so now the tree structure must be
> good.
>
> We still need to change the use of OSV and WizardOSV with ModelView and/or ModelSQL
> And remove all the SQL queries in modules.
Does it mean that the core freeze will be delayed?
Cheers and good work!!
--
Carlos Perelló Marín
[P+] SERVICIOS PROFESIONALES
http://www.pemas.es
mailto:car...@pemas.es || mailto:car...@gnome.org
Cédric Krier
>
> El mar, 17-02-2009 a las 12:31 +0100, Cédric Krier escribió:
> > All the big changes have been done, so now the tree structure must be
> > good.
> >
> > We still need to change the use of OSV and WizardOSV with ModelView and/or ModelSQL
> > And remove all the SQL queries in modules.
>
> Does it mean that the core freeze will be delayed?
>
I think that for now freezing two months before release is too much.
I propose to set two weeks before each freeze.
Carlos Perelló Marín
> On 17/02/09 13:03 +0100, Carlos Perelló Marín wrote:
> >
> > El mar, 17-02-2009 a las 12:31 +0100, Cédric Krier escribió:
> > > All the big changes have been done, so now the tree structure must be
> > > good.
> > >
> > > We still need to change the use of OSV and WizardOSV with ModelView and/or ModelSQL
> > > And remove all the SQL queries in modules.
> >
> > Does it mean that the core freeze will be delayed?
> >
>
> I think that for now freezing two months before release is too much.
> I propose to set two weeks before each freeze.
I guess it depends on how big are the changes and the number of modules
that need to be migrated to the new core. At this stage, I think that
two weeks should be enough. In the future, we may need some more time to
adapt modules to the new core, if we want to have all those modules
available and working at the same time as the core is released, if we
don't have such time constraint, two weeks should be enough, yes.
Cheers.