« Dezember 2007 | Main | Februar 2008 »

Januar 2008 Archives

09.01.08

Im neuen Jahr angekommen

Endlich gibts von mir auch mal wieder einen Blogeintrag. In den vergangenen Tagen musste ich ein paar Sachen für die Uni erledigen und konnte daher nicht allzuviel an der Masterarbeit arbeiten. Trotzdem gibt es seit dem letzten Blogeintrag natürlich Fortschritte:

Den Darstellungsfehler gibt es nicht mehr, allerdings weiß ich nicht mehr genau wie ich ihn beseitigt habe. Allerdings wusste ich ja auch nicht genau wie er überhaupt entstehen konnte. ;)

Die Seite hat jetzt eine akzeptable Farbgebung. (Warum endet das bei mir immer in Blautönen?)

Es werden alle Anforderungen erfüllt, so dass man Customer suchen/betrachten/bearbeiten/hinzufügen kann; deren Ratings bearbeiten/hinzufügen/löschen kann; bei den Ratings Fakten hinzufügen/löschen kann.

Außerdem kann man Fakttypen hinzufügen/bearbeiten und diese in Kategorien einordnen, wobei man natürlich auch neue Kategorien (und beliebig viele Ebenen Unterkategorien) anlegen kann. Hier lässt die Benutzerfreundlichkeit zu wünschen übrig, aber es geht halt.. ;)

Alle Auflistungen werden per Pagination zerlegt, wenn sie zu groß sind. Der Wert wieviele Zeilen auf einer Seite erscheinen sollen ist im Moment Hardcoded, aber könnte man auch durch den Benutzer änderbar machen.

Die Suche nach einem Customer geht über die ID oder über den Namen. Zur Zeit kann man als wildcards die mysqltypischen wildcards benutzen wie zB '%', was nicht so optimal ist.

Aber es gibt noch Probleme...
Manche Änderungen, wie zB das hinzufügen von Fakten oder löschen, werden nicht richtig angezeigt. Es wird zwar in die Datenbank richtig eingetragen, aber in der Webapplication nicht aktualisiert. Das werde ich versuchen heute zu lösen. Später mehr....


Käferplage

Ein Bug behoben, da hat sich schon der nächste eingenistet....

Wird etwas gelöscht oder hinzugefügt, gibt es jetzt keine Inkonsistenzen mehr zwischen EJB und Webapplication, was mich allerdings einen Datenbankaufruf mehr kostet, der IMHO eingespart werden könnte. Zur Zeit weiß ich aber keine bessere Lösung.
Doch nun tritt folgender Fehler auf: Erstelle ich ein Rating und gebe dazu ein paar Facts ein, kann ich das Rating nicht mehr löschen. Die Datenbank meckert, obwohl ich Cascading an habe. Wenn ich zuerst die Facts lösche, dann das Rating klappt es. Das war zu erwarten. Aber richtig merkwürdig wird es, wenn ich die Anwendung neu starte. Dann kann ich das Rating löschen, zusammen mit allen dazugehörigen Facts.

18.01.08

Rails 2.0 ftw

Nachdem ich in JavaEE zu kämpfen hatte, ist Rails doch irgendwie angenehmer. Manchmal muss man suchen, wie man das dem-"rails-way"-entsprechend zu machen hat. Aber wenn man das dann gefunden hat, wie der Befehl heißt oder wo was wie heißen muss, damit einfach alles sofort geht, dann ist es auch logisch und man kann es sich gut merken.
Jedenfalls ist das Erstellen eines ersten Prototypen um einiges leichter - besonders mit scaffold.
Sehr geholfen hat mir dabei das Rails 2.0 Scaffold Tutorial Rolling-with-Ruby-on-Rails-Revised. Leider muss man sich für den Download anmelden, aber das war es mir wert. ;)

Das Design anzupassen war auch nicht schwer und so sehen beide Anwendungen sich schon sehr ähnlich. Wie ich die Navigation in Rails vernünftig definiere muss ich noch rausfinden, aber ich errinnere mich dunkel, dass das relativ einfach war.

Es macht auf jeden Fall mehr Spaß, aber gerade deshalb verliere ich grade zusehens an Disziplin. Wenn man mehr in weniger Zeit schafft, kann man sich die restliche Zeit ja auch frei nehmen... *hust* Gefährliches Spiel....

22.01.08

Wie es ist und wie es sein sollte...

Das schwierigste an Rails ist mitunter, dass man es "schön" machen will, dem "Rails-way" entsprechend. So gibt es ein paar Sachen, die kann man irgendwie programmieren, aber die man natürlich einfach und elegant lösen will. So wie es sein sollte. Da kann man dann auch schonmal gut Zeit mit Suchen nach der besten Lösung verbringen...

Wie ihr wisst, arbeite ich gerade an der Rails-Version der Anwendung und da ich ganz gut voran kam, habe ich in den letzten Tagen nicht wirklich intensiv gearbeitet. Aber der Counter da rechts zählt unbarmherzig weiter runter, also Schluss mit lustig und weiterarbeiten.

Für "Pagination" (gibts da ein anständiges deutsches Wort für?) verwende ich das plugin will_paginate und das funktioniert auch einwandfrei. Ich frage mich jedoch wie ich damit eine Collection "paginaten" kann, die nicht als Abfrage aus der Datenbank kommt. Geht das? Anscheinend baut will_paginate auf find(:all) auf und verändert nur das Array so, dass es auch Informationen zu aktuellen Seite enthält.

Interessanter Weise habe ich ein paar Dinge entdeckt, die man in JavaEE konfigurieren konnte und ich in Rails selber programmieren muss außer es gibt ein plugin... (oder gibts nen Trick/"Rails-way"?)
Gibt es zum Beispiel in Rails etwas äquivalentes zu der Angabe der Customer-Rating-Beziehung "@OneToMany(cascade = CascadeType.REMOVE ...."? D.h. wenn ich einen Customer lösche, werden automatisch auch alle Ratings zu diesem Customer gelöscht.
In Rails würde ich jetzt in der destroy-Methode im customer-controller dafür sorgen, dass auch alle Ratings gelöscht werden. Gibt es einen eleganten Weg dies zu erledigen, oder muss ich tatsächlich jedes Rating (und dann natürlich auch jeden Fact eines Ratings) durchgehen und löschen?

(Nochmal grob zur Erinnerung: customer -hasmany-> ratings -hasmany-> facts -belongsto-> factType)

Ein anderes Problem ist zur Zeit die Umsetzung der Rating-Detail-Ansicht. Hier hatte ich in JavaEE eine Liste aller Fakttypen angelegt und dann angezeigt ob in diesem Rating der Fakt eingetragen wurde oder noch leer ist. (Dort hatte ich die Collection von Facts des Ratings aus der Datenbank und habe dann für alle nicht vorhandenen FactTypen Einträge hinzugefügt. Die Darstellung der überarbeiteten Collection samt pagination hat dann die entsprechende JSF-Komponente übernommen.)

Tja, wie löse ich das jetzt mit Rails? Insbesondere mit pagination? Ich bräuchte im Prinzip alle facts des ratings und dies mit einem right outer join verknüpft mit fact_types. Also so, dass von jedem FactType ein Fact für das Rating aufgelistet wird, ob es nun schon eingetragen ist oder nicht. (deshalb outer join)
Ob das nun verständlich war, wage ich zu bezweifeln.
Aber ich habe eine Idee und werde das auch sogleich mal angehen...

30.01.08

API gefällig?

Ich habe gerade http://www.gotapi.com entdeckt und finde es großartig!
Einfach ausprobieren!

About Januar 2008

This page contains all entries posted to Gerald's Blog in Januar 2008. They are listed from oldest to newest.

Dezember 2007 is the previous archive.

Februar 2008 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.31