Export Notes , Import Notes

[Kalli]

Ich bin auch dafür, dass das mal alles sortiert wird im Code.
wir können es ja zunächst als extra-Menüpunkt machen und wenn es wirklich stabil funktioniert automatisieren.

Wir sollten uns die Sache auch am besten für das nächste Release aufheben und dann richtig machen. Ich erinnere mal vorsichtig an den Coe Freeze zum 31.01.

 

[salzkammergut]

@Kalli: Die Datenbankklasse habe wir de facto schon mit der Klasse Profile. Wir müssen nur dafür sorgen, daß dort wirklich alle auf die Datenbank einwirkenden Methoden angesiedelt sind (lesen/schreiben/regenerieren/sortieren/Distanz zu einem Zentrum berechnen usw.). Wir sollten mit public Access auch sparsamer umgehen, und den Zugriff über Methoden erzwingen.

Ich sehe den Handlungsbedarf hauptsächlich in dieser Klasse, weil einige Methoden derzeit (fälschlicherweise) im UI angesiedelt sind (wie z.B. updateBearingDistance, updateRows).

Ich würde auch die derzeitige Trennung in Profile und CacheHolder beibehalten, wobei letztere alle Methoden, die auf EINEN Cache einwirken enthält. Dazu gehört das Lesen/Schreiben der cache.xml, eventuell das Lesen/Schreiben von Notes/Logs etc,

 

[pfeffer]

@Salzkammergut: bin ich auch für. Habe auch schon was verlegt in profile.java, checke ich demnächst ein.

BTW: ich denke jetzt doch, dass man die Kartengeschichten, zumal sie immer mehr werden, in ein Paket verschieben sollte. Kann das Eclipse irgendwie automatisch?

Gruß,
Pfeffer.

 

[Kalli]

BTW: ich denke jetzt doch, dass man die Kartengeschichten, zumal sie immer mehr werden, in ein Paket verschieben sollte. Kann das Eclipse irgendwie automatisch?

Ja, läuft unter Refactor oder so (sitze gerade nicht vor eclipse). Damit kannst Du Klassen (bzw. Dateien) von einem Package in ein anderes verschieben, eclipse passt dann auch die imports. Als ich das exp-Package gemacht habe, ging das ziemlich fix.

Bilbowolf muss dann natürlich acht geben, dass sein Buildprozeß damit klar kommt.