JSP Replacer

• You are here :
• home
• Java Glossary
• Student Projects
• JSP Replacer
•  

©1996-2012 Roedy Green, Canadian Mind Products

Please do not email me about this project without reading the disclaimer above.

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?

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.

• 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.

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.

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

	You can get the freshest copy of this page from:	or possibly from your local J: drive (Java virtual drive/mindprod.com website mirror)
	http://mindprod.com/project/jspreplacer.html	J:\mindprod\project\jspreplacer.html
	Please email your feedback for publication, letters to the editor, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to Roedy Green : If you want your message kept confidential, not considered for posting, please explicitly specify that.
	Canadian Mind Products
	mindprod.com IP:[65.110.21.43]
view Blog	Your face IP:[38.107.179.214]
Feedback	You are visitor number 8,981.