Parameter

Maandag, 20 augustus 2001
Hoe krijgt een Java applet gegevens uit een database op de server?

PHP scripts benaderen de database met SQL en genereren HTML

  • Bij de meeste web applicaties staan zowel programmatuur als database op de server. Wat er over de lijn gaan is slechts wat gegenereerde HTML. Het is thin client, de PC gebruikt als domme terminal.
  • Maar nu thick client. Hoe praat een Java applet op de PC met de database op de server?
Het eerste wat in me opkomt is SQL. Maar dat blijkt nog niet zo makkelijk. De webserver is als een gesloten fort. De systeembeheerder van de hostprovider (xlserver.com) staat als een poortwachter voor z'n servers.

Alleen HTML komt er door. Andere poorten gaan niet open, zelfs niet op een kiertje voor eigen volk. Hmm, uit beveiligingsoogpunt heeft hij nog 100% gelijk ook. De logincode en password voor de database hou ik ook liever centraal. Maar wat nu?

De coding op de server houden?

  • Daar vanuit PHP een uitstapje maken naar Java (php.net/...Java.php)?
  • Java op de server draaien met een servlet?
Het zijn mogelijkheden, maar die werpen me terug richting een thin client, met beperkte GUI mogelijkheden. Dat is nu precies wat ik niet wil. Ik leg het probleem even ter zijde en ga naar Dordrecht voor een korte zakenreis.

Net zo vrolijk laten IT collegae me daar een Java applet zien, met data uit een centrale database. Grr, hoe doen die boefjes dit? De oplossing is verrassend eenvoudig. Ik had er zelf moeten opkomen:

Genereer, op de server
parameters in de HTML code
voor de applet
(java.sun.com/docs/.../html).

Heerlijk, wat super simpel.

Terug in SUMit HQ doemt een kleiner probleempje op. Een Java applet moet elke parameter bij naam kennen voor de getParameter() method (Java.sun.com/...getParameter). Dat is lastig want ik had variabele parameternamen in gedachten, met een objectid in de naam gefrommeld als identificatie voor één entiteit.

Ik zoek me suf naar een method die alle parameters kan vinden. En tot m'n verbazing kan ik zo'n Java method niet vinden. Wie zo'n method wel gevonden heeft mag me mailen.

Maar goed, als workaround
<applet ...>
<param name=entityClassName value="
118&XX&265-266&5&20010807&0845
126&XY&265-266&5&20010814&0845
105&YZ&460-461&1&20011027&0800"
</param>
<param name=... value="
..."
</param>
</applet>
dan maar alle occurrences van 1 entiteit in 1 parameter, met een vaste naam. Een carriage return scheidt de occurrences van elkaar. De gegenereerde HTML source blijft zo mooi leesbaar, handig bij debuggen.

En jawel, dit werkt: Thick client met thin client technologie.

Een bijkomend voordeel: De hele database heb ik nu niet meer nodig. Ik sla de gegenereerde HTML op en kan verder off-line werken. Vandaag zit ik, met laptop, ver van Nederland een dikke Java applet in elkaar te krassen. Lang leve de parameter!

Tot de volgende week,
Henk Jan Nootenboom

Met dank voor de adviezen van de heren:

Ernst van Erkelens
(poortwachter bij XL Server)
(xlserver.com)
De java experts van 4uit.