Month: October 2007

Betr. JPA

Flattr this!

Bisher hat der Umbau der vorhanden Klassen hinsichtlich der Nutzung von JPA promblemloser funktioniert als gedacht. Bisher versuche ich halt nur, das User Objekt aus der Tabelle User auszulesen.
Letztendlich muss ich aber mein bisheriges Konzept soweit umstellen, dass ich die Validierung von Eingaben aus der User Klasse in eine sperate Application Klasse auslagere.
Allen anschein nach klappt das Laden der User Klasse mit Hilfe eines EntityManagers fehlerlos, allerdings scheint es da an einigen Stellen noch zu Problemen zu kommen.
Nach der Überarbeitung sieht die User Klasse nun wie folgt aus:

Die Methoden isLogin and isWithName werden dann wahrscheinlich auch ausgelagert werden müssen. Das Attribut error wird wohl einer Fehlerbehandlungsklasse weichen und in Folge dessen als Sammlung von Exceptions implimentiert werden.
Als Primary Key habe ich mich jetzt für das Attribut Name entschieden, da es scheinbar nur möglich ist, die find Methode des EntityManagers anhand eines Primary keys zu nutzen und ich aller Vorraussicht nach eher nach Namen als nach IDs suchen werde.
Das Laden des Objektes passiert nun in einer neuen Klasse Application:

Leider wird mir bei der Methode showID() eine NullPointerException geworfen, die ich noch nicht ganz nachvollziehen kann :-/. Letztendlich wird mir JPA aber denke ich eine Menge an Arbeit abnehmen, sobald es erstmal stabil läuft.
Bei Sun habe ich allerdings noch ein Beispiel gefunden, was wie perfekt für mich zu sein scheint, weil es schon ziemlich viel von dem behandelt, was ich eigentlich machen möchte [1]

Was bisher so geschieht…

Flattr this!

Moin…
Ich wollte mal wieder ein wenig Feedback geben, woran ich bisher so sitze…
Letztendlich bin ich endlich mit einer schönen Datenbankklasse ausgestattet, die mir auch die Dinge bietet, auf die ich angewiesen sein werde – ob da jetzt noch etwas dazu kommt, wird sich zeigen, aber erstmal reicht mir das, was bisher vorhanden ist. Zudem bin ich auf ein paar Besonderheiten von JSP/Java und MySQL gestossen, die in meinen Augen recht unlogisch sind, aber nunja, vielleicht gibt sich das noch.
Mein bisheriger Plan ist es, jetzt erstmal die Grundfunktionen des Servers mit einer einfachen HTML Oberfläche zu erstellen, um dann den Client mit Hilfe von YUI dynamischer zu gestallten.
Aber jetzt erstmall ein Überblick über die Klassen:

Die statische Config Klasse ist erst später hinzugekommen, sodass ich die Attribute aus der Datenbankklasse, welche den Zugriff betreffen wohl dann entferne und die Benutzerdaten zentral in der Config Klasse speichere.
Ich habe jetzt auch schon erste Tests mit einer Session hinter mir, aber das Klassendesign ist noch sehr gewöhnungsbedürftig ^^.

Die Klasse TOOLS soll einfach zur Sammlung verschiedener Funktionen dienen.
Die md5 Methode dient einfach dazu, einen gegeben String als md5 Summe zurückzugeben. Dies brauche ich u.a. für die Passwörter.
Sobald ich die erste HTML Oberfläche habe (die dann einfaches Anmelden, Erstellen und Auflisten von Einträgen beherrschen wird, werd ich erste Funktionstests machen.
Das Schöne, was ich an Eclipse gefunden habe ist, dass man per Vorgabe einfache TextKlassen für Klassen erstellen kann. Dort werden alle Methoden einmal aufgerufen.
Ob das für ein Unit Testing ausreicht muss ich dann noch mal sehen.

Achja… Java und MySQL: Die erhaltenen Einträge aus der Datenbank speichert Java in einem sog. Resultset. Mit der methode next() kann man die verschiedenen Einträge durchblättern. Das komische ist nur, dass wenn – nachweislich – nur ein Eintrag vorhanden ist, muss man dennoch einmal die next() methode aufrufen.
Also muss man von 0. Eintrag auf den 1. blättern? O_o. Meiner Meinung nach irgendwie unnlogisch. Dementsprechend hat mich das auch ein wenig aufgehalten.
Betroffen war u.a. diese Methode aus der Klasse User:

public void load(){
    this.DB.Query("SELECT `ID`, `password` " + 
                   "FROM `users` WHERE `name` = '"+this.name+"' ");
    try {
        ResultSet res = this.DB.getLastResult();
        System.out.println(res.toString());
        res.next();
        this.ID = res.getInt("ID");
        this.password = res.getString("password");
    }catch (SQLException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
}

Ob ich jetzt das “erste Blättern” in der getLastResult() unterbringe habe ich mir noch nicht überlegt.
Wünsche allen frohes Schaffen und ein schönes Rest-Wochenende!

Update & Design Entscheidungen

Flattr this!

SOOOO die ersten Erfahrungen mit Java Servlets und Beans sind gemacht.
Letztendlich lässt sich eines sagen: Die Fehlermeldungen sind nicht wirklich sooo hilfreich.
Auf den Weg zu einer ersten funktionierenden Implimentierung einer User Klasse habe ich folgende Dinge (erstmal vorläufig) entschieden um mal ein lauffähiges Grundsystem zu haben:

  1. Alle meine Klassen werden im Package de.hausswolff.Diplom ihren Platz finden. Ob ich die Hirachie dann noch aufbreche muss ich dann noch sehen.
  2. Es gibt eine Datanbankklasse, die mir den Zugriff auf die Datenbank kapselt. Bisher ist das einfach eine Sammlung aller nötigen MySQL Funktionen (wie Update/Queries, Rückgabe der erhaltenen Einträge usw.). Diese Klasse initialisiert beim ersten Aufruf auch alle benötigten Tables (d.h. Letztendlich muss beim ersten Aufruf nur eine beschreibbare Datenbank zur Verfügung stehen)
  3. Es gibt eine (statische) Config Klasse, die hauptsächlich aus Attributen besteht und u.a. die Datenbank-Einstellungen, sowei ein Flag für den LDAP Zugriff enthält. Hier soll dann auch gespeichert werden, ob die Datenbank schon initialisert ist oder nicht – wie das ablaufen soll, muss ich dann noch sehen.
    nachfolgende Festlegungen haben nur im Kontext einer flachen Benutzertabelle, welche als vorläufiger Ersatz einer LDAP Authentifizierung dient.
  4. Ein Username ist eindeutig. Es gibt zwar für jeden Benutzer eine eindeutige ID, allerdings soll kein User einen schon vorhandenen Usernamen benutzen dürfen (dies wird durch die setName methode, welche bei einer Benutzererstellung aufgerufen wird überprüft und ggf. mit einer Fehlermeldung quittiert)
  5. Das Password wird in der Datenbank als md5 Hash abgelegt. Eine Überprüfung auf Richtigkeit eines Passwortes erfolg nur über die md5 hashes.