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/
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.
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.
>
--
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.
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
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.