Chriz

Ich denke das willst du nicht, du kannst das zwar mit dataTable (jQuery Plugin) machen, aber bei einigen hundert Einträgen wird das dann schon sehr träge.

__________________
"Nuschel ich?" - "Was?"

Mister Ad

archer42

Wieso sollte das träge werden?

Wenn sich das "clientär" abspielt sollten doch genügend Ressourcen da sein, zumindest würde mir das mein Laien Wissen so sagen

Für das Sortieren benutze ich Tablesorter, dies sah mir etwas "leichter" aus.

Das Selektieren werde ich mit jQuery-UI umsetzen, allerdings mache ich mich damit morgen dran.

Wenn man tausende Einträge handeln muss, bei welchen man zwischen Seiten umschalten muss, dann fliegt javascript aus Prinzip raus,
aber bisher würde mir nur "Pfusch" einfallen, was die Tabellenfunktionen angeht.

Trainmaster

Was verstehst du bitte unter Pfusch?

archer42

Naja, wenn ich

• Sortierfunktion
• Auswahlfunktion
• Detailansicht

Implementiere, dann habe ich als Ergebnis eine vollgestopfte Action (beachte Umschalten von ASC auf DESC!) mit vollgestopftem Routing.
Abhilfe würde ein eigener "TableManager" schaffen, den ich allerdings nicht sehr positiv gewillt bin umzusetzen...

Chriz

JavaScript ist immer noch JavaScript. Es geht nicht nur darum, dass du alle Clientmaschinen unnötig belastest, sondern auch noch bei allen ein erhöhtes Datenaufkommen verursachst. Aber das wäre eher nebensächlich. Du merkst es einfach nach ein paar tausend Einträgen.

__________________
"Nuschel ich?" - "Was?"

dennis81

Das DataTables Plugin sorgt in der Tat bei einigen Hundert Einträge für ein Performance-Lag. Man kann es, je nach Aufbau der Tabelle mehr oder weniger leicht, mit serverseitiger Verarbeitung der Sortierung umgehen.

__________________
Es ist schon alles gesagt! Nur noch nicht von allen! (Karl Valentin)
Wenn du eine weise Antwort verlangst, musst du vernünftig fragen. (Johann Wolfgang von Goethe)

archer42

Ich habe mich jetzt auch nochmal damit beschäftigt und wie gesagt wurde, kommt man spätestens beim Umschalten der Seiten nicht mehr drum herum bzw. will man nicht mit der Limitierung leben, dass man alles auf einer einzelnen Seite darstellen muss.

Zwei Probleme ergeben sich konkret daraus (zumindest bei Symfony2):
1. Routing
Da so eine Funktion über Slashes (contacts/{column}/{order}) meiner Ansicht nach "scheußlich" aussieht, wäre ich eher für etwas wie: contacts?column={column}&order={order}, da ich aber nicht gefunden habe, wie man bei Symfony im Routing Zeichen escaped, stellt dies ein Problem dar
2. Umschalten zwischen ASC und DESC
Hierzu müsste die ausgewählte Spalte bei ASC auf DESC wechseln.
In den Sinn kämen Javascript, da PHP sehr viel "Boilercode" produzieren würde zumindest wenn man es über die Templates machen würde.

Ich habe mir auch bereits Bundles wie Paginator angesehen, diese sind mir aber zu "eigensinnig".
Gibt es außer $_GET, $_POST, Js noch weitere Möglichkeiten der Sortierung?

Trainmaster

Scheußlich - Boilercode - Eigensinnig. Deine Probleme möchte ich mal haben. Oder ... doch lieber nicht.

Zu 1.) Stehst du auf Kriegsfuß mit Dokumentationen? Im Kapitel zu Routing findest du das gewünschte: http://symfony.com/doc/2.0/book/rout...-query-strings. Dieses "komische" Fragezeichen in der URL und die darauffolgenden "seltsamen" Verkettungen mittels & und = nennt man auch den Query String einer URL. Was du mit einer Konstruktion wie "contacts?column={column}&order={order}" bezwecken willst, ist mir auch ein Rätsel. Hier scheint mir wirklich ein grundlegendes Verständnis zu fehlen.

Zu 2.) Was meinst du, wozu es $_GET, $_POST und Javascript gibt? Damit es nicht genutzt wird?

archer42

Du scheinst ja auf Kriegsfuß mit ganz anderem zu stehen

Trainmaster

Du darfst von mir denken, was du möchtest. Letztlich scheiterst du an dir selbst, wenn du einerseits das Wissen, dass von anderen in mühevoller Arbeit zusammengetragen, aufbereitet und präsentiert wird, nicht zu Nutzen und andererseits mit Verweisen auf dieses bestehende Wissen nichts anzufangen weisst.

Hier werden dir Hinweise und Lösungsansätze gegeben, welche du teils aus nicht nachvollziehbaren Gründen ablehnst.

Im ersten Schritt wurde dir dabei geholfen, den Code deines Repository wesentlich zu verkürzen. Meiner Meinung nach eine erhebliche Verbesserung verglichen mit dem ursprünglich Code. Dass du das nicht ganz so siehst, hat mich schon gewundert. Zitat:
Im zweiten Schritt kritisiert du, dass die Actions zu vollgestopft sind und lieferst zugleich eine gängige Lösungsvariante, welcher du dich aber aus mir unerklärlichen Gründen versperrst. Wieso bist du nicht positiv gewollt, eine Manager-Klasse zu implementieren? Ich frage mich, was du gedenkst, wo die Applikationslogik untergebracht ist? Wenn du der Meinung bist, dass in Actions auf Kontrollstrukturen weitestgehend zu verzichten ist, sind wir in diesem Punkt d'accord. Ich kann dir nur empfehlen, trotz deiner Zweifel eine Manager-Klasse und damit eine weitere Schicht zu implementieren. Zwar mag es mit mehr Arbeit verbunden sein, doch erreichst du damit auch, bei gelungener Implementierung, eine verbesserte Übersichtlichkeit und Wiederverwendbarkeit deines Codes.

Zu den anderen angesprochenen Punkten habe ich bereits meine Meinung gesagt.