Helma Logo
main list history

Version 4 by hannes on 25. September 2008, 17:00

15    [javavm] java [javavm-opts] [helma-jar] -jar run.jar [helma-opts] [script] [script-opts]

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

3=== Response Logging, Toolbar, Debugger
4
5* Don't use global callbacks, set up (thread-local) callback with reference to res object in handleRequest
6

Version 2 by hannes on 20. August 2008, 23:24

3* Unify startup process for runner and shell.=== Starting the shell should do just the same as starting the runner, except that it additionally starts the shell prompt.Helma command line tools
4* Change startup convention to load a config module that contains everything needed to configure the app.
5* Do apps need The current setup of Helma NG command line tools is too much biased towards convenience and not enough towards flexibility. Is there a main function at all? Wouldnneed for dual command line tools (run.jar and shell.jar)? Couldn't it there be better to call a method in single run.jar, and the jetty module app server and shell just two scripts to start run with it? Or the jetty server?shell be activated by some option to run.jar?
6
7Generally 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).
8
9Another requirement is to be able to pass arguments to the script. The exact sequence of command line parameters would be the following:
10
11    [javavm] [javavm-opts] [helma-jar] [helma-opts] [script] [script-opts]
12
13This 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:
14
15    java -jar run.jar -i helma.server apps/demo -p 8080
16
17To 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.
18
19Since 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).
20
21The 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.
22

Version 1 by hannes on 09. July 2008, 11:51

1This is a rough list of ideas I have for Helma NG.
3* Unify startup process for runner and shell. Starting the shell should do just the same as starting the runner, except that it additionally starts the shell prompt.
4* Change startup convention to load a config module that contains everything needed to configure the app.
5* Do apps need a main function at all? Wouldn't it be better to call a method in the jetty module to start the jetty server?