PSR-14 - الحدث الرئيسي في PHP

في العام الماضي ، أصدرت PHP-FIG ، مجموعة مفاهيم توافق PHP ، العديد من المواصفات الجديدة. آخر واحد ، PSR-14 ، مكرس لإرسال الحدث. مثل PSRs الأخرى ، هذا مواصفات محلية ، لكن له تأثير كبير على العديد من جوانب التقييس.

من أحد المترجمين: هذه ترجمة للجزء الأول من سلسلة من المنشورات التي يشرح فيها لاري (كريل) غارفيلد ، أحد أعضاء PHP-FIG ، ماهية PSR-14 وما هي قادرة وما هي ليست كذلك وما هي أفضل طريقة لاستخدامها في مشاريعهم.

هدف

إيفاد الحدث منذ فترة طويلة تستخدم في العديد من اللغات. إذا سبق لك استخدام EventDispatcher في Symfony ، أو Event Event في Laravel ، أو السنانير في Drupal ، أو Event Manager في إطار Zend ، أو حزمة League \ Event ، أو شيء من هذا القبيل ، فأنت تفهم ما يدور حوله.

بمعنى عام ، كل هذه الأنظمة هي شكل من أشكال "الوسيط المراقب". يرسل جزء واحد من التعليمات البرمجية رسالة من النوع - "حدث" ، ويقوم الوسيط بإرسالها إلى أجزاء فردية أخرى من التعليمات البرمجية - "المستمعين". في بعض الأحيان يتم توجيه الإشارة فقط في اتجاه واحد ، في بعض الأحيان يمكن "للمستمع" إرسال البيانات بطريقة ما إلى المتصل. بالطبع ، كلها مختلفة وغير متوافقة للغاية مع بعضها البعض.

هذه مشكلة بالنسبة للمكتبات المستقلة التي ترغب في الاتصال بمختلف المكتبات والتطبيقات. يمكن توسيع العديد من المكتبات عن طريق إرسال الأحداث في نموذج أو آخر بحيث يمكن الاتصال بها رمز آخر. لكن هذه الطبقة الوسيطة هي ، في الواقع ، ملكية. ثم يتم دمج المكتبة التي تدير Symfony EventDispatcher مع Symfony. ثم استخدامه في مكان آخر يتطلب تثبيت EventDispatcher والاتصال بالمكتبات في البرنامج. ثم يتم ربط المكتبة التي تستدعي نظام الربط من Drupal module_invoke_all() بـ Drupal. و هكذا.

الهدف من PSR-14 هو تخليص المكتبات من هذه التبعية. يسمح هذا للمكتبات بالتوسع من خلال طبقة شائعة رقيقة ، ومن ثم تسهيل نقلها إلى بيئة أخرى دون بذل جهد وتكاليف إضافية ، على سبيل المثال ، في Symfony أو Zend Framework أو Laravel أو TYPO3 أو eZ Platform أو Slim. طالما كانت البيئة متوافقة مع PSR-14 ، فكل شيء سينجح.

مواصفة

كما ذكرنا سابقًا ، المواصفات خفيفة جدًا. هذه ثلاث واجهات في طريقة واحدة ووصف تعريف لكيفية استخدامها. كل شيء بسيط ومريح. أدناه هو رمز لهذه الواجهات (لا يوجد تعليق لتوفير مساحة).

 namespace Psr\EventDispatcher; interface EventDispatcherInterface { public function dispatch(object $event); } interface ListenerProviderInterface { public function getListenersForEvent(object $event) : iterable; } interface StoppableEventInterface { public function isPropagationStopped() : bool; } 

الأولين هما جوهر المواصفات. StoppableEventInterface هو امتداد سنعود إليه لاحقًا.

أعتقد أن EventDispatcher مألوف لدى EventDispatcher - إنه مجرد كائن EventDispatcher التي EventDispatcher بها الحدث - الوسيط الذي تحدثت عنه بالفعل. ومع ذلك ، لم يتم تعريف الحدث نفسه - يمكن أن يكون أي كائن PHP . المزيد عن هذا في وقت لاحق.

تحتوي معظم التطبيقات الحالية على كائن واحد أو مجموعة من الوظائف التي تعمل كوسيط أو مرسل وكذلك مكان لتسجيل الكود الذي يستقبل الحدث (المستمعين). بالنسبة إلى PSR-14 ، قمنا بتقسيم هاتين المسألتين عمداً إلى كائنات منفصلة. يتلقى المرسل قائمة المستمعين من كائن الموفر الذي يشكل هذه القائمة.

من أين يحصل المزود على قائمة المستمعين؟ نعم ، أين يريد! هناك مليار وطريقة واحدة لتوصيل المستمع والحدث ، وكلها صالحة تماما وغير متوافقة. في البداية ، قررنا أن توحيد "طريقة واحدة حقيقية" لتسجيل الطلاب سيكون محدودًا جدًا. ومع ذلك ، من خلال توحيد عملية توصيل المستمع بالمرسل ، يمكنك الحصول على مرونة ممتازة دون إجبار المستخدم على القيام بشيء غريب وغير مفهوم.

أيضا ، لا يشير الرمز إلى ما هو المستمع. يمكن أن يكون أي جزء PHP قادرًا على إدراك الإشارة: وظيفة ، وظيفة مجهولة ، طريقة كائن ، أي شيء. نظرًا لأن الكائن المستدعي يمكنه فعل أي شيء ، يجوز أن يكون لديه ، كمستمع ، وظيفة مجهولة تؤدي تأجيل تحميل خدمة من حاوية DI وتتصل بالطريقة الموجودة في الخدمة ، والتي تحتوي بالفعل على رمز الاستماع.

باختصار ، المرسل هو واجهة برمجة تطبيقات بسيطة وسهلة لمؤلفي المكتبة. يقدم مزودو المستمع واجهة برمجة تطبيقات قوية ومرنة لأدوات تكامل الإطار ، وتجمعهم العلاقة بين المرسل والموفر.

مثال بسيط

بشكل عام ، فإن مخطط الجمع بين جميع الأجزاء في مجملها سوف يبدو مثل هذا.

 class Dispatcher implements EventDispatcherInterface { public function __construct(ListenerProviderInterface $provider) { $this->provider = $provider; } public function dispatch(object $event) { foreach ($this->provider->getListenersForEvent($event) as $listener) { $listener($event); } return $event; } } $dispatcher = new Dispatcher($provider); $event = new SomethingHappened(); $dispatcher->dispatch($event); 

توفر هذه الشفرة الصغيرة فرصًا رائعة ، وهي مرنة جدًا. في المقالات التالية ، سنتحدث بالتفصيل عن خصائصها ، ونحلل بعض الحلول الهيكلية وننظر في الطرق العديدة لاستخدام مثل هذه الأحداث خفيفة الوزن.

قانون

يدعم PSR-14 بالفعل الأطر والتطبيقات الرئيسية.

• تعهد Matthew Weier O'Phinney بتقديم دعم PSR-14 في برنامج zend-eventmanager 4.0 في إطار Zend.
  
• أعلنت Symfony مؤخراً عن تغييرات في EventDispatcher للتوافق مع PSR-14 ، والتي ستوفر الدعم الكامل في 5.0 / 5.1.
  
• أعلن إطار Yii عن نيته لدمج PSR-14 في الإصدار 3.0 .
  
• قال Benni Mack من TYPO3 CMS أنه في الإصدار TYPO3 التالي ، ستدعم جميع مفاهيم إشارة + فتحة / مصيدة موجودة PSR-14.
  

يحتوي PSR-14 أيضًا على ثلاثة تطبيقات مستقلة تعمل بكامل طاقتها والتي يمكنك استخدامها بالفعل في أي تطبيق.

• توكيو لاري غارفيلد ، مؤلف هذا المقال.
  
• فلي إيفنت ديسباتشر من قبل ماثيو واير أوفني.
  
• كارت من Benni Mack ، الذي يعمل كبرنامج إضافي مضمن.
  

يشكر المؤلف مجموعة العمل PSR بأكملها: لاري غارفيلد ، سيس جان كيويت ، بنجامين ماك ، إليزابيث سميث ، ريان ويفر ، ماثيو واير أوفنني . طوال العملية ، كانت العملية مثمرة للغاية: عمل الجميع معًا بشكل جماعي ، كما ينبغي. والنتيجة مرضية ، وأود أن تكون كل الجهود الإضافية في العمل المشترك على الهندسة المعمارية مثمرة.

يمكنك معرفة المزيد من التفاصيل إما من أصل الجزء التالي والوثائق أو من 17 مايو في PHP Russia . الخيار الثاني جذاب لعدة أسباب. على سبيل المثال ، رئيس لجنة البرنامج ، ألكساندر ( samdark ) ماكاروف ، هو من بين أولئك الذين قدموا PSR-14 في Yii. ومن حيث المبدأ ، فإن تكوين لجنة البرنامج والمتحدثين قوي بشكل لا يصدق ، لا يكاد يكون هناك أي موضوع من مجال الاستخدام المهني لـ PHP لا يمكن مناقشته في هذا المؤتمر.