Re: [GNUe-dev] Appserver: Procedures implementation proposal

[Jan Ischebeck]

Am Di, den 04.11.2003 schrieb Reinhard Mueller um 17:02:
> Hi all,
> 
> as a base for discussion I'd like to explain here how I would expect
> procedures in gnue-appserver to be implemented:
> 
> in src/classrep:
> ----------------
> Besides gnue_module, gnue_class and gnue_property create a new system
> class, gnue_procedure. This class has the properties gnue_id (type
> "id"), gnue_class (type "gnue_class"), gnue_module (type
> "gnue_module"), gnue_language (type "string[8]"?) and gnue_code (type
> "string")

IMHO it would be good to have a "gnue_compiledcode" field in there too.

> * classrep.ini and base.gsd would have to be updated to reflect the
>   new class
> * It would have to be checked if the type "string" without a length
>   (which should be of virtually unlimited length) is available on all
>   database backends, and if it gets converted to the correct db type
>   in gnue-schema as well as in the XSLT scripts
> * in Class.py, a "Class.procedures" should be available just like the
>   "Class.properties" is now. Probably a new file "Procedure.py" will
>   have to be made and mostly copied over from "Poperty.py".
> If that is done, the code of any given procedure should be accessible in
> geasInstance.py - call like the following:
>   proceduredef = self._classdef.procedures [procedurename]
>   theLang = proceduredef.gnue_language
>   theCode = proceduredef.gnue_code
> A lot of black magic could later be put into Procedure.py, regarding
> dynamic update of procedure code (Procedure code can be changed while
> appserver is running) or intelligent caching of code. But I don't think
> we need that for the first step.
> 
> new directory src/codeif
> ------------------------
> This will only contain a single procedure "call" that accepts 6
> parameters: the classname, the objectid, a dictionary with prefetched
> property names and their values, the language (e.g. "python"), the code,
> and the parameters. It will choose the correct code interface from the
> language parameter and call the "call" function of the responsive
> interface.
> In the first version, of course only "python" will be supported.
> 
> new directory src/codeif/python
> -------------------------------
> This will contain a procedure "call" that accepts 5 parameters: the
> classname, the objectid, a dictionary with prefetched property names and
> their values, the code, and the parameters.
> Using functions of the language interface (src/language), a python
> object will be instantiated that represents the given business object
> instance, using the classname, the objectid and the prefetched
> properties. Then, it will run the procedure code using the instantiated
> object as "self" parameter.
> This function will return a dictionary with the new values of the
> changed properties.
> In a later version, the procedure code should run in a separate process.
> This might be not easy to do, and I'm not sure if we should do it in our
> first version.
> 
I agree with the way to call the function, but we should try to reuse
the GTrigger code in common. So IMHO the support for different
programming languages (the codeif directories you are speaking off)
should go into common instead of into appserver. We definitly have to
improve the common GTrigger code. But that is something I'm actually
looking into. And IMHO it can be done. :)

Splitting GTrigger.py into parts would IMHO mean to create a
src/logic/drivers/python/ directory and a src/logic/drivers/otherlang/
directory etc. Which would not differ much from the codeif version.

> in src/geasInstance.py
> ----------------------
> The procedure "call" should now only have to get the code from the class
> repository (as described above) and the call the code interface for
> every given instance. For every instance, the values of the changed
> properties should be updated calling "_put" internally.
> 
> With this done, we should be able to write and use simple procedures
> that read and change properties of "self".
> 
> What would you think?
> 

Great stuff.

I think that we should implement it in the above described way.

Now, how do you think should we split up the work and assign the parts?

Jan