gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUe-dev] Appserver: Procedures implementation proposal


From: Reinhard Mueller
Subject: [GNUe-dev] Appserver: Procedures implementation proposal
Date: 04 Nov 2003 17:02:07 +0100

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")
* 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.

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?

Thanks,
-- 
Reinhard Mueller
GNU Enterprise project
http://www.gnue.org

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


reply via email to

[Prev in Thread] Current Thread [Next in Thread]