[tryton-dev] New proteus library to access Tryton's models like a client (issue1205045)
Cédric Krier
It is still a proof of concept.
It is readonly for now and doesn't handle all the field types.
Please review this at http://codereview.appspot.com/1205045/show
Affected files:
A COPYRIGHT
A INSTALL
A LICENSE
A MANIFEST.in
A README
A proteus/__init__.py
A proteus/config.py
A proteus/tests/__init__.py
A proteus/tests/test_config.py
A proteus/tests/test_model.py
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/
Cédric Krier
> I started a new project of a library to access Tryton's models like a client.
> It is still a proof of concept.
> It is readonly for now and doesn't handle all the field types.
>
> Please review this at http://codereview.appspot.com/1205045/show
>
> Affected files:
> A COPYRIGHT
> A INSTALL
> A LICENSE
> A MANIFEST.in
> A README
> A proteus/__init__.py
> A proteus/config.py
> A proteus/tests/__init__.py
> A proteus/tests/test_config.py
> A proteus/tests/test_model.py
>
By the way, I choose the name proteus for
http://en.wikipedia.org/wiki/Proteus_(moon)
and also http://en.wikipedia.org/wiki/Proteus
Udo Spallek
> I started a new project of a library to access Tryton's models like a client.
> It is still a proof of concept.
> It is readonly for now and doesn't handle all the field types.
> Please review this at http://codereview.appspot.com/1205045/show
> Affected files:
> A COPYRIGHT
> A INSTALL
> A LICENSE
> A MANIFEST.in
> A README
> A proteus/__init__.py
> A proteus/config.py
> A proteus/tests/__init__.py
> A proteus/tests/test_config.py
> A proteus/tests/test_model.py
On 2010/05/24 11:56:17, ced wrote:
> On 2010/05/24 11:36:21, paepke wrote:
>> On 2010/05/24 10:54:09, ced wrote:
>>> On 2010/05/24 10:50:42, paepke wrote:
>>>> What does it mean "like a client"? What is the difference to using
netrpc?
>>> netrpc is just a protocol.
>>> "like a client" means like tryton.
>> how does tryton it? i don't understand the concept of this library. or for
>> what is is good for.
> My main goals is to be able make write test scenario at business level.
A busines level testing API sounds very interesting to me. Some questions remains:
Can you give a more concrete examples for the later use? Will proteus be able
to evaluate field contents delivered from trytond like the tryton client? I have
already seen test_model and test_config, but these are not on 'business level'.
Do you mean with 'business level' tests which targets the direction I started
with http://codereview.appspot.com/818046 ?
Are you planning to use some BDD-like higher level API ?
Makes Proteus a GUI testing framework (like dogtail) unnecessary ? (I guess not)
For the moment it is hard to review proteus for me, I even can not say 'looks good'
because I don't know the exactly targets of proteus.
TIA
--
Udo Spallek
------------------------------------
virtual things
Preisler & Spallek GbR
Munich - Aix-la-Chapelle
Windeckstr. 77
81375 Munich - Germany
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56
in...@virtual-things.biz
http://www.virtual-things.biz
--
tryto...@googlegroups.com mailing list
Sharoon Thomas
tryto...@googlegroups.com mailing list
Cédric Krier
> On 2010/05/24 11:56:17, ced wrote:
> > On 2010/05/24 11:36:21, paepke wrote:
> >> On 2010/05/24 10:54:09, ced wrote:
> >>> On 2010/05/24 10:50:42, paepke wrote:
> >>>> What does it mean "like a client"? What is the difference to using
> netrpc?
> >>> netrpc is just a protocol.
> >>> "like a client" means like tryton.
> >> how does tryton it? i don't understand the concept of this library. or for
> >> what is is good for.
> > My main goals is to be able make write test scenario at business level.
>
> A busines level testing API sounds very interesting to me. Some questions remains:
>
> Can you give a more concrete examples for the later use?
Not for now.
It is possible to read and write/create records. So not soo much than it can
be done by direct rpc call.
> Will proteus be able
> to evaluate field contents delivered from trytond like the tryton client?
I don't understand.
> I have
> already seen test_model and test_config, but these are not on 'business level'.
It is unittest of the library.
> Do you mean with 'business level' tests which targets the direction I started
> with http://codereview.appspot.com/818046 ?
It will allow to write scripts that behaves like the client.
> Are you planning to use some BDD-like higher level API ?
I have no interest in this concept.
> Makes Proteus a GUI testing framework (like dogtail) unnecessary ? (I guess not)
No.
> For the moment it is hard to review proteus for me, I even can not say 'looks good'
> because I don't know the exactly targets of proteus.
For now, we need only codereview and ideas to add features.
And if someone can write XML-RPC backend, it will be great.
Cédric Krier
> Hi All,
>
> Proteus the way its progressing looks very good to me (but for a different
> purpose).
>
> We are designing a web framework based on Tryton ORM. So building a portal
> or an e-commerce system with the corresponding modules should be easy,
> simple and efficient.
Be carefull that there is no transaction management in proteus.
Every call is commited like in the GTK client.
Sharoon Thomas
tryto...@googlegroups.com mailing list
Udo Spallek
after studying the code of Proteus a bit more and I think I understand
its aim better now.
Proteus seems to be a higher level API to pysocket (for now) for
creating own client scripts in an object oriented way.
So yes, sharoon was right, it is a great idea.
Am Montag, den 24.05.2010, 20:19 +0200 schrieb Cédric Krier:
> On 24/05/10 19:46 +0200, Udo Spallek wrote:
> > On 2010/05/24 11:56:17, ced wrote:
[...]
> > Will proteus be able
> > to evaluate field contents delivered from trytond like the tryton client?
> I don't understand.
Sorry I was misguided by not understanding. Question is meaningless.
[...]
> > For the moment it is hard to review proteus for me, I even can not say 'looks good'
> > because I don't know the exactly targets of proteus.
> For now, we need only codereview and ideas to add features.
Ideas:
* An easy API for calling wizards.
* Logging
Ideas are depending of the question if you're planing proteus to be an
own client framework or an application or just a module. Do you have
ideas for the direction it should go?
Some framework/application features could be:
* Calling proteus from shell and control it with command line
attributes
* A small plug-in or module system for walking through the
remote calling scripts in order
Cheers
Cédric Krier
> Hi Cédric,
>
> after studying the code of Proteus a bit more and I think I understand
> its aim better now.
> Proteus seems to be a higher level API to pysocket (for now) for
Not pysocket but directly trytond.
> creating own client scripts in an object oriented way.
> So yes, sharoon was right, it is a great idea.
>
> Am Montag, den 24.05.2010, 20:19 +0200 schrieb Cédric Krier:
> > On 24/05/10 19:46 +0200, Udo Spallek wrote:
> > > On 2010/05/24 11:56:17, ced wrote:
> [...]
> > > Will proteus be able
> > > to evaluate field contents delivered from trytond like the tryton client?
> > I don't understand.
> Sorry I was misguided by not understanding. Question is meaningless.
> [...]
> > > For the moment it is hard to review proteus for me, I even can not say 'looks good'
> > > because I don't know the exactly targets of proteus.
> > For now, we need only codereview and ideas to add features.
>
> Ideas:
> * An easy API for calling wizards.
Yes, it should but I don't know yet how.
> * Logging
I don't understand.
>
> Ideas are depending of the question if you're planing proteus to be an
> own client framework or an application or just a module. Do you have
> ideas for the direction it should go?
All of that :-)
>
> Some framework/application features could be:
> * Calling proteus from shell and control it with command line
> attributes
Why a shell ? It will be use directly from Python command line.
>>> import proteus
>>> proteus.config.set_trytond('test')
>>> Invoice = proteus.Model.get('account.invoice')
>>> Invoice
<class 'proteus.account.invoice'>
>>> invoices = Invoice.find([('state', '=', 'draft')])
>>> for invoice in invoices:
... invoice.description = 'Test proteus'
...
>>> for invoice in invoices:
... invoice.save()
...
>>> invoices[0]
<account.invoice (35)>
>>>
Rem: I still need to fix Model repr to be produce
"<proteus.account.invoice(35)>" like that it can be evaluated.
> * A small plug-in or module system for walking through the
> remote calling scripts in order
I don't understand.
Udo Spallek
Am Freitag, den 28.05.2010, 08:40 +0200 schrieb Cédric Krier:
> On 28/05/10 08:20 +0200, Udo Spallek wrote:
> > Am Montag, den 24.05.2010, 20:19 +0200 schrieb Cédric Krier:
> > > On 24/05/10 19:46 +0200, Udo Spallek wrote:
> > > > For the moment it is hard to review proteus for me, I even can not say 'looks good'
> > > > because I don't know the exactly targets of proteus.
> > > For now, we need only codereview and ideas to add features.
> > Ideas:
> > * An easy API for calling wizards.
> Yes, it should but I don't know yet how.
>>> import proteus
>>> proteus.config.set_trytond('test')
>>> company = ...
>>> account_template = ...
>>> # Next line gets a chart of accounts (coa) wizard object
>>> # _and_ creates a new wizard id:
>>> coa_wizard = proteus.Wizard.get(
>>> 'account.account.create_chart_account')
>>> # Next line defines the form contents:
>>> form = {'account_template': account_template,
>>> 'company': company}
>>> # Next line executes the wizard:
>>> fiscalyear_wizard.execute('create_account', form=form)
The execute signature could look like this:
execute(wizard_action[, form=None[, print=None[, action=None]]])
or more generic:
execute(wizard_action, type={form|print|action}, data=None)
> > * Logging
> I don't understand.
Main idea is to have a good logging facility included, which is able to
log all read/write/delete. But a good logging à la audit-trail, is
better done server side. So forget this idea.
> > Ideas are depending of the question if you're planing proteus to be an
> > own client framework or an application or just a module. Do you have
> > ideas for the direction it should go?
> All of that :-)
sounds sportive :-). But I like the broader target.
But on writing this, I become unsure about if it is good to make proteus
a python library _and_ client application framework together... When I
think of a use together with django, most of the mentioned 'application'
targets like modules/plug-ins, logging or command line options are not
needed and maybe disturbing.
Maybe it is better to have just a good and efficient python lib and
build on top some separate standalone client application showcases?
> > Some framework/application features could be:
> > * Calling proteus from shell and control it with command line
> > attributes
> Why a shell ? It will be use directly from Python command line.
This is another good idea I would like a lot for testing and hacking
purposes. But my thoughts are more going into the direction of a
small client application framework with proteus. This framework should
provide command line options for most of the initial attributes. Like
database_name, language and more. But as said, I am no longer sure if
it is good to have it inside proteus.
> > * A small plug-in or module system for walking through the
> > remote calling scripts in order
> I don't understand.
Here again I'm targeting a small client application framework.
The provided features of proteus from user side can be applied with
proteus modules or plug-ins. So the user can build his/her functionality
inside proteus which is a full (-blown ;-) client application. It is not
needed for the user, to build an own client application around proteus.
But as said, I am no longer sure if it is good to have it inside
proteus.
Cédric Krier
> Hi,
> Am Freitag, den 28.05.2010, 08:40 +0200 schrieb Cédric Krier:
> > On 28/05/10 08:20 +0200, Udo Spallek wrote:
> > > Am Montag, den 24.05.2010, 20:19 +0200 schrieb Cédric Krier:
> > > > On 24/05/10 19:46 +0200, Udo Spallek wrote:
> > > > > For the moment it is hard to review proteus for me, I even can not say 'looks good'
> > > > > because I don't know the exactly targets of proteus.
> > > > For now, we need only codereview and ideas to add features.
> > > Ideas:
> > > * An easy API for calling wizards.
> > Yes, it should but I don't know yet how.
> as a CLI example it could look like this:
>
> >>> import proteus
> >>> proteus.config.set_trytond('test')
> >>> company = ...
> >>> account_template = ...
>
> >>> # Next line gets a chart of accounts (coa) wizard object
> >>> # _and_ creates a new wizard id:
> >>> coa_wizard = proteus.Wizard.get(
> >>> 'account.account.create_chart_account')
>
> >>> # Next line defines the form contents:
> >>> form = {'account_template': account_template,
> >>> 'company': company}
The form content is also define in Tryton by a model. So it will be better to
use the proteus.Model to fill it.
>
> >>> # Next line executes the wizard:
> >>> fiscalyear_wizard.execute('create_account', form=form)
>
> The execute signature could look like this:
> execute(wizard_action[, form=None[, print=None[, action=None]]])
> or more generic:
> execute(wizard_action, type={form|print|action}, data=None)
>
--
Cédric Krier
> It is still a proof of concept.
> It is readonly for now and doesn't handle all the field types.
>
> Please review this at http://codereview.appspot.com/1205045/show
>
It is now at http://hg.tryton.org/proteus