Hartes Stück Einarbeitung für den 1. Prototyp

Also die Inter-Servlet-Kommunikation ist schon ein anspruchsvolles Thema. Die letzten 2 Tage habe ich größtenteils damit verbracht, eben damit vertraut zu werden. Der 1. Prototyp soll 2 der 3 Use-Cases realisieren bzw. zumindest simulieren.

Ich habe am Anfang meinen Schwerpunkt, wie wirs im Meeting besprochen haben, auf die Basisfunktionalität beschränkt, das heißt: Login, Registrierung, Session-Handling. Im Großen und Ganzen kann ich sagen, dass das nun funktioniert – und zwar, und deswegen war es so anspruchsvoll, unter Einhaltung der Trennung von Code und Ansicht.

Das machte Arbeitsteilung möglich, insofern die Conny das Designen der JSPs und das Erstellen eines CSS übernommen hat und ich mich auf die Programmlogik gestürzt habe. Das sagt sich leichter, als man denkt. Beim Entwickeln der Programmlogik muss man zumindest wissen, wie man dann die Daten in die JSP bringt, ohne zuviel Code zu schreiben.

Die Antwort: JSTL (Java Standard Tag Libraries), Expression Language sowie Controller-Servlets. Es hat einiges an Versuche gekostet, bis ich draufgekommen bin, dass die Controller am Besten Servlets sein sollten, denn damit lassen sich Anfragen leicht verarbeiten. Man schickt z.B. ein Formular mit <form action=“Servlet“ method=“post“> an ein Servlet. Die Verarbeitung im Servlet erfolgt über die Klasse HttpRequest, wo die Formulardaten gekapselt und über getParameter(String name) verfügbar sind.

Man kann dort ganz normal Java-Code-mäßig abarbeiten und das Ergebnis dann entweder an ein anderes Servlet weiterleiten oder aber an ein JSP, wo dann über JSTL die Ergebnisse ausgelesen werden. Das hört sich jetzt leicht an, bis man das alles verinnerlicht hat, vergeht aber eine Weile. Es ist in einem Servlet außerdem möglich, Methoden von anderen Servlets oder normalen Java-Klassen aufzurufen, und sogar die HttpRequest und HttpResponse-Objekte zu verändern, was ganz parkatisch sein kann.

.::WAS IST NOCH ZU TUN::.

Damites nicht wieder zu weitschweifig wird, gehe ich konkret darauf ein, was für das Erfüllen der Anforderungen des Prototyp1 noch fehlt:

Grunsätzlich: Was wir nicht mehr implementieren können, müssen wir wenigstens schön im JSP darstellen = faken.

• Use-Case: Profil bearbeiten / Qualifikation hinzufügen:
  - Im editprofile.jsp den String „Hier stehen dann die Qualifikationen“ mit ein paar Beispielhaften Qualifikationen versehen. Die addquali.jsp wäre gut wenn man die auch noch stylen könnte, damit man das Pattern-Prinzip besser erklären kann.
  - Implementiert: 10% (nämlich: Profil wird mit Namen und Beziehungen angezeigt) , Gestylt: 65%
• Menü:
  - Überall wo das Menü vorkommt, die Buttons verlinken, das man beim Herzeigen schön durchnavigieren kann.
  - Eventuell das Menü ausklinken in eine eigene menu.jsp – die man dann leicht überall, wo man es braucht, dazuladen kann. page include wenn, ich mich recht erinnere.
  - die einzelnen Links+Buttons dürfen nur dargestellt werden, wenn es für den eingeloggeten (oder nicht eingeloggten) Sklaven/herren/Gott sinnvoll ist. Vielleicht kann sich dazu mal jemand etwas überlegen, also für alle 3 Usergruppen die möglichen Fälle zusammenschreiben und dann im googleCode-Wiki veröffentlichen, damit wir das einsehen/verändern können.
• Use-Case: Beziehungsgraphen anzeigen:
  - da hätten wir die relations.jsp, die eigentlich ausreicht für Iteration1 ist.
  - Implementierung wird aufwändiger, das dürfte dann die Krone unseres Projektes sein, gehört also ans Filmende.
  - implementiert: 0%, gestylt: werden-wir-sehen%
• Use-Case: Bewertungen hinzufügen (requires: Beziehungen hinzufügen)
  - Das wäre halt toll, wenn man das schon implementieren könnte. Also falls jemand ust hat, kann er mal versuchen, ähnlcih wie ich es bei der Registrierung gemacht habe, fürs Beziehungs-Insert so einen Pathweg durch die nötigen Controller zu schreiben.
  - Von wo aus soll man Beziehungen/Bewertugnen hinzufügen können? Direkt von der Profilpage aus, wenn es ein fremdes Profil ist? Und für Bewertungen: Wenn der Herr/Sklave mit mir in einem Arbeitsverhältnis steht? Das ist wenig Programmieraufwand und lässt sich im Zusammenspiel mit dem Sessions-User-Objekt und der Profilanfrage über JSTSL+EL realisieren.
  - Auf jeden Fall sollten wir für Dienstag etwas anschaubares (Buttons oder eigene JSPs) in Puncto Beziehung + Bewertung herzeigen können.
• Eigene / Fremde Profilseite
  _ Zur Zeit hab ich nurmal die Beziehungen vom Typ A (Arbeitsverhältnis) ausgelesen – mit den anderen Typen gehts aber genauso (da braucht man gar ncihts mehre programmieren, sondern einfach nur die JSTL+EL-Tags entsprechend einfügen wie ichs für A-Typen gemacht habe.
  - Zur Zeit liegt die Implementation im Ctrl_BeziehungsAbfrage, wobei die Ctrl_Profilabfrage später die gesamte Aufgabe übernehmen soll: Auslesen der Profilinformationen, die man darstellen möchte und unterscheiden zwischen eigener und fremder Profilseite, sodass man unterschiedliche Buttons plazieren kann. Die Ctrl_Profilabfrage soll dabei auf die anderen Abfragetypen zugreifen und die Ergebnisse nur noch sammeln. Bei der eigenen Profilabfrage soll das Session-User-Objekt davon profitieren, indem Qualifikationen und (jetzt schon) Beziehungen im User-Objekt verlinkt werden, sodass man bei Profiländerung etc. leicht darauf zugreifen kann.
  - Was eben noch fehlt sind Qualifikationen und die anderen Dinge, die man noch anzeigen will.
  _ Implemenierung: 35-40%, Darstellung: 60%
  - Dem Problem der verschiedenen Auflösungen und unterschiedlichen Darstellungen in versch. Browsern sollten wir auch Beachtung schenken.

.::FÜR SPÄTER::.

• Use-Cases für Treffpunkt überlegen?
  - Was ist der Treffpunkt und was kann man da machen?
• Nachrichten-Handling
• Firmen-Registrierung, Zusammenhänge zwischen Herr + Firma. Sollen
  - solche Zshg. auf der Profilseite der Firma und d. Herrn dargestellt werden?
• Log4j-File-Logging zum Laufen bringen (so kann man auch gut debuggen)
• Iteratoren (oder besser: Colections) für User, die gerade Online sind (kann man evt. im Treffpunkt darstellen) Dafür gibt es das Scope(=Gültigkeitsbereich) ServletContext, wo man solche Dinge ablegen kann.
• Braucht man sonst noch solche Iteratoren oder /Collections? Hier mal zum Konstrukt Collection: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collection.html
• Ah – GANZ WICHTIG: SUCHE von Usern, Beziehungen, Qualifikationen, Arbeitsstellen, etc.
  - Macht man das alles über SQL-Abfragen oder hält man sich eine Art Cache in Form von Iteratoren im Servlet-Context

Also fad wird uns sicher ned. ^^

Gn8!