Helma Logo
main list history

Ideas

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

Response Logging, Toolbar, Debugger

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:

    java [javavm-opts] -jar run.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 java -jar run.jar 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.

Comments

#1 by zumbrunn at 2008/07/10 08:25

Starting the jetty server via javascript and app.start() is the right approach in my opinion. Instead of needing to do this in a main function, it could be the config module that has to invoke app.start(). There could be a default config module at modules/helma/config.js that gets called if the app itself doesn't have a config.js file.

#2 by hannes at 2008/07/12 13:14

This is pretty much how I'm planning to do it, Chris. If there is a default config module, I think a good idea might be to automatically copy it over to the app directory when creating an app (using some shell command). I also think there should be a way to shut down an application, so the current main.main() method may be replaced by start() and stop() methods in the config module.