Monday, 20 August 2001
How does a Java applet extract data from a database on the server?

PHP scripts access the database with SQL and generate HTML

  • In most web applications both programs and database reside on the server. Only generated HTML gets sent across. This is the thin client approach, using the PC as dumb terminal.
  • Now, on to thick client. How will an applet on the PC talk with the database on the server?
The first option that springs to mind is SQL. But as it turns out, that option is not so easy. The webserver is like a impenetrable fort. The host provider's system controller ( stands in front of his servers like a gatekeeper.

Only HTML gets passed. Other ports won't open, not even a little bit to let familiar folks in. Hmm, from a security point of view it is 100% correct. Same story for the login code and password to the database. I'd rather keep them at server side as well. So, what to do?

Keep the program on the server?

Yes, these are options, but they limit my GUI to thin client technology. That is exactly what I want to avoid. I put this problem aside. I'm off to Dordrecht for a business trip.

One of the first things they show me is a Java applet, with data from a central database. Grr, how did they manage to do this? The solution excels in simplicity. I should have thought of this myself:

Generate parameters
for the applet
in the HTML code
on the server.

I love it. How superb in simplicity.

Back at SUMit HQ a smaller problem comes up. A Java applet needs to know the name of every parameter for the getParameter() method ( That is a snag as I had variable parameter names in mind, with an object id included to identify one entity.

In vain I search for a method to retrieve all parameters. I'm amazed that I am unable to locate such a method. Please mail me if you do find it.

Well, as a workaround
<applet ...>
<param name=entityClassName value="
<param name=... value="
I put all occurrences of the same entity type into 1 parameter, with a fixed name. A carriage return separates the occurrences. It keeps the HTML source readable, which comes in handy for debugging.

And yes, this works: Thick client with thin client technology.

An additional advantage: I don't need the database any more for development. I just save a copy of the generated HTML and continue working off line. Today I'm far from Holland, working on the laptop to construct a thick Java applet. Long live the parameter!

Till next week,

Special thanks to these gentlemen for their support:

Ernst van Erkelens
(gatekeeper at XL Server)
The java experts of 4uIT.