Auslaufende Ressourcen
-
@simon2 sorry, beim Ort einen Kommentar einzutragen, finde ich einen üblen Workaround. Sollte eigentlich den FR stützen
Aber das mit dem Blocker finde ich gut.
-
@bwl21 sagte in Auslaufende Ressourcen:
@simon2 sorry, beim Ort einen Kommentar einzutragen, finde ich einen üblen Workaround....
Optimal finde ich das auch nicht und natürlich bin ich im Prinzip bei dir: Man sollte Attribute als das nutzen, als was sie gedacht sind.
... allerdings sehe ich hier keinerlei "echte Ortssemantik" hinterlegt (gibt kein Adressfeld, Maps-Koordinaten, ... was typisch für einen Ort wäre, auch keine Operationen oder Referenzen, die die Ortseigenschaften nutzen/berücksichtigen).Es ist einfach ein Freitextfeld, das mehr zurällig "Ort" heißt. Wenn man in seiner Übersetzung "Ort" zu "Kommentar" (oder gar "Auslaufdatum") umbenennen würde, würde das absolut funktionieren.
Bei uns (deshalb hatte ich ursprünglich auch gedacht, dass das Feld "Kommentar" heißt) steht da auch mehr ein Hinweis, wo der Raum sich befindet - (in der Art "Ihr wisst schon: Hinter dem Wirtschaftsraum links"
).
Deshalb fände ich das nicht so besonders schlimm.Aber das mit dem Blocker finde ich gut.
Danke für die Klärung.
Finde ich auch eine gute (und bessere als die andere) Lösung - ist mir aber erst als zweites eingefallen und deshalb nachgeschoben. Und wer weiß: Vielleicht gefällt einem die "Kommentarlösung" auch besser .und der freut sich vielleicht darüber.Gruß
Simon
-
@simon2 sagte in Auslaufende Ressourcen:
... auch keine Operationen oder Referenzen, die die Ortseigenschaften nutzen/berücksichtigen).
Das stimmt so nicht. Soweit ich weiß wird die Ortsangabe der Ressource an die ical Datei im Kalendertermin übergeben, welcher diese Ressource enthält.
Das stammt noch aus der Zeit bevor man direkt einen Ort im Kalendertermin anlegen konnte. -
@andrej OK, die ical-Datei habe ich mir nicht angeschaut.
Aber der Text wird dann vermutlich im Kalender zwar unter der Rubrik "Ort" angezeigt, hat dort aber ähnlich wenig "Ortseigenschaften" wie im CT-Ressourcenmodul, oder? -
@simon2 sagte in Auslaufende Ressourcen:
Es ist einfach ein Freitextfeld, das mehr zurällig "Ort" heißt. Wenn man in seiner Übersetzung "Ort" zu "Kommentar" (oder gar "Auslaufdatum") umbenennen würde, würde das absolut funktionieren.
Ich habe in letzter Zeit einiges an Datenmigrationen durchgeführt, und fand in solchen Freitextfeldern plötzlIche Telefonnummern obwohl es E-mails sein sollten ...
Daher bin ich der Meinung, es sollte Immer ein Freitextfeld geben für solche, nicht im Schema vorgesehenen Daten. Wenn es ein solches allgemeines Freitextfeld nicht gibt, provozieren wir solche üblen Workarounds.
-
@simon2 sagte in Auslaufende Ressourcen:
@andrej OK, die ical-Datei habe ich mir nicht angeschaut.
Aber der Text wird dann vermutlich im Kalender zwar unter der Rubrik "Ort" angezeigt, hat dort aber ähnlich wenig "Ortseigenschaften" wie im CT-Ressourcenmodul, oder?Ich denke, es hängt von der Anwendung ab, mit der man die ical nutzt/ einbindet. Ich habe zum Beispiel die Termine in meiner Kalender APP auf dem Smartphone und dort ist bei der Ortsangabe direkt ein Link "Auf Karte finden". Dieser sendet dann die Angaben bei Ort an google maps und zeigt auf der Karte die Treffer an.
-
@bwl21 sagte in Auslaufende Ressourcen:
...
Daher bin ich der Meinung, es sollte Immer ein Freitextfeld geben für solche, nicht im Schema vorgesehenen Daten. Wenn es ein solches allgemeines Freitextfeld nicht gibt, provozieren wir solche üblen Workarounds.Gerne - allerdings sehe ich immer noch nicht, was an dieser Nutzung ein "..übler Workaround.." ist.
Für mich ist eigentlich das Gegenteil ein "übler Workaround": Wenn man in Freitextfeldern "geheime Schnittstellen" implementiert. Also z.B. in bestimmtes Format nutzen muss, damit (ggf. woanders) ein Prozess/Programm/... funktioniert.
Das Übel sind mMn nicht Freitextfelder, sondern deren Missbrauch für technische Auswertung.
Solange klar ist, dass Freitextfelder immer nur von Menschen interpretiert werden, habe ich kein Problem mit einer "individuellen Interpretation".
... und wo Information nicht (nur) von Menschen interpretiert werden, sollte man keine Freitextfelder (oder zumindest keine Freitexteingaben) verwenden.
Aber nun genug von meiner Schnittstellenphilosophie.
@andrej sagte in Auslaufende Ressourcen:
..."Auf Karte finden". Dieser sendet dann die Angaben bei Ort an google maps und zeigt auf der Karte die Treffer an.
Nunja - das ist aber dann quasi Glückssache, ob das funktioniert - bzw. muss man dann manuell auf die "Kartenapp" anpassen (Was passiert eigentlich, wenn jemand eine andere App nutzt? Sind die Daten kompatibel?).
Außerdem ist das schon eine sehr spezielle Interpretation des Begriffes "Ort". Wir haben z.B. nur eine Adresse für unsere 2 Gebäude mit 12 Räumen. Da hilft eine Ortsangabe, die per Google-Maps auswertbar ist, nicht viel.Apropos: "Hilfreich" sind bei uns Ortsangaben, die auf gemeindeintern übliche Begrifflichkeiten zurückgreifen "unter der Kirche", "Neben dem Wirtschaftstraum", .... ich wüsste nicht, wie das gemeindeübergreifend formalisiert werden sollte.
-
@simon2 sagte in Auslaufende Ressourcen:
Nunja - das ist aber dann quasi Glückssache, ob das funktioniert - bzw. muss man dann manuell auf die "Kartenapp" anpassen
Ja, definitiv Glückssache! Ich sag ja auch nicht, dass ich es so wie es ist gut finde, wollte nur darauf hinweisen, dass das Ortsfeld in den Ressourcen an die ical übergeben wird und dadurch eben nicht ein x-beliebiges Freitextfeld ohne Funktion ist.
Ideal ist es bei Weitem nicht, zumal bei einem Termin mit mehreren Ressourcen alle Ortsangaben hintereinander gesetzt werden. Sinnvoll ist das meiner Meinung nach nicht.
Wesentlich besser ist es, wenn der ical Datei die neu hinzugekommende Ortsangabe aus dem Kalender mitgegeben wird und nicht die aus den hinterlegten Ressourcen. Aber das ist ein anderes Thema und dazu gibt es auch bereits andere Forenbeiträge. -
@simon2 sagte in Auslaufende Ressourcen:
Solange klar ist, dass Freitextfelder immer nur von Menschen interpretiert werden, habe ich kein Problem mit einer "individuellen Interpretation".
... und wo Information nicht (nur) von Menschen interpretiert werden, sollte man keine Freitextfelder (oder zumindest keine Freitexteingaben) verwenden.leider ist das nicht wirklich klar. Spätestens bei einer anstehende Migration oder Ankopplung externer System kommt der Wunsch auf, auch solche Felder zu verarbeiten. Da reicht es, dass man den Freitext verarbeiten muss (dazu gibt es brauchbare Techniken). Wenn man aber die Bedeutung nicht kennt wegen einer 'individuellen Interpretation', d.h. wenn das Label 'ort' heisst, manchmal aber eine E-Mail drin steht, wird da deutlich komplexer. Darauf wollte ich hinweisen.
Aber nun genug von meiner Schnittstellenphilosophie.
dem schließe ich mich an
-
@bwl21 sagte in Auslaufende Ressourcen:
...leider ist das nicht wirklich klar. Spätestens bei einer anstehende Migration oder Ankopplung externer System kommt der Wunsch auf, auch solche Felder zu verarbeiten. ....
Dann muss man aber sowieso erst einmal eine "Datenbereinigung" durchführen (denn woher sollte in den Jahren vorher schon sichergestellt sein, dass man das nun plötzlich erforderte Format eingehalten hat?).
BTW: Ich glaube, hier sprechen wir von ein paar Handvoll Daten - die kann man in so einem Fall schon relativ einfach "glattziehen".