I'm working on a project that allows for executing arbitrary, user-defined Mathematica scripts. It's an internal tool running on a trusted, local network. It's basically a web interface to Mathematica.
For every user-defined package I import, I can run
Names to get the list of public functions, which I can display in a combobox. Once the user selects a function to call, I would like to have specific widgets to select the appropriate values for the arguments.
f could have two arguments: the name of a column in a database table and a list of
WHERE conditions. I would then show a combobox with all the column names and an expandable list of text boxes for conditions.
There's this nifty
countArgs function which I can use to get the number of parameters, but I'm stuck on adding type information on each parameter. I have two ideas right now:
- For each function
fin a package, look for a
fMetaand standardize a way of returning the meta information required.
f::usage, embed the information there and parse it, giving something like
I'm probably going for the first option. Anybody has something smarter than this?
Here's a bit more information on the setup:
The core of the tool is a C++ program. It spawns Mma kernels running on the local machine using WSTP and connects to a Postgres database using
libpq. Mma will also connect to the database using
DatabaseLink. The C++ program also runs a fastcgi server and serves web pages as its main user interface.
As a simpler example, users can enter verbatim Mma scripts on the web page and execute them. Here's what would happen:
- A user types the Mma code in a
textboxon the web page and submits it;
- It gets posted using AJAX to the C++ program, which picks it up through its fastcgi server;
- The C++ program then passes
ExportString[ToExpression[code], "SVG"]to Mma and sends back the SVG to the web page.
Because the results of Mma are always exported as images, I can't use any of its interactive features like
FormObject. As for
webMathematica, my understanding is that it's just a front end to Mma, which is too low level for me. The whole point of this tool is to give easy access to high level operations to a couple of stats guys so they don't have to copy paste from SPSS to Excel to PowerPoint to Excel to Excel to PowerPoint.
As for calling a function from the script instead of looking for a
function + "Meta", it's a good idea, but I haven't set up two way communication between the C++ program and Mma. I'm not even sure it's possible. I would have to check whether I can get Mma to somehow call into the C++ code, but it looks more complicated than the other way around for now.