ZF2 EventManager

मैथ्यू वेयेर ओफ़िननी ब्लॉग से ज़ेंड फ्रेमवर्क 2 में EventManager बारे में एक लेख का थोड़ा मुफ्त अनुवाद।
उदाहरण में लेख Zend\EventManager बारे में बात करता Zend\EventManager , इसका उपयोग कैसे करें, PHP में प्रोग्रामिंग समस्याओं को हल करने के लिए घटना-आधारित तरीके से क्या लाभ है। ZF2 में नया क्या है।
मूल और अनुवाद zf2.dev4 की रिलीज के दौरान लिखा गया था, .beta1 से पहले, कोई महत्वपूर्ण बदलाव नहीं हुए थे। लेकिन फिर भी, लेख का उपयोग समीक्षा के लिए किया जाना चाहिए, अब और नहीं।

शब्दावली

• इवेंट मैनेजर
  एक ऑब्जेक्ट जो इवेंट हैंडलर (श्रोता) को एक या अधिक नामांकित ईवेंट (ईवेंट) के लिए एकत्रित करता है, और इन ईवेंट के प्रसंस्करण को भी ट्रिगर करता है।
  
• श्रोता (इवेंट हैंडलर)
  कॉलबैक फ़ंक्शन / विधि।
• घटना (इवेंट)
  एक क्रिया जो कुछ घटना संचालकों के निष्पादन को ट्रिगर करती है

एक घटना एक वस्तु है जिसमें डेटा कब और कैसे ट्रिगर किया गया था: किस वस्तु ने इसे कहा, पैरामीटर पारित किया, आदि। इस घटना का एक नाम भी है, जो आपको इस घटना के नाम का जिक्र करते हुए हैंडलर को एक विशेष घटना में बांधने की अनुमति देता है।

चलिए शुरू करते हैं

इस सब के साथ काम करने के लिए आवश्यक न्यूनतम चीजें:

• EventManager वर्ग की एक आवृत्ति।
• एक या अधिक इवेंट हैंडलर एक या अधिक ईवेंट से जुड़े होते हैं।
• ईवेंट प्रोसेसिंग आरंभ करने के लिए EventManager::trigger() को कॉल करें।

 use Zend\EventManager\EventManager; $events = new EventManager(); $events->attach('do', function($e) { $event = $e->getName(); $params = $e->getParams(); printf( 'Handled event "%s", with parameters %s', $event, json_encode($params) ); }); $params = array('foo' => 'bar', 'baz' => 'bat'); $events->trigger('do', null, $params); 

उत्पादन में हम प्राप्त:

  हैंडल किए गए ईवेंट "डू", मापदंडों के साथ {"फू": "बार", "बाज": "बैट"} 

कुछ भी जटिल नहीं!

नोट: उदाहरण एक अनाम फ़ंक्शन का उपयोग करते हैं, लेकिन आप एक फ़ंक्शन नाम, एक स्थिर क्लास विधि या एक ऑब्जेक्ट विधि का उपयोग कर सकते हैं।

लेकिन $events->trigger() पद्धति में दूसरा "अशक्त" तर्क क्या है?

आमतौर पर, एक EventManager उपयोग एक वर्ग के भीतर किया जाता है, और इस घटना को उस वर्ग के कुछ तरीके से शुरू किया जाता है। और यह दूसरा तर्क एक "संदर्भ" या "लक्ष्य" है, और वर्णित मामले में, इस वर्ग का एक उदाहरण होगा। यह ईवेंट हैंडलर के लिए अनुरोध ऑब्जेक्ट तक पहुंच प्रदान करता है, जो कभी-कभी उपयोगी / आवश्यक हो सकता है।

 use Zend\EventManager\EventCollection, Zend\EventManager\EventManager; class Example { protected $events; public function setEventManager(EventCollection $events) { $this->events = $events; } public function events() { if (!$this->events) { $this->setEventManager(new EventManager( array(__CLASS__, get_called_class()) ); } return $this->events; } public function do($foo, $baz) { $params = compact('foo', 'baz'); $this->events()->trigger(__FUNCTION__, $this, $params); } } $example = new Example(); $example->events()->attach('do', function($e) { $event = $e->getName(); $target = get_class($e->getTarget()); // "Example" $params = $e->getParams(); printf( 'Handled event "%s" on target "%s", with parameters %s', $event, $target, json_encode($params) ); }); $example->do('bar', 'bat'); 

यह उदाहरण अनिवार्य रूप से पहले जैसा ही काम करता है। मुख्य अंतर यह है कि trigger() विधि के लिए दूसरा तर्क, हम हैंडलर (इस घटना को संसाधित करने की प्रक्रिया शुरू करने वाली वस्तु trigger() के संदर्भ को पास करते हैं, और हैंडलर इसे $e->getTarget() विधि के माध्यम से प्राप्त करता है - और इसके साथ कुछ भी कर सकता है (कारण के भीतर) :))।

आपके 2 प्रश्न हो सकते हैं:

• EventCollection क्या है?
• और हम किस EventManager तर्क देते हैं EventManager कंस्ट्रक्टर?

इसका जवाब आगे है।

EventCollection बनाम EventManager

उन सिद्धांतों में से एक जो ZF2 का पालन करने की कोशिश कर रहा है, वह है Lisk प्रतिस्थापन सिद्धांत । इस सिद्धांत की व्याख्या निम्नानुसार हो सकती है: किसी भी वर्ग के लिए जिसे भविष्य में किसी अन्य वर्ग द्वारा पुनर्परिभाषित करने की आवश्यकता हो सकती है, "आधार" इंटरफ़ेस को परिभाषित किया जाना चाहिए। और यह डेवलपर्स को इस इंटरफ़ेस के तरीकों को परिभाषित करके एक वर्ग के एक अलग कार्यान्वयन का उपयोग करने की अनुमति देता है।

इसलिए, EventCollection इंटरफ़ेस विकसित किया गया था, जो श्रोताओं को घटनाओं को EventCollection करने और इन घटनाओं को शुरू करने में सक्षम ऑब्जेक्ट का वर्णन करता है। EventManager एक मानक कार्यान्वयन है जो ZF2 में जाएगा।

StaticEventManager

EventManager कार्यान्वयन प्रदान करता है कि एक पहलू StaticEventCollection के साथ बातचीत करने की क्षमता है। यह वर्ग आपको हैंडलर को न केवल नामित घटनाओं में संलग्न करने की अनुमति देता है, बल्कि एक विशिष्ट संदर्भ या लक्ष्य द्वारा ट्रिगर की गई घटनाओं के लिए भी। EventManager , जब घटनाओं को संसाधित करता है, तो StaticEventCollection ऑब्जेक्ट से ईवेंट हैंडलर (वर्तमान संदर्भ में सब्सक्राइब्ड) भी लेता है और उन्हें निष्पादित करता है।

यह कैसे काम करता है?

 use Zend\EventManager\StaticEventManager; $events = StaticEventManager::getInstance(); $events->attach('Example', 'do', function($e) { $event = $e->getName(); $target = get_class($e->getTarget()); // "Example" $params = $e->getParams(); printf( 'Handled event "%s" on target "%s", with parameters %s', $event, $target, json_encode($params) ); }); 

यह उदाहरण पिछले एक के समान है। अंतर केवल इतना है कि attach() पद्धति का पहला तर्क, हम संदर्भ को पास करते हैं - 'उदाहरण', जिससे हम अपने हैंडलर को जोड़ना चाहते हैं। दूसरे शब्दों में, 'डू' ईवेंट को संसाधित करते समय, यदि यह ईवेंट 'उदाहरण' के संदर्भ में ट्रिगर होता है, तो हम अपने हैंडलर को कॉल करते हैं।

यह बिल्कुल वही है जहां EventManager कंस्ट्रक्टर EventManager एक भूमिका निभाते हैं। कंस्ट्रक्टर आपको संदर्भों के नाम (ओं) को परिभाषित करते हुए एक स्ट्रिंग, या स्ट्रिंग्स के एक सरणी को पास करने की अनुमति देता है, जिसके लिए आप StaticEventManager से इवेंट हैंडलर लेना चाहते हैं। यदि संदर्भों की एक सरणी पारित हो जाती है, तो इन संदर्भों से सभी घटना संचालकों को निष्पादित किया जाएगा। इवेंट EventManager से सीधे जुड़े हुए इवेंट हैंडलर को EventManager में परिभाषित हैंडलर से पहले निष्पादित किया जाएगा।

पिछले 2 उदाहरणों से उदाहरण वर्ग और स्थिर घटना हैंडलर की परिभाषा को मिलाएं, और निम्नलिखित जोड़ें:

 $example = new Example(); $example->do('bar', 'bat'); 

उत्पादन में हम प्राप्त:

  संभाला घटना "लक्ष्य" पर "उदाहरण", मापदंडों {"फू": "बार", "बाज": "बल्ले"} के साथ 

अब उदाहरण वर्ग का विस्तार करते हैं:

 class SubExample extends Example { } 

EventManager कंस्ट्रक्टर के लिए हम किन मापदंडों पर ध्यान देते हैं - यह __CLASS__ और get_called_class() की एक सरणी है। इसका मतलब है कि जब आप SubExample वर्ग के do() विधि को कॉल करते do() , तो हमारा ईवेंट हैंडलर भी निष्पादित होगा। यदि हमने कंस्ट्रक्टर में केवल 'SubExample' निर्दिष्ट किया है, तो हमारा हैंडलर केवल SubExample::do() साथ निष्पादित करेगा, लेकिन Example::do() साथ नहीं Example::do() ।

संदर्भ या लक्ष्य के रूप में उपयोग किए जाने वाले नामों में वर्ग के नाम नहीं होते हैं; आप मनमाने नामों का उपयोग कर सकते हैं। उदाहरण के लिए, यदि आपके पास कैशिंग या लॉगिंग के लिए जिम्मेदार वर्गों का एक सेट है, तो आप संदर्भों को "लॉग" और "कैश" के रूप में नाम दे सकते हैं, और इन नामों का उपयोग कर सकते हैं, वर्ग के नाम नहीं।

यदि आप नहीं चाहते कि इवेंट मैनेजर स्थैतिक घटनाओं को संभाल ले, तो आप null पैरामीटर को setStaticConnections() पास कर सकते हैं:

 $events->setStaticConnections(null); 

स्थैतिक घटनाओं के प्रसंस्करण को फिर से जोड़ने के लिए:

 $events->setStaticConnections(StaticEventManager::getInstance()); 

श्रोता तड़पता है

आपको कई घटनाओं को संभालने के लिए एक संपूर्ण वर्ग पर हस्ताक्षर करने की आवश्यकता हो सकती है, और इस "वर्ग हैंडलर" में कुछ घटनाओं को संभालने के तरीकों को परिभाषित करना होगा। ऐसा करने के लिए, आप अपने "क्लास हैंडलर" में HandlerAggregate इंटरफ़ेस लागू कर सकते हैं। यह इंटरफ़ेस 2 तरीकों को attach(EventCollection $events) करता है attach(EventCollection $events) और detach(EventCollection $events) ।

(मैं खुद नहीं समझ पाया कि मैंने क्या अनुवाद किया है, नीचे दिया गया उदाहरण अधिक स्पष्ट है)।

 use Zend\EventManager\Event, Zend\EventManager\EventCollection, Zend\EventManager\HandlerAggregate, Zend\Log\Logger; class LogEvents implements HandlerAggregate { protected $handlers = array(); protected $log; public function __construct(Logger $log) { $this->log = $log; } public function attach(EventCollection $events) { $this->handlers[] = $events->attach('do', array($this, 'log')); $this->handlers[] = $events->attach('doSomethingElse', array($this, 'log')); } public function detach(EventCollection $events) { foreach ($this->handlers as $key => $handler) { $events->detach($handler); unset($this->handlers[$key]; } $this->handlers = array(); } public function log(Event $e) { $event = $e->getName(); $params = $e->getParams(); $log->info(sprintf('%s: %s', $event, json_encode($params))); } } 

ऐसे हैंडलर को इवेंट मैनेजर में जोड़ने के लिए, हम उपयोग करते हैं:

 $doLog = new LogEvents($logger); $events->attachAggregate($doLog); 

और हमारे हैंडलर ( LogEvents ) को संभालने वाली किसी भी घटना को संबंधित वर्ग विधि द्वारा संसाधित किया जाएगा। यह आपको एक स्थान (स्टेटफुल हैंडलर) में "जटिल" ईवेंट हैंडलर को परिभाषित करने की अनुमति देता है।

detach() पद्धति पर ध्यान दें। attach() तरह, यह एक EventManager ऑब्जेक्ट को एक तर्क के रूप में लेता है और सभी हैंडलर (हैंडलर के इस एरे से - $this->handlers[] ) को इवेंट मैनेजर से लेता है। यह संभव है क्योंकि EventManager::attach() हैंडलर का प्रतिनिधित्व करने वाली एक वस्तु देता है - जिसे हम पहले LogEvents::attach() विधि में 'संलग्न' करते LogEvents::attach() ।

हैंडलर परिणाम

आपको ईवेंट हैंडलर निष्पादित करने का परिणाम प्राप्त करने की आवश्यकता हो सकती है। यह ध्यान में रखना होगा कि कई हैंडलर को एक ईवेंट के लिए सब्सक्राइब किया जा सकता है। और प्रत्येक हैंडलर के परिणाम को अन्य हैंडलर के परिणामों के साथ संघर्ष नहीं करना चाहिए।

EventManager एक ResponseCollection ऑब्जेक्ट देता है। यह वर्ग SplStack वर्ग से विरासत में SplStack , और आपको सभी हैंडलर के परिणामों तक पहुंच प्रदान करता है (अंतिम हैंडलर का परिणाम परिणाम स्टैक की शुरुआत में होगा)।

SplStack , SplStack विधियों के अतिरिक्त, अतिरिक्त तरीके हैं:

• first() - पहले हैंडलर का परिणाम
• last() - अंतिम हैंडलर का परिणाम
• contains($value) - परिणाम स्टैक में परिणाम के लिए जांच, true / false देता true ।

एक नियम के रूप में, जब एक घटना के प्रसंस्करण की शुरुआत करते हैं, तो आपको हैंडलर के काम के परिणाम पर बहुत निर्भर नहीं होना चाहिए। इसके अलावा, जब किसी घटना को ट्रिगर किया जाता है, तो आप हमेशा यह सुनिश्चित नहीं कर सकते हैं कि कौन से इवेंट हैंडलर्स को इस ईवेंट को सब्सक्राइब किया जाएगा (शायद कोई हैंडलर नहीं होगा और आपको कोई परिणाम नहीं मिलेगा)। हालांकि, आपके पास हैंडलर के निष्पादन को बाधित करने का अवसर है यदि आवश्यक परिणाम पहले से ही किसी हैंडलर में प्राप्त किया गया है।

व्यवधान घटना प्रसंस्करण

यदि संचालकों में से एक को परिणाम प्राप्त होता है, जो कि घटना के आरंभकर्ता को अपेक्षित है; या हैंडलर अचानक फैसला करता है कि कुछ गलत हो रहा है; या किसी एक हैंडलर, किसी कारण से, यह तय करता है कि बाद के हैंडलर को निष्पादित करना आवश्यक नहीं है - आपके पास इवेंट हैंडलर के 'स्टैक' के निष्पादन को बाधित करने के लिए एक तंत्र है।

एक उदाहरण जहाँ इसकी आवश्यकता हो सकती है, EventManager के आधार पर निर्मित कैशिंग तंत्र है। अपनी पद्धति की शुरुआत में, आप "कैश में खोज डेटा" घटना को ट्रिगर करते हैं, और यदि हैंडलर में से एक कैश में इसके लिए ज़िम्मेदार डेटा पाता है, तो बाकी हैंडलर बाधित होते हैं और आप कैश से प्राप्त डेटा वापस कर देते हैं। यदि यह नहीं मिलता है, तो आप डेटा बनाते हैं और "कैश टू राइट" ईवेंट को फायर करते हैं

EventManager इसे लागू करने के दो तरीके प्रदान करता है। पहला तरीका विशेष triggerUntil() विधि का उपयोग करना है, जो प्रत्येक निष्पादित हैंडलर के परिणाम की जांच करता है, और यदि परिणाम कुछ आवश्यकताओं को पूरा करता है, तो बाद के हैंडलर का निष्पादन बाधित होता है।

एक उदाहरण:

 public function someExpensiveCall($criteria1, $criteria2) { $params = compact('criteria1', 'criteria2'); $results = $this->events()->triggerUntil(__FUNCTION__, $this, $params, function ($r) { return ($r instanceof SomeResultClass); }); if ($results->stopped()) { return $results->last(); } // ... do some work ... } 

triggerUntil() पद्धति की दलीलें trigger() विधि के तर्कों के समान हैं, अंत में एक अतिरिक्त तर्क के अपवाद के साथ - कॉलबैक फ़ंक्शन, जो प्रत्येक हैंडलर के परिणाम की जांच करने के लिए ज़िम्मेदार है, और यदि वह true , तो बाद के हैंडलर का निष्पादन बाधित होता है।

इस पद्धति के बाद, हम जानते हैं कि घटना के प्रसंस्करण में बाधा डालने का संभावित कारण यह है कि अंतिम निष्पादित हैंडलर का परिणाम हमारे मानदंडों को संतुष्ट करता है।

ईवेंट प्रोसेसिंग को बाधित करने का एक और तरीका है हैंडलर के शरीर में stopPropagation(true) विधि का उपयोग करना। घटना प्रबंधक के बाद के संचालकों के निष्पादन को रोकने के लिए क्या कारण होगा।

 $events->attach('do', function ($e) { $e->stopPropagation(); return new SomeResultClass(); }); 

इस दृष्टिकोण के साथ, आप अब यह सुनिश्चित नहीं कर सकते हैं कि हमारे मापदंड को हैंडलर के अंतिम परिणाम के पत्राचार के कारण किसी घटना के प्रसंस्करण को बाधित किया गया था।

हैंडलर निष्पादन आदेश

आप संचालकों के निष्पादन आदेश को निर्दिष्ट करना चाह सकते हैं। उदाहरण के लिए, आप चाहते हैं कि हैंडलर जो लॉग को लिखने के लिए निष्पादित करने की गारंटी देता है, इस तथ्य के बावजूद कि अन्य हैंडलर किसी भी समय इस घटना के प्रसंस्करण को बाधित कर सकते हैं। या कैशिंग लागू करते समय: कैश में दिखने वाला एक हैंडलर दूसरों की तुलना में पहले निष्पादित किया गया था; और प्रोसेसर जो कैश को लिखता है, इसके विपरीत, बाद में निष्पादित किया जाता है।

EventManager::attach() और StaticEventManager::attach() में एक वैकल्पिक priority तर्क है (डिफ़ॉल्ट रूप से यह 1 है), जिसके साथ आप संचालकों की निष्पादन प्राथमिकता को नियंत्रित कर सकते हैं। उच्च प्राथमिकता वाले हैंडलर को कम प्राथमिकता वाले हैंडलर से पहले निष्पादित किया जाता है।

 $priority = 100; $events->attach('Example', 'do', function($e) { $event = $e->getName(); $target = get_class($e->getTarget()); // "Example" $params = $e->getParams(); printf( 'Handled event "%s" on target "%s", with parameters %s', $event, $target, json_encode($params) ); }, $priority); 

मैथ्यू वीयर ओ'पनी ने प्राथमिकताओं का उपयोग करने की सलाह दी है, यदि बिल्कुल आवश्यक हो और मैं, शायद, उससे सहमत हूं।

यह सब एक साथ लाना: एक साधारण कैशिंग तंत्र

पिछले खंडों में, यह लिखा गया था कि घटनाओं का उपयोग करना और उनका प्रसंस्करण बाधित करना एक आवेदन में कैशिंग तंत्र को लागू करने का एक दिलचस्प तरीका है। चलिए इसका एक पूरा उदाहरण बनाते हैं।

सबसे पहले, हम एक विधि को परिभाषित करते हैं जो कैशिंग का उपयोग कर सकती है।

अपने उदाहरणों में, मैथ्यू वीयर ओ'पनी ने अक्सर घटना के नाम के रूप में __FUNCTION__ का उपयोग किया है, और वह इसे एक अच्छा अभ्यास मानता है, क्योंकि यह घटनाओं को ट्रिगर करने के लिए एक मैक्रो लिखना आसान बनाता है, और आपको विशिष्ट रूप से इन नामों की विशिष्टता निर्धारित करने की अनुमति देता है (विशेषकर जब से संदर्भ आमतौर पर वर्ग द्वारा शुरू किया जाता है) घटना)। और ऐसी घटनाओं को अलग करने के लिए जिन्हें एक विधि के ढांचे के भीतर कहा जाता है, जैसे "do.pre", "do.post", "do.error" आदि पोस्टफिक्स का उपयोग करें।

इसके अलावा, घटना के लिए पारित $params विधि के लिए पारित तर्कों की एक सूची है। इसका कारण यह है कि तर्क को ऑब्जेक्ट में संग्रहीत नहीं किया जा सकता है, और हैंडलर को संदर्भ से आवश्यक पैरामीटर नहीं मिल सकते हैं। लेकिन सवाल यह है कि, कैश में ईवेंट लेखन के लिए परिणामी पैरामीटर का नाम कैसे दिया जाए? उदाहरण __RESULT__ का उपयोग करता है, जो सुविधाजनक है क्योंकि दोनों तरफ डबल अंडरलाइनिंग आमतौर पर सिस्टम द्वारा आरक्षित होती है।

हमारी विधि कुछ इस तरह दिख सकती है:

 public function someExpensiveCall($criteria1, $criteria2) { $params = compact('criteria1', 'criteria1'); $results = $this->events()->triggerUntil(__FUNCTION__ . '.pre', $this, $params, function ($r) { return ($r instanceof SomeResultClass); }); if ($results->stopped()) { return $results->last(); } // ... do some work ... $params['__RESULT__'] = $calculatedResult; $this->events()->trigger(__FUNCTION__ . '.post', $this, $params); return $calculatedResult; } 

अब हम घटना संचालकों को परिभाषित करते हैं जो कैश के साथ काम करते हैं। हमें हैंडलर को 'someExpensiveCall.pre' और 'someExpensiveCall.post' जैसी घटनाओं से जोड़ना होगा। पहले मामले में, यदि डेटा कैश में पाया जाता है, तो हम इसे वापस कर देते हैं। उत्तरार्द्ध में, हम डेटा को कैश में संग्रहीत करते हैं।

हम यह भी मानते हैं कि $cache चर पहले परिभाषित किया गया है, और Zend_Cache ऑब्जेक्ट के समान है। 'SomeExpensiveCall.pre' हैंडलर के लिए, हम यह सुनिश्चित करने के लिए 100 को प्राथमिकता देते हैं कि हैंडलर दूसरों के सामने चलता है, और 'someExpensiveCall.post' के लिए प्राथमिकता 100 है, यदि कैश को लिखने से पहले अन्य हैंडलर डेटा को संशोधित करना चाहते हैं।

 $events->attach('someExpensiveCall.pre', function($e) use ($cache) { $params = $e->getParams(); $key = md5(json_encode($params)); $hit = $cache->load($key); return $hit; }, 100); $events->attach('someExpensiveCall.post', function($e) use ($cache) { $params = $e->getParams(); $result = $params['__RESULT__']; unset($params['__RESULT__']); $key = md5(json_encode($params)); $cache->save($result, $key); }, -100); 

नोट: हम HandlerAggregate को परिभाषित कर सकते हैं, और इसे एक अनाम फ़ंक्शन में आयात करने के बजाय, क्लास की संपत्ति में $cache स्टोर कर सकते हैं।

बेशक, हम ऑब्जेक्ट में ही कैशिंग मैकेनिज्म को लागू कर सकते हैं, न कि किसी इवेंट हैंडलर में डाल सकते हैं। लेकिन यह दृष्टिकोण हमें कैशिंग हैंडलर्स को अन्य घटनाओं से जोड़ने का अवसर देता है (अन्य वर्गों के लिए कैशिंग तंत्र को लागू करना, कैश से प्राप्त करने और कैश को एक स्थान पर संग्रहीत करने का तर्क संग्रहीत करना), या इन घटनाओं में अन्य हैंडलर संलग्न करना (जो लॉगिंग में लगे होंगे, उदाहरण के लिए) या मान्यता)। तथ्य यह है कि यदि आप घटनाओं का उपयोग करके अपनी कक्षा को डिज़ाइन करते हैं, तो आप इसे अधिक लचीला और एक्स्टेंसिबल बनाते हैं।

निष्कर्ष

EventManager Zend फ्रेमवर्क के लिए एक नया और शक्तिशाली अतिरिक्त है। पहले से ही, इसके कुछ पहलुओं की क्षमताओं का विस्तार करने के लिए नए एमवीसी प्रोटोटाइप के साथ इसका उपयोग किया जा रहा है। ZF2 की रिहाई के बाद, घटना मॉडल, मुझे यकीन है, बहुत मांग में होगा।

बेशक, कुछ खुरदरेपन हैं जिन्हें खत्म करने के लिए लोग काम कर रहे हैं।

मैं अपने दम पर जोड़ूंगा - कोई नया मामला नहीं है, यह अच्छा है कि ज़ेंडे में ऐसा कुछ दिखाई देगा - मैं निश्चित रूप से इसका उपयोग करूंगा।
मुझे लगता है कि पाठ को शब्दों के साथ ओवररेट किया गया है और पढ़ना मुश्किल है (आंशिक रूप से लेखों के अनुवाद में थोड़ा अनुभव होने के कारण)।
मेरी आलोचना के खिलाफ कुछ भी नहीं है।

मूल: http://weierophinney.net/matthew