Menu
▾
▴
ftraq-devel
|
From: Erik M. <mo...@sc...> - 2002-06-20 00:31:58
|
So, ich habe jetzt mal die Settnigs-Interfaces eingecheckt. Wer immer irgendwelche Konfig.-Parameter abfragen will, sollte sich =FCber LgApplication mit getSettings das Objekt holen und kann dann mit den Methoden aus dem Interface die einzelnen Parameter abfragen (siehe Javadoc). Wenn Ihr =C4nderungen wollt, meldet Euch bitte m=F6glichst bald, damit ich bei der Implementierung weniger Arbeit habe. Wie Steffen vorgeschlagen hat, habe ich Knabes typsichere Liste mit Search&Replace verwendet. Ich habe au=DFerdem noch eine (halbwegs) typsichere Map gebastelt. Beide sowie die daraus erzeugten Listen + Maps sind im Paket ftraq.util, was mir logisch erscheint, da man sie vielleicht an mehreren Stellen benutzen m=F6chte. Bei der Implementierung von LgSettings werde ich es nicht wie bei der BookmarkLibrary machen -- dass die ganze Zeit auf einen JDOM-Baum zugegriffen wird -- sondern statt dessen beim Einlesen der XML-Datei den JDOM-Baum in die Objekte der Lg-Schicht umwandeln und umgekehrt. Die andere Methode ist viel aufwendiger, besonders bei komplexen Datenstrukturen, und bringt keine wirklichen Vorteile (au=DFer, dass man eher eine Drei-Schichten-Architektur einh=E4lt).=20 Die Idee war, dass der JDOM-Baum die Objekthierarchie enth=E4lt -- da man ja aber st=E4ndig diese Hierarchie wieder in Java-Listen und Maps konvertieren muss, hat man eine sehr gro=DFe Redundanz. Wenn man in den oberen Schichten auch mit JDOM arbeiten w=FCrde, w=E4re es halbwegs effizient, aber das w=E4re ja dann wieder nicht sauber getrennt. Evtl. werde ich die BookmarkLibrary irgendwann umschreiben, aber solange sie funktioniert, soll's mir recht sein. Ich bin ziemlich m=FCde und lege mich jetzt hin. Alex, was die TransferQueue angeht: Ignoriere den Aspekt des Schreibens und Lesens einfach. Es wird im LgTransferQueue-Interface die Methoden open(), commit() und rollback() geben wie in den anderen Interfaces auch, aber die Setter und Getter der Items kannst Du ganz normal auf die Variablen anwenden. Auch hier werde ich nur beim Einlesen und Schreiben der XML-Datei auf den JDOM-Baum zugreifen, so dass Du mit der Datenbankschicht nicht zu tun hast. Die drei oben genannten Methoden baue ich dann ein, sobald ich mit der DbTransferQueue fertig bin (also irgendwann im Laufe des Tages). MfG EM=D6 --=20 Scientific Reviewer, Freelancer, Humanist -- Berlin / Germany Phone: +49 (0)30 45491008 -- Web: http://www.humanist.de/erik Editor of: http://www.violence.de, http://www.infoanarchy.org Patriotism is an ephemeral motive that scarcely ever outlasts the particular threat to society that aroused it. -- Denis Diderot |
|
From: Steffen S. <ste...@gm...> - 2002-06-20 23:22:35
|
Erik Moeller wrote:
>So,
>
>ich habe jetzt mal die Settnigs-Interfaces eingecheckt. Wer immer
>irgendwelche Konfig.-Parameter abfragen will, sollte sich über
>LgApplication mit getSettings das Objekt holen und kann dann mit den
>Methoden aus dem Interface die einzelnen Parameter abfragen (siehe
>Javadoc).
>
Ein bischen spät, ich weiß aber ich habe heute genug mit dem Streams und
Sockets rumgekrampft
um das abbrechen und resumen sauber hinzukriegen daß ich mir die
Settings erst jetzt richtig
angeschaut habe. Zwei Sachen gefallen mir mittlerweile aber nicht so
1. hier (und woanders nochmal)
/**
* assign the directory map list we want to use - this method is
* used by the database layer.
*
* @param i_list the list that we want to use.
*
*/
void setDirectoryMapList(ftraq.util.LgDirectoryMap_List i_list);
Die unteren Schichten sollten die darüber nicht kennen
(->3-Schichten-Modell). Wenn sie
es doch tun müssen, dann aber bitte heimlich und nicht noch in den
Kommentaren mit
den Fingern draufzeigen ;). Besser wäre auch hier wenn sich die
LgSchicht die Werte aus
der DbSchicht mit gettern holt, und wenn nötig mit Observer Pattern dazu
aufgerufen wird.
2. Die typsicheren Maps und Listen sind zwar eine feine Sache, aber
irgendwie schöner
wäre es doch, die Implementierung als Listen und Maps nicht nach außen
preiszugeben,
sondern stattdessen nur Methoden zum logischen Zugriff ohne Hinweis auf die
verwendete Implementierung bereitzustellen
z.B.
void setIntegerOption(String i_name, int i_value);
int getIntegerOption(String i_name);
boolean doesFileNameHaveTextFileExtension(String i_fileName);
void addTextFileExtension(String i_extension);
void removeTextFileExtension(String i_extension);
String getMappedDirectoryName(LgSystemID i_theSystemOfThePathName,
String i_thePathName, LgSystemID i_theCurrentlyRunningSystem);
void addNewMapping(LgSystemID i_firstSystem, String
i_pathNameOnFirstSystem, LgSystemID i_secondSystem, String
i_pathNameOnSecondSystem);
dann könnte man auch außerdem Gültigkeitsprüfungen in der Klasse
LgSettings durchführen
denn da gehören sie meiner Meinung nach hin, so finde ich es z.B. bei
der Verwendung von Maps
sehr häßlich daß sie bei nicht vorhandenen Elementen null pointer
herausgeben.
>
>Wenn Ihr Änderungen wollt, meldet Euch bitte möglichst bald, damit ich
>bei der Implementierung weniger Arbeit habe.
>
>
Ich hoffe das war nicht zu spät, aber ich hatte schon ohne das Laufwerks
Mapping genug Probleme mit dem FileSystem, und hatte
deswegen zuerst nur einen kurzen Blick auf die eingecheckten Dateien
geworfen und mir dabei nur das util und db paket angesehen.
gruß,
Steffen
morgen um 2 treffen und abmachen wer was vorzeigen will?
|
|
From: Andreas D. <dri...@gm...> - 2002-06-21 00:11:32
|
> > > morgen um 2 treffen und abmachen wer was vorzeigen will? Oh backe, ich dachte wenigstens die erste Halbzeit sehen zu können. Reicht nicht auch 2:15 Uhr?? Gruß, Andreas PS: Also ohne vernünftiges Composite-Pattern in der Db-Schicht der Library wird die Lg-Schicht nix bis morgen.. |
|
From: Erik M. <mo...@sc...> - 2002-06-21 08:21:12
|
Am Fre, 2002-06-21 um 01.21 schrieb Steffen Sauder: > Die unteren Schichten sollten die dar=FCber nicht kennen=20 > (->3-Schichten-Modell). Wenn sie > es doch tun m=FCssen, dann aber bitte heimlich und nicht noch in den=20 > Kommentaren mit > den Fingern draufzeigen ;). Besser w=E4re auch hier wenn sich die=20 > LgSchicht die Werte aus > der DbSchicht mit gettern holt, und wenn n=F6tig mit Observer Pattern daz= u=20 > aufgerufen wird. Die Db-Schicht muss zwar auf das Lg-Objekt zugreifen, aber sie braucht eigentlich die setter zum Zuweisen der Listen nicht, wenn die Lg-Schicht leere Standardlisten verwendet. Ich meine, es ist aber wenig logisch, elementare Datenhaltungsobjekte wie Maps und Listen unbedingt in die Db-Schicht zu stecken. Dann m=FCsste auch das FileSystem eine Db-Schicht haben nur f=FCr den Fall, dass man es u.U. mal serialisieren wollte ..=20 Der urpsr=FCngliche Aufruf, der dazu f=FChrt, dass die Db-Schicht die Lg-Schicht bedient, geht aber von der Lg-Schicht an die Db-Schicht (open). > 2. Die typsicheren Maps und Listen sind zwar eine feine Sache, aber=20 > irgendwie sch=F6ner > w=E4re es doch, die Implementierung als Listen und Maps nicht nach au=DFe= n=20 > preiszugeben, > sondern stattdessen nur Methoden zum logischen Zugriff ohne Hinweis auf d= ie > verwendete Implementierung bereitzustellen >=20 > z.B. > void setIntegerOption(String i_name, int i_value); > int getIntegerOption(String i_name); >=20 > boolean doesFileNameHaveTextFileExtension(String i_fileName); > void addTextFileExtension(String i_extension); > void removeTextFileExtension(String i_extension); >=20 > String getMappedDirectoryName(LgSystemID i_theSystemOfThePathName,=20 > String i_thePathName, LgSystemID i_theCurrentlyRunningSystem); > void addNewMapping(LgSystemID i_firstSystem, String=20 > i_pathNameOnFirstSystem, LgSystemID i_secondSystem, String=20 > i_pathNameOnSecondSystem); Hm, komplett verpacken werde ich die Listen wohl nicht, da man dann wieder viele Methoden verbergen m=FCsste (keys(), values() usw.). Gerade das mit dem Null-Pointer kann man ja auch in der Liste als Exc realisieren. Da wo es Sinn macht, kann man aber noch abgepr=FCfte Methoden hinzuf=FCgen. Der Nutzer kann dan halt immer auch die unsicheren verwenden. MfG EM=D6 --=20 Scientific Reviewer, Freelancer, Humanist -- Berlin / Germany Phone: +49 (0)30 45491008 -- Web: http://www.humanist.de/erik Editor of: http://www.violence.de, http://www.infoanarchy.org Patriotism is an ephemeral motive that scarcely ever outlasts the particular threat to society that aroused it. -- Denis Diderot |
|
From: Steffen S. <ste...@gm...> - 2002-06-21 10:24:29
|
Erik Moeller wrote:
>Am Fre, 2002-06-21 um 01.21 schrieb Steffen Sauder:
>
>
>
>>Die unteren Schichten sollten die darüber nicht kennen
>>(->3-Schichten-Modell). Wenn sie
>>es doch tun müssen, dann aber bitte heimlich und nicht noch in den
>>Kommentaren mit
>>den Fingern draufzeigen ;). Besser wäre auch hier wenn sich die
>>LgSchicht die Werte aus
>>der DbSchicht mit gettern holt, und wenn nötig mit Observer Pattern dazu
>>aufgerufen wird.
>>
>>
>
>Die Db-Schicht muss zwar auf das Lg-Objekt zugreifen, aber sie braucht
>eigentlich die setter zum Zuweisen der Listen nicht, wenn die Lg-Schicht
>leere Standardlisten verwendet.
>
Statt leere Standardlisten zu verwenden müsste das Lg-Settings objekt
beim Initiliaisieren
einfach das Db-Settings-Objekt erzeugen und sich von ihm genau jene
Listen holen, die du
mit den settern übergeben wolltest
> Ich meine, es ist aber wenig logisch,
>elementare Datenhaltungsobjekte wie Maps und Listen unbedingt in die
>Db-Schicht zu stecken.
>
richtig, ich meinte auch nicht daß alle Werte aus der Db-Schicht
gehalten werden holen sollen,
nur sollte die Entnahme der Listen und Maps aus der Db-Schicht(zu Beginn
oder beim Rollback) von
den LgSettings ausgehen mit (z.B. dbSettings.getStringOptionMap()) und
nicht andersherum
>Der urpsrüngliche Aufruf, der dazu führt, dass die Db-Schicht die
>Lg-Schicht bedient, geht aber von der Lg-Schicht an die Db-Schicht
>(open).
>
wenn dieser open Befehl sich die aktuellen Einstellungen aus den
Db-Settings holt,
wozu denn dann noch die Setter?
>>2. Die typsicheren Maps und Listen sind zwar eine feine Sache, aber
>>irgendwie schöner
>>wäre es doch, die Implementierung als Listen und Maps nicht nach außen
>>preiszugeben,
>>sondern stattdessen nur Methoden zum logischen Zugriff ohne Hinweis auf die
>>verwendete Implementierung bereitzustellen
>>
>>
>>
>Hm, komplett verpacken werde ich die Listen wohl nicht, da man dann
>wieder viele Methoden verbergen müsste (keys(), values() usw.).
>
Wer braucht außerhalb der Klasse diese Methoden? Und sind die Listen
threadsicher, oder muß sich
der Benutzer selber um die Synchronization kümmern? wenn ich zum Beispiel
alle TextFileExtensions durchlaufen will (z.B. um sie in der Gui
anzuzeigen)., müsste ich jetzt so vorgehen):
String_List fileExtensionList =
ftraq.Main.getLgApplication().getSettings().getTextExtensionList();
// um zu verhindern, daß bei gleichzeitiger Änderung der Liste durch
// einen anderen Thread eine ConcurrentModificationException
ausgelöst wird
synchronized(fileExtensionList) {
String_List.Iterator it = fileExtensionList.listIterator();
while (it.hasNext()) {
String fileExtension = it.next();
doSomethingWith(fileExtension);
}
}
Übersichtlicher wäre doch etwas wie hier:
String[] textExtensions =
ftraq.Main.getLgApplication().getSettings().getAllTextExtensions[];
for (int i=0; i<textExtensions.length; i++) {
doSomethingWith(textExtensions[i]);
}
Genauso fände ich es praktischer anstatt an vielen Stellen immer die
gleiche Zeile
if
(fileExtensionList.contains(fileNameToTest.substring(fileNameToTest.lastIndexOf('.')+1).toLowerCase())
{ doKram() }
zu schreiben, stattdessen eine ausgelagerte Funktion zu haben:
if (lgSettings().hasFileNameTextFileExtension(fileNameToTest)) {doKram() }
Neben diesen Funktionen bräuchte ich nur noch add- und
removeTextFileExtension(String i_extension).
Auf alle anderen Funktionen der Liste kann ich verzichten.
> Gerade
>das mit dem Null-Pointer kann man ja auch in der Liste als Exc
>realisieren.
>
richtig.
>Da wo es Sinn macht, kann man aber noch abgeprüfte Methoden
>hinzufügen. Der Nutzer kann dan halt immer auch die unsicheren
>verwenden.
>
wie gesagt, da wo es nicht benötigt wird, fände ich es sinnvoller die
Listen und Maps
in LgSettings zu verstecken, unteranderem wegen des Problems des
gleichzeitigen
Zugriffs von mehreren Threads. Wie würde zum Beispiel die Db-Schicht
reagieren
wenn während eines commits von zweit Threads gleichzeitig neue Elemente in
die Listen und Maps der Logikschicht eingetragen werden? Eine Sperrung der
Daten während des commits ist meiner Meinung nach am einfachsten möglich,
wenn jeder Veränderung der Daten nur über eigens dafür gedachte Methoden
in LgSettings passiert, die die Kontrolle über die Synchronization des
Zugriffs auf
die Maps und Listen haben.
gruß
Steffen
|
Thanks for helping keep SourceForge clean.
X