Hallo, leider etwas spät, aber mir ist noch aufgefallen, daß ihr die noch nicht so alte Funktion, die Art der Aggregierung auf alle rechts folgenden Spalten mittels eines Klicks auszudehnen, offenbar vergessen habt zu migrieren. Oder muß man das jetzt woanders auswählen?
Außerdem hätte ich mir gewünscht, daß man irgendwie die Zeile mit den Spaltennamen fixieren kann à la Excel. Wenn man nach einem Script Error sucht und ihn in der 580. Zeile findet, wäre es gut, wenn man sieht, in genau welcher Spalte man da ist. Klar kann ich vorher die Spalte farblich hinterlegen oder mir die Vorschau als Excel runterladen, aber falls ihr eine Chance seht, wäre das sicher eine schöne die übersichtlichkeit erhöhende Funktion.
Ansonsten: Lob! Gerade das Filtern auf bestimmte Spalten ist richtig klasse.
Bei der Aggregat-Funktion fehlt diese leider noch. Wir werden das noch hinzufügen. Bei allen anderen Funktionen kannst du die Funktion jetzt schon über das Dreipunkt-Menu nach rechts oder links übernehmen.
Ich bin mir noch nicht ganz sicher was du meinst. Die Spaltennamen sollten schon beim scrollen ganz oben angezeigt werden. D.h. man sollte auch jetzt schon relativ einfach erkennen können, in welcher Spalte sicher der Fehler befindet.
@synesty-Torsten im alten Mapper kam immer dieser nette Hinweis, wenn im Wert Zeilenumbrüche standen, mit einem Link, um direkt die String-Funktion „trimmen & Umbrüche entfernen“ zu setzen.
Den Hinweis gibts immer noch, aber die Funktion kann ich nicht mehr triggern. Ich hab die sehr gerne benutzt, können wir das zurück bekommen?
Wenn ich im Mapper Spalten verschiebe (STRG + L), dann hakelt das etwas, wenn ich nach oben außerhalb des Sichtbereichs will, also gescrollt werden muss.
Danke das nehmen wir mit auf die TODO.
Als Workaround kannst du auch mal versuchen das Element an diese Stelle zu ziehen und zu halten. Da scheint es dann zu scollen (getestet im Chrome).
Wenn ich im Mapper Spalten verschiebe (STRG + L), dann hakelt das etwas, wenn ich nach oben außerhalb des Sichtbereichs will, also gescrollt werden muss.
Dafür ist nun ein fix live gegangen, welcher beim sortieren die Suchleiste ausblendet (und kurz nach dem sortieren wieder einblendet).
Die neuen Buttons bei den Spaltennamen sagen mir ehrlich gesagt nicht zu.
ich gehe egtl davon aus, dass nichts gespeichert wird, bevor ich nicht „Konfiguration abschließen“ drücke. Warum hier diese zweite Ebene?
es passiert mir regelmäßig, dass ich nen Spaltentitel anpasse, die Knöpfe ignoriere, und dann „etwas“ tu (Spalten zufügen triggert es z.B., glaube ich), und die Spalte ihren Namen wieder verliert und wieder empty heißt.
Was waren die Beweggründe das auf die Art zu ändern?
es ohne Frage nun etwas aufwendiger geworden den Spaltentitel umzuändern. Direkt vorab schonmal zwei Hinweise:
A)
Wenn du den Namen änderst und „Enter“ drückst, wird das Speichern für die aktuelle Spalte getriggert - du musst also nicht zwangsweise mit der Maus den Button klicken.
B)
ich gehe egtl davon aus, dass nichts gespeichert wird, bevor ich nicht „Konfiguration abschließen“ drücke.
Okay ein Punkt den wir irgendwie im UI besser kommunizieren sollten (z.B. durch eine anderes Button-Label) → drückst du beim umbenennen auf speichern, dann wird der Name nicht schon in der MappingDefintion (=der JSON Klops der dein fertiges Mapping beschreibt) gespeichert, sondern nur in deiner aktuellen Konfiguration. Gehst du also nachdem du eine Spalte umbenannt hast aus dem Mapper raus ohne auf „Konfiguration abschließen“ zu klicken, wird auch nichts gespeichert.
Nun zu deinen Punkten/Fragen:
Der Grund für diese Neuerung war, dass es zu Problemen kommen konnte, sobald eine Gruppier- oder Sortierspalte gab und eine andere Spalte (kurzzeitig) den gleichen Namen hatte.
Hier hat ein Kunde berichtet, dass es bei ihm zu einem ungewollten Umsetzen der entsprechenden Gruppier/Sortierspalte kam.
Wir konnten das intern nicht nachstellen, vermuten aber das es hier durch ein Laufzeitproblem wie z.B. „Browser hat etwas länger gebraucht den Namen umzusetzen“ zu den Problem kam.
Da das auch an individuellen Faktoren liegen könnte (Rechnerperformance, Browserauslastung etc.), haben wir uns hier für den sichersten Weg entschieden und das ganze mittels eines dedizierten „Speichern“ gelöst, denn hier wird dann explizit bei „Klick“ der Abgleich gemacht.
Andere Felder als der Name besitzen aktuell keine Referenzen zu anderen Funktionen (aus diesem Grund ist hier also die Eindeutigkeit des Titels enorm wichtig), deswegen die Sonderbehandlung für dieses eine Feld.
Wir schauen uns das an und versuchen eine Lösung zu finden.
Wir stecken auch nochmal teamintern die Köpfe zusammen und schauen, ob wir doch noch eine einfachere Lösung finden können die genauso sicher ist wie der aktuelle Wurf.
wie versprochen haben wir (gleich gestern) nochmal intern eine Runde gedreht. Es ist nun folgendes dabei herausgekommen:
Wenn das Titelfeld den Fokus verliert (=du klickst/tabst woanders hin), wird nun ebenfalls der Titel übernommen.
„ESC“-Taste bricht das editieren ab (bildet also das Gegenstück zu „Enter“)
Wir haben das Label „Speichern“ in „Übernehmen“ abgeändert
Wir hoffen das mit 1. die Benutzerführung wieder im etwa dem entspricht, wie es vor der Anpassung war. Mit 2. wollten wir erreichen, dass beide Funktionen im Editieren auch komplett mit der Tastatur steuerbar sind.
Um die Datenintegrität zu gewähleisten, wird nach wie vor ein Fehler geschmissen, wenn eine Spalte so benannt wird wie eine andere Spalte im Mapper (also nach Klick auf „Übernehmen“, Enter oder rausklicken).
Der Fokus wird dann automatisch in den Titel zurück gesetzt. An dieser Stelle gibt es also kein Entkommen mehr! → Man muss dann einfach einen eindeutigen Namen wählen, denn ansonsten ist das Mapping (wie ja schon seit anbeginn des Mappers) ungültig.
–
TL;DR → Wir hoffen:
das wir die Neuerung mit Hilfe deines Feedbacks so verpacken konnten, dass sich Nutzer davon nicht gestört fühlen
Fehler und Bugs die durch doppelte Spaltentitel entstehen können zu minimieren
Die Änderungen sollten spätestens morgen live gehen.
ich habe auch noch eine kleinen Wunsch zu dem Feature „Alle Zeichen anzeigen“. Im Moment muss man diese Funktion ja immer manuell für jede Spalte aktivieren. Ist es möglich, die Default-Einstellung irgendwie konfigurierbar zu machen?
Wenn ich die Option hätte, würde ich die Funktion gerne immer aktiv haben und nur bei Bedarf deaktiveren. So handhabe ich es auch in Notepad++.
es wurde mittlerweile ein Update eingespielt, welches beim ändern der Anzeige der Unsichtbaren Zeichen den aktuellen Status speichert. Dieser Status gilt für alle Mapper und alle CodeAreas (z.B. also auch im TextHTMLWriter etc.)
Durch die Umstellung machte das „Zeichen für eine bestimmte Spalte anzeigen“ keinen Sinn mehr, d.h. es wird jetzt für das ganze Mapping an- bzw. ausgeschaltet. Einhergehend ist die Einstellung (im Mapper) nun an eine etwas zentralere Stelle gewandert.
sehr cool, so habe ich’s mir vorgestellt. Nur beim Wert-Feld im Mapper ist es etwas misslungen, finde ich.
Hier fehlt nun das Line/Word wrapping, ist das vorgesehen? So muss man nahezu immer den Code-Editor benutzen, damit der gesamte Code angezeigt wird.
Ich würde hier eigentlich weiterhin das Wrapping erwarten, könnte aber auch ohne Wrapping leben. Dann sollte das Feld in der Breite veränderbar sein. Grade passen nur 30 Zeichen in eine Zeile, das reicht nahezu nie aus.
Und das Skriptfeld wird von der Einstellung noch garnicht betroffen.
Das mit den fehlendem Wrapping war auch schon vorher so, ist aber wsl. einfach durch die manuelle Aktivierung nicht so oft/noch nicht aufgefallen.
Ohne jetzt zu sehr ins Detail zu gehen → wir haben zum Anzeigen der „Invisibles“ eine bereits vorhandene Funktion des CodeEditors wiederverwendet, bei dem das Wrapping/Folding ausgeschaltet sein muss.
Mit Einführung der „permanenten“ Darstellung und der von dir beschriebenen Probleme müssen wir das ganze aber nochmal neu denken. Denn es ist keine Frage das damit viele Unschönheiten zum Vorschein kommen.
Wir packen uns das auf die ToDo-Liste und versuchen das irgendwie gangbar zu bekommen.