Ankündigung

Einklappen
Keine Ankündigung bisher.

Optionen aus einer php-, xml-Datei oder aus einer Datenbank

Einklappen

Neue Werbung 2019

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

  • Optionen aus einer php-, xml-Datei oder aus einer Datenbank

    Hallo ich möchte mir ein kleines, eigenes Framework schreiben.
    Darin möchte ich ein Pluginsystem realisieren, in welchem die Plugins sich ihre screens, bzw. actions registrieren müssen, parameter für eine Registrierung, wären:
    - Name des screens, bzw. action
    - Pfad zur jeweiligen Datei, in der der code liegt.
    - Name der Klasse, welche den screen, bzw. action implementiert.
    - Und ein permissionkey, über welchen der Nutzer mindestens verfügen muss.

    Dazu habe ich jetzt 3 Ideen:
    1. Ich habe eine standardisierte php-Datei mit einer standardisierten Klasse, welche Registrierungsmethoden implementiert z.b. Plugin.php:
    PHP-Code:
    Plugin extends BasePlugin {
        function 
    init() {
            
    registerScreen("Index""/screens/index.php""Index""IsUser");
            
    registerScreen("Login""/screens/login.php""Login""IsGuest");
            
    registerAction("Logout""/actions/logout.php""Logout""IsUser");
        }

    2. Ich habe wieder eine standardisierte Datei, diesmal aber alles im xml Format.
    Code:
    <plugin>
    	<screen name="Index" file="/screens/index.php" class="Index" permussion="IsUser" />
    	<screen name="Login" file="/screens/login.php" class="Login" permussion="IsGuest" />
    	<action name="Logout" file="/actions/logout.php" class="Logout" permussion="IsUser" />
    </plugin>
    3. Ich habe im Plugin ein installscript, welches alle Registrierungen in einer Datenbank vornimmt.

    So welches der 3 Konzepte, oder ein 4. an das ich noch nicht gedacht habe, ist das schnellste?

  • #2
    So welches der 3 Konzepte, oder ein 4. an das ich noch nicht gedacht habe, ist das schnellste?
    Was das schnellste ist, ist von vorneherin die falsche Frage. Ich antworte daher eher auf die Frage, welche die sinnvollste ist Optimieren lässt sich nachträglich immer noch, falls notwendig (z.B. XML-Daten cachen).

    Wenn du ein Framework entwickelst, solltest du das Hollywood-Prinzip kennen: Don't call us, we call you. Wenn deine "Plugin"-Klasse also nichts macht, als das eigentliche Plugin beim Framework zu registrieren, ist sie überflüssig, das Framework sollte seine registerScreen()-Methode selbst aufrufen und vom Plugin mittels definierter Schnittstelle die nötigen Informationen zur Verfügung gestellt bekommen. Deine Variante (2) funktioniert in diesem Sinne, kann man so machen, wenn man auf XML-Konfiguration steht, da es sich aber anscheinend um feste Werte handelt würde ich sie eher im Plugin-Code abbilden (das solltest du ohnehin, auch wenn die Werte letztlich aus XML-Dateien kommen):
    PHP-Code:
    interface Screen
    {
      function 
    getName();
      function 
    getFile();
      function 
    getPermission();
      
    // ...
    }
    interface 
    Action
    {
      function 
    getName();
      function 
    getFile();
      function 
    getPermission();
      
    // ...
    }
    class 
    Index implements Screen
    {
      public function 
    getName()
      {
        return 
    'Index';
      }
      
    // ...

    Wenn du jetzt noch nach dem Prinzip Convention over Configuration vorgehst, kannst du erreichen, dass Screen- und Action-Klassen ohne weitere Konfiguration anhand des Dateinamens gefunden werden (Dateipfade auf Klassen und Typen mappen, z.B. plugin/screens/index.php enthält Klasse Index vom Typ Screen, das Framework lädt dazu alle Dateien in plugin/screens und prüft ob Screen-Klassen entsprechend der Dateinamen vorhanden sind). Damit entfällt dann ggf. auch getFile() - auch wenn ich mir nicht sicher bin ob das der Dateipfad zur Klasse sein sollte oder eine URL.

    Das ist alles nur ein sehr ungefähres Beispiel, da ich keine Ahnung habe, wie dein Framework aufgebaut ist. Das Konzept von Screens und Actions als Klassen ist mir ehrlich gesagt auch etwas suspekt, aber wenn du das im Detail vorstellen möchtest, bin ich gerne bereit das weiter zu diskutieren.
    [IMG]https://g.twimg.com/twitter-bird-16x16.png[/IMG][URL="https://twitter.com/fschmengler"]@fschmengler[/URL] - [IMG]https://i.stack.imgur.com/qh235.png[/IMG][URL="https://stackoverflow.com/users/664108/fschmengler"]@fschmengler[/URL] - [IMG]http://i.imgur.com/ZEqflLv.png[/IMG] [URL="https://github.com/schmengler/"]@schmengler[/URL]
    [URL="http://www.schmengler-se.de/"]PHP Blog[/URL] - [URL="http://www.schmengler-se.de/magento-entwicklung/"]Magento Entwicklung[/URL] - [URL="http://www.css3d.net/"]CSS Ribbon Generator[/URL]

    Kommentar


    • #3
      Danke, dass Hollywood-Prinzip klingt auch sehr interessant. Danke!
      Aber bei Klassen habe ich den Vorteil, dass vorarbeiten, wie Parameter aufbereiten, Datenbank öffnen, etc. sowie die Aufräumarbeiten, Template ausgeben, Datenbank schließen, etc. nicht im Plugin selber gemacht werden, sondern alles die Basisklasse übernimmt. Es kann also nichts wichtiges vergessen werden.

      Aber warum sind dir Klassen als screens/actions suspekt?

      Kommentar


      • #4
        1. Hardcoding ~ unflexibel
        2. + 3. Initialisierung durch Konfiguration ( wo und wie auch immer gespeichert ) ~ flexibel

        Mir erschließt sich allerdings noch nicht ganz wie deine Entscheidungskomponente das anbindet ( isGuest, isUser, ... ),
        setzt du da nen ACL-Konzept um ? Falls ja, "wirkt" es relativ statisch im moment. Grundlegend sollte das Plugin ( je nach eigenschaft ) Lese-Möglichkeit in der ACL bekommen oder Lese- & Schreib-Möglichkeiten. Statt auf statische "Felder" wie isGuest oder isUser zuzugreifen oder aufzurufen. Ein "hat recht plugin xy zu benutzen" + "hat recht core komponente ab zu nutzen" ist da wohl deutlich transparenter.
        [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


        • #5
          Ntürlich kommt da ein ACL system hinter, mit Permissions, Gruppen und Usern.

          Kommentar


          • #6
            Aber bei Klassen habe ich den Vorteil, dass vorarbeiten, wie Parameter aufbereiten, Datenbank öffnen, etc. sowie die Aufräumarbeiten, Template ausgeben, Datenbank schließen, etc. nicht im Plugin selber gemacht werden, sondern alles die Basisklasse übernimmt. Es kann also nichts wichtiges vergessen werden.

            Aber warum sind dir Klassen als screens/actions suspekt?
            Ich wusste nicht, was BasePlugin alles macht, daher schrieb ich ja
            Wenn deine "Plugin"-Klasse also nichts macht, als das eigentliche Plugin beim Framework zu registrieren
            Ein Denkanstoß: Sowohl das was du gerade als Basisklasse für Plugins beschrieben hast als auch (vermutlich) deine Screen-Klassen verstoßen gegen einige Prinzipien von objektorientiertem Design, was schlecht für Wartbarkeit, Erweiterbarkeit und Wiederverwendbarkeit ist - Eigenschaften, die man gerade bei einem Framework unbedingt erreichen will. Die Prinzipien:

            Single Responsibility: Eine Klasse sollte genau eine Verantwortlichkeit haben, oder anders gesagt, nur aus einem Grund geändert werden müssen. Das Anti-Pattern dazu ist die "God Class", lange Klassen mit zu viel Verantwortung und danach riecht es mir hier gerade.
            Separation of Concerns: Dinge wie Datenbank und Templates sollten sauber getrennt behandelt werden, siehe auch [WIKI]Schichtenmodell[/WIKI]

            Aber warum sind dir Klassen als screens/actions suspekt?
            Wie gesagt, ich vermute, dass das bei dir Klassen sind, die keine sauber eingegrenzten Verantwortlichkeiten haben, vor allem da du den Eindruck erweckst, dass sie den Kern eines Plugins darstellen. Es ist nicht per se schlecht, für "Actions" und "Screens" Klassen zu haben, eine "Action" könnte z.B. genausogut ein Command-Objekt oder auch ein Controller sein, ein "Screen" ein Page Controller - zu Controllern siehe MVC (Achtung, unterschiedliche Interpretation in Desktop- und Web-Anwendungen!)

            Wie gesagt...
            wenn du das im Detail vorstellen möchtest, bin ich gerne bereit das weiter zu diskutieren.
            Im Moment kann ich sowohl in Bezug auf dein Vorwissen als auch auf die Arbeitsweise deines Frameworks nur mutmaßen.
            [IMG]https://g.twimg.com/twitter-bird-16x16.png[/IMG][URL="https://twitter.com/fschmengler"]@fschmengler[/URL] - [IMG]https://i.stack.imgur.com/qh235.png[/IMG][URL="https://stackoverflow.com/users/664108/fschmengler"]@fschmengler[/URL] - [IMG]http://i.imgur.com/ZEqflLv.png[/IMG] [URL="https://github.com/schmengler/"]@schmengler[/URL]
            [URL="http://www.schmengler-se.de/"]PHP Blog[/URL] - [URL="http://www.schmengler-se.de/magento-entwicklung/"]Magento Entwicklung[/URL] - [URL="http://www.css3d.net/"]CSS Ribbon Generator[/URL]

            Kommentar

            Lädt...
            X