JSP Replacer
©1996-2017 Roedy Green of Canadian Mind Products
Disclaimer
This essay does not describe an existing computer program, just one that should exist. This essay is about a suggested student project in
Java programming. This essay gives a rough overview of how it might work. I have no source, object, specifications, file layouts or anything
else useful to implementing this project. Everything I have prepared to help you is right here.
This project outline is not like the artificial, tidy little problems you are spoon-fed in school, when all the facts you need are included, nothing extraneous is mentioned, the answer is
fully specified, along with hints to nudge you toward a single expected canonical solution. This project is much more like the real world of messy problems where it is up to you to fully the
define the end point, or a series of ever more difficult versions of this project and research the information yourself to solve them.
Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; or give you any additional materials. I have too many
other projects of my own.
Though I am a programmer by profession, 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 in any way you please and to keep all the profits from your endeavour.
Please do not email me about this project without reading the disclaimer above.
JSP
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 (Central Processing Unit) 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 (Hypertext Markup Language) 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 (Remote Method Invocation) 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 (Java Virtual Machine) 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 (Internet Explorer), 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 (Disk Operating System) without the GUI (Graphic User Interface)
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.
