Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- dev:all:psr [03.06.2015 15:48] – Externe Bearbeitung 127.0.0.1
+++ dev:all:psr [31.12.2024 03:23] (aktuell) – [Allgemeine Regeln für Addons] Manuela v.d.Decken
@@ Zeile 3: / Zeile 3: @@
 {{:check.png?nolink&128 |Standards}}Die Standards für WebsiteBaker wurden jetzt auch nicht neu erfunden und willkürlich festgelegt, sondern wir verwenden prinzipiell die selben, die auch sehr viele andere namhafte Projekte und große Frameworks (siehe [[http://www.php-fig.org/#voting-members|PHP-FIG Referenzliste]]) benutzen.
-Die grundlegenden Standards für WebsiteBaker sind die Standards [[http://www.php-fig.org/psr/psr-0|PSR-0]] / [[http://www.php-fig.org/psr/psr-1|PSR-1]] / [[http://www.php-fig.org/psr/psr-2|PSR-2]] und [[http://www.php-fig.org/psr/psr-4|PSR-4]] der **PHP Framework Interop Group**.\\
+Die grundlegenden Standards für WebsiteBaker sind die Standards [[http://www.php-fig.org/psr/psr-1|PSR-1]] / [[http://www.php-fig.org/psr/psr-12|PSR-12]] und [[http://www.php-fig.org/psr/psr-4|PSR-4]] der **PHP Framework Interop Group**.\\
-Auf den nachfolgenden Seiten haben wir die Originalstandards ins Deutsche übersetzt. Vielleicht nicht ganz wörtlich, jedoch absolut sinngemäß. Manche mögen sich an der recht strikten Ausdrucksweise (das MUSS!, das DARF NICHT! etc.) stören. Diese Ausdrücke sind aber exakt so aus den originalen PSRs, die sich wiederum strikt an [[http://tools.ietf.org/html/rfc2119|RFC 2119]] halten, übernommen worden und sollten auch exakt so verstanden werden.\\
+Auf den nachfolgenden Seiten haben wir die Originale ins Deutsche übersetzt. Vielleicht nicht ganz wörtlich, jedoch absolut sinngemäß. Manche mögen sich an der recht strikten Ausdrucksweise (das MUSS!, das DARF NICHT! etc.) stören. Diese Ausdrücke sind aber exakt so aus den originalen PSRs, die sich wiederum strikt an [[http://tools.ietf.org/html/rfc2119|RFC 2119]] halten, übernommen worden und sollten auch exakt so verstanden werden.\\
 Die wichtigsten Schlüsselworte wurden/werden nach folgendem, in RFC2119 definierten Sinn übersetzt:
 ^englisch ^deutsch ^Erklärung |
-|MUST / REQUIRED / SHALL |MUSS / ERFORDERLICH / SOLL |es ist ein absolutes Erfordernis der Spezifikation. |
+|MUST /\\ REQUIRED /\\ SHALL |MUSS /\\ ERFORDERLICH /\\ SOLL |es ist ein absolutes Erfordernis der Spezifikation. |
-|MUST NOT / SHALL NOT |DARF NICHT / SOLL NICHT |es ist ein absolutes Verbot durch die Spezifikation. |
+|MUST NOT /\\ SHALL NOT |DARF NICHT /\\ SOLL NICHT |es ist ein absolutes Verbot durch die Spezifikation. |
-|SHOULD / RECOMMENDED |SOLLTE / EMPFOHLEN |Auch das ist ein absolutes Erfordernis/Verbot. Jedoch kann es in Ausnahmefällen gute Gründe geben, diesen Punkt zu ignorieren. Dazu sollten aber die vollen Auswirkungen der Missachtung gut verstanden und sehr genau überlegt werden ob die Abweichung tatsächlich erforderlich ist.|
+|SHOULD /\\ RECOMMENDED |SOLLTE /\\ EMPFOHLEN |Auch das ist ein absolutes Erfordernis/Verbot. Jedoch kann es in wenigen Ausnahmefällen gute Gründe geben, diesen Punkt zu ignorieren. Dazu sollten aber die vollen Auswirkungen der Missachtung gut verstanden sein und sehr genau überlegt werden ob die Abweichung tatsächlich erforderlich ist.|
-|SHOULD NOT / NOT RECOMMENDED |SOLLTE NICHT / NICHT EMPFOHLEN |:::|
+|SHOULD NOT /\\ NOT RECOMMENDED |SOLLTE NICHT /\\ NICHT EMPFOHLEN |:::|
-|MAY / OPTIONAL |KANN / OPTIONAL |hiermit wird eine wirkliche Option bezeichnet, die sein kann aber nicht muss|
+|MAY /\\ OPTIONAL |KANN /\\ OPTIONAL |hiermit wird eine wirkliche Option bezeichnet, die sein kann aber nicht sein muss|
-  * **[[dev:all:psr:psr-0|Autoloading Standard]]** - Er zielt darauf ab, ein standardisiertes Dateiformat sowie Klassennamen und Namespace Konventionen bereitzustellen, die Plug&Play Code ermöglichen.
+  * **[[dev:all:psr:psr-0|Autoloading Standard]]** - Er zielt darauf ab, ein standardisiertes Dateiformat sowie Klassennamen und Namespace Konventionen bereitzustellen, die Plug&Play Code ermöglichen. <span important>Seit 2014-10-21 ist PSR-0 als unerwünscht markiert. PSR-4 ist jetzt als Alternative empfohlen.</span>
   * **[[dev:all:psr:psr-1|Basic Coding Standard]]** - Hiermit soll ein möglichst hoher Grad an Kompatibilität von PHP-Code aus unterschiedlichen Quellen erreicht werden.
-  * **[[dev:all:psr:psr-2|Coding Style Guide]]** Enthält Anweisungen, die dafür sorgen, dass PHP-Code immer eine standardisierte optische Erscheinung hat.
+  * **[[dev:all:psr:psr-2|Extended Coding Style]]** Enthält Anweisungen, die dafür sorgen, dass PHP-Code immer eine standardisierte optische Erscheinung hat.
-  * **[[dev:all:psr:psr-4|Improved Autoloading]]** - Eine modernere Interpretation automatischen Ladens, die die weiteren Fortschritte im Ökosystem reflektiert.
+  * **[[http://www.php-fig.org/psr/psr-4|Improved Autoloading]]** - Eine modernere Interpretation automatischen Ladens, die die weiteren Fortschritte im Ökosystem reflektiert.
   * **[[dev:all:wb-adaption|WebsiteBaker-Adaption]]** - Generelle Anpassung der PSR-Standards an spezielle Bedingungen von WebsiteBaker.
 ===== Grundsätzliche Regeln zur Programmierung im WB-Umfeld =====
-Mit jeder weiteren Version von WebsiteBaker entfernt sich der Programmierstil immer weiter vom bisherigen, seit fast 10 Jahren gewohnten, 'anarchischen' Stil, hin zu einer immer modulareren, jedoch zwangsweise auch an strenge Schnittstellen gebundenen Programmierweise. Das wird vor allem von Addon-Programmierern ein konsequentes Umdenken erfordern.\\
+Mit jeder weiteren Version von WebsiteBaker entfernt sich der Programmierstil immer weiter vom bisherigen, seit 20 Jahren gewohnten, 'anarchischen' Stil, hin zu einer immer modulareren, jedoch zwangsweise auch an strenge Schnittstellen gebundenen Programmierweise. Das wird vor allem von Addon-Programmierern ein konsequentes Umdenken erfordern.\\
-Derzeit, also __bis zur 2.8.4__ ist die Einhaltung vieler Regeln noch freiwillig, __in der 2.8.4__ wird vieles bereits deprecated und __nach der 2.8.4__ werden viele der Vorgaben zwingend sein. Das alles hört sich für viele sehr einschränkend an, was aber gerne in Kauf genommen wird, da genau diese Einschränkungen letztendlich für eine stabile Modularität, für stabile Flexibilität und für Austauschbarkeit, Wiederverwendbarkeit und vor allem Wartungsfreundlichkeit von Code sorgen werden.
+Derzeit, also __bis zur 2.10__ ist die Einhaltung vieler Regeln noch freiwillig, __in der 2.12__ wird vieles bereits deprecated und __nach der 2.12__ werden nach und nach viele der Vorgaben zwingend werden. Das alles hört sich für viele sehr einschränkend an, was aber gerne in Kauf genommen wird, da genau diese Einschränkungen letztendlich für eine stabile Modularität, für stabile Flexibilität und für Austauschbarkeit, Wiederverwendbarkeit und vor allem Wartungsfreundlichkeit von Code sorgen werden.
 ==== Allgemeine Regeln für Addons ====
@@ Zeile 27: / Zeile 27: @@
 Addons...
-  - ... dürfen weder den Core noch andere Addons triggern, sondern werden grundsätzlich vom steuernden Core getriggert
+  - ... dürfen weder den Core noch andere Addons triggern, sondern werden grundsätzlich selbst vom steuernden Core getriggert
   - ... dürfen den Ablauf des Gesamtsystems nicht stören
   - ... ist im Normalfall keine direkte Verbindung zur Außenwelt gestattet
@@ Zeile 34: / Zeile 34: @@
   - ... dürfen ausschließlich über den Responder des Core Daten zum Browser etc. senden
   - ... dürfen keine globalen Variablen oder globalen Konstanten definieren.
-für spätere Versionen (nach 2.8.4) werden noch weitere Einschränkungen kommen. Siehe die jeweiligen Abschnitte dieser Dokumentation.
+  - ... dürfen **niemals** eine indirekte Adressierung verwenden oder zulassen!
+für spätere Versionen (nach 2.10.x) werden noch weitere Einschränkungen kommen. Siehe die jeweiligen Abschnitte dieser Dokumentation.

WebsiteBaker Documentation

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge