#69 make -j code on server-side more flexible

[steph96]

Hello!

This enhancement (see attached file) correlates with Bug 3410534.

When chaining web services it would be cool to maintain a list of web services. Than we can iterate on it and call the dispatch() function for each service. Therefore all services have to share the same interface to allow for a dynamic binding. If the generated code (-j) allows for an injection of such an interface class we can easily chain them.

Another feature that might be cool is to add a
virtual void setSoap(struct soap*);
function. Now we are able to replace the shared soap struct afterwards. This might be interesting in a scenario where we have two ports (soap structs), one for http and an other for https connection. Then we are able to inject the appropiate soap struct to the service and call the dispatch function afterwards.

I hope I make might feature request clear. If you have any questions, do not hesitate to contact me.

Kind regards,
Stephan

[steph96]

[steph96]

Further optimizations (-j option):

- Rename the <name>Service_init() function to init() for example (without the <name> prefix). Thus, it can be used with the inheritance functionality reported in the initial request.

- make the namespace table accessable. Currently it is not possible to access the namespace table from an object because it is hidden in the init function of that object. It may be interesting to request the namespace tables of all objects that are chained to merge the namespaces. Thus add a function like:
const struct Namespace* getNamespace();
to the class.

- on demand creation of soap struct in default constructor: In some cases it is not appropriate to pass a soap struct to the constructor just to avoid an allocation of a new soap struct as done in the default constructor, especially since the constructor modifies the passed soap struct. I propose to initialize the soap member with NULL and create the soap struct (if it is not passed with the setSoap() function meanwhile) on the first access. If the reduces performance (if usage) is a problem, you can create an additional constructor that just initializes the soap member with NULL. Of cause the object can first be used afet calling the setSoap() function with a valid soap struct.

This is all for now,
Stephan

[steph96]

I have further enhancements:

Instead of the ...Service_init() function just implement the namespace functionality. As proposed earlier, the namestace table of an object should be accessable at runtime via a getNamespacetable() function for example.

For -i and -j code generation there are two different solutions.

* For the -j code generation
** in the default constructor imode and omode can be ignored
** same for the ...Service(struct soap *_soap) constructor, since they are overwritten with their old value
** in ...Service(soap_mode iomode) construtor move the "iomode" argument to the soap_new: change soap_new() to soap_new1(iomode)
** same for ...Service(soap_mode imode, soap_mode omode) constructor: use soap_new2(imode, omode) instead.

* For -i code generation
** in the default construtor mode arguments are unnecessary
** the copy constructor already uses the base class initialization
** ...Service(soap_mode iomode) should use the base constructor soap(iomode), thus changing "...Service(soap_mode iomode)" to "...Service(soap_mode iomode) : soap(iomode)"
** ...Service(soap_mode imode, soap_mode omode) should use the base constructor soap(imode, omode) as above.

Steph