nicht angemeldet
Hi!
Aber so vier Sprachen in einander schachteln.... hier also PHP, HTML, CSS und JS und dabei keine Zwischenspeicherung zu verwenden (deren Kontext-Wechsel man dann Ebene für Ebene auflösen könnte) ist halt irgendwie anstrengend.
Deswegen lieber gleich ein ordentliches Design als all diese Probleme mit invalidem Code oder einem aufwendigen dafür aber validen Workaround.
Mal angenommen, wir bleiben bei einer Backend-Lösung (MVC) und stellen die Daten vor der Darstellung bereit. Philosophische Frage: Wo bauen wir die Sortierfunktion ein, in der Bereitstellung der Daten (Konstruktor) oder in die Prozedure zur Darstellung?
Was hat denn ein Konstruktor mit der Bereitstellung von Daten zu tun? Wenn du MVC als Lösungsmuster verwendest, dann spielt darin ein Konstruktor keine Rolle, denn das MVC-Muster legt nicht fest, dass es mit OOP realisiert werden müsse. Wenn du OOP verwendest, ist fraglich, ob ein Konstruktor der geeignete Platz für die Erledigung einer Aufgabe jenseits der Initialisierung des Objekts ist.
Wenn die Daten sowieso für jeden Request neu abgefragt werden, und die Reihenfolge für die Verarbeitung im abfragenden Script keine Rolle spielt, kann man sie ja gleich sortiert aus dem DBMS holen. Das setzt allerdings voraus, dass das DBMS nicht nur blind den Inhalt speichert sondern über die verwendete Zeichenkodierung Bescheid weiß und die Sortierregeln korrekt anwenden kann.
Lo!