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}
>>> # 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.
Cheers
--
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
i...@virtual-things.biz
http://www.virtual-things.biz
--
tryton-dev@googlegroups.com mailing list
