Benutzer-Werkzeuge

Webseiten-Werkzeuge


dev:all:psr

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
dev:all:psr [20.08.2019 01:49] – [Offizielle Standards] Manuela v.d.Deckendev: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.  {{: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-12]] 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: Die wichtigsten Schlüsselworte wurden/werden nach folgendem, in RFC2119 definierten Sinn übersetzt:
 ^englisch ^deutsch ^Erklärung | ^englisch ^deutsch ^Erklärung |
Zeile 20: Zeile 20:
  
 ===== Grundsätzliche Regeln zur Programmierung im WB-Umfeld ===== ===== Grundsätzliche Regeln zur Programmierung im WB-Umfeld =====
-Mit jeder weiteren Version von WebsiteBaker entfernt sich der Programmierstil immer weiter vom bisherigen, seit 15 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.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. 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.
  
Zeile 27: Zeile 27:
  
 Addons...   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   - ... dürfen den Ablauf des Gesamtsystems nicht stören
   - ... ist im Normalfall keine direkte Verbindung zur Außenwelt gestattet   - ... ist im Normalfall keine direkte Verbindung zur Außenwelt gestattet
dev/all/psr.1566265744.txt.gz · Zuletzt geändert: 20.08.2019 01:49 von Manuela v.d.Decken