JSP Replacer

This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. It does not describe an actual complete program. I have no source, object, specifications, file layouts or anything else useful to implementing this project. Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; I have too many other projects of my own.

I do contract work for a living, which could include writing a program such as this. However, I don’t do people’s homework for them. That just robs them of an education.

You have my full permission to implement this project any way you please.

JSP (Java Server Pages) has caught on surprisingly quickly. However, I think it (and its server-only-solution relatives like Tea, ColdFusion, FreeMarker, Velocity…) are only a stop gap solution. why?

JSP and Brethren Make Inefficient Use of Communication Lines

Every time you want new information on your screen, even one character, JSP must send you an entire new page from the server.
If you want to view the same information already on your screen in a different sorted order, JSP has to send you an entire new page from the server.
The communication line sits idle while you are reading. Presumably it could be preemptively downloading information you will likely need to read next.
Data are transmitted in an extremely fluffy, text-only form with no compression whatsoever.

JSP And Brethren Make Inefficient Use of the Servers

JSP wastes the CPU power of the client workstations, preferring instead to overload the servers. The client has to pester the server for every trivial request.

Human Considerations

HTML has no data validation to speak of. You don’t find out about a keying error until you hit SUBMIT when you have finished keying the entire form. Even data entry of the 60s was more sophisticated. If you make three typos filling in a form, it typically takes four rounds of hitting submit to correct them, with precious little help in locating them.
JSP is actually a mismash of at least three incompatible languages: HTML, Java and Taglib. Some of its competitors are a mish mash of only two.
There is no clean separation between data and presentation. Web artists meddle with program code and programmers meddle with the HTML.

What should replace JSP?

Applets + Servlets. The client Applet is 100% responsible for presentation and data validation and the server servlet is 100% responsible for fetching and storing the raw data. They should communicate using RMI or another simpler serialised protocol.

Wait a minute! That has been tried and it fell on its nose. What went wrong?

Slow loading of the JVM for the first Java Applet gave Applets the reputation of being slow. Had either the JVM been loaded with the browser, or had the JVM been optimised to load quickly, that problem could be eliminated. Applets themselves are typically very compact.
Incompatible browsers. It drove you nuts writing Applets then tweaking the Applet to work on old versions of IE, Netscape etc. Microsoft refused to implement RMI. That problem is now almost behind us with the Java 1.4.1 JVM that seamlessly hooks into recent versions of IE, Netscape and Opera.
Applets are even harder for artists to write that HTML or JSP!! Only programmers can build them and they tend to build ugly ones. This brings us to the main point of this essay. How could it be possible for non-programmers to create beautiful Applets?

The Grand Plan

First you create a large set of widgets for data entry and display. A numeric data entry widget should know the low and high bound acceptable, and should be capable of prompting the user with that information. There should be widgets for entering phone numbers (for each nation), states, provinces, postal codes (for each nation), zips, addresses, credit card numbers, prices (in any country’s currency), countries,… all the usual sorts of data you deal with in business. The widget is self-validating. It won’t let the user enter bad data. The widget does this all on its own without application code.
Next you create a wizard that builds layouts. The artist does not need to name fields, just position them. The wizard works by introspection on class provided by the programmer that provides the field names, types, bounds, sizes, sample values (including worst cases), and cross field edits required. This class might be an extension of the stripped down class that will be sent later as raw serialised data. The Wizard helps the artist to remember to display all the fields. The important point is that nobody reads or meddles with the generated code. It contains a blend of artist and programmer input, but the artist never meddles with the programmer part or vice versa. Any customising of the Applet has to be done via the descriptor class provided by the programmer — not by manually tweaking the code generated by the wizard.
The wizard has to be clever and not make you start from scratch should the descriptor class be modifified. The wizard thus probably needs to store an artist’s description of the Applet in its own internal format that makes it easy to recover from changes to the programmer’s Applet description class.
In a real world example, an Applet has to handle many different programmer descriptor classes.
Gradually you make your wizard more powerful, by allowing more things to be controlled by the programmer’s description class and by allowing other things to be controlled visually. Hopefully you can avoid just grew like Topsy effect that plagues JSP. At least you won’t need to keep inventing new strange syntax.
The client delivers clean binary objects to the server. The server has to repeat some edits, to counter hackers sending in bogus objects, but the testing is simpler. For example, instead of checking the format of a currency field, you only have to check the bounds. This testing could be done by the same decriptor classes used to help contruct the client code.

We are cutting down some of the power and flexibility of the Applet in return for:

Ability to construct Applets by non-programmers.
Ability to crank Applets out at least as fast as HTML forms.
Ability of programmers to protect their code from accidental meddling by the artists.
Ability of the artists to protect their creations from heavy-handed mangling by the programmers.
Servlet programmers need no longer parse and construct messages. Everything comes and goes in tidy binary format objects.

You could think of it that we are using Applets to create a sort of intelligent data entry terminal that lets the programmers focus on processing data rather than presentation and editing.

This is not quite such as pipe dream as you might think. I devised a Forth-based computer language that called Abundance back in 1979 that does much of this, and much more, though just for DOS without the GUI complications.

Advantages Of Servlets + Wizard Applets over JSP

Efficient use of data commucications lines, compact binary transmissions.
No retransmission to display data in other forms, e.g. other sorted orders, prices in other currencies. Those can all be generated instantaneously locally.
Fast scrolling through locally stored data preemptively downloaded.
Keystroke or field level notification of data entry errors.
Artists work visually.
Programmers work at the data abstraction level using ordinary classes to describe what they want and what they are prepared to provide, using only the familiar Java syntax.
Clean decoupling of data and presentation.

Even without the wizard, the toolbox would make it much faster to compose data entry Applets. Even without the widgets, classes for validating at a field/keystroke level might be very useful to the community.

If you are not interested is such a drastic replacement for JSP, but just want something a little simpler, than works essentially the same way see servlet womb for your alternatives.

My Implementation

I have implemented a scheme something like the one described here. If you examine the source code of my website you will see it peppered with macro comments that expand into html code. I have written about 75 macros. You can read more about how it works under the HTML entry. I have not yet released the source code. It not quite ready for general distribution, but if you are curious, I could let you have a look on an as-is basis.

	Please email your feedback for publication, errors, omissions, broken/redirected link reports and suggestions to improve this page to Roedy Green :
	Canadian Mind Products
	mindprod.com IP:[65.110.21.43]
	Your face IP:[38.103.63.18]
	You are visitor number 5,019.
	You can get a fresh copy of this page from:	or possibly from your local J: drive (Java virtual drive/Mindprod website mirror)
	http://mindprod.com/project/jspreplacer.html	J:\mindprod\project\jspreplacer.html