Ankündigung

Einklappen
Keine Ankündigung bisher.

RESTful PHP Applikation mit Emberjs und Silex

Einklappen

Neue Werbung 2019

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

  • RESTful PHP Applikation mit Emberjs und Silex

    Hallo zusammen,

    ich würde gerne eine PHP-Applikation entwickeln, die mit der JavaScript-Bibliothek Emberjs zusammenarbeitet. Das ganze soll als TDD-Projekt erfolgen.

    Vorbemerkungen:

    Emberjs nutzt als Template-Engine Handlebars, welches 2 Möglichkeiten bietet, entsprechende Templates einzubinden:

    1.) html-Version: Die Templates werden über das Script-Tag
    Code:
    <script type="text/x-handlebars" data-template-name="template-name">
    mein template
    </script>
    einfach in den HTML-Code eingebunden. Für größere Projekte eignet sich das natürlich nicht

    2.) js-Version: Die Templates werden über eine Engine (Konsolenaufruf oder über grunt) "vorkompiliert" und einfach als JavaScript-Datei eingebunden (z.B. templates.js)



    Für Nodejs gibt es entsprechende Tools, um Templates zur Laufzeit zu kompilieren (also beim Page-Refresh) und Unit-Tests sowie Integration-Tests automatisiert auszuführen. Leider ist Nodejs nicht richtig "PHP-kompatibel", abgesehen davon würde ich die Anwendung gerne auf einem Webspace deployen, der kein Nodejs unterstützt.

    Was ich schon versucht habe:
    Nodejs mit PHP Unterstützung ausstatten: Hat bis zu einem gewissen grad funktioniert, aber es kommt hier zu komischen Seiteneffekten (Seiten nicht aufrufbar, urlrewrite funktioniert nicht richtig, mit anderen Worten: Untauglich)
    Zend-Server und Nodejs gleichzeitig laufen lassen: Funktioniert grundsätzlich, allerdings bekomme ich über die Same-Origin-Policy Probleme beim Zugriff auf den RESTful-Service.

    Meine aktuelle Lösung:
    Ich habe mir in PHP einen hbs-Loader geschrieben, der, wenn ein "development"-Flag gesetzt ist, die hbs-Dateien lädt und ins HTML reinschreibt (also die nicht kompilierte Variante des Template-Loadings). Beim Deployment generiere ich dann die templates.js-Dateien und lasse das HTML weg. Funktioniert ganz brauchbar, aber es erscheint mir sehr unsauber.

    Zur Fragestellung:
    Hat jemand zufällig fundierten Lesestoff für eine elegantere Lösung a la "yeoman" in Kombination mit PHP. Vorab: Ich habe lange gegoogled und viel gelesen, also die ersten 3 Links in Google zu posten, wird mir sicher nicht weiter helfen. Ich bin aber offen für Vorschläge, falls jemand schon Erfahrung bei größeren Projekten mit PHP und Emberjs hat. Insbesondere geht es mir um folgende Themen:

    - Laufzeitkompilierung von Emberjs-Templates in Kombination mit PHP
    - Ausführung von Emberjs-Unit-Tests in einer Entwicklungsumgebung (PHPStorm, Eclipse, etc.)
    - Projektstruktur und Aufbau

    Bin dankbar für Vorschläge
    Tutorials zum Thema Technik:
    https://pilabor.com
    https://www.fynder.de

  • #2
    Zitat von Andreas Beitrag anzeigen
    Leider ist Nodejs nicht richtig "PHP-kompatibel", abgesehen davon würde ich die Anwendung gerne auf einem Webspace deployen, der kein Nodejs unterstützt.
    Was genau meinst du damit? Und wofür brauchst du genau PHP?

    Kommentar


    • #3
      verstehe das auch nicht so ganz, soweit ich weis wird bei RESTful application gemeint, dass man außer POST und GET auch noch DELETE und PUT methoden verwendet.. i.d.r erwartet man auch von einer RESTfull API einen JSON array der dann in ein layout eingebunden werden kann..

      silex bietet es ja die schon an mit $app->put('url',function()) und $app->delete

      alles was du brauchst ist die PHP anwendung die ledeglich daten annimmt, verarbeitet und resultat NICHT als HTML zurückliefert. dein EmberJS etc, dafür machst du eine zweite anwendung, die dann zb über ajax die Rest schnittstelle anspricht
      apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

      Kommentar


      • #4
        Was genau meinst du damit? Und wofür brauchst du genau PHP?
        Ok, wahrscheinlich habe ich es schlecht erklärt:

        - Der RESTful-Service ist in PHP/Silex implementiert (hier gibts kein akutes Problem, abgesehen von Silex selbst ), der Link http://www.youtube.com/watch?v=bTawx0TGIj8&noredirect=1 war aber trotzdem hilfreich
        - Der Client (die Applikation) ist in PHP (html) / JavaScript / EmberJS implementiert
        - Emberjs verwendet Handlebars als Template-Engine
        - Handlebars wird entweder über <script>-Tags (unkompiliert) oder eine templates.js (kompiliert) eingebunden
        - Die Templates (welche als .hbs-Files vorliegen) können vorkompiliert werden
        - Dies kann man über die Konsole lösen (ember-compile *.hbs template.js), automatisch beim Refresh über ein Grunt/Nodejs target oder so, dass man die hbs-Dateien einfach als Script-Tags in den Output schreibt
        - Nodejs-WebServer mit Grunt und ember-live-compiler funktioniert (z.B. localhost:8000)
        - ZendServer mit Silex und PHP funktioniert (z.B. localhost:80/rest/users)
        - Zugriff mit ember-Applikation auf RESTful-Service funktioniert wegen Cross-Domain-Policy / unterschiedlichem Port nicht und zwei Server zu betreiben ist Mist

        Ist-Zustand:
        - Meine index.php lädt alle hbs-Dateien und gibt <script>-Tags aus, so das die Templates direkt nach der Änderung in der Anwendung zur Verfügung stehen (nicht elegant, aber läuft)

        Soll-Zustand:
        - Beim Page-Refresh werden die HBS-Templates automatisch in eine templates.js kompiliert und und ich muss sie nicht mehr manuell über PHP laden (bei Nodejs / Rails gibt es dafür Tools)

        Meine Versuche:
        - PHP unter dem NodeJS-Server (Grunt-Basis) zu aktivieren (so dass ich PHP Scripte unter localhost:8000 ausführen kann und alle notwendigen extensions zur Verfügung stehen) => fail
        - Live-Kompilierung unter PHP / Zend-Server realisieren => nur über das Laden der Scripte möglich

        Meine Frage: Gibt es irgendjemanden, der eine ähnliche Konstellation bei sich einsetzt und mir Tipps zur Strukturierung der Anwendung geben kann?
        Ich habe irgendwie das Gefühl, dass Rad ein 2. mal zu erfinden. Es gibt sehr viele (aus meiner Sicht aber eher halbfertige) Applikationsstruktur-Templates für emberjs, die aber alle nix mit PHP zu tun haben, sondern eher mit Ruby.

        Zum Thema "Ausführung von Emberjs-Unit-Tests in einer Entwicklungsumgebung (PHPStorm, Eclipse, etc.)"
        habe ich eine Lösung gefunden, mit der ich soweit erst mal zufrieden bin: js-test-driver für Eclipse, einfach mal zum Original-Post runterscrollen, funktioniert einwandfrei, wenn man die QunitAdapter.js von dem Fork nutzt
        Tutorials zum Thema Technik:
        https://pilabor.com
        https://www.fynder.de

        Kommentar


        • #5
          Ich habe das Problem wahrscheinlich immer noch nicht verstanden. Für mich stellt sich das so dar, dass du einfach zur Laufzeit template.js Destillate aus .hbs Dateien erstellen willst. Warum kannst du dazu nicht einfach hotfolder nutzen (PHPStorm => Filewatcher), mit denen du die jeweiligen Compiler direkt bei Veränderung der Sourcen ausführst?

          Kommentar


          • #6
            Warum den Client mit Templates zumüllen ?
            [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

            Kommentar


            • #7
              Weil das den Server entlastet?

              Kommentar


              • #8
                Captn Microoptimierung, Ahoi.
                [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                Kommentar


                • #9
                  Warum den Client mit Templates zumüllen ?
                  Naja, es kann schon gute Gründe geben. Wenn Du eine hochdynamische JS-lastige Anwendung hast, kann Templates zu benuzten schon echt fetzen. Und auf der anderen Seite nen reinen Datendienst via REST zu betreiben und nur einen kleinen Service, der Templates erzeugt, finde ich schon ein attraktives Modell. Ganz nah an REST halt. Probleme wie Sicherheit sind natürlich immer auch zu lösen.

                  Mir ist noch nicht ganz klar, warum die Templates jetzt ständig neu erzeugt werden müssen. Wiederspricht das nicht dem Templategedanken?
                  [COLOR="#F5F5FF"]--[/COLOR]
                  [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                  „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                  [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                  [COLOR="#F5F5FF"]
                  --[/COLOR]

                  Kommentar


                  • #10
                    Nur das die "Templates" eigentlich nur "Aufgeblähte" HTML-Schnipsel sind, die der XSLT-Parser des Browser auch ohne javascript auf die Reihe bekommen hätte.. Wenn du etwas auslagern willst, kannst du das doch tun, aber dafür extra Javascript bemühen ? XSLT mag der Browser auch und es ist nicht einmal möglich das zu unterdrücken ( JS schon ).

                    Auch hier kannst du bspw. den renderprozess der gesamten UI der Anwendung dem Client überlassen.

                    Im Falle einer JS-basierten Web-Anwendung mag ich da vorsichtig zustimmen, aber auch da, könnte man Client-seitig eher zu XSL(-Templates) greifen, statt mit JS HTML zu verwursten.
                    [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                    Kommentar


                    • #11
                      Bei XSLT hast Du aber IMHO bspw. keine Kontrolle über das Repaint des Layouts. Und das ist ein wichtiger Aspekt bei JS-basierten Applikationen. Auch wie man mit XSLT Events an einzelnen (dynamischen) DOM-Nodes anknüpft, bin ich jetzt gerade nicht sicher. Events kann man natürlich auch global definieren, aber ein Aspekt ist das auch.
                      [COLOR="#F5F5FF"]--[/COLOR]
                      [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                      „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                      [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                      [COLOR="#F5F5FF"]
                      --[/COLOR]

                      Kommentar


                      • #12
                        Klar, XSLT... weil man ja Javascript deaktivieren könnte. Aber bestimmt ist das mit ember.js genau so einfach mit XSLT als wo wie wenn wer JS an gehabt hätte...

                        Kommentar


                        • #13
                          Zitat von rkr Beitrag anzeigen
                          Klar, XSLT... weil man ja Javascript deaktivieren könnte. Aber bestimmt ist das mit ember.js genau so einfach mit XSLT als wo wie wenn wer JS an gehabt hätte...
                          XSLT nicht weil man JS deaktivieren könnte, eher weil man nicht noch einen Template-Manager in JS brauch wenn der Browser schon mit Templates umgehen kann.

                          Blizzard Entertainment hat vor der Auslagerung der Battle.net API beispielsweise das World of Warcraft Armory via XSLT im Browser gerendert und nur die API-Daten in die XML jeweilige gepackt, sodas man die Url ohne Beiwerk direkt als API für sein Webprojekt nutzen konnte.
                          [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                          Kommentar


                          • #14
                            Naja, bevor hier die Spekulationen überhand nehmen, erkläre ich mal kurz das Prinzip der Anwendung:

                            - Der REST Service ist nur für die Daten verantwortlich
                            - Die Templates enthalten nicht nur Platzhalter, die mit JavaScript gefüllt/replaced werden, sondern auch Leistungsfähige View-Helper und Bindings, die man per XSLT nicht umsetzen kann
                            - Die Templates werden "Kompiliert", das heißt, dass sie in einem nicht leserlichen Format als JS gespeichert werden (ähnlich minified)
                            - Das Bearbeiten der Templates erfolgt in hbs-Dateien.

                            Wenn man entwickelt geht das ganze also auch ohne Kompilierung, aber dann braucht man immer eine Unterscheidung zwischen "lade mir alle HBS-Files manuell als script" und "lade mir die templates.js einmal". Bei einer Live-Kompilierung könnte man sich diese Unterscheidung sparen und immer die templates.js nehmen, weil sie ja automatisch bei einer Änderung neu kompiliert werden würde.

                            Das Rendering lasse ich auf dem Client machen, da ich keine Suchmaschinenoptimierung für meine Seite benötige und die Anwendung recht komplex ist.

                            @nikosch: Silex beinhaltet schon eine sehr leistungsfähige Session, Auth, und Berechtigungsprüfungskomponente. Ich habe die ein bisschen umgebogen, bin aber recht zufrieden damit. Jede REST-Resource stellt eine Berechtigung dar, die mit den Aktionen get, post, put, delete und patch versehen kann. Die ersten 4 sind flags, bei patch kann man, sofern vorhanden die Eigenschaften der Entity auswählen, die zugegriffen werden können sollen... Das ganze wird dann über Doctrine-Entitäten abgebildet und automatisch in der API ausgelesen. Kommt eine neue Resource bzw. Entity dazu, wird diese automatisch auf ein Standard-Entity-Repository (oder auch Store) gemappt, die Metadaten werden ausgelesen und diese als Berechtigungen zur Verfügung gestellt.

                            Die Entität steht somit also direkt in der REST API, der Rechteverwaltung und der Rollenverwaltung zur Verfügung. Sonderverhaltensweisen, wie z.B. das hashen eines Passworts, werden dann im "UserRepository", dass sich aus einem DefaultRepository ableitet, realisiert. EmberJS orientiert sich an jsonapi.org, was ein großer Vorteil ist, denn diese Konventionen sind meiner Ansicht nach sehr durchdacht.

                            Das Login wird übrigens über ein POST /session mit einer Verknüpften User-Entity gelöst Ob das so elegant ist, stelle ich mal in den Raum, aber es funktioniert. Glücklicherweise unterstützt emberjs auch Models mit hasMany und belongsTo Eigenschaften Mit Ember-Data macht das richtig Spaß.
                            Tutorials zum Thema Technik:
                            https://pilabor.com
                            https://www.fynder.de

                            Kommentar

                            Lädt...
                            X