vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisFeedbacknächstes Kapitel


Tag 21

Dynamische Applikationen testen und einsetzen

Zum Abschluss unserer dreiwöchigen Tour durch Dreamweaver UltraDev werden wir einen Aspekt bei der Einrichtung von Websites betrachten, der sehr wichtig ist, im Allgemeinen jedoch wenig Beachtung findet - das Testen und Debuggen. Selbst auf statischen Websites gibt es Situationen, wo sich die Dinge nicht so verhalten, wie Sie sich das vorstellen. Der Schlüssel zu Ihrer Zufriedenheit ist, zu verstehen, was schief laufen kann und warum. Heute geht es um die folgenden Themen:

21.1 Codierprobleme

Bei der Entwicklung einer Website sollten Sie sich immer vor Augen halten, dass es extrem unwahrscheinlich wäre, würde das Programm gleich im ersten Anlauf funktionieren. Manchmal wird einfach nur die Breite einer Tabellenzelle falsch gesetzt, was in wenigen Sekunden erkannt und behoben werden kann. Leider gibt es auch Situationen, wo Sie stundenlang auf Ihre HTML-Seite starren und nie herausfinden, was passiert ist.

Wenn Sie das ohnehin bereits recht mäkelige HTML nehmen und eine eingebettete Programmiersprache damit kombinieren, kann das noch schlimmer sein. Was passiert, wenn Sie dem Bildschirm dynamisch HTML hinzufügen, aber im HTML-Code ein Fehler enthalten ist? Statt an einer einzigen Stelle zu debuggen, müssen Sie nun plötzlich feststellen, ob der HTML-Code oder die eingebettete Programmiersprache für den Fehler verantwortlich sind. Und manchmal liegt es an beidem!

Durch die automatische Codeerstellung von UltraDev können Sie größtenteils davon ausgehen, dass der zugrunde liegende Code korrekt ist. Aber selbst mit diesem Ansatz können Fehler auf Ihrer Site entstehen. Die einzige Möglichkeit, diese Probleme zu umgehen, ist wirklich zu verstehen, wo die Ursachen liegen können - und darum soll es in diesem Kapitel gehen. Insbesondere sollen die drei folgenden Gebiete näher beleuchtet werden:

21.2 Fehler im HTML-Entwurf

Ob von einem Programm oder manuell erstellt: Fehler im HTML-Entwurf sind ein häufiges Problem, selbst auf kommerziellen Websites. Verschlimmert wird das Ganze dadurch, dass viele Probleme durch den Browser kompensiert werden, d.h., der Browser errät, was Sie vorhatten und stellt die Seite nicht selten korrekt dar, auch wenn das HTML falsch ist. Das ist praktisch, wenn Sie einen Browser haben, der das Problem korrekt behebt, aber andernfalls können die Ursachen sehr schwer zu finden sein.

Formulare

Wir beginnen mit dem gebräuchlichsten Entwurfsproblem - insbesondere, wenn Sie Ihr HTML manuell anpassen. Statt zu versuchen, das Problem zu erkennen, geben Sie das folgende HTML in eine Textdatei ein und zeigen diese unter Verwendung von Netscape an:

<table border=1 BGCOLOR="#FF0000">
<tr><td>Hello World</td><td>
<table border=1 BGCOLOR="#FFFF00">
<tr><td>Hello World</td></tr>
</table></td></tr>
<tr><td>
<table border=1 BGCOLOR="#FF00FF">
<tr><td>Hello World</td></tr>
</table>

Wie Sie in Abbildung 21.1 sehen, wurden zwar drei Tabelle mit dem Inhalt »Hello World« definiert, aber im Netscape-Fenster erscheint kein Inhalt.

Abbildung 21.1:  Der Code enthält drei Tabellen, aber wo sind sie?

Öffnen Sie jetzt den Internet Explorer, und betrachten Sie genau dasselbe HTML- Dokument. Plötzlich sind die Tabellen da. Abbildung 21.2 zeigt genau dasselbe Dokument im Internet Explorer. Was ist passiert?

Abbildung 21.2:  Drei Tabellen, und sie sind alle da.

Falls Sie es noch nicht bemerkt haben - das Problem im Code ist ein fehlendes </TABLE>- Tag im Dokument. Es gibt drei Start-Tags, aber nicht für jedes gibt es ein zugehöriges Ende-Tag.

Netscape kann diese falsch formatierte Tabelle nicht anzeigen. Es ist der Meinung, dass nicht genügend Daten zur Verfügung stehen, um die Tabelle darzustellen, wenn man nicht weiß, wo sie endet. Der Internet Explorer dagegen setzt automatisch voraus, dass ein Ende-Tag fehlt und stellt die Tabellen korrekt dar.

Welcher Browser verhält sich falsch?

Scheinbar ist der Internet Explorer der bessere Browser, aber dem möchte ich energisch widersprechen. Durch die Kompensierung eines menschlichen Versagens bewirkt er, dass ein HTML-Fehler nicht erkannt wird. Netscape bietet zwar keinen Hinweis darauf, wo das Problem begründet liegt, aber er macht zumindest deutlich, dass ein Problem vorliegt.
Die Frage ist - wie weit kann das Ganze gehen? Wie schlampig können die Codierer sein, ohne dass sie dafür zur Verantwortung gezogen werden? Und wie viele Benutzer werden deshalb die Website nicht sehen?

Glücklicherweise erkennt UltraDev das fehlende Ende-Tag und weist in der Entwurfsansicht auf das Problem hin, wie in Abbildung 21.3 gezeigt. Eine Zeit lang hielt ich das für eine überflüssige Funktion, weil ich einige der Fehler selbst gut erkennen konnte und es müßig fand, so rüde daran erinnert zu werden. Jetzt aber weiß ich zu schätzen, wie offensichtlich damit ein Problem für den Benutzer wird.

Abbildung 21.3:  UltraDev markiert problematische Tags unmittelbar in der Entwurfsansicht.

Neben dem Hinweis, dass ein Problem mit einem Tag vorliegt, bietet UltraDev auch einige praktische Informationen dazu, wie Sie Ihr System reparieren können. Klicken Sie in der Entwurfsansicht auf das markierte Tag. Die Eigenschaftenpalette beschreibt genau, um welches Problem es sich handelt, wie in Abbildung 21.4 gezeigt.

Abbildung 21.4:  Wenn Sie ein markiertes Tag anklicken, sehen Sie sofort, welches Problem vorliegt.

Eine der gebräuchlichsten Erklärungen für leere Seiten, die eigentlich einen Inhalt haben sollten, sind unvollständige Tabellen. Das passiert häufig bei der Verwendung des Serververhaltens Bereich wiederholen, wenn es sich bei dem wiederholten Bereich um eine Tabellenzeile handelt. Wenn während der Ausführung der Schleife irgend etwas passiert, beendet der Applikationsserver seine Arbeit möglicherweise, bevor er die Gelegenheit hatte, die restliche Seite auszuspucken - mit dem Tabellenende-Tag. Und Sie fragen sich anschließend, was passiert ist, wenn auf dem Bildschirm nichts angezeigt wird.

Die einfache Lösung für das Problem des unsichtbaren Inhalts ist immer, die Quellcode-Funktion Ihres Browsers aufzurufen, um das HTML direkt zu betrachten, wenn Sie das Gefühl haben, es fehlt etwas. Sie werden wahrscheinlich einen Tabellenanfang sehen, gefolgt von einer Fehlermeldung Ihres Servers, die beschreibt, was passiert ist.

Ein ähnliches aber weniger offensichtliches Problem ist das verfälschte Formular. Auch dieses Problem soll am besten anhand eines Beispiels demonstriert werden, damit Sie verstehen, wovon ich spreche. Geben Sie das folgende HTML in eine neue Seite ein:

<TABLE BORDER="1">
<TR>
<TD>Geben Sie Ihren Namen ein:</TD>
<TD><INPUT TYPE="text" NAME="name"></TD>
</TR>
<TR>
<TD>Wählen Sie Ihre Lieblingsfarbe:</TD>
<TD><SELECT NAME="color">
<OPTION>Rot</OPTION>
<OPTION>Blau</OPTION>
<OPTION>Gelb</OPTION>
<OPTION>Schwarz</OPTION>
<OPTION>Grün</OPTION>
</SELECT>
</TD>
</TR>
<TR>
<TD COLSPAN="2"><INPUT TYPE="submit" NAME="submit"></TD>
</TR>
</TABLE>

Wie Sie sehen, war ich sehr sorgfältig bei der Formatierung und alle Start- und Ende-Tags befinden sich an Ort und Stelle. Alles sieht ganz richtig aus. Eigentlich sieht auf der UltraDev-Oberfläche, die Sie in Abbildung 21.5 sehen, alles ganz gut aus.

Abbildung 21.5:  Auf der UltraDev-Oberfläche sieht es aus, als sei alles in Ordnung.

Probieren wir es jetzt im Internet Explorer. Wie Sie in Abbildung 21.6 sehen, sieht hier wieder alles ganz ordentlich aus. Das ist nicht das wunderbarste Formular der Welt, aber es sieht aus, als würde es funktionieren. Aber weil wir vorsichtig sind, öffnen wir es jetzt in Netscape.

Abbildung 21.6:  Auch im Internet Explorer ist alles in Ordnung.

Nanu! Was ist das? Wie Sie in Abbildung 21.7 sehen, zeigt Netscape das Formular an, wie es nicht vorhersehbar war. Das Eingabefeld fehlt, die Senden-Schaltfläche fehlt, und die Auswahlliste enthält ein wildes Durcheinander aus den Wörtern der Options-Tags.

Warum erkennt UltraDev nicht, dass ein Fehler vorlag, und auch der Internet Explorer merkt nichts - aber Netscape meckert. Auch hier ist Netscape der Buhmann. Die Erklärung für diese seltsame Aktivität besteht darin, dass das Dokument keine <FORM>-Tags enthält. Das ist nicht unbedingt eine falsche Verhaltensweise, scheint jedoch im Vergleich zu anderen Browsern (IE, Opera, iCab usw.) inkonsistent zu sein. Durch Einfügen der <FORM>-Tags löst sich das Problem sofort auf.

Abbildung 21.7:  Netscape kommt mit dem Formular nicht zurecht.

In dieser Situation können Sie schneller sein, als Sie es für möglich halten. UltraDev warnt Sie (es sei denn, Sie fordern es auf, dies zu unterdrücken), dass Sie ein <FORM>-Tag einfügen sollten, wenn Sie ein Formularelement verwenden - und es übernimmt diese Aufgabe sogar für Sie. Das Lustige dabei ist, dass nachfolgende Felder nicht unbedingt in dasselbe Formular eingefügt werden.

Am einfachsten stellen Sie sicher, dass alle Formulartags an der richtigen Stelle enden, indem Sie immer ein Formulartag einfügen, bevor Sie Formularelemente einfügen. Überprüfen Sie das HTML, nachdem das Formular erstellt wurde, und stellen Sie sicher, dass alle Felder innerhalb der Tags <FORM> und </FORM> liegen, indem Sie die Formularelemente manuell verschieben.

Ebenen

Ebenen machen Spaß. Sie ermöglichen dem HTML-Entwickler, Objekte auf Pixel genau zu platzieren, und sie können mit JavaScript dynamische Webseiten anlegen, die ausschließlich im Browser des Clients ausgeführt werden. Und was am besten ist: Ebenen funktionieren in fast allen aktuellen Browsern. Wenn Ihre Benutzer die Browser-Version 4.0 oder höher einsetzen, können sie auch Ihre Ebenen anzeigen, richtig? Nicht unbedingt.

Legen Sie eine einfache Seite mit Ebenen in UltraDev an, oder geben Sie das folgende HTML in einen Texteditor ein:

<body bgcolor="#FFFFFF">
<div id="Test" style="position:absolute; width:225px;
height:261px; z-index:1; left: 45px; top: 43px;
background-color: #CCCCFF; layer-background-color: #CCCCFF;
border: 1px none #000000">
<div align="center">
<br>
<br>
<br>
<br>
<br>
<p>I'm a test too!</p>
</div>
</div>

<div id="Layer1" style="position:absolute; width:247px;
height:242px; z-index:2; left: 170px; top: 183px;
background-color: #CCFFCC; layer-background-color: #CCFFCC;
border: 1px none #000000">
<div align="center">
<br>
<br>
<br>
<br>
<br>
<p>This is a test!</p>
</div>
</div>
</body>

Dieser Code definiert zwei überlappende Ebenen, eine grüne, eine blaue, und beide mit einer Meldung als Inhalt. In der Entwurfsansicht von UltraDev sehen diese Ebenen aus wie in Abbildung 21.8 gezeigt.

Abbildung 21.8:  Zwei überlappende Ebenen, die in Ihrem Browser ab Version 4.0 korrekt angezeigt werden sollten - oder?

Nach den beiden ersten Beispielen sind Sie vielleicht schon darauf gefasst, dass, falls etwas schief gehen kann, das im Netscape passiert. Wenn Sie also auf den Screenshot des Internet Explorers warten, dann machen Sie sich keine Gedanken. Er sieht aus wie erwartet.

Jetzt betrachten wir die Seite in Netscape. Was sehen Sie? Es ist sehr wahrscheinlich, dass in Ihrem Dokument alles korrekt aussieht. Das bedeutet jedoch nicht, dass wirklich alles in Ordnung ist, weil eine einfache Änderung in den Einstellungen von Netscape das Layout der Ebenen vollständig ruinieren kann. Interessant dabei ist, dass diese Änderung überhaupt nichts mit den Ebenen zu tun hat.

Deaktivieren Sie die Ausführung von JavaScript in Netscape:

  1. Wählen Sie Bearbeiten > Einstellungen in Netscape.
  2. Wählen Sie in der linken Liste die Kategorie Erweitert.
  3. Entfernen Sie die Markierung für JavaScript aktivieren.
  4. Verlassen Sie das Fenster mit den Einstellungen.

Jetzt fragen Sie sich, welches JavaScript ich in die Webseite eingefügt haben könnte. Betrachten Sie den Quellcode - Sie werden absolut kein JavaScript erkennen. Aber wenn im Code kein JavaScript enthalten ist, sollte es keinen Unterschied machen, ob er aktiviert oder deaktiviert ist. Laden Sie jetzt die Seite mit den Ebenen. Abbildung 21.9 zeigt, dass dies gar nicht mehr wie unser Entwurf aussieht. Die Ebenen sind weg und nur der darin enthaltene Text erscheint.

Abbildung 21.9:  Wo sind die Ebenen hingekommen?

Wenn Sie wie ich sind, dann haben Sie es satt, dass überall plötzlich JavaScript-Fenster auftauchen. Stellen Sie sich meine Überraschung vor, als ich in einer dieser Situationen eine Site besuchte, die ursprünglich mithilfe von Ebenen angelegt war. Statt von einer Webseite wurde ich von einer leeren Seite empfangen. Die Überprüfung des Quellcodes hat gezeigt, dass das HTML zwar vorhanden war, aber nicht angezeigt wurde. Das kann insbesondere dann Nerven kosten, wenn man das Problem nie zuvor gesehen hat. Ihre Seite ist wunderbar, aber sie kann im Browser nicht angezeigt werden. Ist das nicht entzückend?

Netscape und die relative Positionierung

Sie kennen dieses letzte Problem noch nicht, das durch die Verwendung von Ebenen in Netscape verursacht wird. Ein weiteres Problem ist ebenso seltsam wie unangenehm. Es betrifft die relative Positionierung in einem HTML-Dokument. UltraDev unterstützt keine relative Positionierung direkt auf der UltraDev-Oberfläche. Es tut sein Bestes, um die Ebene darzustellen, aber es ist nicht perfekt.

Falls Sie noch nie eine relative Positionierung verwendet haben, machen Sie sich keine größeren Gedanken. Wenn Sie dagegen ein großer Fan von Ebenen sind, kann es nur eine Frage der Zeit sein, wann Sie die relative Positionierung brauchen. Statt einer absoluten Positionierung, wobei die Ebenen an bestimmten Pixelkoordinaten angelegt werden, platziert die relative Positionierung die Ebene in einem Abstand relativ zu einem anderen Objekt. Wenn Sie eine Gruppe von Ebenen anlegen wollen, die sich selbst in der Seite zentrieren, ist das die einzige Möglichkeit, das zu bewerkstelligen. Leider hat Netscape ein Problem damit. Um zu sehen, was passiert, fügen Sie dies in eine neue Seite ein:

<body bgcolor="#FFFFFF">

<div id="Layer1" style="position:relative; left:240px; top:100px;
width:200px; height:170px; z-index:1; background-color: #FFFFCC;
layer-background-color: #FFFFCC; border: 1px none #000000">
<div align="center"><br>
<br>
<br>
<br>
<br>
<br>
<a href="http://www.poisontooth.com/">
Click Here to Jump to Poisontooth</a></div>
</div>
</body>

Dies ist nichts anderes als eine Ebene, die einen Link enthält. Öffnen Sie nun die Seite in Netscape. Ihr Bildschirm sollte so aussehen wie Abb. 21.10.

Abbildung 21.10:  Der Bildschirm sieht auf den  ersten Blick gut aus...

In diesem Beispiel führt die Verwendung der relativen Positionierung zu denselben visuellen Ergebnissen wie die absolute Positionierung, weil die Ebene relativ zu ihrem übergeordneten Objekt positioniert wird.

Alles sieht gut aus - ist es aber in Wirklichkeit nicht. Positionieren Sie Ihren Mauszeiger über dem Link. Klicken Sie ein- oder zweimal darauf. Sie sehen, dass überhaupt nichts passiert. Der Link verhält sich nicht wie ein normaler Link. Die Ziel-URL wird nicht in der Statusleiste des Browsers angezeigt, wie es normalerweise der Fall ist. Was also passiert hier? Netscape kann Links in relativ positionierten Ebenen nicht korrekt verarbeiten.

Zeigen Sie jetzt mit dem Mauszeiger auf die Ebene, als wäre sie in der oberen linken Ecke des Webbrowsers positioniert. Und da ist der Link - völlig unsichtbar, aber er ist da!

Die Ebenenattribute sind ein großes Problem der CSS-Implementierung von Netscape. Die Positionierungsattribute werden inkonsistent verarbeitet und führen nicht selten zu Problemen.

Verstehen Sie mich nicht falsch - ich mag Netscape. Ich setze es sogar als primären Browser auf allen meinen Computern ein.

Ich empfehle nur jedem, der den Internet Explorer zum Testen seiner Web-Entwicklungen verwendet, dafür auch den Netscape Navigator heranzuziehen. Wenn Sie eine Seite haben, die im Netscape funktioniert, dann läuft sie fast garantiert auch im IE. Der Umkehrschluss dagegen gilt nicht.

Dies sind einige häufige und frustrierende Probleme, die Ihnen im HTML-Teil Ihrer Projekte begegnen können. Aber was ist mit den datenbankgestützten Sites? Was kann dort schiefgehen?

21.3 Probleme mit Serververhalten

Während Sie dieses Buch gelesen haben, haben Sie sicher bemerkt, dass es viele verschiedene Fälle gibt, in denen Sie Ihre UltraDev-Ausgabe ein bisschen »verfeinern« müssen. Die Probleme liegen dabei nicht im eigentlichen Code, sondern entstehen durch bestimmte Konstellationen, die Sie vermeiden lernen sollten. Durch die Befolgung einiger allgemeiner Richtlinien können Sie sich viel Ärger ersparen.

Überbleibsel

Das erste Problem ist ganz einfach zu vermeiden - aber man denkt häufig nicht daran. UltraDev hat ein Problem damit, Ordnung zu hinterlassen, insbesondere, wenn Sie manuell HTML eingefügt oder Programme eingebettet haben.

Häufig kommt es vor, dass Sie Ihrer Seite Serververhalten hinzufügen, die Sie später wieder entfernen. Wenn Sie jedoch Code aus dem HTML entfernen, entsteht ein instabiles Dokument, das möglicherweise nicht mehr korrekt funktioniert, wenn neue Verhaltens eingefügt werden. UltraDev tut, was es kann, um Sie zu zwingen, die Verhaltens in der richtigen Reihenfolge zu entfernen, aber manchmal verhält es sich eben nicht wie erhofft.

Ich empfehle Ihnen wirklich dringend, sich mit dem manuellen Entfernen von Code in der HTML-Ansicht vertraut zu machen, oder bei jeder Überarbeitung Ihrer Serververhalten neu zu starten. Benutzer von ASP und JSP sollten kein Problem haben, die eingebetteten Tags im HTML zu finden - obwohl CFMS oft ein bisschen blendet. UltraDev sollte diesen Code jedoch für Sie hervorgehoben darstellen, sodass Sie ihn einfach finden und entfernen können.

Erweiterte Abfragen

Einer der Orte, wo gerne etwas schief geht, ist die Spezifikation erweiterter Abfragen. Die unterschiedlichsten Probleme können auftreten, und man kann kaum etwas dagegen unternehmen. Diese Probleme erzwingen häufig, das eingebettete SQL manuell zu bearbeiten, um eine Lösung zu schaffen.

Identische Feldnamen

Bei der Entwicklung eines der Kapitel im Buch habe ich mehrere Tabellen angelegt, die ich miteinander verknüpfen wollte. Das erste Tabellenlayout sah etwa wie folgt aus:

create table tblAnswer (
userID int not null,
question1 int,
question2 int,
question3 int,
primary key (questionID)
)

create table tblOption1 (
optionID int not null,
optionText varchar(50),
primary key (optionID)
);

create table tblOption2 (
optionID int not null,
optionText varchar(50),
primary key (optionID)
);

create table tblOption2 (
optionID int not null,
optionText varchar(50),
primary key (optionID)
);

Aus diesen Tabellen wollte ich eine Liste aller übereinstimmenden optionText-Felder für alle drei Fragen erstellen (d.h. ich wollte die Fragen question1 bis question3 den entsprechenden Options-IDs tblOption1 bis tblOption3 zuordnen).

Das SQL dafür ist relativ einfach:

SELECT tblOption1.optionText,tblOption2.optionText,tblOption3.optionText FROM
tblAnswer,tblOption1,tblOption2,tblOption3 WHERE
tblAnswer.question1=tblOption1.optionID AND
tblAnswer.question2=tblOption2.optionID AND
tblAnswer.question3=tblOption3.optionID

Damit werden die Tabellen einfach verknüpft. Auf diese Weise haben Sie Zugriff auf die Felder tblOption1.optionText, tblOption2.optionText usw. - aber im Fenster Datenbindungen werden alle diese Felder zu drei Kopien von optionText. Wählt man eines dieser optionText-Felder aus den Bindungen aus, erhält man immer denselben Wert.

Man findet häufig Tabellen mit mehreren gleich benannten Feldern. Wenn Sie mit alten Daten arbeiten, wird das Problem dadurch verstärkt, dass es nicht möglich ist, den Datenbankentwurf zu ändern. Falls Sie die Kontrolle über Ihre Daten haben, ist die einfachste Lösung, sicherzustellen, dass alle Ihre Felder eindeutige Namen haben - zumindest in den Tabellen, die Sie irgendwie miteinander verknüpfen wollen.

Wenn Sie an existierende Daten gebunden sind, könnten Sie die Feldnamen in MySQL dynamisch ändern. Aus Kapitel 18 wissen Sie, dass Sie in einer Abfrage as verwenden können, um einen Ausdruck in einer Variablen abzulegen und ihn innerhalb einer Abfrage als Feld bereitzustellen.

Legen Sie beispielsweise die folgende einfache Tabelle auf Ihrem System an und füllen Sie sie mit Beispieldaten:

create table tblTest (
field1 int,
field2 int
);

insert into tblTest values (1,3);
insert into tblTest values (2,4);
insert into tblTest values (3,5);

Anschließend führen Sie eine Abfrage für diese Daten aus - eine Standardabfrage, die die normalen Datensatzgruppen-Titel anzeigt:

mysql> select * from tblTest;
+--------+--------+
| field1 | field2 |
+--------+--------+
| 1 | 3 |
| 2 | 4 |
| 3 | 5 |
+--------+--------+
3 rows in set (0.00 sec)

Jetzt verwenden Sie eine Abfrage, die die Felder dynamisch während der Verwendung umbenennt:

mysql> SELECT field1 as 'myfield1',field2 as 'myfield2' FROM tblTest;
+----------+----------+
| myfield1 | myfield2 |
+----------+----------+
| 1 | 3 |
| 2 | 4 |
| 3 | 5 |
+----------+----------+
3 rows in set (0.00 sec)

Die eigentlichen Feldnamen in der Datenbank sind field1 und field2, aber durch die Verwendung des Schlüsselworts as können wir sie in der Datensatzgruppe als myfield1 und myfield2 bereitstellen.

Länge und Komplexität von Abfragen

Ein weiterer Stolperstein beim Anlegen der erweiterten Abfragen ist das seltsame Verhalten der UltraDev-Anzeigen bei der Arbeit mit erweiterten Abfragen sowie Abfragen, die komplexe SQL-Techniken einsetzen. Es ist müßig, eine Viertelstunde eine Abfrage im erweiterten Abfrage-Builder einzugeben und sie zu speichern, um nach ein paar Minuten zurückzukommen und festzustellen, dass sie bis zur Unkenntlichkeit zerlegt wurde. Leider passiert das in UltraDev nicht selten.

Das erste Problem scheint die Länge der Abfrage zu sein. Es kam vor, dass ich arglos SQL in das Abfragefeld eingab, um irgendwann festzustellen, dass ich nicht mehr an das Ende der Abfrage blättern oder meinen Cursor nicht mehr korrekt positionieren konnte. Das mag vielleicht ein Fehler in der aktuellen UltraDev-Version sein, aber es wird damit extrem schwierig, den erweiterten Abfrage-Builder ernst zu nehmen.

Ich empfehle Ihnen, Ihre Abfragen in einem Texteditor außerhalb der UltraDev- Umgebung zu schreiben und sie in das Abfragefenster einzufügen, wenn Sie sie benutzen wollen. Dieser Ansatz hat zwei Vorteile. Erstens haben Sie eine Kopie der Abfrage, falls irgend etwas schief geht. Zweitens scheint das Eintippen langer Abfragen in UltraDev das Problem mit den langen Abfragen zu umgehen. Der erweiterte Abfrage-Builder erspart ja wirklich nur ein paar kleine Handgriffe, und nachdem Sie erst einmal mit SQL vertraut sind, stellt er eigentlich keine größere Zeitersparnis mehr dar.

Falls Sie Ihre Abfragen in einem externen Editor speichern, achten Sie darauf, dass es sich dabei um einen reinen Texteditor handelt. Wenn Sie eine herkömmliche Textverarbeitung verwenden, wie beispielsweise MS Word oder WordPerfect, könnten Sie damit unbeabsichtigt Steuerzeichen in Ihr Abfragefenster einfügen. Sie sind in der vom Abfrage-Builder verwendeten Mono-Schrift schwer zu erkennen und können Ihnen Kopfzerbrechen bereiten, wenn Ihre perfekte Abfrage ständig irgendwelche Fehler produziert.

Ähnlich schwierig ist das Problem der Komplexität. UltraDev hat in seiner aktuellen Version offensichtlich Probleme, erweiterte Abfragen zu erkennen, nachdem sie in das System eingegeben wurden. Wieder finden Sie in Kapitel 18 eines der Beispiele, wie Dinge in einer Abfrage schiefgehen können. Teilweise wird dies dadurch verursacht, wie UltraDev Daten speichert. Statt Informationen in einer separaten Datei abzulegen und sie der Seite zuzuordnen, verwendet UltraDev die eigentliche Seite, um Serververhalten und Datenbindungen zu verwalten.

Das bedeutet für den Entwickler, dass es ganz einfach ist, Dateien von einem System auf ein anderes zu übertragen. Sie können sogar einfachen eingebetteten Code in das Dokument einfügen und ihn in der Datenbindungen-Palette anzeigen lassen. Um diese Funktionalität bereitzustellen, muss UltraDev diese Seite auswerten und ermitteln, bei welchem Code es sich um eine Serververhaltensweise, um eine Abfrage usw. handelt. Wie Sie sich vorstellen können, ist dafür eine komplexe Mustersuche nötig. Wenn Sie den Code manuell verändern, sodass UltraDev ihn nicht mehr in seine Musterschablonen einpassen kann, kommt es nicht mehr damit zurecht. Manchmal kann das schon bei der Eingabe komplexer Abfrageelemente passieren.

Am besten kommt man mit diesem Problem mit den langen und komplexen Abfragen zurecht, indem man eine SQL-Ansicht verwendet, um das Ganze zu vereinfachen. Eine Ansicht stellt man sich am besten als virtuelle Tabelle vor. Sie ist das Ergebnis einer Standard-SQL-Abfrage, steht aber zur Verfügung, als handelte es sich dabei um eine eigene Einheit. Weitere Informationen über Ansichten finden Sie in Kapitel 12, »Komplexe Datenbankabfragen«.

Ansichten werden leider in der aktuellen Version von MySQL nicht unterstützt. Sie stehen auf der Liste der bevorstehenden Wohltaten, aber noch gibt es sie nicht. Die meisten kommerziellen Datenbanken unterstützen Ansichten, aber auch einige nicht-kommerzielle Produkte, wie beispielsweise PostgreSQL. Lesen Sie in der Dokumentation Ihrer Datenbank nach, ob sie unterstützt werden.

Mehrere Primärschlüssel

UltraDev bietet in vielen seiner Serververhalten keine Unterstützung der Verwendung mehrerer Primärschlüssel. Das ist normalerweise nur eine Frage der Semantik. Sie können UltraDev zwingen, Datensätze in eine Untermenge einer Tabelle einzufügen oder daraus zu löschen, indem Sie eine Abfrage definieren, die Datensätze basierend auf den entsprechenden Schlüsseln auswählt. Leider kann die Software momentan nicht mehrere Primärschlüssel verarbeiten. Auch das ist ein Beispiel dafür, dass eine Ansicht extrem praktisch sein kann. Mithilfe einer Ansicht begrenzen Sie die Datenmenge, die UltraDev zur Verfügung gestellt wird, und es arbeitet nur mit den in der Ansicht enthaltenen Daten.

Wenn Sie Ansichten auf diese Weise verwenden, ergeben sich in einigen Datenbanksystemen Probleme. Erstens muss Ihr Datenbanksystem Ansichten unterstützen, und zweitens muss es erlauben, Daten in eine Ansicht einzufügen. Auch hier kann Ihnen nur Ihre Datenbankdokumentation weiterhelfen.

Halten Sie die Dinge möglichst einfach

Wenn Sie Programmierer sind, versuchen Sie möglicherweise, einige der von UltraDev gebotenen Funktionen in herkömmlichen Programmkonstrukten einzusetzen. Betrachten Sie beispielsweise wiederholte Bereiche. Wenn Sie bereits über Programmiererfahrung verfügen, werden Sie darin eine Art Schleife erkennen.

Ein gebräuchlicher Trick in der Programmierung sind verschachtelte Schleifen. Beispielsweise könnten Sie ganz einfach manuell zwei verschachtelte Schleifen programmieren, die mehrere Fotos in einem tabellarischen Format anordnen. Die eine Schleife würde die Spalten mit den Zellen einrichten, während die andere alle Zeilen durchläuft. Mithilfe von UltraDev können Sie zwei Schleifen verschachteln, aber betrachten wir doch einmal, wie diese beiden Schleifen arbeiten:

<%
Dim Repeat1__numRows
Repeat1__numRows = 3
Dim Repeat1__index
Repeat1__index = 0
rsTest_numRows = rsTest_numRows + Repeat1__numRows
%><%
Dim Repeat2__numRows
Repeat2__numRows = 10
Dim Repeat2__index
Repeat2__index = 0
rsTest_numRows = rsTest_numRows + Repeat2__numRows
%>

Der erste Teil des Programms richtet die Schleifenbegrenzungen ein. Die erste Schleife soll dreimal durchlaufen werden, die zweite zehnmal.

<%
While ((Repeat2__numRows <> 0) AND (NOT rsTest.EOF))
%><%
While ((Repeat1__numRows <> 0) AND (NOT rsTest.EOF))
%><%=(rsTest.Fields.Item("featureID").Value)%>
<%=(rsTest.Fields.Item("optionID").Value)%>
<%
Repeat1__index=Repeat1__index+1
Repeat1__numRows=Repeat1__numRows-1
rsTest.MoveNext()
Wend
%><%
Repeat2__index=Repeat2__index+1
Repeat2__numRows=Repeat2__numRows-1
rsTest.MoveNext()
Wend
%>

Hier sind die beiden Schleifen verschachtelt. Leider gibt es ein kleines Problem. Für beide Schleifen wird der Zähler (numRows) an derselben Stelle initialisiert. Nachdem der Durchlauf der ersten Schleife beendet ist, kann sie nicht erneut durchlaufen werden, weil die Schleifenvariable ihre Obergrenze bereits erreicht hat. Und Sie können aufgrund der Verarbeitung dieser Verhalten in UltraDev nicht einfach andere Programmiererfahrungen anwenden. Erledigen Sie in UltraDev, was möglich ist, und machen Sie den Rest manuell.

21.4 Testen

Die wichtigste Aufgabe bei allen Applikationen ist das Testen. Weil der gesamte UltraDev- Code dynamisch erzeugt wird, müssen Sie wenig Bedenken haben, dass programmtechnisch etwas schiefgehen könnte. Wenn Sie dem System jedoch eigenen Code hinzufügen, müssen Sie diesen auch debuggen.

Was jedoch schiefgehen kann, sind die Abfragen, die Sie für das System definieren. Wenn wir davon ausgehen, dass in UltraDev alles korrekt ist, kann die Fehlersuche darauf begrenzt werden, was wir, die Benutzer, dem Programm bereitstellen - also das SQL und die Datenbankdefinitionen. Betrachten wir einige Situationen, in denen die Ergebnisse nicht wie erwartet erscheinen, und welche Schritte Sie ergreifen können, um Ihr System vor der Auslieferung zu testen.

Prüfung auf NULL-Werte

Bei den Datenbanken, die wir in diesem Buch entwickelt haben, haben Sie vielleicht bemerkt, dass einige Felder als not null definiert wurden - das gilt immer für die Primärschlüsselfelder. Die MySQL-Datenbank erzwingt, das Attribut not null für den Primärschlüssel anzugeben, aber in einigen anderen Systemen ist das nicht der Fall. Beachten Sie, dass implizit vorausgesetzt wird, dass Ihre Primärschlüssel nicht null sind, auch wenn sie nicht explizit entsprechend definiert wurden.

Was bedeutet das für Sie? Jedes Feld, das als not null definiert ist, muss einen Wert enthalten. Wenn Sie noch nie ein datenbankgestütztes System entwickelt haben, kann das etwas verwirrend sein. Betrachten Sie beispielsweise die folgende Tabelle:

create table tblUserInfo (
userID int not null,
username varchar(80) not null,
password varchar(80) not null,
email varchar(250) not null,
primary key (userID);
)

Um Daten in dieser Tabelle ablegen zu können, muss jeder der Feldwerte definiert werden. Wenn Sie ein Formular erstellen, das Daten in diese Tabelle sendet, müssen Sie sicherstellen, dass alle Felder ausgefüllt sind. Sie können nicht erwarten, dass UltraDev eine Meldung anzeigt, in der es darauf hinweist, dass alle Felder des Formulars ausgefüllt werden müssen. Statt dessen erhält der Benutzer eine Fehlermeldung vom Server, die auf das Problem hinweist. Sie sollten dieses Problem abfangen, bevor es auftritt.

Am einfachsten verwenden Sie dafür die Verhaltensweise Formular auswerten, wie in Abbildung 21.11 gezeigt (keine Serververhaltensweise):

  1. Legen Sie ein Formular an, das Daten an die Datenbank sendet.
  2. Legen Sie fest, welche Felder Werte enthalten müssen, und notieren Sie diese.
  3. Öffnen Sie die Verhaltenspalette.
  4. Klicken Sie auf das Plussymbol (+), und wählen Sie Formular auswerten.
  5. Wählen Sie ein Feld aus der Liste, für das Sie die Eingabe eines Wertes erzwingen wollen.
  6. Geben Sie an, ob das Feld nur ausgefüllt sein muss oder ob ein bestimmter Datentyp dafür angegeben werden muss (Zahl, E-Mail-Adresse oder Zahlenbereich).
  7. Klicken Sie auf OK.

    Abbildung 21.11:  Wählen Sie die Felder, für die die Eingabe eines Wertes erzwungen werden soll.

Durch die Verwendung einer Formularauswertung wird erzwungen, dass bestimmte Formularelemente einen Wert erhalten, bevor sie den Serververhalten zum Einfügen oder Aktualisieren übergeben werden. Damit werden Probleme vermieden, dass ein Benutzer Formulare mit leeren Feldern sendet, die in der Datenbank einen Wert aufweisen müssen.

Überprüfen Sie Ihre Formulare immer darauf, was passiert, wenn eines der Felder für die Benutzereingaben leer übergeben wird. Das ist der Extremfall für das Testen auf null- Werte und sollte etwaige Probleme sofort aufdecken.

Überprüfung auf bereits verwendete Daten

Der zweite Problemtyp, der für die Serververhaltensweisen auftreten kann, ist die Übergabe doppelter Daten in Formularen. Sie können keine Einfügen-Verhalten verwenden, um existierende Daten in der Datenbank zu ersetzen. Das ist vielleicht zwar offensichtlich, stellt aber ein potenzielles Problem dar, wenn ein System Datensätze und Abfragen abhängig von Benutzereingaben formuliert. In der letzten Woche, in der die verschiedenen Projekte vorgestellt wurden, gab es einige Situationen, in denen der Benutzer ein eigenes Konto auf dem System einrichten konnte.

Beim Anlegen dieser Systeme musste der Benutzer die Daten, die nicht doppelt vorhanden sein dürfen (wie beispielsweise der verwendete Benutzername), separat eingeben. Durch diese phasenweise Registrierung konnten wir einen Test auf bereits existierende Daten durchführen, bevor ein Problem daraus wurde. Wenn wir versuchen, alle Daten gleichzeitig einzugeben und ein Konflikt mit bereits existierenden Daten auftaucht, erzeugt der Datenbankserver einen Fehler und die Web-Applikation kann abstürzen.

Selbst wenn Sie glauben, dieses Problem beträfe Sie nicht, sollten Sie Ihre Applikation immer daraufhin prüfen, wie sie reagiert, wenn mehrere identische Datensätze eingegeben werden.

Überprüfen maximaler Längen

Wie kommt Ihr Datenbankserver mit Werten zurecht, die die maximale Länge überschreiten? Werden sie abgeschnitten? Wird ein Fehler erzeugt? Was passiert? Ohne Testen kann man keine Aussagen darüber treffen. MySQL beispielsweise kürzt die Daten, wenn sie länger als das bereitgestellte Feld sind. Das ist einer der Extremfälle, der überprüft werden muss.

Sie begrenzen die Datenmenge, die ein Eingabefeld aufnehmen kann, indem Sie das Attribut max chars in der Eigenschaftenpalette entsprechend setzen. Leider funktioniert das nur für Eingabefelder mit einer einzigen Zeile. Mehrzeilige Eingabefelder (Textbereiche) können nicht begrenzt werden.

Wenn Sie eine grundlegende Teststrategie nach diesen drei Bedingungen durchführen, werden Sie feststellen, dass in Ihren Web-Applikationen alles mögliche schiefgehen kann - und das auch tut. Insgesamt kann man sagen, jede Applikation kann mehrere Stresstests durchführen:

Selbst wenn Sie glauben zu wissen, wie Ihre Applikation auf diese Bedingungen reagiert, sollten Sie sie testen. Fehler sind schnell gemacht - und Sie sollten später nicht dafür büßen.

Einige Einschränkungen, die Sie erzwingen müssen, sind für den Benutzer vielleicht nicht ganz offensichtlich. Informieren Sie ihn über etwaige Einschränkungen im Formular, die für die Felder, die Größenvorgaben usw. im Dokument gelten.

21.5 Weitere Hilfestellungen

Im Internet finden Sie zahlreiche Informationen, die Ihnen die Problemlösung sehr viel einfacher machen können. Dieses Buch konnte einfach nicht detailliert auf die ASP-, JSP- , CFML- und SQL-Programmierung eingehen - das hätte den Rahmen gesprengt. Ich habe versucht, möglichst viele Informationen bereitzustellen, aber manchmal brauchen Sie einfach mehr:

21.6 Zusammenfassung

Das war's! Dieses Kapitel hat die letzte Woche mit einem Ausblick auf ein paar Dinge abgeschossen, die bei der Entwicklung Ihrer Website zu Problemen führen könnten und wie Sie sie verhindern können.

Wenn Sie eigene Applikationen und Projekte entwickeln, sollten Sie immer beachten, dass UltraDev nur ein Werkzeug ist und seine Einschränkungen hat. Den größten Nutzen ziehen Sie aus dieser Software, indem Sie möglichst viel über Ihren Datenbankserver und die UltraDev-Umgebung wissen. In ihrer Kombination machen diese beiden Komponenten fast alles möglich.

Es wird nicht immer alles ganz einfach sein, aber ich hoffe, die Sonderfälle, auf die ich im Text immer wieder hingewiesen habe, bereiten Sie auf mögliche Probleme vor, die bei der Verwendung von Serververhalten oder der Erweiterung des Codes zusätzlich zu den von UltraDev angebotenen Funktionen auftreten können.

Wenn Sie Fragen zu den Projekten in diesem Buch haben, wenden Sie sich einfach an mich. Ich beantworte sie gerne. Schicken Sie mir eine E-Mail: jray@poisontooth.com.

Viel Glück, viel Spaß und spielen Sie schön!

21.7 Fragen und Antworten

Frage:
Wie gehen Sie bei der Entwicklung am besten vor, wenn Sie die Probleme in Netscape auffangen wollen?

Antwort:
Entwickeln Sie für das Sorgenkind (und das ist momentan Netscape), und probieren Sie alles überall aus. Wenn Sie für den Browser mit den meisten Problemen entwickeln, müssen Sie Ihren Code später nicht anpassen.

Frage:
Warum werden Ebenen in Netscape durch JavaScript gesteuert?

Antwort:
Ich bin mir nicht sicher. Die Ebenen verhalten sich im Internet Explorer auch dann problemlos, wenn dort das JavaScript deaktiviert ist.

Frage:
Gibt es eine definitive Methode, eine Abfrage zu erkennen, die UltraDev verwirren wird?

Antwort:
Verwenden Sie keine Abfragen, die Tag-Bezeichner für die verwendete eingebettete Sprache enthalten. Beispielsweise ist es gefährlich, mit <%>-HTML- Tags in einer SQL-Abfrage zu vergleichen.

Frage:
Wenn ich das Dokument teste wie hier beschrieben, ist es dann perfekt?

Antwort:
Vielleicht - vielleicht aber auch nicht! Das ist von Ihrer Datenbank, den verwendeten Serververhalten und Ihrem speziellen Projekt abhängig. Ich kann Ihnen nur Hinweise geben, die Sie in die richtige Richtung führen sollen. Der Rest bleibt Ihnen überlassen.

21.8 Workshop

Der Workshop dient dazu, den gelesenen Stoff mithilfe von gezielten Fragen und Übungen zu vertiefen. Die Antworten finden Sie in Anhang A, »Quiz-Antworten«.

Quiz

  1. Was passiert, wenn Sie versuchen, eine Tabelle mit fehlendem Ende-Tag in Netscape anzuzeigen?
  2. Welches Funktionsmerkmal von CSS sollte auf jeden Fall vermieden werden?
  3. Wie können Sie verhindern, dass in einem Eingabeformular ein not null-Fehler auftritt?
  4. Wie können Sie die Eingabemenge begrenzen, sodass die Kapazität der Datenbank nicht überschritten wird?

Übung

Die einzige Übung, die ich Ihnen hier noch empfehlen kann, ist UltraDev für Ihre eigenen Projekte und Datenbankentwürfe einzusetzen. Achten Sie dabei auf die möglichen Probleme, die heute angesprochen wurden. Fangen Sie einfach an!



vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisFeedbackKapitelanfangnächstes Kapitel


© Markt+Technik Verlag, ein Imprint der Pearson Education Deutschland GmbH