Tabellen - Standardsortierung als Textfeld

[tbaddade]

Bis jetzt kann man nur eine Spalte auswählen. Optional könnte man ein Textfeld anbieten, so dass man die Sortierung selbst festlegen kann. Bsp.: country, zip, title

[alxndr-w]

Das stimmt. Sobald eine beschränkte prio im Spiel ist, wäre das Gold wert: Dann könnte man erst nach Beschränkung und dann nach prio sortieren - und dadurch die Einträge korrekt gruppiert und sortiert ausgeben.

[dergel]

hmm.. also ganz frei ? sowas will ich eigentlich so viel wie möglich vermeiden.. fehler etc.

[alxndr-w]

etwas Offtopic:

An mehreren Stellen in YForm und Redaxo würde sich dafür JQuery Chosen anbieten. Das würde die freie Eingabe von Feldern, aber dennoch datenbankgestützt, extrem erleichtern.

• Auswahl von Feldnamen in den Tabelleneigenschaften, bei be_relation und diversen anderen Values / Validates
• Darstellung von kommagetrennten Werten (wie bspw. bei der Eingabe von Dateiendungen) in Form von Tags
• Durchsuchbare Dropdowns, bspw. beim Prio-Feld. Manchmal habe ich Formulare mit 30 Feldern und muss lange suchen, wo sich das richtige "Nach $feld" befindet.

[skerbis]

oder select2 https://select2.github.io/examples.html

[dergel]

und order by müsste auch irgendwie rein .. die varianten sind eigentlich ganz cool (ich glaube aber, dass die reihenfolge nicht üübernommen wird, oder) ..

[alxndr-w]

Stimmt, das mit der Reihenfolge könnte ein Problem werden... Diskussion: https://github.com/harvesthq/chosen/pull/197

Lösung (chosen): http://labo.tristan-jahier.fr/chosen_order/

[alxndr-w]

Für ASC/DESC könnte man ja auch (notfalls) die Werte doppelt im select2 oder chosen hinterlegen, also [field1 ASC] [field1 DESC] und mit den richtigen Namen ausstatten [Feldname1 aufsteigened][Feldname1 absteigend]

[alxndr-w]

Das Feature wäre für yform_usability relevant, wenn man beschränkte Prio-Felder hat.

[gharlan]

Wenn du einfach nur nach Prio sortierst, passt es nicht?

[alxndr-w]

id, name, nam2, unit, category, prio

Felddefinition:

Nein, die zusätzliche Beschränkung wird übergangen.

[gharlan]

Wenn ich ein beschränktes Prio-Feld benutzt habe, dann bisher immer nur in Tabellen, die nur über ein "multiple 1-n"-Feld erreichbar waren. Also habe die Tabellen in der Navigation immer ausgeblendet. Also konnte man bei mir die Tabelle auch nur beschränkt pro Kategorie öffnen, also immer nur ein Prio-Bereich.

[gharlan]

Bei dir sind die Prios übrigens vor allem auch falsch. Denn sie sind ja gar nicht pro Kategorie aufsteigend, sondern Kategorieübergreifend. Ist also nicht nur ein Anzeigeproblem (Sortierung).

[alxndr-w]

Das ist yform_usability geschuldet, weil ich in dem Screenshot noch Datensätze sortiert habe, um zu schauen, ob das irgenwie greift.

[alxndr-w]

Also konnte man bei mir die Tabelle auch nur beschränkt pro Kategorie öffnen, also immer nur ein Prio-Bereich.

Wie machst du das?

[gharlan]

Bei der Tabelle auswählen "In Navigation verstecken" (oder so ähnlich). Dann in der Kategorie ein "multiple 1-n"-Feld anlegen (falls nicht schon vorhanden), dort "In Liste verstecken" NICHT anhaken. Dann sollte in der rex_list zur Kategorie-Tabelle in jeder Zeile ein Link zu den zugehörigen Datensätzen sein.

[gharlan]

Übrigens, das Grund-Issue hier unterstütze ich. Fände also eine flexiblere Sortierauswahl auch toll, wie auch immer man es am besten löst.

[alxndr-w]

Sorry, ich versteh's noch nicht. Welche Tabelle meinst du bei "Tabelle"? Die Tabelle mit den Artikeln sollte nicht in der Navigation versteckt werden, sondern bearbeitbar bleiben. be_relation-Felder lassen sich auch nicht sortieren, wie soll das mit der Prio funktionieren?

[gharlan]

Vorweg: Es kann schon sein, dass es für dich, in deinem Fall nicht passt. Ich meinte ja nur, bei meinen bisherigen Fällen, wo ich beschränkte Prio-Felder genutzt habe, hatte ich sowieso so eine Struktur, wo sich die entsprechende Tabelle nur mit Beschränkung betrachten ließ.

Habe mal auf die Schnelle einen solchen Fall konstruiert, um es anhand von Screenshot zu zeigen. Habe zwei Tabellen, angelegt, Produkte und Produkt-Kategorien. Die Produkt-Tabelle lasse ich in der Navigation verstecken. Die Navi sieht also so aus:

In den Produkten gibt es ein Relationsfeld category_id (select single). In den Kategorien gibt es eine Rückreferenz darauf über ein "Popup (multiple 1-n)"-Feld. Dieses lasse ich in der Liste NICHT verstecken.

Wenn man also über die Navigation die Kategorien öffnet, erhält man das:

Bei jeder Kategorie gibt es den Link "Produkte". Über diesen Link kommt man dann zur Produkttabelle, aber beschränkt auf diese eine Kategorie:

Hätte ich jetzt ein beschränktes Prio-Feld (beschränkt auf die Kategorie), wäre also in jeder Ansicht der Produkttabelle immer nur ein solcher Teilbereich der Prios zu sehen. Somit passte es bei mir dann auch, wenn ich die Tabelle einfach nur nach Prio sortieren lasse.

Klar, der Nachteil ist, dass es umständlicher ist, zur Produkttabelle zu gelangen. Aber wie gesagt, in den Fällen, wo ich bisher beschränkte Priofelder genutzt habe, wollte ich das sowieso so haben, dass die jeweilige Tabelle nicht als ganzes erscheint, sondern immer nur für den Teilbereich.

[alxndr-w]

Ach so geht das! (dieser Link zu "Produkte") Ich glaube, das ist ein Feature, das keiner kennt außerhalb von Yakamara.

(Umgeht das Problem, Featurewunsch bleibt trotzdem bestehen)

[gharlan]

Ein paar müssten es schon kennen, habe es jedenfalls schon häufiger erklärt, aber waren eigentlich immer Einzelgespräche. Daher kann es schon sein, dass es der Masse unbekannt ist. ;)

Eingeführt wurde es in XForm 4.10: https://github.com/yakamara/redaxo_xform/commit/6879d61e07f84f4ca36c978d8f89e1396e8ecb6a

[alxndr-w]

Nichtsdestotrotz habe ich gerade den Fall, bei dem ich erst nach Datum sortieren möchte (Termine), und dann nach prio (Termine auf Anfrage) - es wäre klasse, wenn man hier zumindest bis zu 3 Sortierungen angeben kann oder optional eine andere Lösung findet wie oben angedacht...

[tbaddade]

Ich wäre für das freie Textfeld, da kann man auch direkt ASC und DESC angeben.

sowas will ich eigentlich so viel wie möglich vermeiden.. fehler etc.

Dann müsste man das bei den Values auch nachziehen, sodass dort eben keine eigenen SQL-Statements mehr hinterlegt werde können. Wobei ich die freie Eingabe eher als Vorteil sehe und vermutlich auch nur von Devs genutzt werden.

[alxndr-w]

@tbaddade du hast recht. Man müsste auch abfangen, ob es bspw. Felder nicht mehr gibt, wenn sie gelöscht wurden. Freitext ist sicher am besten.