Malte said:
And for the documentation, at the moment I always have to manually go into the tcl directory to find the procedure. This is why I would love to exchange all occurances of "proc ::" with "ad_proc ::", so at least the procedure is avialable for browsing in the ACS API and I do not have to go back to the shell, go to the directory, open the file,search for the procedure, look what it does and what variables it expects and what variables it returns. This makes development really burdensome 😊. This could be quickly fixed by you however. Just have a wrapper in init.tcl like:
You will not get very far with tWSDL or TWiST if you rely on the _static_ definition of ad_proc. You should use the inspect package which is part of tWSDL. You mount inspect anywhere you wish, by creating a symlink. I don't expect everyone to agree with me, but inspect gives you the current state of namespace variables and procedures, not what you think they are, or were at one point in time. Since most of the code in TWiST is autogenerated, you have to use something like this.
I know that as of right now, <ws>type and <ws>element are not documented, they are still in development and subject to minor changes. This does not mean that I need to rush out and use ad_proc, which would help nobody. I'm not really sure why anyone would recommend this. Did someone really do such a thing with tDOM, or with tcllib? How about Tcl itself? The world does not revolve around the OpenACS API, and complaints of this sort don't help anyone or solve any real problem. In fact, if I followed your instructions, the package would immediately only work for full installations of OpenACS. But, my goal is to abstract out even the dependencies on AOLserver, which will take very few hours as it only involves _one_ procedure in all of tWSDL! In the same way, I'm sure we can come up with a very thin layer to integrate TWiST with OpenACS, but not by hacking away on code which works.
Please keep in mind that TWiST is a _user_ API, tWSDL is a developer API. Unless you are very comfortable with how both work, it is way premature to start 'fixing' any code.