JSP Replacer
©1996-2009 Roedy Green, Canadian Mind Products
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.
This project outline is not like the artificial tidy 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, 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 endeavor.
Please do not email me about this project without reading the disclaimer above.
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, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to
Roedy Green :
