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

[Sacha Schlegel]

Hi Reinhard

I think this looks good and I can imagine that this would give you
simple procedures rather quickly.

Not having followed to much whats going on at the moment I remember
siesel thinking about unittests, or simply some forms of testing.

You might add a constraint, that each procedure must have test code
associated with it. Might be a procedure for a procedure instance.

This would allow to call all test procedures in one go.

Just my thoughts.

Sacha

On Wed, 2003-11-05 at 00:02, Reinhard Mueller wrote:
> 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,
-- 
------------------------------------------------
Sacha                                   Schlegel
------------------------------------------------
4 Warwick Str, 6102 St. James, Perth,  Australia
address@hidden                www.schlegel.li
public key:            www.schlegel.li/sacha.gpg
------------------------------------------------

signature.asc
Description: This is a digitally signed message part