PHP rocks! wünscht allen Mitgliedern einen guten Rutsch ins neue Jahr 2017 !!!
Hinweis: Das Forum zieht um! Um keine Datenverluste zu haben, schalten wir zwecks Übernahme der Daten das Forum am Sonntag, den 24.04.2016 um ca. 21:00 Uhr offline und passen anschliessend die DNS-Einträge an.
www.php-rocks.de wird euch dann nach den Aktualisierungen der DNS-Server wieder wie gewohnt uneingeschränkt zur Verfügung stehen.
Danke für euer Verständnis!

Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Zend Zend Framewok, Psr-Autoloader
#1
Hallo an Alle,
ich möchte keine Grundsatzdiskussion vom Zaun brechen, auch ist es nicht wirklich wichtig, möchte es aber mal äußern und Meinungen dazu hören.

Aus verschieden Gründen (welche genau jetzt hier den Rahmen sprengen) möchte ich nun doch wohl das Zend Framework meinem Paradigma hinzufügen.

Dazu gibts eigentlich nicht mehr viel zu sülzen, was mich nur gerade beschäftigt und was mir gar nicht gefällt, es
geht im wesentlichen um Psr-0 versus Psr-4:
PHP-Code:
class Model_MyChildClass_undsoweiter ... 
Ich bevorzuge eigentlich
PHP-Code:
class <AppNamespace>/VendorNamespace/Model/MyClass .... 

Was nun, Expertenmeinungen?

Mein Framework berücksichtigt und implementiert eigentlich alle Psr-Autoloader, trotzdem gefällt es mir irgendwie nicht in bezug auf die Struktur der Application/Implementation.

mfg
Till
Antworten
#2
Die Spezifikation (PSR-4) ist in der Hinsicht einigermaßen strikt, dass der erste Teil der „vendor name“ ist.

Zitat:The fully qualified class name MUST have a top-level namespace name, also known as a “vendor namespace”.

- http://www.php-fig.org/psr/psr-4/

Die Idee/Konvention ist aber vor allem auch, dass Namespaces hierarchisch „von links nach rechts“ angeordnet sind und dass nur der Anbieter, dem ein Namespace „gehört“, diesen verwalten und darin Elemente erstellen sollte.

Ein „Zend\mermshaus“ statt eines „mermshaus\Zend“ wäre zwar wahrscheinlich auch sehr kollisionsresistent, weil die Zend-Framework-Leute sicher nie auf die Idee kommen würden, „mermshaus“ als zweiten Teil zu verwenden, aber je mehr Leute das machen, desto unübersichtlicher wird die gesamte Angelegenhet und desto schwieriger wird es unter Umständen, tatsächlich noch die Elemente zu finden, die wirklich vom Anbieter selbst (in dem Fall Zend – als Kurzform für die Zend–Framework–Entwickler) stammen. Irgendwann liegen sonst vielleicht 200 Sub-Namespaces im Zend-Namespace, obwohl nur 30 oder so davon wirklich von den eigentlichen Entwicklern stammen.

Das macht alles unnötig unübersichtich und suggeriert eben auch eine Assoziation des Codes mit einem Anbieter, die gar nicht besteht, weil einfach nur jemand seine Elemente in einem fremden Namespace platziert hat.

Technisch spricht wohl nichts dagegen, das zu tun, aber es verletzt eben Konventionen und dürfte zudem von der Community insgesamt nicht so gern gesehen werden, weil es im Sinne der gängigen Konvention eben auch „unhöflich“ ist, in fremden Namespaces rumzuwurschteln, auch wenn es überhaupt nicht unhöflich gemeint ist.
Antworten
#3
Hi,
ich glaube da hast Du irgendwas falsch verstanden:
Der <AppNameSpace> kann auch ein Vendornamespace sein, die <klammern> sollen andeuten das es sich nicht um einen "echten Namespace" handelt.
Fangen wir wieder beim Vendornamespace und das bin ich der das Package entwickelt, und nein natürlich nenne ich mich nicht Zend und mixe auch meinen Code nicht mit anderem core.
Dann gibt es noch so nette Features wie class_alias und use .... usw...

Beim den Psr-Autoloadern geht es vor allem darum Klassennamen auf Dateien/Verzeichnisse zu mappen.

Was Zend da macht ist eine Namingconvention meiner Meinung nach auch wenn sie es MVC nennen, ich glaube das wird hier mit Autoloading durcheinandergeworfen.

Aber wie dem auch sei, Zend hat sich lange bewehrt und ich als Zend-Einsteiger möchte keinesfalls draufrumhacken, aber mal meine Gedanken äußern.

Zitat:dass Namespaces hierarchisch „von links nach rechts“ angeordnet sind
Exakt das ist das Prinzip, ob von links nach rechts oder zurück es funktioniert bei domainnames, oid und telefonnumern warumm also nicht auch bei php namespaces.

Zitat:Ein „Zend\mermshaus“ statt eines „mermshaus\Zend“
Wenn mermshaus Deine App ist dann sei es auch der RootNamspace aber Zend liegt natürlich nicht darunter.
Unter mermshaus liegt nur Dein eigener krams.
Zend liegt außerhalb und wird mit Deinem Autloader geladen, zum Beispiel aus einem Verzeichnis vendor.
[docroot]
appdir/mermshaus\MermsApp
appdir/mermshaus\MermsApp\MermsSubModel
vendordir/Zend/...
vendordir/frdl/webfan

index.php :
PHP-Code:
<?php
namespace mermshaus;
use 
Zend;

require 
'https://github.com/frdl/webfan/blob/master/test/example.com/apc/apc-bootstrap/bootstrap.php';

 
 \frdl\webfan\Autoloading\SourceLoader::top()
 
      ->addPsr4('myCodeDealer\\'__DIR__.DIRECTORY_SEPARATOR.'vendordir'.DIRECTORY_SEPARATOR.'myCodeDealer'.DIRECTORY_SEPARATOR.'UndSeinZeugs'.DIRECTORY_SEPARATORfalse
 
       
->addPsr4('MermsApp\\'__DIR__.DIRECTORY_SEPARATOR.'appdir'.DIRECTORY_SEPARATOR.'MermsApp'.DIRECTORY_SEPARATORfalse 
       
->addPsr0('\\'__DIR__.DIRECTORY_SEPARATOR.'appdir'.DIRECTORY_SEPARATOR.'MermsApp'
 
                                                          .DIRECTORY_SEPARATOR.'mz'.DIRECTORY_SEPARATOR
                                                           
.DIRECTORY_SEPARATOR.'Merms'.DIRECTORY_SEPARATOR
                                                           
.DIRECTORY_SEPARATOR.'SeinZendModel'.DIRECTORY_SEPARATOR
                                                           
false 
 
  

Mh, so ungefähr sieht das aus in einer Implementation aus meinem Namespace.
Es sieht halt aktuell so aus das ich hier eine Komponente hab welche Zend verwendet und ich eine Anwendung implementieren muß, und diese ganze studiererei von Namenskonventionen hält mich irgendwie von der Arbeit ab,
dieses mixen von Vendor_Parent_Interface_Name im Klassennamen.
Faßt würde ich sagen wollen im hebräischen schreibt man auch abwechselnd von rechts nach links und umgekehrt in einem Satz.
Ich weiß nur noch nicht was das zu bedeuten hat.

Wie dem auch sei, tut mir leid, unnötiger Thread.

mfg
Antworten


Gehe zu: