Ich bin gerade nicht sicher, ob du das, was ich gepostet hatte, mal gestartet hast. Aber es berücksichtigt auch die „historie“ (außer, wenn du die gerade umgekehrt berücksichtigen willst). Das volle Beispiel unter CommonUI/src/test/java/de/javagl/common/ui/table/test/TableSortingTest.java at master · javagl/CommonUI · GitHub zeigt sogar die schönen Header für die „historischen“ Sprtierkriterien. (Ist dir eigentlich aufgefallen, dass man bei sowas normalerweise nie Arrays.sort aufrufen muss?)
(EDIT: Nur aus Neugier hab’ ich gerade mal geschaut: Wenn man das ganze startet, wurde schon 383 mal sort aufgerufen, und bei jedem Sprtieren kommen nochmal genausoviele Aufrufe dazu. Schreib’ doch mal JavaDocs an die Methoden, bin gespannt, was da drin stehen würde…)
Nun. Auch wenn ich gerade das Gefühl habe, dass du mich durch gespielte Dummheit dazu überlistest, hier mehr Zeit zu verschwenden, als das ganze wert ist, muss ich immernoch die Möglichkeit in Betracht ziehen, dass da nichts gespielt ist. Dass trotzdem jegliche Interaktion mit dir komplette Zeitverschwendung ist, ist davon nochmal unabhängig. Manchmal ist ja „egal“ ob man ein bißchen Zeit verschwendet. Und dass ich mich wiederhole, ist auch nicht schlimm. In dem geposteten Code sind auch einige Wiederholungen. Und manchmal ist ja „egal“, ob man ein bißchen Zeit verschwendet. Und es ist manchmal auch nicht schlimm, wenn man sich wiederholt. Das ist zwar manchmal Zeitverschwendung, aber manchmal ist ein bißchen Zeitverschwendung ja nicht schlimm. Und wenn du das so liest, und dir denkst "Ja, was soll das Gelaber mit den ganzen Wiederholungen? Das zu lesen ist Zeitverschwendung! " dann denke immer daran: Manchmal sind Wiederholungen nicht schlimm, und manchmal ist es auch nicht schlimm, wenn man ein bißchen Zeit verschwendet.
Dein kompletter Ansatz ist FALSCH
Ja, ich könnte Kritik auf allen Ebenen üben. Aber wenn ich „ganz oben“ anfangen soll, dann muss es eben diese Ebene sein. Dein kompletter Ansatz ist von vorne bis hinten unsinnig und falsch (und der ganze Quäl-Kot, mit dem du uns hier belästigst, ist zumindest teilweise darauf zurückzuführen).
Das Modell speichert die Daten. Die Daten sind nicht 739.6MiB oder 1.72% - auch wenn das das ist, was zufällig von irgendeinem Kommando auf der Konsole ausgegeben wird. Die Daten sind 775526809 oder 0.0172. Ja, wenn du die „alte“ Darstellung dann haben willst, brauchst du einen eigenen TableCellRenderer, aber den kann man recht generisch (und wiederverwendbar) implementieren.
Ja, was du „findest“ ist halt wurscht. Daumen drücken, dass
docker stats nie „schlau“ wird und die Ausgabe von der Sprache des Systems abgängig macht, und du dann auf einmal 1,23% dort stehen hast
niemand dieses Programm benutzt, und genau fordert, dass die Ausgabe mit Kommas angezeigt werden soll
Niemand einen breakpoint in sort setzt, und dann die Fenstergrößde ändert…
Nie wieder irgendjemand irgendwas an diesem Code ändern muss
Die Frage nach dem „Benutzen“ und „ändern“ stellen sich aber nicht. Ich weiß, wie entspannend es sein kann, wenn man Code schreiben kann, bei dem man keinen Anspruch an sich selbst haben und praktisch direkt in die Mülltonne coden kann.
Ich meine das aber ernst. Lass doch mal die Sticheleien weg. Die Ausgabe von docker stats ist immer gleich, und mit deinem Vorschlag würde man die Daten zweimal halten. Deshalb möchte ich bei meinem Ansatz bleiben, weil dieser nicht schlecht ist (imho).
… Oder du würdest sagen, dass es ganz einfach ist, mehrere Renderer zu schreiben.
Und jetzt ein kleines Spielchen: WIr schreiben beide mal eine Funktion, die die Summen und Durchschnittswerte aller Spalten anzeigt (meinetwegen nur auf der Konsole ausgegeben).
Auf die Plätze… fertig… (bei mir: zwei Minuten. Drei vielleicht…)
das Suffix B für Byte oder „“ für nicht Byte-Werte.
Ich schreibe gleich mal ein Hybrid-Modell, dass die Rohdaten und formatieren Daten hält. Zusammen mit einem sehr einfachen Renderer sollte dann ein Custom-Sorter auch entfallen.
Das wäre doch das nächste Problem, wie bringst das in der Tabelle unter?
Die fast schon wieder amüsante Mischung aus Naivität und Dreistigkeit überrascht mich nicht. Du rotzt hier irgendwelchen Dreckscode ins Forum, ich kritisiere einen Punkt, und zeige, wie man es besser machen kann, und du beschwerst dich, dass ich dir nicht deine komplette Anwendung sauber neugeschrieben habe. („Terabytes fehlen da auch noch!!!111einseinself“).
Woraus besteht die Tabelle? Aus Zahlen. Die kann man sortieren und meinetwegen bunt machen…
Nenn’ vielleicht mal Argumente. Z.B. warum du die Daten sortierst. Ein RowSorter sortiert nicht die Daten, sondern ermöglicht eine sortierte Sicht auf die Daten. Also, was machst du richtig, was jeder andere Entwickler falsch macht?
Das stimmt nicht. Ein RowSorter macht das, was der Name sagt, nur normalerweise implementiert meinen keinen eigenen, sondern nimmt schon vor-implementierte Klassen.
Hatten wir doch schon … weil eine normale Sortierung hier nicht reicht.
Jetzt habe ich mich doch verleiten lassen, zu antworten.
Die Daten sind so, wie sie sind. Sie stehen in einer bestimmten Reihenfolge im Modell. Der RowSorter verändert diese Reihenfolge nicht. Er bewirkt nur, dass die Zeilen in einer nach verschiedenen Kriterien sortierten Reihenfolge angezeigt werden. Der RowSorter sortiert nicht die Daten. Er sortiert die Sicht auf die Daten.
weil eine normale Sortierung hier nicht reicht.
Beschreib’ mal technisch (meinetwegen sogar mit Formeln) den Unterschied zwischen einer „normalen“ Sortierung und einer „nicht-normalen“ Sortierung. Das Standardverhalten einer sortierten JTable ist schon, dass die „Historie“ berücksichtigt wird (man könnte höchstens über die Reihenfolge streiten). Und wenn man einen passenden Renderer für den Header verwendet, sieht man auch die primären, sekundären, und tertiären Sortierkriterien. Wie in dem Test aus CommonUI:
Zuerst wird nach „B“ sortiert. Dann nach „C“. Dabei wird „B“ als sekundäres Kriterium beibehalten (d.h. immer wenn „C“ gleiche Werte hat, wird nach „B“ sortiert). Dann wird die Reihenfolge für „C“ umgedreht. Dabei bleibt „B“ als sekundäres Kriterium beibehalten (d.h. immer wenn „C“ gleiche Werte hat, wird nach „B“ sortiert).
Bisher hast du nichts gesagt, was den Murx, den du da verzapfst, auf einer technischen Ebene rechtfertigen würde.
Danke, dass dein Ton wieder freundlicher geworden ist.
Nein, ich möchte jetzt kein formales Pflichtenheft, das die funktionalen Anforderungen genau definiert, schreiben, zumal ich glaube, dass du mich eigentlich bereits richtig verstanden hast, und also schon weißt, worum es geht, und evtl. den „sticking point“ schon kennst.
Kurze Rückfrage: Oben in der Animation klickst du erst auf B, dann auf C, und die Sortierungsrichtungspfeilchen (v und ^) bleiben in beiden Spalten erhalten. Ist das nur ein Darstellungsfehler von deinem GIF-Generator?
Wieder nur eine Frage der Darstellung. Die Sortierkriterien (im Sinne der „SortKeys“) bleiben erhalten. In der Standard-Impementierung des JTable-Header-Renderers werden sie nur nicht angezeigt. Im Test, mit dem das GIF erstellt wurde, wird ein SortOrderTableHeaderCellRenderer verwendet. Der zeigt sie halt an.