MB: Wie strukturiertes landen von Klassen in Index.php?

nabend Community,

Frage: wie kann ich eigentlich all die klassen in einen index.php verfachtet und ist das sinnvoll? ich hab mir überlegt wie ich paar dinge machen will.

  • Eine Dialoganzeige was am Bach ist in index.php über MSG.inc extends MSG.cfg
  • Ein Datenbankschnttstelle in DB.inc extends SQL.cfg worin die ganzen Statements abgelegt sind
  • über include auf anfrage lande ich die einzelnen Seiten nach

Mir ist aber überhaupt nich klar wie die "Oberfläche" aufgebaut ist. Ich spreche von <head> und seinen variablen Attributen z.B. <meta description >. Ich würde das mit massiv verschachtelten Klassen lösen.

Der ansatz von pl head() content() usw. schien mir sinnvoll zu sein. Wohl gemerkt: ich bin ziehmlich neu in diesem Gebiet. Wie löst Ihr das bezogen auf MVC?

Grüße MB

  1. Hi,

    Frage: wie kann ich eigentlich all die klassen in einen index.php verfachtet und ist das sinnvoll?

    Hääää?

    Kannst Du bitte versuchen, daraus einen deutschen Satz zu machen?

    ich hab mir überlegt wie ich paar dinge machen will.

    Eine Dialoganzeige was am Bach ist in index.php über MSG.inc extends MSG.cfg

    Häää? Siehe oben.

    Usw.

    Mir ist aber überhaupt nich klar wie die "Oberfläche" aufgebaut ist. Ich spreche von <head> und seinen variablen Attributen z.B. <meta description >.

    meta ist kein Attribut, sondern ein Element. Wovon redest Du?

    Der ansatz von pl head() content() usw. schien mir sinnvoll zu sein. Wohl gemerkt: ich bin ziehmlich neu in diesem Gebiet. Wie löst Ihr das bezogen auf MVC?

    Wenn Du Deine Anfrage verständlich machen könntest, bestünde ggf. die Chance, daß man sinnvoll drauf antworten könnte.

    cu,
    Andreas a/k/a MudGuard

    1. Hallo MudGuard

      uff, ok sorry. Ich versuche mich anders Auszudrücken.

      Ich möchte eine Webseite erstellen nach MVC Architektur. Sie soll zusätzlich mit dem Webclient direkt über Nachrichten in einem Dialog kommunizieren könnnen z.B. "login erfolgreich" und eine Datenbankverbindung enthalten mit definierten SQL Statements z.B. "SELECT * FROM tbl_users;". Diesen Zusatz habe ich auf meinem Wege Klassenbasierend gelöst. aber nur das.

      Ich möchte germe wissen wie ich diese beiden Zusätze in die Webseite integrieren nach MVC-Architektur. Ich habe noch nicht damit angefagen und möchte gerne lösungs Ansätze von eurer Seite bekommen.

      Besser verständlich?

      Grüße MB

      1. Tach!

        Ich möchte eine Webseite erstellen nach MVC Architektur. Sie soll zusätzlich mit dem Webclient direkt über Nachrichten in einem Dialog kommunizieren könnnen z.B. "login erfolgreich"

        Das heißt konkret, dass neben den Requests des Browsers nach HTML-Seiten (eingebundene Ressourcen wie Bilder, CSS und JS außer Acht gelassen) auch noch Requests via Ajax gestellt werden? Für die kann man sich eine WebAPI-Schnittstelle erstellen, beispielsweise nach dem REST-Prinzip.

        Ins MVC integriert kann man sich spezielle Controller erstellen, die diese API-Aufrufe behandeln. Oder aber man integriert die Aufrufe in die bestehenden Controller als eigene Actions.

        Ob man das so oder so macht ist eine Frage der Organisation. Framework-Ersteller neigen gern dazu, die Ordnung anhand von architekturellen Typen vorzunehmen. Das heißt, sie sortieren die Controller in die eine Ecke und die Models in die andere, die Views bekommen ihre, WebAPI und Helfer und was sonst noch so anfällt bekommen ebenfalls ihre Ecken. Sieht ordentlich aus? Ist aber Mist. Man arbeitet (besonders als Einzelkämpfer) ja meist themenorientiert und nicht architekturorientiert. Wen man zum Beispiel an der Kundenverwaltung arbeitet, an der Artikelverwaltung, an der Abwicklung des Warenkorbs und anderen Themen, dann arbeitet man meist erst an dem einen Thema, schaut dass da alles zusammenpasst und nimmt dann das nächste. Es ist kaum so, dass man zuerst alle Models erstellt und dann alle Controller und zum Schluss die Views. Sortiert man sich nun architekturell, muss man nun immer zwischen drölf Hauptverzeichnissen hin und her laufen, anstatt dass man alles an einem Ort hat.

        dedlfix.

        1. Hi dedlfix,

          Das heißt konkret, dass neben den Requests des Browsers nach HTML-Seiten (eingebundene Ressourcen wie Bilder, CSS und JS außer Acht gelassen) auch noch Requests via Ajax gestellt werden?

          habe ich vergessen zu erwähnen: nein nicht mit ajax. wozu auch. ich bastel ja keinen chat oder blogs. Andere Formen und Funktionen von xmlhttprequest() sind mir nicht bekannt.Ich will mich aber auch nicht auf AJAX versteifen.

          Ich will eine index.php bastel in der alles per include( 'seite.php' ); geladen wird.

          Für die kann man sich eine WebAPI-Schnittstelle erstellen, beispielsweise nach dem REST-Prinzip.

          Was sind WebAPI-Schnittstellen und das REST-Prinzip. Kleine erläuterung und Literatur. Fnde ich in Wiki was? Oder kenne ich diesen Begriff nur unter einem anderen Namen?

          Man arbeitet (besonders als Einzelkämpfer) ja meist themenorientiert und nicht architekturorientiert.

          Klingt einleuchtend. Hast du dazu nen Schaubild für die von Dir bennante Struktur und Controller Code Beispiel? Würde mich zu gern interessieren.

          Ich habe auf YouTube einen video sammlung von einem Youtuber gesehen der nach MVC PHP programmierte. Ich wollte das zur übung nach machen, haberte dann leider am .htaccess da XAMPP nicht das machen will was ich ihn beauftragt habe.

          vgl MB

          1. Tach!

            Ich will eine index.php bastel in der alles per include( 'seite.php' ); geladen wird.

            Aber wie passt dann diese Aussage

            [Die Webseite] soll zusätzlich mit dem Webclient direkt über Nachrichten in einem Dialog kommunizieren könnnen

            dazu? Wer kommuniziert denn nun auf welche Weise mit wem?

            Für die kann man sich eine WebAPI-Schnittstelle erstellen, beispielsweise nach dem REST-Prinzip.

            Was sind WebAPI-Schnittstellen und das REST-Prinzip. Kleine erläuterung und Literatur. Fnde ich in Wiki was? Oder kenne ich diesen Begriff nur unter einem anderen Namen?

            WebAPIs sind beispielsweise auch SOAP und XMLRPC. Das sind Ansammlungen von URLs, die nicht für den direkten Aufruf durch menschliche Nutzer vorgesehen sind und vollständige HTML-Seiten liefern, sondern die nur Daten liefern und/oder solche entgegennehmen und verarbeiten und dann nur eine maschinenlesbare Erfolgsmeldung oder Antwortdaten zurückgeben. - Aber das scheint ja nun doch nicht dein Anwendungsfall zu sein.

            Man arbeitet (besonders als Einzelkämpfer) ja meist themenorientiert und nicht architekturorientiert.

            Klingt einleuchtend. Hast du dazu nen Schaubild für die von Dir bennante Struktur und Controller Code Beispiel? Würde mich zu gern interessieren.

            Die übliche Struktur ist sowas wie

            - Controllers
              - CustomerController
              - ItemController
              - ShopController
              - CheckoutController
            - Models
              - Customer
              - Item
              - Cart
            - Views
              - Customer
                - Edit
                - List
              - Item
                - Edit
                - List
              - Shop
                - List
                - Buy
              - CheckoutController
                - Address
                - PayMethod
                - OrderConfirmation
            - Helpers
              - SomeCommonValidator
              - CreditCardValidator
            - Repositories
              - CustomerRepository
              - ...
            - Services
              - CustomerService
              - ...
            

            Sieht auf den ersten Blick schön sortiert aus. Und diese Struktur hat auch Vorteile, beispielsweise dann, wenn man Dinge in mehreren Kontexten benötigt. Items - die Dinge, die man im Shop kaufen kann - müssen nicht nur verwaltet werden, sie müssen auch vom Shop gelistet werden und der Warenkorb muss die Daten der ausgewählten Dinge auch anzeigen.

            Nachteilig ist aber, dass für die Erstellung der Kundenverwaltung der Controller in dem einen Verzeichnis ist, das Model in einem anderen, die für die Speicherung zuständigen Repositorys und Services in ihren Verzeichnissen und die Views in einem weiteren. Wenn ich mich recht erinnere, gibt es auch IDEs, in denen man sich individuelle Ansichten erstellen kann, so dass man die zum Arbeiten an einer bestimmten Aufgabe benötigten Dateien an einen Fleck verlinken kann. Aber das nützt einem nur etwas, wenn man dieselbe IDE und dieselben Ansichtsdefinitionen verwendet. Versucht man das Projekt über seine Verzeichnisstruktur zu ergründen, hat man diese nicht zur Verfügung. Deshalb ist es besser, um die Sinnzusammenhänge leichter zu erkennen, dass Projekte nicht nach Programmiermustern / Architekturtypen strukturiert sind, sondern nach fachlicher Zusammengehörigkeit. Nur, wie schon gesagt, ist es nicht immer möglich, klare Grenzen zu ziehen. Eine ordentliche Struktur zu schaffen ist also ähnlich schwierig wie das Finden von aussagekräftigen Namen für Bezeichner. Mitunter ist es auch vom verwendeten Framework vorgegeben, in welchen Verzeichnissen nach bestimmten Dingen gesucht wird, beispielsweise Controller nur im Controllers-Verzeichnis.

            - Customers
              - Customer
              - CustomerController
              - Views
                - Edit
                - List
              - CustomerRepository
              - CustomerService
            - Items
              - ...
            - Shop
              - ...
              - Cart
                - CheckoutController
                - CheckoutViews
                    - ...
                - ...
              - CreditCardValidator
            - Helpers
              - SomeCommonValidator
            

            Das ist ein Vorschlag, wie man es fachlich sortieren könnte. Natürlich kann man darüber streiten, ob das eine oder andere nicht woanders besser einsortiert wäre. Aber da das nur ein Beispiel ist, zu dem keine konkreten Anforderungen (z.B. eines Auftraggebers) definiert wurden, wird es hier wohl auch kein eindeutiges Richtig oder Falsch geben können. Und, was in dem einen Projekt richtig und sinnvoll war, muss nicht zwangsläufig in einem anderen Projekt ebenso bewertet sein.

            dedlfix.

            1. Deshalb ist es besser, um die Sinnzusammenhänge leichter zu erkennen, dass Projekte nicht nach Programmiermustern / Architekturtypen strukturiert sind, sondern nach fachlicher Zusammengehörigkeit.

              Verstehe

              Nur, wie schon gesagt, ist es nicht immer möglich, klare Grenzen zu ziehen. Eine ordentliche Struktur zu schaffen ist also ähnlich schwierig wie das Finden von aussagekräftigen Namen für Bezeichner.

              Habe ich meine Ersten erfahrungen gemacht ja. Besten Dank.

              Zu deiner Frage:

              Ich will eine index.php bastel in der alles per include( 'seite.php' ); geladen wird.

              Aber wie passt dann diese Aussage

              [Die Webseite] soll zusätzlich mit dem Webclient direkt über Nachrichten in einem Dialog kommunizieren könnnen

              dazu? Wer kommuniziert denn nun auf welche Weise mit wem?

              Vereinfachte Code Darstellung:

              index.php

              <?php
              session_start()
              ...
              ?>
              <html>
              <head>
              </head>
              <body>
              <?php nav->getMSG(); ?>   // der User-System Dialog wie "login erfolgreich"
              <?php nav->getNav(); ?>   // Navigation abhängig von zu inkludierdenden PHPs z.B. Rubrik "Kontakt"
              <?php nav->getPage(); ?>  // die Inkludierte PHP z.B. PHP Seite Kontakt
              </body>
              </html>
              

              Verständlicher?

              Schönen Anend

              vlg MB

              1. Tach!

                Verständlicher?

                Zumindest glaub ich, weiß ich jetzt, wo ich mich in die Irre führen ließ. Und meine Antwort ist nun bezogen auf deine Frage im Ausgangsposting

                Wie löst Ihr das bezogen auf MVC?

                Ich erfinde kein MVC-Framework, ich nehm einfach eines der vielen vorhandenen. Welches davon das beste ist, ist stets eine subjektive Entscheidung. Dazu muss man sie aber erstmal ausprobieren. Zumindest das Tutorial sollte man mal durchspielen, um einen Eindruck zu bekommen. Wenn man nach "PHP Framework" sucht, bekommt man auch Vergleiche, Aufzählungen und Ranking zu sehen. Vor nicht allzulanger Zeit war Yii auf einer der Seiten auf Platz 1, nun ist es wohl Laravel. Ich habe mir früher mal das Zend Framework angeschaut, aber das gefällt mir nicht mehr. Zu viele tausendmal verschachtelte Konfigurationsarrays war das letzte was ich sah, bevor ich ihm den Rücken zuwandte. Die anderen großen, Symfony und CakePHP, gefielen mir auch nicht, die Gründe sind in Vergessenheit geraten. Mit Yii(1) hab ich mal ein Projekt gemacht. Das sah erstmal gut aus, krankte aber auch an der einen oder anderen Eigenschaft. Seitdem hab ich kein PHP-Projekt angefangen, das ein Framework benötigt. Und so hatte ich keinen Bedarf, mich umzuschauen und kann dir grad nicht sagen, welches ich aktuell nehmen würde. Deshalb bleibt nur der der allgemeine Rat: Schau dir die vorhandenen an. Selbst wenn du dann immer noch ein eigenes erfinden willst, kannst du dir bei den existierenden den Aufbau, die Arbeitsweise und andere Ideen abschauen.

                Mein Hauptkriterium, ein Framework abzulehnen, scheint nur eine unbedeutende Kleinigkeit zu sein: wenn zu viel mit Strings gearbeitet werden muss und damit eigentlich Bezeichner gemeint sind.

                $config = array(
                  'foo' => 'FooController'
                );
                

                In diesem Beispiel verlangt das Framework, dass ich einen Konfigurationswert namens "foo" definieren muss, der den Namen einer Klasse enthalten soll. Ich kann das "foo" nicht von meiner IDE autovervollständigen lassen. Stattdessen muss ich den Namen aus der Dokumentation kennen und ihn dann selbst eintippen - weil es ein String ist. "FooController" ist ein Klassenname, den ich aber auch nicht autovervollständigen kann, weil er ebenfalls als String übergeben werden muss. Die IDE hat in dem Fall keine Ahnung, dass dieser String einen Klassennamen darstellt und ich kann da kein "Go to definition" verwenden oder ein Umbenenen ausführen, bei dem die IDE alle Vorkommen selbständig finden und ändern kann. Strings sind da meist und aus gutem Grund ausgeklammert. Gut, zumindest ein Punkt lässt sich heutzutage - sprich seit PHP 5.5 - lösen. KlassenName::class liefert den Namen der Klasse als String, und damit habe ich in meinem Code einen echten Bezeichner und keinen String mehr, auch wenn das Framework selbst zu doof ist, mit richtigen Bezeichnern umzugehen und unbedingt Strings haben will.

                Strings sind Mist, aber nicht überall lassen sie sich vermeiden (eine URL beispielsweise lässt sich schlecht als Bezeichner formulieren). An den Stellen nehm ich dann lieber in Kauf, dass ich mir eine Konstante oder eine zusätzliche Variable definiere.

                Also, wie gesagt: Schau dir die vorhandenen Frameworks an. Es gibt nicht nur einen richtigen Weg, ein bestimmtes Problem zu lösen, es gibt verschiedene Philosophien, Herangehensweisen und Lösungsmuster. In den großen Frameworks steckt sehr viel Erfahrung drin. In der Regel sind sie auch nicht wie Korsetts gebaut, sondern eher wie das Seil am Berg, an dem man sich entlanghangeln kann, aber nicht muss. Man muss nicht alles selbst nacherfinden und nur aus den eigenen Fehlern lernen, man lernt auch bei der Benutzung von anderer Software eine Menge kennen. Es ist wie beim Sprechenlernen, erstmal einfach nachmachen, was die Eltern da labern. Man kommt mit der Zeit dahin, eigene Gedanken so formulieren zu können, dass es sich richtig anhört.

                dedlfix.

  2. nabend Community,

    Frage: wie kann ich eigentlich all die klassen in einen index.php verfachtet und ist das sinnvoll?

    Ne. Sinnvoll wäre, nur die Klassen zu laden/kompilieren, die zum Ausliefern einer Response tatsächlich gebraucht werden.

    Schönen Sonntag.pl

    1. Guten Tag pl,

      Frage: wie kann ich eigentlich all die klassen in einen index.php verfachtet und ist das sinnvoll?

      Ne. Sinnvoll wäre, nur die Klassen zu laden/kompilieren, die zum Ausliefern einer Response tatsächlich gebraucht werden.

      Du meinst mit den neueren _autoload() ?

      Schönen Sonntag wünsche ich dir auch.

      vlg MB

      1. Guten Tag pl,

        Frage: wie kann ich eigentlich all die klassen in einen index.php verfachtet und ist das sinnvoll?

        Ne. Sinnvoll wäre, nur die Klassen zu laden/kompilieren, die zum Ausliefern einer Response tatsächlich gebraucht werden.

        Du meinst mit den neueren _autoload() ?

        Nein ich meine URL-Routing das hat mit dem AutoLoader gar nichts zu tun. URL-Routing mit Klassenbindung teilt den CODE so auf, dass nur das kompiliert wird, was tatsächlich gebraucht wird. So ist infolge der Klassenbindung der Name der Klasse bekannt und braucht keinen weiteren Automatismus.

        --pl

        1. nabend pl,

          ah so ähnlich habe ich das auch in meinem Projekt wie du aber nicht so perfekt und ich wusste nicht dass das URL-Routing heißt. Besten Dank für die Aufklärung :-)

          VLG MB

          1. Tach!

            Nein ich meine URL-Routing das hat mit dem AutoLoader gar nichts zu tun. URL-Routing mit Klassenbindung teilt den CODE so auf, dass nur das kompiliert wird, was tatsächlich gebraucht wird. So ist infolge der Klassenbindung der Name der Klasse bekannt und braucht keinen weiteren Automatismus.

            ah so ähnlich habe ich das auch in meinem Projekt wie du aber nicht so perfekt und ich wusste nicht dass das URL-Routing heißt. Besten Dank für die Aufklärung :-)

            Und weil das URL-Routing, wie pl so schön sagte, gar nichts mit dem Autoloader zu tun hat, war das auch nicht die zu deiner Frage passende Antwort. Das Problem, von einer URL auf das zu kommen, was ausgeführt werden muss, ist doch grad gar nicht deins, oder doch? Jedenfalls hat man in den üblichen MVC-Frameworks nicht nur eine einzelne Klasse, die pro Request aufzurufen ist. Da gibt es nicht nur den Controller, der die auszuführende Action enthält. Da stellt sich spätestens dann die Frage, wie eine weitere Klasse zu laden ist, wenn man mit einem Model arbeitet. Und noch eine, wenn die Daten des Models von einer Datenbankklasse beschafft werden. Wo legt man diese Klassen hin und wie werden sie ins Programm eingebunden? Die Antwort darauf heißt hoffentlich nicht URL-Routing, denn das ist kein Problem, das irgendwie im Zusammenhang mit URLs steht. Das ist vielmehr eine ganz allgemeine Frage. Eine Antwort darauf ist in den PSR enthalten und hat dort die Nummer 4. Dieser Autoloading-Standard wird in dieser oder einer ähnlichen Version schon seit einer Weile in den großen Framework-Projekten verwendet. Das Prinzip erfährt man quasi ganz nebenbei, wenn man sich mit ihnen beschäftigt. Der Standard definiert aber nur, wie der Klassenname zu notieren ist, und wie der Autoloader implementiert sein muss, damit der die zugehörige Datei findet. Er definiert nicht, wie die logische Struktur eines Projekts aussehen sollte.

            dedlfix.

          2. hi,

            ah so ähnlich habe ich das auch in meinem Projekt wie du aber nicht so perfekt und ich wusste nicht dass das URL-Routing heißt. Besten Dank für die Aufklärung :-)

            Woanders hab ich das auch als URL-Mapping gelesen. Was natürlich nicht heißt, dass 500 verschiedne URLs 500 verschiedene Subklassen benötigen. Wen der Unterschied nur die Template-Datei ist, na dann wird das eben durch eine Attribut file=datei.html gesteuert.

            Und wenn Formular-Eingaben, Ajax, XMLRPC, REST, SOAP o.a. beliebige Webservices über einen bestimmten URL laufen soll, kann ich auch mit dem Attribut interface=xmlrpc den URL lebendig (interaktiv) machen oder einfach nur dynamische Inhalte einbauen.

            Was den AutoLoader betrifft: Ich lade damit keine Klassen sondern Methoden im Rahmen einer Factory. Und diese Methoden können on Demand zur Laufzeit weitere Klassen einbinden, z.B. MySQL-Verbindungen, Serializer, IO::File, wo Du wolle. GGf. erfolgt in diesen Methoden eine Aggregation von Instanzen nicht verwandter Klassen. Factory heißt ja, dass eine eigene Methode Instanzen erstellt; die jedoch können unsichtbar in der ausgelagerten Methode verbleiben oder werden zum Attribut der eignenen Instanz gemacht, nämlich dann wenn sie später noch einmal gebraucht werden.

            Es gibt verschiedene Konzepte. An meinem FW hab ich fast 10 Jahre gebaut. Aber nicht am CODE an sich, sondern am Konzept. Und dabei bin ich 2x in einer mächtigen Sackgasse steckengeblieben, Gründe waren beidesmal dieselben: Zuviel CODE musste auf einmal kompiliert werden und die Übersicht ging flöten.

            Lösung ist eine flache Klassenhierarchie und klare Abgenzung der Namespaces bei gleichnamigen Methoden. Und die Erkenntnis, dass praktische OOP NICHT das ist, was Dozenten vermitteln.

            1. Tach!

              Was den AutoLoader betrifft: Ich lade damit keine Klassen sondern Methoden im Rahmen einer Factory.

              Dieser Thread ist vom OP mit dem Tag PHP gekenzeichnet worden. Es ist in PHP in seinem Standardlieferumfang nicht möglich, zur Laufzeit Klassen oder Objekte um Methoden zu erweitern. Es gibt lediglich Vorgehensweisen, die so etwas simulieren, aber die sind alle undurchsichtig oder unhübsch. Ich sehe auch keine Notwendigkeit für ein solches Vorgehen. Man kann über eine Factory auch einfach Instanzen von Klassen erzeugen, die eine auf dem üblichem Weg geerbte Klasse um eine Methode erweitern. Falls man das überhaupt so braucht.

              Zudem ruft PHP den Autoloader nur auf, wenn eine Klasse oder ein Interface verwendet wird, die/das nicht in den bereits vorhandenen Klassen/Interfaces gefunden wurde. Ein Autoloading von Funktionen ist nicht möglich.

              Lösung ist eine flache Klassenhierarchie und klare Abgenzung der Namespaces bei gleichnamigen Methoden.

              Als Methoden werden Funktionen bezeichnet, die einer Klasse zugeordnet sind. Eine Klasse kann in PHP keine zwei Methoden mit demselben Namen haben. Demzufolge braucht man auch keine Namespaces, die sowieso nicht innerhalb von Klassen verwendet werden können. Zwei gleichnamige Methoden können sich lediglich in unterschiedlichen Klassen befinden und dann sind sie durch die Klassen bereits abgetrennt.

              Verwendest du mal wieder die Begriffe auf unübliche Weise?

              dedlfix.

              1. Als Methoden werden Funktionen bezeichnet, die einer Klasse zugeordnet sind. Eine Klasse kann in PHP keine zwei Methoden mit demselben Namen haben.

                In Perl auch nicht. Namespaces werden jedoch dann interessant, wenn es um ausgelagerte Methoden geht: Bei denen soll es ja möglich sein, dass die von Instanzen verschiedener Subklassen aufgerufen werden dürfen. Somit wird auch das Mocken ermöglicht, Srichwort Qualitätssicherung.

                Beispiel, $foo, $bar sind Instanzen verschiedner Klassen und rufen jeweils eine Methode dumper():

                $foo->dumper();
                $bar->dumper();
                

                Methode dumper() kompiliert eine Klasse Dumper. So ergeben sich für den kompilierten CODE dieser Klasse Dumper und auch den CODE der Methoden 2 verschiedene Namespaces, das zeigen die Symboltabellen.

                PS: Auch in PHP gibt es eine Möglichkeit, Methoden aus beliebigen Quellen (z.B. Dateisystem) zu laden, wenn sie im eigenen Namespace nicht gefunden werden.

                1. Tach!

                  PS: Auch in PHP gibt es eine Möglichkeit, Methoden aus beliebigen Quellen (z.B. Dateisystem) zu laden, wenn sie im eigenen Namespace nicht gefunden werden.

                  Dann zeig diese Möglichkeit! Zeig, wie eine Klasse um eine Methode erweitert wird. Es zählt aber nicht das Verwenden von nicht zum Standardumfang gehörenden Erweiterungen wie runkit. Auch das ersatzweise Aufrufen der Magic Method __call(), wenn eine Methode nicht gefunden wurde, zählt nicht als Erweitern.

                  dedlfix.

              2. Hallo dedlfix,

                Eine Klasse kann in PHP keine zwei Methoden mit demselben Namen haben.

                auch nicht mit unterschiedlichen Parametern? Java kann das.

                Bis demnächst
                Matthias

                --
                Wenn eine Idee nicht zuerst absurd erscheint, taugt sie nichts. (Albert Einstein)
                1. Tach!

                  Eine Klasse kann in PHP keine zwei Methoden mit demselben Namen haben.

                  auch nicht mit unterschiedlichen Parametern? Java kann das.

                  Auch nicht mit unterschiedlichen Parametern. Diese Art von Methoden-Überladen gibt es in PHP nicht. Es gibt zwar Overloading in PHP, aber: „PHP's interpretation of "overloading" is different than most object oriented languages. Overloading traditionally provides the ability to have multiple methods with the same name but different quantities and types of arguments.“ In PHP heißt Overloading, dass man mit den magischen Methoden __set/__get/__call und Konsorten reagieren kann, wenn nicht vorhandene Methoden oder Eigenschaften angesprochen werden. Das ist auch nur für Klassen verfügbar, nicht für einfache Funktionen.

                  In PHP kann man jedoch unterschiedliche Signaturen von Funktionen oder Methoden nachbilden. Man kann zum einen Default Values für die Parameter definieren, und beim Aufruf diese Parameter weglassen. Oder man nimmt seit kurzer Zeit Variable-length argument lists. Man kann auch schon viel länger einfach gar keine oder nur wenige Parameter definieren und greift dann auf die tatsächlich übergebenen über die Funktionen func_get_arg()/func_get_args() zu.

                  dedlfix.

  3. Hallo,

    Frage: wie kann ich eigentlich all die klassen in einen index.php verfachtet und ist das sinnvoll? ich hab mir überlegt wie ich paar dinge machen will.

    du willst ein paar Pattern einsetzen: das Front Controller-Pattern, welches alle Anfragen entgegennimmt und mittels eines Routers (aus dem Router-Pattern) an die geeignete Klasse weiterleitet, die die Anfrage dann beantwortet. Innerhalb der beantwortenden Klasse nutzt du dann MVC (oder ein ähnliches Pattern) und trennst deine fachliche Logik ("Model"), Anzeige ("View" bzw. Template) und den Klebecode, der deinen Request entgegennimmt, geeignete Logik aus dem Model aufruft und dann das Template aufruft mit geeigneten Werten aus dem Model.

    Zu deiner Frage bzgl Templates: hier gibt es verschiedenen Möglichkeiten. Ich nutze (als Bestandteil des Symfony-Frameworks ist es ganz automatisch dabei) Twig als Template-Engine, und hier gibt es das Konzept von "Blöcken", die man hierarchisch überschreiben kann.

    Ich finde folgenden Link eigentlich immer sehr gut um die Funktionsweise von modernen Frameworks zu erklären: von flat PHP zu Symfony.

    Viele Grüße, Matti

    1. Tach!

      Ich finde folgenden Link eigentlich immer sehr gut um die Funktionsweise von modernen Frameworks zu erklären: von flat PHP zu Symfony.

      Sehr schöne Erklärung, aber sie haben da einen Fehler drin. Der ist was für aufmerksame Experten und ändert nichts daran, dass man im Prinzip wie dort beschrieben vorgehen kann/sollte.

      So steht es im ersten Beispiel:

      $link = new PDO("mysql:host=localhost;dbname=blog_db", 'myuser', 'mypassword');
      // ...
      $link = null;
      

      Nach der Benutzung der PDO-Instanz wird die in der Variable $link gehaltene Referenz durch null ersetzt. Der Garbage Collector kann nun die Instanz wegräumen, da nichts mehr auf sie referenziert.

      Dann haben sie es umgebaut. Erstmal zwei Funktionen erstellt,

      function open_database_connection() {
          $link = new PDO("mysql:host=localhost;dbname=blog_db", 'myuser', 'mypassword');
          return $link;
      }
      
      function close_database_connection($link) {
          $link = null;
      }
      

      die dann so verwendet werden:

      $link = open_database_connection();
      // ...
      close_database_connection($link);
      

      Damit wird die Connection nicht mehr freigegeben, weil die Referenz bestehenbleibt. Die Funktion close_database_connection() definiert sich einen Parameter namens $link. Der ist nicht zu verwechseln mit der Variable $link, in der das Ergebnis von open_database_connection() abgelegt wird (im Folgenden als das äußere $link bezeichnet). Und auch das $link innerhalb der letztgenannten Funktion hat nichts mit den beiden anderen $link zu tun. Alle drei sind separate Variablen.

      In open_database_connection() wird eine Instanz von PDO erzeugt, und in $link erstellt PHP eine Referenz auf diese Instanz. $link wird zurückgegeben. Damit wird eine weitere Referenz erstellt, wenn diese Rückgabe im äußeren $link ablegt wird. Das $link innerhalb open_database_connection() wird beim Verlassen der Funktion aufgeräumt, somit wird diese Referenz vernichtet und nur noch die im äußeren $link bleibt bestehen. Beim Aufruf von close_database_connection() wird nun für die dortige lokale Variable $link eine weitere Referenz erstellt. Und nur diese wird beim Zuweisen von null überschrieben. Die Referenz im äußeren $link bleibt bestehen. Und somit wird auch die Datenbankverbindung nicht zum Schließen freigegeben. Das passiert erst zum Scriptende, wenn auch das äußere $link von PHP aufgeräumt wird.

      Zum Nachvollziehen gibts hier dieses einfache Beispiel

      function bar($foo) {
          debug_zval_dump($foo); // 2
          $foo = null;
      }
      
      $foo = new stdclass();
      debug_zval_dump($foo); // 1
      
      bar($foo);
      
      debug_zval_dump($foo); // 3
      
      $foo = null;
      debug_zval_dump($foo); // 4
      

      Die Ausgabe ist

      object(stdClass)#1 (0) refcount(2){}
      object(stdClass)#1 (0) refcount(4){}
      object(stdClass)#1 (0) refcount(2){}
      NULL refcount(2)
      

      Die dritte Zeile zeigt, dass $foo immer noch eine Referenz auf das Objekt enthält. Erst in der vierten ist sie weg.

      dedlfix.