Forum OpenACS Development: Re: API Browser Support for Other Programming Languages

The API browser does not have to do much with xowiki. The API is providing a general interface, which is programming language agnostic [1].

In essence, the information is kept in an nsv, which can be filled with data from different providers. To explore what is the content of this data structure e.g. for the function "acs_user::get_by_username", use the following from ds/shell:

nsv_dict keys api_proc_doc acs_user::get_by_username

The command "ns_dict" was introduced recently in NaviServer, for older version, one can use:

dict keys [nsv_get api_proc_doc acs_user::get_by_username]

To get a certain dict entry, use

nsv_dict get api_proc_doc  acs_user::get_by_username main

Pretty-printing of the source-code is performed through [2] based on the proc-name and introspection, so this will need some awareness of other languages (by e.g. adding as well a language identifier to the dict, etc.), but here the question arises, how much information will be provided. Currently, the API-browsers provides minimal support for e.g. SQL [3] (also XQL [3]), but it does not show the used .css files (there is just minimal support via the developer support, but often the CSS and/or JavaScript files are minified and nor really useful).

So, depending on the goals, one can go different direction, it really depends, what other languages one has in mind...

Hope this helps
-g

[1] https://openacs.org/api-doc/procs-file-view?version_id=5433171&path=packages/acs-api-browser/tcl/acs-api-documentation-procs.tcl
[2] https://openacs.org/api-doc/proc-view?proc=apidoc::tcl_to_html&source_p=1
[3] https://openacs.org/api-doc/package-view?version_id=5452089&public_p=0&about_package_key=&kind=sql_files
[4] https://openacs.org/api-doc/proc-view?source_p=1&proc=forum::get&version_id=5452089

Carl,
If I understood correctly you need, the best way to inhibit api-browser from the user is to work properly with permission system.
Site-wide-administration, SWA, is designed to own (i.e. have access) the entire system, to access api-browser, developer support tools, and a bunch of other features. You don't want to change that. Believe me!

A Subsite administrator is the one you should be setting up to be your admin for site administration tasks.
https://openacs.org/doc/configuring-configuring-permissions

Could you create a custom package for that?
A possibility is to make it available to site admins, then they won’t have access to the api-browser section, but they will have access to your "custom code library" package.

Best wishes
I

Actually, i do not see the big problem in changing permissions of the api-browser.

The api-browser was designed and implemented as a singleton package for providing documentation for developers about the code running on this instance (there is only one code basis). If one wants multiple instances to be used for different purposes, maybe in multiple subsites, one has to
- remove the singleton-property (with all consequences),
- make the package subsite-aware (maybe not much),
- provide configuration options per instance (what kind of code you want to see),
- extend the API in what instance the data should be seen (and maybe provide as well source-code language information)
- extend the data-model (i.e. the nsvs, naming etc.)

This is some effort, but it it look in general doable to me, since the existing API and datastructures are rather simple. One should be able to provide default settings, such that existing usages can continue to work unmodified.