Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Bibliotheken standarisierung

Einklappen

Neue Werbung 2019

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

  • [Erledigt] Bibliotheken standarisierung

    Hallo,

    ich entwerfe aktuell eine Software die durch Apps erweiterbar sein soll. Jetzt ist mir aufgefallen, das es ja anscheinden bei PHP Bibliotheken, keinen Standard gibt wie es Beispielsweise bei Paketen bei Debian ist.

    Die Probleme sind folgenden bei geteilten Bibliotheken:
    - Jede Bibliothek hat andere autoload Methoden
    - Die Version ist immer unterschiedlich abrufbar
    - Namenskontroversen
    - Eigene Namespace implementierungen (siehe Zend)

    Gibt es etwa schon Ansätze oder würdet ihr, wenn ihr so eine Software entwickelt einfach das Format oder den Aufbau vorschreiben und eine globale spl_autoload Funktion definieren?

  • #2
    Es gibt einen inoffiziellen „Standard“: http://www.php-fig.org/ (dort PSR-0)

    Dann gibt es Composer als Paketmanager mit Packagist als „offiziellem“ Repository.

    Mit Composer bist du gut dabei. Konkretere Fragen dazu kannst du gerne stellen, falls die Links etwas unklar lassen.

    PS: Composer bringt auch einen Autoloader mit, der hinreichend PSR-0-kompatibel ist. Es kann sich schon allein deshalb lohnen, Composer ins Boot zu holen, um den Autoloader zu kriegen.

    Kommentar


    • #3
      Ich umreiße das PS doch mal kurz mit einem Beispiel.

      Nehmen wir mal an, wir haben ein Projekt „MyProject“ mit dem beliebigen Projektverzeichnis PROJECTDIR. Das Projekt hat eine Klasse MyProject\Foo\Hello. Nach unter anderem PSR-0 läge die in einer Datei MyProject/Foo/Hello.php, sagen wir mal in einem ./src-Unterverzeichnis des Projektverzeichnisses.

      PROJECTDIR/src/MyProject/Foo/Hello.php:

      Code:
      <?php
      
      namespace MyProject\Foo;
      
      class Hello
      {
          public function __construct()
          {
              echo "Hello World!\n";
          }
      }
      Für alles aus dem Namespace MyProject wollen wir nun Autoloading per Composer.

      Dazu wird eine composer.json-Datei im Projektverzeichnis benötigt.

      PROJECTDIR/composer.json:

      Code:
      {
          "autoload": {
              "psr-0": {
                  "MyProject": "src"
              }
          }
      }
      „Lieber Autoloader, wenn du etwas aus dem MyProject-Namespace laden willst, findest du die Dateien im src-Verzeichnis, angeordnet nach dem PSR-0-Schema.“

      In einer Index-Datei im Projektverzeichnis wird nun der Autoloader eingebunden und die Klasse instanziiert.

      PROJECTDIR/index.php:

      Code:
      <?php
      
      require __DIR__ . '/vendor/autoload.php';
      
      new MyProject\Foo\Hello();
      Das war es im Prinzip. Was jetzt noch kommt, ist das Standard-Composer-Setup: composer.phar herunterladen und install ausführen.

      Das erledigen diese Befehle in PROJECTDIR:

      Code:
      $ curl -s http://getcomposer.org/installer | php
      $ php composer.phar install
      (Das ist für u. a. Linux. Falls das jemand auf Windows „übersetzen“ kann, sehr gerne. Das sollte aber kein großes Problem darstellen. Download + Ausführen.)

      Ausgabe:

      Code:
      Downloading...
      
      Composer successfully installed to: /home/public_html/marc/fiddle/composer/composer.phar
      Use it: php composer.phar
      Code:
      Installing dependencies
      Nothing to install or update
      Writing lock file
      Generating autoload files
      Der komplette Inhalt von PROJECTDIR sieht nun so aus:

      Code:
      .
      ├── composer.json
      ├── composer.lock
      ├── composer.phar
      ├── index.php
      ├── src
      │   └── MyProject
      │       └── Foo
      │           └── Hello.php
      └── vendor
          ├── autoload.php
          └── composer
              ├── autoload_classmap.php
              ├── autoload_namespaces.php
              └── ClassLoader.php
      
      5 directories, 9 files
      Das war alles.

      Code:
      $ php -f index.php 
      Hello World!
      * * *

      Hinzufügen einer Abhängigkeit aus dem Packagist-Repository. Etwa Twig. Oder Doctrine. Oder beide.

      PROJECTDIR/composer.json erweitern:

      Code:
      {
          "require": {
              "doctrine/orm": "2.2.3",
              "twig/twig": "1.9.1"
          },
          "autoload": {
              "psr-0": {
                  "MyProject": "src"
              }
          }
      }
      Composer-Anweisung:

      Code:
      $ php composer.phar update
      Composer lädt die Dateien herunter und packt sie mit in das vendor-Verzeichnis und aktualisiert den Autoloader.

      Code:
      Updating dependencies
        - Installing doctrine/common (2.2.2)
          Downloading: 100%         
      
        - Installing doctrine/dbal (2.2.2)
          Downloading: 100%         
      
        - Installing doctrine/orm (2.2.3)
          Downloading: 100%         
      
        - Installing twig/twig (v1.9.1)
          Downloading: 100%         
      
      Writing lock file
      Generating autoload files
      Die Abhängigkeiten zu doctrine/common und doctrine/dbal wurden automatisch erkannt und befriedigt.

      Veränderte index.php-Datei:

      Code:
      <?php
      
      require __DIR__ . '/vendor/autoload.php';
      
      new MyProject\Foo\Hello();
      
      var_dump(
          Twig_Environment::VERSION,
          Doctrine\ORM\Version::VERSION
      );
      Wenn alles geklappt hat:

      Code:
      Hello World!
      string(5) "1.9.1"
      string(5) "2.2.3"
      * * *

      Tipp für die Versionsverwaltung: ./composer.phar und das ./vendor-Verzeichnis auf die Ignore-Liste setzen und nach jedem Checkout kurz

      Code:
      $ curl -s http://getcomposer.org/installer | php
      $ php composer.phar install
      ausführen.

      Für Leute, die gern den Workflow komplett unter Kontrolle haben, gibt es auch Lösungen. Das habe ich hier ausgeklammert. Es ist etwa möglich, ein eigenes Packagist-Repository aufzusetzen und so die Verfügbarkeit zu garantieren. Oder noch einfacher lassen sich als Abhängigkeiten Git-Repositories angeben (ich glaube auch SVN), die natürlich lokal aufbewahrt werden können. (Edit: Ich glaube, es sind sogar Zip-Archive als Quellen möglich, falls gar kein VCS vorhanden ist.)

      Composer klont zudem Abhängigkeiten, die Git-Repositories sind (dito ich glaube auch SVN) und bietet so im Grunde auch die Funktionalität von Git-Submodules (SVN-Externals?) an. Na ja, Doku lesen.

      Kommentar


      • #4
        Vielen Dank für die ausführliche Antwort.

        Mein Frage ist damit beantwortet

        Überschneidender Threadt: http://www.php.de/php-fortgeschritte...paces-spl.html

        Kommentar

        Lädt...
        X