Zend फ्रेमवर्क पर एक ब्लॉग विकसित करने का एक उदाहरण 2. भाग 3. उपयोगकर्ताओं के साथ काम करना

यह Zend फ्रेमवर्क का उपयोग करते हुए एक सरल अनुप्रयोग के विकास के लिए समर्पित तीसरा (अंतिम?) भाग है। पहले भाग में मैंने ZendSkeletonApplication की संरचना की जांच की, दूसरे भाग में मैंने एक साधारण मॉड्यूल के विकास का एक उदाहरण दिया। यह हिस्सा उपयोगकर्ताओं के साथ काम करने के लिए समर्पित है, और मैं इस परियोजना के लिए ट्विग टेम्पलेट इंजन भी पेंच करूंगा।

उपयोगकर्ताओं के साथ काम करें

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

Zf के कॉमन्स

ज़ेंड फ्रेमवर्क के लिए बहुत सारे मॉड्यूल लिखे गए हैं जो मानक कार्यों को हल करते हैं; आप उन्हें एक विशेष साइट पर पा सकते हैं: mod.zendframework.com । मानक समस्याओं को हल करने के लिए अपनी खुद की साइकिल विकसित करने के बजाय, मुझे लगता है कि अपने लिए तैयार समाधानों का उपयोग करना / अनुकूल करना अधिक उपयुक्त है (साइकिल विकसित करने के लिए शुरू करने से पहले कम से कम तैयार समाधानों का अध्ययन किया जाना चाहिए)।

कई मॉड्यूल डेवलपर्स के बीच, ZF कॉमन्स टीम बाहर खड़ी है, इस टीम के लोगों ने कई बहुत उपयोगी मॉड्यूल विकसित किए हैं जो हम इस परियोजना में उपयोग करेंगे: github.com/ZF-Commons । उनमें से कुछ पर विचार करें जो हमें इस स्तर पर चाहिए।

ZfcBase

कर्नेल जो अन्य ZF कॉमन्स मॉड्यूल पर निर्भर करता है ( https://github.com/ZF-Commons/ZfcBase )।

ZfcUser

एक मॉड्यूल जो उपयोगकर्ता पंजीकरण / प्राधिकरण तंत्र, उपयोगकर्ता प्रोफ़ाइल और व्यू हेल्पर्स को टेम्प्लेट ( https://github.com/ZF-Commons/ZfcUser ) में उपयोग के लिए लागू करता है।

ZfcUserDoctrineORM

डिफ़ॉल्ट रूप से, ZfcUser मानक डेटाबेस तंत्र के साथ काम करता है, क्योंकि हमारी परियोजना Doctrine ORM का उपयोग करती है, हमें ZfcUserDoctrineORM मॉड्यूल ( https://github.com/ZF-Commons/ZfcserserooctrineORM ) की भी आवश्यकता है।

ZfcTwig

Twig टेम्पलेट इंजन ( https://github.com/ZF-Commons/ZfcTwig ) के साथ एकीकरण के लिए मॉड्यूल।

BjyAuthorize

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

उपयोगकर्ता अधिकृत हो सकता है और अधिकृत नहीं। एक अधिकृत उपयोगकर्ता की एक या एक से अधिक भूमिकाएँ हो सकती हैं। इस संदर्भ में गार्ड एक नियंत्रक / कार्रवाई है जिसके लिए हम विभिन्न भूमिकाओं के लिए एक्सेस अधिकारों को कॉन्फ़िगर करते हैं।

उपयोगकर्ता कॉन्फ़िगरेशन के लिए तैयारी कर रहा है

इससे पहले कि आप उपयोगकर्ता अनुभव को कॉन्फ़िगर करें, आपको उपयोगकर्ता के लिए एक इकाई बनाना होगा और भूमिकाएं जो डॉक्ट्रिन का उपयोग करेंगी। BjyAuthorize मॉड्यूल के साथ शामिल ऐसी संस्थाओं के उदाहरण हैं, उनके आधार पर मैंने MyUser मॉड्यूल बनाया।

मॉड्यूल में कुछ भी मूल नहीं है, आप इसका कोड यहां देख सकते हैं: github.com/romka/zend-blog-example/tree/master/module/MyUser , इसकी संरचना में यह ऊपर दिए गए एप्लिकेशन और MyBlog मॉड्यूल से भिन्न नहीं है: इसमें एक कॉन्फ़िगरेशन और 2 शामिल हैं इकाई।

आपको केवल इसके विन्यास ( https://github.com/romka/zend-blog-example/blob/master/module/MyUser/config/module.config.php ) पर ध्यान देना चाहिए:

return array( 'doctrine' => array( 'driver' => array( 'zfcuser_entity' => array( 'class' =>'Doctrine\ORM\Mapping\Driver\AnnotationDriver', 'paths' => array(__DIR__ . '/../src/MyUser/Entity') ), 'orm_default' => array( 'drivers' => array( 'MyUser\Entity' => 'zfcuser_entity', ) ) ) ), 'zfcuser' => array( // telling ZfcUser to use our own class 'user_entity_class' => 'MyUser\Entity\User', // telling ZfcUserDoctrineORM to skip the entities it defines 'enable_default_entities' => false, ), 'bjyauthorize' => array( // Using the authentication identity provider, which basically reads the roles from the auth service's identity 'identity_provider' => 'BjyAuthorize\Provider\Identity\AuthenticationIdentityProvider', 'role_providers' => array( // using an object repository (entity repository) to load all roles into our ACL 'BjyAuthorize\Provider\Role\ObjectRepositoryProvider' => array( 'object_manager' => 'doctrine.entity_manager.orm_default', 'role_entity_class' => 'MyUser\Entity\Role', ), ), ), ); 

इस कॉन्फ़िगरेशन में, हम अपने स्वयं के साथ zfcuser इकाई को प्रतिस्थापित करते हैं, जो उपयोगकर्ता के साथ काम करने के लिए जिम्मेदार है, और भूमिकाओं के साथ काम करने के लिए जिम्मेदार BjyAuthorize मॉड्यूल को इंगित करता है।

MyUser मॉड्यूल को application.config.php में जोड़ा जाना चाहिए और फिर कंसोल में कमांड निष्पादित करें:

 ./vendor/bin/doctrine-module orm:schema-tool:update --force ./vendor/bin/doctrine-module orm:validate-schema 

पहला डेटाबेस में MyUser मॉड्यूल द्वारा बनाई गई संस्थाओं के लिए तालिकाओं को बनाने के लिए है, दूसरा यह सुनिश्चित करना है कि पहले कमांड ने सही तरीके से काम किया है।

अंतिम प्रारंभिक कार्रवाई अनुरोध को निष्पादित करने के लिए होगी, जो उचित भूमिका बनाएगी:

 INSERT INTO `role` (`id`, `parent_id`, `roleId`) VALUES (1, NULL, 'guest'), (2, 1, 'user'), (3, 2, 'moderator'), (4, 3, 'administrator'); 

ZfcUser, ZfcUserDoctrineORM और BjyAuthorize को कॉन्फ़िगर करना

सबसे पहले, आपको संगीतकार की सेटिंग में नए मॉड्यूल दर्ज करने की आवश्यकता है:

 "zf-commons/zfc-base": "v0.1.2", "zf-commons/zfc-user": "dev-master", "zf-commons/zfc-user-doctrine-orm": "dev-master", "doctrine/doctrine-orm-module": "0.7.*", "bjyoungblood/bjy-authorize": "1.4.*" 

अद्यतन php कंपोज़र। थापर अद्यतन निष्पादित करें और नए मॉड्यूल को application.config.php में जोड़ें:

 'ZfcBase', 'ZfcUser', 'ZfcUserDoctrineORM', 'BjyAuthorize', 

चेतावनी! इनमें से कुछ मॉड्यूल की सेटिंग स्व-लिखित मॉड्यूल की सेटिंग्स द्वारा ओवरराइड की जाएगी, इसलिए इन मॉड्यूल को सूची के शीर्ष पर जोड़ा जाना चाहिए।

अब आपको zfcuser.global.php.dist फ़ाइल को वेंडर / zf-commons / zfc-user / config निर्देशिका से कॉपी करने के लिए config / autoload को कॉपी करना होगा और इसे zfcuser.global.php पर नाम बदलना होगा। इस कॉन्फ़िगरेशन फ़ाइल में, आपको मान सेट करने की आवश्यकता है:

 'table_name' => 'users', 

चूंकि उपयोगकर्ता तालिका उपयोगकर्ताओं के साथ काम करने के लिए डिफ़ॉल्ट रूप से उपयोग की जाती है।

उसी निर्देशिका में, आपको कॉन्फ़िगरेशन फ़ाइल bjyauth.global.php बनाने की आवश्यकता है जिसमें विभिन्न भूमिकाओं के लिए एक्सेस राइट्स सेटिंग्स हैं। आप इस फ़ाइल का पूरा संस्करण github github.com/romka/zend-blog-example/blob/master/config/autoload/bjyauth.global.php पर देख सकते हैं, इसका दिलचस्प हिस्सा, जो विभिन्न नियंत्रकों तक पहुँच अधिकारों के वितरण के लिए जिम्मेदार है। नीचे दिया गया है:

 'guards' => array( /* If this guard is specified here (ie it is enabled), it will block * access to all controllers and actions unless they are specified here. * You may omit the 'action' index to allow access to the entire controller */ 'BjyAuthorize\Guard\Controller' => array( array( 'controller' => 'zfcuser', 'action' => array('index', 'login', 'authenticate', 'register'), 'roles' => array('guest'), ), array( 'controller' => 'zfcuser', 'action' => array('logout'), 'roles' => array('user'), ), array('controller' => 'Application\Controller\Index', 'roles' => array()), array( 'controller' => 'MyBlog\Controller\BlogPost', 'action' => array('index', 'view'), 'roles' => array('guest', 'user'), ), array( 'controller' => 'MyBlog\Controller\BlogPost', 'action' => array('add', 'edit', 'delete'), 'roles' => array('administrator'), ), ), ), 

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

अब हम लिंक / उपयोगकर्ता / रजिस्टर का उपयोग करके पंजीकरण कर सकते हैं और SQL क्वेरी के साथ हमारे उपयोगकर्ता को व्यवस्थापक विशेषाधिकार प्रदान कर सकते हैं:

 INSERT INTO user_role_linker (user_id, role_id) VALUES (1, 4); 

(हां, ZfcUser मॉड्यूल उपयोगकर्ता भूमिकाओं के प्रबंधन के लिए एक व्यवस्थापक पैनल प्रदान नहीं करता है)।

डेवलपर टूलबार में पृष्ठ के निचले भाग में प्राधिकरण के बाद, वर्तमान उपयोगकर्ता की भूमिका के बारे में जानकारी प्रदर्शित की जाएगी और क्रिया / जोड़ / हटाएं अब 403 त्रुटि वापस नहीं करेंगे।

परियोजना की वर्तमान स्थिति का एक ध्यान देने योग्य दोष यह है कि ब्लॉग पोस्ट को संपादित करने / हटाने के लिंक सभी उपयोगकर्ताओं को दिखाए जाते हैं, इस तथ्य के बावजूद कि गुमनाम लोगों के पास इस तरह की कार्रवाई करने के अधिकार नहीं हैं। BjyAuthorize मॉड्यूल में IsAllowed View प्लगइन है, जो समस्या को ठीक करना आसान बनाता है। टेम्प्लेट में निम्नलिखित पंक्तियाँ जोड़ें:

 if ($this->isAllowed('controller/MyBlog\Controller\BlogPost:edit')) { // some code here } 

जहां संबंधित नियंत्रक / कार्रवाई तक पहुंच अधिकारों की उपलब्धता की जांच करना आवश्यक है, यह उन टेम्पलेट लिंक में प्रदर्शित नहीं होने देगा जो वर्तमान उपयोगकर्ता के लिए सुलभ नहीं हैं।

इसी तरह से, प्रवेश के लिए अनुक्रमणिका () कार्रवाई में, ब्लॉग पोस्टों की एक पूरी सूची प्रदर्शित की जा सकती है, न कि केवल प्रकाशित लेख:

 if ($this->isAllowed('controller/MyBlog\Controller\BlogPost:edit')) { $posts = $objectManager ->getRepository('\MyBlog\Entity\BlogPost') ->findBy(array(), array('created' => 'DESC')); } else { $posts = $objectManager ->getRepository('\MyBlog\Entity\BlogPost') ->findBy(array('state' => 1), array('created' => 'DESC')); } 

प्रोजेक्ट अपने वर्तमान रूप में Github रिपॉजिटरी में कॉन्फ़िगर किए गए_यूज़र टैग: github.com/romka/zend-blog-example/tree/configured_user के साथ उपलब्ध है।

फ़ैशन

अपने अभ्यास में, मैंने कई अलग-अलग टेम्पलेट इंजनों का उपयोग किया और मैं पायथन जिनजा 2 को उन लोगों के लिए सबसे सुविधाजनक मानता हूं जिनके साथ मुझे काम करना था। ट्विग पीएचपी टेंपलेटिंग इंजन मूल रूप से जिंजा 2 के लेखक अर्मिन रोनचेर द्वारा विकसित किया गया था, और फिर सिम्फनी फ्रेमवर्क के विकासकर्ता फैबिन पोटेंशियर ने उनका समर्थन और विकास किया।

Twig और Zend फ्रेमवर्क में निर्मित टेम्प्लेट इंजन के बीच एक महत्वपूर्ण अंतर यह है कि आप Twig टेम्प्लेट में PHP कोड का उपयोग नहीं कर सकते हैं, इसके बजाय, लूप, सशर्त विवरण आदि को लागू करने के लिए टेम्प्लेट इंजन का अपना सिंटैक्स है। Twig टेम्पलेट्स को PHP कोड में संकलित किया जाता है और परिणामस्वरूप PHP कोड में प्रदर्शन नहीं खोते हैं।

टेम्प्लेट इनहेरिटेंस, मैक्रोज़, फ़िल्टर सिस्टम आदि जैसी विशेषताओं के लिए धन्यवाद। टहनी टेम्पलेट कॉम्पैक्ट और पढ़ने में आसान हैं।

स्थापना

टहनी को स्थापित करने के लिए, मानक चरणों का पालन करना पर्याप्त है: कंपोजर के लिए एक पंक्ति जोड़ें। आगजनी , php कंपोज़र को अद्यतन करें। थापर अपडेट करें और मॉड्यूल को application.config.php में जोड़ें।

अब, मॉड्यूल जो इस टेम्पलेट इंजन का उपयोग करेंगे, view_manager सेक्शन में कॉन्फ़िगरेशन फ़ाइल में निम्न पंक्तियाँ जोड़ें:

 'strategies' => array( 'ZfcTwigViewStrategy', ), 

और टहनी का उपयोग करने के लिए तैयार हो जाएगा। इसके अलावा, दोनों टेम्पलेट इंजन (टहनी और डिफ़ॉल्ट) को एक साथ उपयोग किया जा सकता है, अर्थात, टेम्पलेट का हिस्सा एक टेम्पलेट पर लागू किया जा सकता है, दूसरे पर भाग।

टहनी टेम्प्लेट

ऊपर उल्लिखित टेम्प्लेट इनहेरिटेंस का मतलब यह है कि हम एक डिफ़ॉल्ट लेआउट बना सकते हैं। लगभग निम्नलिखित सामग्री के साथ टेम्पलेट:

 <html> <head> <title> {% block title %}Default title{% endblock title %} </title> {% block script %} <script type="text/javascript" src="/js/jquery.min.js"></script> {% endblock script %} </head> <body> <div class="content"> {% block content %}{{ content|raw }}{% endblock content %} </div> <div class="sidebar"> {% block sidebar %}{{ sidebar|raw }}{% endblock sidebar %} </div> </body> </html> 

इसके बाद, हम एक ऐसा टेम्प्लेट बना सकते हैं, जो कि लेआउट से निकलेगा। इसमें, हम केवल टेम्प्लेट के परिवर्तित हिस्सों को फिर से परिभाषित करेंगे:

 {% extends 'layout/layout.twig' %} {% block script %} {{ parent() }} <script type="text/javascript" src="some-additional-file.js"></script> {% endblock script %} {% block content %} Custom content {% endblock content %} 

डिफ़ॉल्ट रूप से, उत्तराधिकारी टेम्पलेट में ओवरराइड किया गया ब्लॉक अभिभावक टेम्पलेट में ब्लॉक को बदल देता है, लेकिन स्क्रिप्ट ब्लॉक में {{पेरेंट ()}} पर ध्यान देता है, इसके उपयोग का अर्थ है कि पेरेंट टेम्पलेट से उसी ब्लॉक की सामग्री को इस ब्लॉक में लोड किया जाएगा।

अब नए टेम्प्लेट इंजन का उपयोग करके टेम्प्लेट को फिर से लिखते हैं। मैंने Zend Skeleton Application से मानक Layout.phtml टेम्पलेट के साथ शुरुआत की, आप इसे MyBlog मॉड्यूल में दृश्य / लेआउट निर्देशिका github.com/romka/zend-blog-example/blob/master/module/MyBlog/view/layout/layout से पा सकते हैं। टहनी ।

इस बात पर ध्यान दें कि यह कितना अधिक कॉम्पैक्ट हो गया है, उदाहरण के लिए, दृश्य-सहायकों का उपयोग करते हुए, अब इसके बजाय:

 <?php echo $this->url('blog', array('action' => 'edit')); ?> 

आप कॉल कर सकते हैं:

 {{ url('blog', {'action': 'edit'}) }} 

बजाय:

 <?php echo $this->showMessages(); ?> 

सरल:

 {{ showMessages() }} 

मुख्य टेम्पलेट को संसाधित करने के बाद, हम रूपों से निपटेंगे। सबसे पहले, मॉड्यूल की दृश्य निर्देशिका में, मैक्रोज़ उपनिर्देशिका और निम्न सामग्री के साथ form.twig फ़ाइल बनाएँ:

 {% macro input(name, value, type, label, size, messages) %} {% if type != 'hidden' %} <div class="form-element-{{ name }}"> {% endif %} {% if label %} {{ label }}: {% endif %} {% if type == 'textarea' %} <textarea name="{{ name }}" size="{{ size|default(20) }}" {% if messages|length > 0 %}class="error"{% endif %}/>{{ value|e }}</textarea> {% elseif type == 'checkbox' %} <input type="{{ type }}" name="{{ name }}" value="1"{% if value == true %} checked="checked"{% endif %} {% if messages|length > 0 %}class="error"{% endif %}/> {% else %} <input type="{{ type|default('text') }}" name="{{ name }}" value="{{ value|e }}" size="{{ size|default(20) }}" {% if messages|length > 0 %}class="error"{% endif %}/> {% endif %} {% if type != 'hidden' %} </div> {% endif %} {% if messages|length > 0 %} <ul> {% for m in messages %} <li>{{ m }}</li> {% endfor %} </ul> {% endif %} {% endmacro %} 

इस मैक्रो का उपयोग फॉर्म फ़ील्ड प्रदर्शित करने के लिए किया जाएगा। इनपुट पर, यह क्षेत्र के मापदंडों को प्राप्त करता है, आउटपुट पर, यह html मार्कअप लौटाता है।

अब आप मौजूदा add.phtml टेम्प्लेट को हटा सकते हैं और इसे निम्नलिखित सामग्री के साथ एक नए ऐड.टाइग के साथ बदल सकते हैं:

 {% extends 'layout/layout.twig' %} {% import 'macros/forms.twig' as forms %} {% block content %} <h1>{{ title }}</h1> <form method="{{ form.attributes.method }}" action="{{ url('blog', {'action': 'add'}) }}"> {% for element in form %} {{ forms.input(element.attributes.name, element.value, element.attributes.type, element.label, 20, element.messages) }} {% endfor %} </form> {% endblock content %} 

इसी तरह, मैंने बाकी टेम्प्लेट्स को रीडायरेक्ट कर दिया और अब मॉड्यूल को हटा दिया। * .ttml टेम्प्लेट जो अनावश्यक हो गए: github.com/romka/zend-blog-example/tree/master/module/MyBlog/view/my/blog/blog ।

निष्कर्ष

इस पर मैं समाप्त करना चाहूंगा। मैं बहुत सारे महत्वपूर्ण बिंदुओं पर नहीं छू पाया, जैसे लॉगिंग, कैशिंग, डिपेंडेंसी इंजेक्शन, लेखन परीक्षण, आदि, लेकिन ये सभी मुद्दे परिचयात्मक लेख के दायरे से परे हैं। लेकिन मुझे उम्मीद है कि शुरुआती के लिए ज़ेंड फ्रेमवर्क 2 सीखना होगा, यह लेख एक उपयोगी शुरुआती बिंदु होगा।

मैंने इस लेख के सभी 3 भागों को पहले भाग के प्रकाशन से पहले लिखा था और पाठ के पूरा होने के समय मैंने इसे खत्म करने की योजना बनाई थी। टिप्पणियों को पढ़ने के बाद, मैंने एप्लिकेशन को थोड़ा सुधारने का निर्णय लिया:

• GET / POST अनुरोध के प्रकार की जाँच करने के बजाय REST का उपयोग करें,
• कार्यों से पहले हुक करने के लिए कार्यों का हिस्सा स्थानांतरण,
• कार्यों के सिद्धांत को सिद्धांत हुक में स्थानांतरित करें,
• जादू स्थिरांक से छुटकारा पाएं,
• yaml को कॉन्फिगरेशन ट्रांसफर करें,
• DI (?) के साथ कॉल का हिस्सा बदलें।

इन परिवर्तनों को तैयार करने में कुछ समय लगेगा, मुझे उम्मीद है कि लेख का चौथा भाग जल्द ही प्रकाशित होगा।