Änderung im Dateiformat

[MiK]

Das sind aber zwei total verschiedene Stellen. Bei einem Import (eigentlich nur beim Spidern, oder?) ist es klar, dass eine Umsetzung in das interne Format erfolgen muss. Das man intern zwischen Datei und internem Code ständig solche Verrenkungen macht, ist unverständlich.

 

[Engywuck]

Bei einem Import (eigentlich nur beim Spidern, oder?)

Auch beim GPX-Import - da kommt schließlich ne 1856 an...

Das man intern zwischen Datei und internem Code ständig solche Verrenkungen macht, ist unverständlich.

Das liegt ja nur daran, dass ich das Erscheinungsbild des Cachetyps für den Rest des Cachewolf (absichtlich) erstmal so gelassen habe, wie es bisher ist.
Es ist natürlich kein Problem (nur etwas Tipp- und Sucharbeit), interne Konstanten für die Cachetypen zu definieren und zu benutzen. Dann ist CW_TRADITIONAL halt -126, es bleibt in der Datei wie es ist, niemand muss was umrechnen (außer export/import) und im Rest des CW werden (wo konkrete Cachetypen abgefragt werden) nur noch die Konstanten benutzt. Diese größere Umstellungsarbeit hab ich mir allerdings erstmal gespart, zumal sie funktional keinen Nutzen hat.

Gruß,
E.

P.S.: Dann sollte auch noch jemand daran denken, die Typ-Icons umzubennen...

 

[greiol]

mein wunsch wäre tatsächlich entweder eine klare regel ohne ausnahmen oder ein explizites mapping mit einem höflichen, aber bestimmten

default: throw(new IllegalArgumentException);

am ende. da merkt man auch gleich wenn man etwas vergessen hat. man muss sich nur die konstanten anschauen (braucht man eh) und muss nicht 200+ zeilen runterscrollen um dahinter zu kommen wie denn nun a zu b wird. zugegeben nicht unbedingt elegant, aber idiotensicher.

heute haben wir zwei ausnahmen und morgen kommt einer auf die idee und bringt die total neuen cachetypen 3456 und 7890. die müssen wir sowieso eintragen. und falls ein cachetyp 100 auftaucht, ist sofort klar, dass er ein mapping braucht. so ist der ablauf für die integration klar vorgegeben und steht nicht 200 zeilen auseinander.

der nächste logische schritt wäre dann in meinen augen die umrechung aus dem cacheholder hinaus in die ex- und importer zu verlagern. der cacheholder an sich sollte nichts mehr umrechnen müssen und daten stumpf auf die platte schreiben bzw. von ihr lesen können.

 

[MiK]

Bei einem Import (eigentlich nur beim Spidern, oder?)

Auch beim GPX-Import - da kommt schließlich ne 1856 an...

Nein, da kommt "Wherigo Cache" an. Diese Nummern kommen nur vom Spidern. Das sind die Namen der Icons auf der CW-Seite. Diese werden zum Erkennen des Typs beim Spidern benutzt. In den GPX-Files kommen diese Codes gar nicht vor. Wahrscheinlich haben die Caches nicht mal GC-intern diese Codes. Das sind wirklich nur Icon-Namen auf dem GC-Server.

Das man intern zwischen Datei und internem Code ständig solche Verrenkungen macht, ist unverständlich.

Das liegt ja nur daran, dass ich das Erscheinungsbild des Cachetyps für den Rest des Cachewolf (absichtlich) erstmal so gelassen habe, wie es bisher ist.
Es ist natürlich kein Problem (nur etwas Tipp- und Sucharbeit), interne Konstanten für die Cachetypen zu definieren und zu benutzen. Dann ist CW_TRADITIONAL halt -126, es bleibt in der Datei wie es ist, niemand muss was umrechnen (außer export/import) und im Rest des CW werden (wo konkrete Cachetypen abgefragt werden) nur noch die Konstanten benutzt. Diese größere Umstellungsarbeit hab ich mir allerdings erstmal gespart, zumal sie funktional keinen Nutzen hat.

Das ist Arbeit, die auf jeden Fall getan werden muss. Aber ich sehe keinen Grund, warum man dabei den Wert einzelner Konstanten nicht noch einmal ändern kann, damit man sich später nicht fragt, warum diese so seltsame Nummern haben. Die Tatsache, dass das jetzt mal ein paar Tage so im SVN war, ist da für mich kein Hindernis.

 

[MiK]

Soweit ich weiß, tauchen extern Nummern für Cachetypen nur an zwei Stellen auf: Beim OC-Import und beim Spidern. An allen anderen Stellen wird mit Klartext für die Cachetypen gearbeitet. Beim OC-Import werden die OC-IDs jetzt schon per explizitem Mapping in das CW-Format gewandelt. Beim Spidern werden die Namen von Bildern ausgewertet, um den Cachetyp zu ermitteln. Bisher waren das immer Nummern. Das könnte sich aber jederzeit ändern. Diese Bildnamen als Grundlage für interne Nummern zu benutzen, halte ich für keine gute Idee.

 

[Engywuck]

der nächste logische schritt wäre dann in meinen augen die umrechung aus dem cacheholder hinaus in die ex- und importer zu verlagern. der cacheholder an sich sollte nichts mehr umrechnen müssen und daten stumpf auf die platte schreiben bzw. von ihr lesen können.

Das würde ich genau anders sehen. Der CacheHolder kennt seine Pappenheimer (d.h. internen und externen Typen) und kann sie auch gut mappen, am besten in einer Funktion. Warum sollen sich 5 Exporter alle darum kümmern, eine Information in gleicher Weise zu transformieren?
Mein Vorschlag wäre die Funktion getCacheTypeExternal(), die den CacheTyp als externen (GC-typisierten) Wert liefert. Den kann dann jeder Exporter, der ihn braucht, verwenden.
Oder hab ich Deine Idee falsch verstanden?

Aber ich sehe keinen Grund, warum man dabei den Wert einzelner Konstanten nicht noch einmal ändern kann, damit man sich später nicht fragt, warum diese so seltsame Nummern haben. Die Tatsache, dass das jetzt mal ein paar Tage so im SVN war, ist da für mich kein Hindernis.

Wenn wir uns darauf einigen, dass es nur die 3 Exoten betrifft, kann ich damit gut leben - wenn es denn Leute gibt, die die Änderung glücklich macht. Die kommen ja kaum vor und das Problem ist mit Aktualisieren schnell behoben.

Soweit ich weiß, tauchen extern Nummern für Cachetypen nur an zwei Stellen auf

Es sollte reichen, mal nach "137" zu suchen...

Gruß,
E.

 

[greiol]

ich hab jetzt mal nach 1858 gesucht, das taucht 14 mal explizit auf. davon drei mal als string. die stellen an denen es auftaucht sind sicherlich kandidaten für eine nähere betrachtung ob auch die anderen typen explizit auftauchen.

an den meisten stellen liesse sich das problemlos durch CW_WHERIGO ersetzen und in der folge dürfte das meiste sogar noch klappen, wenn man den wert von CW_WHERIGO hinterher ändert.

eine klare ausnahme hiervon ist der spider weil er

Integer(inRex.stringMatched(1)).intValue()

benutzt und damit implizit eine zahl generiert. hier müsste die sw ein paar tricks lernen.

bei der suche habe ich noch 1304 "GPS Adventures Exhibit" als kandidaten für ein explizites mapping gefunden. allerdings dürften nicht sehr viele user betroffen sein (cw kennt es auch ohnehin noch nicht).

 

[MiK]

Das würde ich genau anders sehen. Der CacheHolder kennt seine Pappenheimer (d.h. internen und externen Typen) und kann sie auch gut mappen, am besten in einer Funktion. Warum sollen sich 5 Exporter alle darum kümmern, eine Information in gleicher Weise zu transformieren?
Mein Vorschlag wäre die Funktion getCacheTypeExternal(), die den CacheTyp als externen (GC-typisierten) Wert liefert. Den kann dann jeder Exporter, der ihn braucht, verwenden.
Oder hab ich Deine Idee falsch verstanden?

Ich würde da zwischen Im- und Export unterscheiden. Beim Import ist das meist sehr speziell. Einmal müssen IDs umgesetzt werden, ein anderes mal ein String umgesetzt werden und ein drittes mal ein Bildname ausgewertet werden. Da ist es am einfachsten nur den Importer anfassen zu müssen, wenn sich an einer Schnittstelle etwas ändert. Beim Export verwenden wir (bitte korrigiert mich) nur Klartextstrings für die Cachetypen. Da das häufig die selben sind, können die entsprechenden Funktionen gerne in die Cacheholder- oder Cachetype-Klasse.

Wenn wir uns darauf einigen, dass es nur die 3 Exoten betrifft, kann ich damit gut leben - wenn es denn Leute gibt, die die Änderung glücklich macht. Die kommen ja kaum vor und das Problem ist mit Aktualisieren schnell behoben.

Genau das habe ich doch jetzt schon mehrmals geschrieben...

Soweit ich weiß, tauchen extern Nummern für Cachetypen nur an zwei Stellen auf

Es sollte reichen, mal nach "137" zu suchen...

Ich sprach von "extern". Das das intern vielleicht öfter mal vorkommt, habe ich nicht bestritten.

 

[MiK]

eine klare ausnahme hiervon ist der spider weil er

Integer(inRex.stringMatched(1)).intValue()

benutzt und damit implizit eine zahl generiert. hier müsste die sw ein paar tricks lernen.

Diese Stelle ist sowieso höchst gefährlich, weil sie davon ausgeht, dass hier nur Nummern als Namen für die Cachebilder benutzt werden. Hier müssten eigentlich besser eine Funktion verwendet werden, die die Strings explizit auf Cachetypen abbildet.

 

[greiol]

Hier müssten eigentlich besser eine Funktion verwendet werden, die die Strings explizit auf Cachetypen abbildet.

und damit wäre die abbildung auch kein problem mehr. aber jetzt ist erst mal feierabend. morgen abend geht es weiter. mit etwas glück müssen wir insgesamt noch weniger ändern als angenommen und gewinnen auch noch an lesbarkeit. das hätte was ...

 

[huzzel]

Ich wollte jetzt mal anfangen mich in die neue Version einzuarbeiten, doch leider ist die Windowsversion zur Zeit nicht auf dem Server verfügbar
Gibts noch einen anderen Link?

 

[MiK]

Nein, nur der Link ganz oben ist falsch. Versuch es mal weiter unten bei den Links zu den einzelnen Versionen.

 

[huzzel]

Nein, nur der Link ganz oben ist falsch. Versuch es mal weiter unten bei den Links zu den einzelnen Versionen.

Danke

 

[Geo-Johnny]

Nein, nur der Link ganz oben ist falsch. Versuch es mal weiter unten bei den Links zu den einzelnen Versionen.

@huzzel
Tipp von greiol und mir:
Sichere Dir vorher den Datenbestand Deiner Profile, damit kannst Du jederzeit (mit NB r1786) wieder zum alten Datenformat zurück!

 

[huzzel]

Nein, nur der Link ganz oben ist falsch. Versuch es mal weiter unten bei den Links zu den einzelnen Versionen.

@huzzel
Tipp von greiol und mir:
Sichere Dir vorher den Datenbestand Deiner Profile, damit kannst Du jederzeit (mit NB r1786) wieder zum alten Datenformat zurück!

Ich habe es als Parallelinstallation gemacht

Frage an die Devs (oder wer es sonst weiß):

Wo finde ich im neuen Format:
- Wegpunkttype (Tradi, Multi, QTA, Final, ...)
- Größe
- T/D Wertung
- ob er online ist

Es steht ja weder in der Index noch in der [Cache].xml, zumindest nicht mehr so leicht ersichtlich. Und da Java nicht so mein Ding ist, habe ich mir auch noch nie den Sourcesode zu Cachewolf angeschaut und mich noch nie da reingedacht.

Könnt Ihr mir kurz erklären, wo ich was wiederfinde?
Danke schon mal.

 

[greiol]

Frage an die Devs (oder wer es sonst weiß):

Wo finde ich im neuen Format:
- Wegpunkttype (Tradi, Multi, QTA, Final, ...)
- Größe
- T/D Wertung
- ob er online ist

Es steht ja weder in der Index noch in der [Cache].xml, zumindest nicht mehr so leicht ersichtlich. Und da Java nicht so mein Ding ist, habe ich mir auch noch nie den Sourcesode zu Cachewolf angeschaut und mich noch nie da reingedacht.

du findest es in den feldern bitfields und bytefields. ohne in den source zu schauen wirst du nicht weit kommen. der genau inhalt der felder ist u.a. das was hier gerade teilweise leidenschaftlich diskutiert wird. warte mit dem einarbeiten bis es fertig ist, dann musst du es nicht zweimal machen. wobei du dich auf jeden fall mit logischen binär operationen vertraut machen solltest, denn die wirst du so oder so brauchen.

und wenn wir ganz nett sind dokumentieren wir das format am ende noch, aber halt erst am ende.

 

[huzzel]

du findest es in den feldern bitfields und bytefields. ohne in den source zu schauen wirst du nicht weit kommen

das habe ich schon befürchtet.

Ohne mich jetzt in den kompletten Sourcecode einzuarbeiten, kannst Du mir sagen, wo ich suchen muss?

 

[greiol]

Ohne mich jetzt in den kompletten Sourcecode einzuarbeiten, kannst Du mir sagen, wo ich suchen muss?

du bekommst die info wenn wir durch sind. wenn ich jetzt sage es steht in a und heute abend b hochlade, müsste ich es anschliessend wieder erklären.

 

[greiol]

ok, wer motzt muss auch was zeigen

ich habe mal eine neue klasse CacheSize hochgeladen die zeigt wie ich mir das ganze vorstelle. langweilig, aber hoffentlich robust.

natürlich käme, falls das so implementiert würde noch die (zugegeben lästige) fleissarbeit herauszufinden wo das im moment noch überall hart verdrahtet ist und es zu ersetzen.

kann man das ding brauchen? was fehlt noch? spontan fiele mir noch ein array für das füllen der drop down box bei den details ein.

 

[Engywuck]

ok, wer motzt muss auch was zeigen

Löblich

Folgende Anmerkungen:

• Für die interne Repräsentation der Sizes solltest Du die Werte nehmen, die ich schon in CacheHolder (ab Zeile 50) verwendet habe.
• Würde die Klasse static final machen
• Ich halte nicht so viel davon, jetzt schon jede Menge Code einzubauen für Zwecke, die bislang noch gar nicht benötigt werden. Wenn bislang keine Images exportiert werden, braucht man dafür auch keine Methode anzulegen oder Konstanten zu definieren - das macht nur die Exe unnötig größer. Wenn man die Methode braucht, kann man sie erstellen, das ist ja dann unproblematisch.
• Bei den Exceptions sollte noch eine Message dazu, die angibt, welcher Typ denn gerade nicht unterstützt wurde.

Das wärs, was mir spontan auffällt.

Gruß,
E.