Helma Logo
main list history
previous version  overview  next version

Version 3 by hannes on 25. September 2008, 16:53

This is a rough list of ideas I have for Helma NG.

=== Response Logging, Toolbar, Debugger

* Don't use global callbacks, set up (thread-local) callback with reference to res object in handleRequest

=== Helma command line tools

The current setup of Helma NG command line tools is too much biased towards convenience and not enough towards flexibility. Is there a need for dual command line tools (run.jar and shell.jar)? Couldn't there be a single run.jar, and the app server and shell just two scripts to run with it? Or the shell be activated by some option to run.jar?

Generally speaking, Helma NG should become more like a traditional language interpreter: A tool to run scripts or interactively entering code through a shell. Both the shell and the app server (as well as possibly other tools) would be started using the same runtime by passing different options or running different scripts. More specifically, the interactive shell could start if no script is passed to the runtime, or if it is explicitly required using a command line option (Python uses -i for this).

Another requirement is to be able to pass arguments to the script. The exact sequence of command line parameters would be the following:

    [javavm] [javavm-opts] [helma-jar] [helma-opts] [script] [script-opts]

This is an example of how this may look in practice, with -i telling Helma to run in interactive (shell) mode after the script has run, and -p setting the web server port:

    java -jar run.jar -i helma.server apps/demo -p 8080

To make this more usable, there should be shell scripts containing the java invocation part and possibly also the script name. For example, there may be a generic helma-ng script containint the <code>java -jar run.jar</code> part, and a helma-ng-server script including the helma.server script part.

Since the scripts to start an application will now live in the modules directory of the Helma installation, it is no longer possible to automatically add the application directory to the module path. There are various ways to fix this. Either the current directory can be added to the module path automatically, or the script can take care of setting up the application directory in the module path. Another solution would be to create a thin wrapper around a standard module in the app directory that provides the functionality of the wrapped script in the context of the application (Django does this with manage.py, which is a wrapper around django-admin.py).

The app also needs to provide setup information to various scripts. This will be done through a setup.js script which can be easily imported once the app directory is part of the module path.