Enver, Karsten, Leszek, Marko, Oliver, René, Saad, Slav, Sebastian, Thomas F., Thomas S., Tobias, Tomasz
Langwierige Sichtung verschiedenster Buttons ergab, daß keine der auf kommerziellen Web-Seiten verwendeten Buttons unsere Ansprüche Erfüllen. Dementsprechend werden wir das Design selbst übernehmen müssen. Für einen solchen Task bietet sich Ergün an.
Thomas S. ist nach seinen Versuchen mit html überzeugt, daß er Dokumentwart bleiben möchte. Weiterhin sind dementsprechend alle zur Veröffentlichung bestimmten Dokumente an ihn (sliwa@inf.fu-berlin.de) zu senden. Er wäre sehr erfreut, wenn diese bei ihm schon in html-Form ankämen. Deshalb sind an dieser Stelle noch einmal ein paar grundlegende Dinge zu html und ein paar Tips aufgelistet, die wahrscheinlich sowieso schon allen bekannt sind:
Das Grundgerüst einer html-Datei sieht so aus:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN";
"http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<title>Titel des Textes</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8559-1">
</head>
<body>
</body>
</html>
Hilfreich für unsere Zwecke können folgende Informationen sein:
Alles weitere, was zu Formularen und Buttons referiert wurde, wird demnächst von Thomas S. ins Netz gestellt. Außerdem gibt es einen Hyperlink zu selfhtml: www.teamone.de.
Weiterhin stellt sich die Frage, ob unsere dynamischen URLs überhaupt direkt in html generiert werden sollen, oder ob man xml verwenden sollte. Und html-style-sheets erstellen. Das hätte den Vorteil, daß man je nach client problemlos zum Beispiel auch wml-Seiten generieren könnte. Möglicherweise passt xml aber nicht zu der uns vorgegebenen Technologie. Task: Roman, René und Sebastian erstellen zum nächsten Tutoriumstermin mit Hilfe des architectural spike eine Demonstration, untersuchen, inwieweit xml/xsl mit JDBC kompatibel ist und referieren über xsl. Tobias hat den Task übernommen, über xml zu referieren. Auf jeden Fall sollte bedacht werden, daß das Konzept von JDBC gerade ist, plattformunabhängig zu sein. Wenn wir xml benutzen, beschränken wir unsere Unabhängigkeit insofern, daß wir nur noch Datenbanken benutzen können, für die es xml-Treiber (heißt das wirklich so?) gibt. Bei Oracle ist das zwar wohl standardmäßig der Fall, aber wir wollen unser Produkt ja auch unter die GPL stellen und anderen die Benutzung leichtmachen.
Das Protokoll für sichere Verbindungen heißt "https://...". Ob eine solche Verbindung sich mit unserer Technologie verträgt, muß geprüft werden. Diesen Task haben Slav und Thomas F. übernommen.
Mehrere Prozesse laufen auf einem Computer nicht wirklich gleichzeitig. Jeder einzelne Prozeß (Thread) bekommt jeweils eine bestimmte Zeitspanne zugewiesen, in der er abgearbeitet wird. So kann es passieren, daß ein Prozeß mitten in die Laufzeit eines anderen hineingerät und für diesen wichtige Daten verändert. Um das zu verhindern, haben Java-Objekte ein "Schloß" (Lock), das der erste Prozeß, der auf dem Objekt läuft, zuschließt. Solange, bis er wieder aufschließt, darf kein anderer Prozeß auf diesem Objekt arbeiten. Realisiert ist das in Java durch das Codewort synchronized. Das kann man entweder in den Kopf der Methode schreiben oder in den Rumpf:
Kopf der Methode:
public synchronized void m(){ }
Rumpf:
public void n(){
synchronized(this){ }
}
Allerdings meinten die Experten, auch bei Java Server Pages gäbe es eine Funktion, um den Zugriff zu sperren. Welche Methode für unsere Zwecke wann am besten geeignet ist, wird in einem späteren Task zu eruieren sein.
siehe Dokument von Karsten
siehe Dokument von Oliver
Wir wollen keine Frames benutzen, weil dadurch unüberschaubarer würde, welche Elemente unseres Shops der Kunde gerade sieht, welche nicht und welche er aus Versehen wegklickt etc. Der Warenkorb soll einfach mit jeder dynamisch generierten Seite in deren oberem Teil neu erzeugt werden.
Wie die Produkte gespeichert werden sollen, ist noch nicht ganz klar. Auf jeden Fall wird jeder Produkt einen Namen, eine ID-Nummer, eine Beschreibung und einen Herstellerverweis haben. Darüber hinaus soll jedes Produkt in eine oder mehrere Kategorien gehören. Die Kategorien sollen hierarchisch geordnet sein in Ober- und Unterkategorien in mehreren Ebenen. Da die Zahl der Kategorien, in denen eine Ware ist, nicht begrenzt ist, wäre es unklug, in jedem Datensatz statisch Platz für diese zu reservieren. Statt dessen könnte man eine weitere Liste benutzen, in der jedes Produkt mit jeder seiner Kategorien (oder besser: die IDs der Produkte und Kategorien) genau einmal eingetragen wäre, wodurch eine Mehrfachzuordnung in beide Richtungen möglich ist.
Task: René kümmert sich darum, daß unser Tabellenmodell ausgearbeitet wird für Einträge wie: Kunde, Artikel, Lieferort, Kategorie, Artikel-to-Kategorie.
Unser Web-Shop wird auf jedenfall eine Suchfunktion haben. Auch darauf, daß diese nicht zu aufwendig wird, sollte man bei der Planung der Datenstrukturen achten.
Kundenprofile sollen mit Namen und Passwörtern gespeichert werden können. Ob ein Kundenprofil aber notwendige voraussetzung schon zum surfen auf unserer Page ist, darüber ist noch zu streiten. Cookies könnten Kundenerkennung für diese komfortabler machen. Den Task, die Sicherheit von Cookies zu prüfen, haben Thomas F. und Slav übernommen.
| Person | Task | geplante Stunden | verbrauchte Stunden |
|---|---|---|---|
| Thomas S. | Verschriftlichung des Referats | 2 | 0.5 |
| (Ständig:) Dokumentwart | 2 | 3 | |
| Roman | xsl-Referat und Demonstration | 8 | 9 |
| René, Sebastian | xsl-Referat, Kompatibilität mit JDBC | 1,? | 1,8 |
| (Ständig:) JDBC-Experten | mehrwöchig | ||
| René | Tabellenmodell | 2 | 2 |
| Slav, Thomas F. | Kompatibilität von ssl und unserer Tech. | 3,3 | 3,3 |
| Referat über Session-Management | |||
| Prüfung der Sicherheit von cookies | |||
| Tobias | xml-Referat | 5 | 6 |
| Tomasz, Leszek | (Ständig:) Experten für Java-Servlets | mehrwöchig | 2,4 |
| Oliver | Protokoll | 3 | 4 |
| Ergün, Marco | Zustandsdiagramm | 3,3 | 3,3 |