What is a Scripting Page ?
There are two different types of Scripting Pages :
Embedded script commands : This is very close to a JSP, but much simpler.
You just include in your HTML page portions of script between the signs
<% and %>. The commands are evaluated on page load, and their
outputs send as HTML outputs to the client browser.
Functions : You replace the URL in a link with a command name and its
arguments, following the syntax of the scripting language,
like print("hello") or puts "hello".
Which Scripting language is used ?
This is the funny part : there is no required scripting language to use SSP. In theory, you may use anything and plug it into SSP if the requirements below are met :
- There is a Java interface to the things you want to use,
- You may interpret or evaluate portions of code on the fly,
In fact, SSP is a set of Java classes build on a core abstract class. When you want to add a new language in SSP, just derive this class and connect the classes from your code.
Which Scripting language are already available ?
In the current version (SSP-0.2), the following scripting languages are connected
(select one for a link to more informations) :
- TCL (the Tool Command Language)
- BeanShell
- JPython (Java implementation of the Python language)
- FESI (the Free ECMA Script Language)
- DynamicJava (a Java interpreter written in Java)
Of course, the implementation is not always complete, or fully compliant with all
available possibilities of the scripting language. This may evolve with the further
versions of SSP, depending of the needs of the users.
For now, the TCL implementation works fine, as I know how to use this scripting tool,
and jpython has been more tested than the others.
How to use it ?
Web Server Administrator point of vue
SSP is a set of Java Servlets. You will have to find the right servlet for your scripting language. Then, you should assign it to
- a virtual context ending with the right extension ( ex: /myProject/jpython for using JPython commands in a context named 'myProject').
- a type of file ( ex: *.hpy for using embedded JPython)
and create a file named myProject.ext where ext
is an extension type specific to the language.
This file is rereaded each time it changes.
This, of course, depends on your web server. The distribution of SSP come with a sample context for Tomcat. If you use Tomcat, just put the content of 'webapps' in the Tomcat's 'webapps' directory, and add the context to the conf/server.xml file in Tomcat :
<Context path="/lang" docBase="webapps/lang" debug="0" reloadable="true" />
The current mapping of informations is as follow :
| Language |
Servlet |
subContext |
Extension |
init file ext. |
| Tool Command Language |
alantea.com.ssp.TclServlet |
tcl |
.htcl |
.tcl |
| Bean Shell |
alantea.com.ssp.BeanShellServlet |
BeanShell |
.hbsh |
.bsh |
| Python |
alantea.com.ssp.PythonServlet |
python |
.hpy |
.py |
| Free Ecma Script |
alantea.com.ssp.FesiServlet |
Fesi |
.hes |
.es |
| Java Interpreter |
alantea.com.ssp.DynamicJavaServlet |
djava |
.hjava |
.djava |
Web Server Designer point of vue
When SSP is plugged in the server for the language you want (see above),you may customise your contexts. This may be done is three ways :
- write some script functions in the initial file of the context.
- embbed some script portions in HTML pages (between the signs <% and %>) and save this pages with right extension.
- call script functions as URL in HTML links.
For all that, see the samples.
Web User point of vue
Most of all that is not visible from the browser, since it only receive the HTML code generated by the script output, and never sees the code.
The only visible part is shell script calls that are used as URLs.
It is also possible to send code from the browser to the server, using forms. This is a hook, and may not be very useful. When you call directly the servlet (ex: /lang/python ) from a form doing a "POST" command, and if the form contains an object named "cmd", then the content of this object is used as a script portion, evaluated, and its output returned to the browser.
For the current version, all other objects from the form are packed as command arguments, by pairs name value
and passed to the script. This is new in the version 0.2. I think this will become the rule.
Servlet Programmer point of vue
It is up to everybody to expand the possibilities of SSP with new scripting servlets. All you need is a Java class that :
- derives from alantea.com.ssp.LangServlet
- implements the following methods :
- protected void initServlet(boolean firstTime) that initialise the servlet. It is called each time the initialisation file has changed. The first call, it is given true as argument, else false.
- protected void evaluate(String cmd) that implements the evaluation of a string containing one or more lines of script code. When calling this function, System.out is set to point directly to the servlet's response writer.
What is missing ?
Of course, a lot !
If I should summarize what shall be done to get a correct implementation, I'll
suggest :
- Session management
- Concurrent evaluation (SSP uses only one script interpreter)
- Script control of the Servlet (creating scripting commands able to
interact with the servlet itself)
All those ideas are planned, and should be made available in future releases.
Why this Project ?
Writing pages in HTML is just fine when you only want to build static, stone-shaped pages with information that never change. You may then use any available HTML editor and draw your site. Anyone is able to access your informations, just using a simple web browser. But if you want to change the layout, create new pages, update anything in your site, it will be very painful, and you will have to spend lots of time in validating the new design.
You may use CSS or JavaScript to help you control the look and feel of you site. These tools are very useful and may help you for most your jobs. You will be able to create almost any design you want and get a very friendly GUI. But this will not help you with dynamic informations on the site, as they are used in a client point of vue.
Another way to dynamise you work is to use CGI scripts. They are on the server side of the connection, and are able to look at the files on the server's disk. But this is only a pack of scripts, that the end-user targets when selecting a link. Tying that with JavaScript is fine, but you will have to learn three languages (HTML, JavaScript and Perl) to achieve your goal!
When designing the site, you may create specialized applets and servlets, if you are able to code in Java. This is the heavy way to build a site. Ho yes, you are then able to do whatever you want, from a mastermind game to a database browser, but this remains heavy.
Searching the web, I found a small thing that was very impressive. This was the TCL HTTP server from Scriptics. This is a real HTTP web server written entirely in the TCL scrpting language. It is able to parse pages on the fly, just as JSP, and uses script commands as URLs. I thought this was a very good idea. But the server itself is not as robust, fast and secure as Apache, Tomcat or other compiled web servers.
The only solution was to create myself a way to give site designers an access to their favorite scripting language directly in the server. This has led to SSP.