Wordpress und ereignisgesteuerte Programmierung - worum geht es?


7

Ich möchte ganz klar sagen, dass dies nicht die Absicht hat, die Diskussion über funktionale / prozedurale Programmierung im Vergleich zu objektorientierter Programmierung wiederzubeleben. Darüber wird auf WPSE und im ganzen Netz viel gesagt.

Aber vor einiger Zeit habe ich einige Diskussionen über die Programmiergrundlagen von Wordpress gelesen und etwas gelesen - ich muss es umformulieren, weil ich es damals leider nicht mit einem Lesezeichen versehen habe - ungefähr so:

Eines der attraktiven Dinge bei der Verwendung von Wordpress ist, dass sie zusätzlich auf dem ereignisgesteuerten Paradigma der Programmierung basieren .

Von dem, was ich verstehe , ereignisgesteuerte Programmierung in diesem Zusammenhang ist ziemlich viel Synonym zu Signal oder Datenflussprogrammierung . Darüber hinaus - wahrscheinlich zu stark vereinfacht - ist das Hauptmerkmal möglicherweise die Verwendung von Haken - Aktionen und Filtern - als Dreh- und Angelpunkt für die Methode.

So weit, ist es gut. Scheint einfach zu sein, aber ich komme nicht aus der Informatik, daher bin ich mir ziemlich sicher, dass noch mehr zu sagen ist. Ich bin wirklich an einigen Beiträgen interessiert, wie zum Beispiel: Worum geht es wirklich oder wird das oben Gesagte so ziemlich gesagt? Ist es ein zusätzliches Paradigma? Wie verhält es sich zu den anderen? Ist es ein Kernprinzip oder nur eine Ergänzung?

Diese sind einfach unglaublich und verstoßen eindeutig gegen die Regeln, indem sie nicht eine einzige Frage stellen, die eine eindeutige Antwort hat, aber vielleicht wird dies einmal vergeben.

Antworten:


9

Lassen Sie uns zunächst klären, was paradigmWort in der Programmierung bedeutet. Dies bedeutet, dass wir uns darauf einigen, dass wir bestimmte Fälle / Probleme / Situationen auf bestimmte Weise behandeln.

Zum Beispiel kommen wir zu Vereinbarungen, dass Fußgänger in unserem Land grünes Licht über eine Straße geben sollen. Dies ist unser grünes Licht Paradigma. In einem anderen Land könnte eine Vereinbarung getroffen werden, eine Straße mit erhobener Hand zu überqueren. Das ist ihr Paradigma der erhobenen Hand . Sie sind nicht miteinander verwandt, sie existieren nur und Fußgänger könnten entweder ein Paradigma verwenden oder ihr eigenes Kreuzungskreuz erstellen , wann immer ich ein Paradigma möchte .

Die gleiche Situation ist in der Programmierung. Das Paradigma ist nur eine Reihe von Regeln oder Vereinbarungen, um eine Anwendung auf eine bestimmte Weise zu entwickeln oder einen bestimmten Ansatz zu verwenden. Nichts mehr.

Ok, kehren Sie zu WordPress und dem ereignisgesteuerten Paradigma zurück. Dieses Paradigma ist nur ein Teil des gesamten WordPress-Systems. Dieses Paradigma legt eine Reihe von Regeln / Vereinbarungen fest, wie der Kern um Erweiterungen von Drittanbietern erweitert werden kann, wobei Hooks für Aktionen und Filter ein zentraler Ansatz sind. Beachten Sie, dass dieses Paradigma nur Erweiterungsfälle / -probleme / -situationen abdeckt und dass dies nicht nur das von WordPress verwendete Paradigma ist, sondern eines der Kernparadigmen.

Das ist alles. Natürlich kannst du dein eigenes Plugin / Theme schreiben, wie ich das Paradigma will und damit zufrieden sein :)


2
Danke, ich liebe den Einblick in den Paradigmenbegriff! Persönlich bin ich mir dessen sehr bewusst, da ich meine Masterarbeit über die Feldtheorie des Wissens, der Erkenntnistheorie, der Wissenschaftsgeschichte usw. geschrieben habe. Glauben Sie mir, was ich geschrieben habe, war nicht so eingängig wie Ihre Erklärung. Ich bin sicher, was Sie geschrieben haben, wird den Menschen zu einem besseren Verständnis verhelfen.
Nicolai

Bitte schön. Ich hoffe, dass es auch helfen wird.
Eugene Manuilov

Nur um es aufzuschlüsseln, kann als Teil des Wordpress SystemAspekts von event-driven programminginterpretiert werden als paradigm of expansibility. Ich würde in erster Linie sagen, dass andere den WordPress-Kern nutzen sollen. Und wenn man kein Plugin mit "wie ich will" -Paradigma schreibt, sondern dem folgt paradigm of expansibility, kann es als Grundregel verwendet werden, um Plugins / Themes auch erweiterbar zu machen.
Nicolai

2

Ich denke, dass mit ereignisgesteuerten Paradigmen , die Artikel schreiben, Observer Pattern beabsichtigt .

Und das in WordPress wird über die Plugins Api abgewickelt . Ich glaube nicht, dass es noch viel mehr zu sagen gibt.


Ihr erster Satz ist schwer zu verstehen, aber mit dem Artikel, den Sie verlinkt haben, bekomme ich, was Sie anstreben. Mir ist klar Plugins API, dass es in diesem Zusammenhang bemerkenswert sein könnte, auf den Unterschied zwischen Filtersund hinzuweisen Actions.
Nicolai

Nur um zu verdeutlichen, obwohl der Beobachter ereignisgesteuert ist, stimmt er nicht vollständig mit der gleichmäßigen Natur von Wordpress überein. Hauptsächlich, weil die beiden Objekte - Beobachter und Subjekt - unter Verwendung des Beobachtermusters einander kennen und miteinander kommunizieren. Dies ist nicht der Fall, wenn Hooks verwendet werden, um ein ereignisgesteuertes Paradigma zu verwenden, wie es WordPress implementiert hat. In diesem Fall findet nur ein Abfangen statt und es findet keine wechselseitige Kommunikation statt.
Nicolai

2
@ialocin Observer Es ist nur ein abstraktes Muster, das auf verschiedene Arten implementiert werden kann. Abstrakt gesprochen benachrichtigt das Subjekt die Beobachter und es ist nicht erforderlich, dass Beobachter mit dem Subjekt kommunizieren . Implementieren Sie dieses Muster nach diesem WP nicht wirklich, sondern ahmen Sie es einfach nach: In WP gibt es weder ein Subject- Objekt noch ein Observer- Objekt: Alles wird mit globalen Variablen behandelt ...
gmazzap

@ialocin In Bezug auf Ihren ersten Kommentar gibt es in diesem speziellen Fall keinen Unterschied zwischen Aktionen und Filtern. Beide lösen Ereignisse aus: Versuchen Sie es add_filter('the_title', 'test'); function test($t) { error_log('foo'); return $t; }. Es ist vollkommen legal und das Ereignis wird sogar mit einem Filter ausgelöst.
gmazzap

Vielen Dank für die weitere Klärung des Beobachtermusters . Ich habe nicht versucht zu sagen, dass dies der einzige Weg ist, dies umzusetzen. Ich habe nur versucht zu erklären, dass das Common Ground Event Driven nicht bedeutet, dass es in WordPress auf die gleiche Weise implementiert wird, aber Ihr Kommentar macht das sehr gut. Über den ersten Kommentar, danke, dass Sie das auch klar gemacht haben. Sie haben Recht - natürlich. Ich habe mehr über Leute nachgedacht, die nichts über die Plugins-API wissen und wie man den Punkt in Ihrer Antwort plausibler und / oder für sie zugänglicher macht.
Nicolai


1

Wordpress ist aufgrund der Einschränkungen der Sprache, in der es geschrieben ist, ereignisgesteuert und nicht, weil es in irgendeiner Weise so konzipiert ist.

Die beliebtesten Webserver sind ereignisgesteuert und PHP hat nur sehr wenige Dienstprogramme (keine?), Um sich anders zu verhalten. Da WordPress von PHP abhängt, kann es einfach nichts anderes sein.

Der PHP-Teil von WordPress-Plugins und -Themen OTOH sollte so gestaltet sein, dass er von "Ereignissen" gesteuert wird, die vom Kern "gesendet" werden. JS-Code ist ebenfalls ereignisgesteuert, aber die Ereignisse sind fast nur diejenigen, die von einem tatsächlichen Benutzer ausgelöst werden (obwohl ein Teil des WordPress-JS-Codes ihn ebenfalls abstrahiert und eigene Ereignisse auslöst).


Selbst mit PHP ist es möglich, verschiedene Muster und Designs zu implementieren. Es geht also nicht nur darum, dass WordPress auf PHP basiert, sondern es gibt natürlich auch Grundregeln.
Nicolai

@Nicolai ok, vielleicht ist es möglich, und ich war nicht ganz genau, aber Apache + PHP sind auf das Ereignis und seine Reaktion ausgerichtet. Wenn das Skript nicht "immer ausgeführt" wird, beispielsweise wie Java-basierte Webserver, wird es schwieriger, etwas anderes zu implementieren.
Mark Kaplun
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.