Ankündigung

Einklappen
Keine Ankündigung bisher.

Template-Logiken trennen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Template-Logiken trennen

    Hi,

    ich arbeite an einem Projekt, welches PHP für das Backend und tonnenweise JS (Angular, jQuery und zig andere Bibliotheken) für das Frontend verwendet.
    Die Applikation ist relativ datenbanklastig und ich will daher unnötige Queries vermeiden.

    Beispiel:
    Jeder eingeloggte Benutzer hat eigene Notizen. Für Notizen gibt es einen kleinen Button - klickt man auf diesen Button, holt sich die Applikation via Ajax die Daten die es haben will. Ähnlich verfahre ich auch bei anderen Bereichen - alles, was nicht "auf den ersten Blick ersichtlich ist", wird dynamisch nachgeladen.
    Die andere Seite ist der "ersichtliche" Teil. So befindet sich z.B. im Dashboard ein Feed von Actions. Das wird nicht über Ajax geladen, sondern ist direkt im Response mit drin.

    Ich verwende momentan Laravel als Framework fürs Backend. Problem aber ist, dass ich in manchen Template-Dateien zwei verschiedene Template-Sprachen habe: zum einen die von Laravel (ggf. irgendwann mal Twig, momentan noch Blade) und die für JS von Angular. Sieht dann in etwa so aus:

    Code:
    {{{ trans('general.notes') }}}
    
    <table ng-controller="NotesController">
      <tr ng-repeat="note in notes">
        <td><% note.title %>
      </tr>
    </table>
    Da Angular und Blade die selbe Template-Syntax verwendet, hab ich Angular umkonfiguriert und verwende hierfür jetzt <% respektive %>.

    Man sieht aber schon: ich habe hier zwei Template-Sprachen in einer Datei, was mir irgendwie nicht so ganz passt.

    Wie kann ich sowas denn lösen? Meine eigenen Lösungsansätze wären:
    1) das UI komplett vom Backend trennen; d.h. es wird alles über eine API geholt. Problem dabei: ich erachte es als relativ sinnfrei Dinge wie Übersetzungen oder ähnliches via API zu holen (der Payload wäre riesig wenn ich so nachdenke).
    2) damit zu leben dass es solche Dateien nunmal gibt, sind ja nicht ewig viel

    Gibts sonst Lösungsansätze für sowas?

    Danke


  • #2
    Hallöchen,

    mit der Konfiguration der Template-Syntax hast du ja bereits eine akzeptable Lösung für dein Problem gefunden. Ich persönlich lasse mich auf einen solchen Mix eigt. nur noch dann ein, wenn der JavaScript-Anteil der Anwendung minimal ist. Bei komplexen Ajax-Anwendungen hole ich mir mittlerweile alles per Ajax-Requests vom Server und nutze diesen nur noch als API für den Datenzugriff. Bei großen Datenmengen, die deine Anwendung für die Initialisierung braucht, macht es auch durchaus Sinn, diese im Response direkt in einem Script-Element auszuliefern und später auszuwerten. Bspw.:
    Code:
    <script>
        // generated by backend
        var initialData = {
            ..
        };
    </script>
    Viele Grüße,
    lotti

    Kommentar


    • #3
      Es kommt drauf an.

      Aus meiner Sicht hast du noch nicht ausreichend Informationen geliefert, damit ich hier eine Empfehlung geben kann.
      Basierend auf deinen Aussagen destilliere ich folgende Annahme:
      - Es ist kein Problem deine User mit viel Javascript zu belasten.
      - Deine Server sollen so gut es geht geschont werden.

      Ein großer "Vorteil" (wenn man es denn so sehen möchte) bei der traditionellen Verfahrensweise mit HTML durch PHP ist, dass du nur einmal den Effort zum Aufbau der Seite übernehmen musst. Du musst dich nicht um den Abbau und den Umbau kümmern. Das macht Webentwicklung und Resourcenmanagement (up to a certain extend) zum no-brainer.

      Meiner Erfahrung nach erfordern sehr javascript-lastige Seiten hier (weit) mehr Entwicklungsaufwand als traditionelle Verfahren. Man muss sich um viele Dinge kümmern, um die man sich vorher keine Gedanken gemacht hat. Das kippt aber schnell, wenn man RIA baut. Denn dort steigt der Bedarf an client-seitigen Statusinformationen sehr schnell an. Als Beispiel nehmen wir eine einfache Anwendung mit einem Grid. Dieses Grid (das eigentlich eine hübsch geschmückte <table> ist) hat ne Paginierung, die Spalten können sortiert (und evtl gefiltert und gruppiert, umgeordnet etc) werden. Wenn du nicht alle Daten auf einmal im Grid darstellen willst, dann musst du das Grid entweder durch eine intelligente Datenspeicherung ergänzen (Topic: "Infinite Scrolling"), oder einen wie auch gearteten "Seitenwechsel" ermöglichen. Traditionelle, auf HTML+PHP basierende Anwendungen bekommen hier nichts mehr auf den Teller. Wenn du dann noch eine verschachtelte Navigation brauchst (Doppelklick auf Gridzeile öffnet weiteres Grid etc), dann sieht deine Url schnell nicht mehr gut aus.

      Eine Vermischung von PHP-generierten Seiten und von Javascript-gemanag'ten Seiten macht die Anwendung schnell unflexibel (... 1000 Gründe). Es kommt aber immer drauf an. Bei Facebook ist das alles kein Problem! Da kann ich sehr gut so arbeiten. In einer Backoffice-Anwendung kann das schnell zum Problem werden.



      Mehr kann ich dazu erst mal nicht sagen...
      Standards - Best Practices - AwesomePHP - Guideline für WebApps

      Kommentar

      Lädt...
      X