Bristowhill Server Pages was a templating system which provided dynamic web pages. Initially it had its own scripting language, but once the Rhino implementation of Javascript was available, server-side Javascript became the main feature of BHSP.
Since BHSP pages were written in XML, you could use your favorite XML editor to create them, avoiding the syntax errors that come from doing things on your own. Being template-based, the source XML bore a strong resemblence to the HTML which would be sent to the browser, so strong conceptualization ability was not required to have a feeling for the final appearance. Once could begin with XHMTL and slowly add dynamic content to a page, which makes it easy to get started on a project. Finally, since Javascript is used on both the server and the client, programmers only need to know this one simple programming language.
While templating systems have the straightforwardness of "What you see is what you get" editing systems, they also suffer from the same "What you see is all that you get" limitation. They provide a quick and easy solution for simple projects, but they are hard to use for more complicated projects. It is tempting to leave all of the program logic in the templates, creating a maintenance nightmare. To be fair to BHSP, it did allow for the creation of Java libraries which abstracted away the hard bits from the presentation layer, but there was no obvious way to draw the line between the presentation and the control logic.
Perhaps the most satisfactory alternative to BHSP for those who want to use a Javascript-capable templating system is Whitebeam. This system has been developed to the point that it is very rich in features and it has been tested in production systems. Besides being more complete than BHSP ever was, it uses Mozilla's compiled version of Javascript rather than the Java version and so it is faster than BHSP.
My own feeling is that template based systems tend to be hard to maintain as they mix together in one place the presentation layer, the control logic and (if you are not careful) the business rules. I find that the adaptations of the MVC pardigam to web servers as found in Ruby on Rails, Turbo Gears or Java Struts provide systems which are easier to implement and easier to maintain than templating systems. However, they also require slightly more disciplined programmers than templating systems since not everything is visisble in one place. Ideally for MVC development one should have database experts to handle the models (the business rules), general programmers to handle the controllers and designers to handle the views. Such a division of labor may not be feasible for a small operation.
The orignal code for BHSP consisted of a Java servlet plus a collection of Java classes which provided a support library for such things as JDBC connection pooling.
Tomcat or other servlet container would be configured to pass processing of any file whose name ended in .bhsp over to the BHSP base servlet. This servlet would pass a SAX processor over the XML. It was expected that tag names were ordinary HTML tags, but that their argument lists were allowed to include assignment statments or replacement statements. Processing instructions contained Javascript to be executed, with standard ouptut directed into the response cache.
Assignment statements were removed and the assignments were saved in a hashtable of environment values which included all form data. The rest of the tag and its content were passed along to the output stream. Pre and post caches were maintained to bracket the output generated by tags which were embedded in content.
Replacement tags had their content (typically empty) with the values taken from the environmental hashtable which was maintained by the BHSP servlet. For example, if the hash mapped "name" to "value", then <span replace="name" /> would cause "value" to be placed into the response stream at that point.
Along with individual replacements, it was possible to also create iterated replacements using arrays of variables in the manner made popular by ColdFusion.
When a processing instruction was encountered which indicated that the Rhino Javascript interpeter was to be invoked, that interpreter was given a Java object known as its environment. That object contained fields which contained the HTTP input data, the name-value pairs defined up to this point in processed tags and the names of all tags which had been given names. Since the DOM representation was not yet available (and never was created on the server side), it was not possible to directly manipulate tags on the server side. Of course, it was quite possible to inject Javascript into the response which would manipulate DOM objects in the client browser. It was also possible to dynamically create HTML output, though of course this HTML did not pass through the SAX parser unless one chained server output, something which was powerful but probably inadvisable from the point of view of maintability.
The environment object was maintained thoughout a page, so that earlier Javascript invocations could communicate with later invocations by modifying the environment object. Strictly speaking, this capability makes the assignment of environmental values inside tags redundant, but such assignments are more efficient than loading up the Javascript interpreter just to make an assignment and they are easier to read than repeated processing instructions.