Redmine। प्लगइन्स कैसे लिखें

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

मुझे लगता है कि यह लेख उन लोगों के लिए उपयोगी होगा, जो पहले से ही रूबी की रूपरेखा पर रूबी की बुनियादी बातों से परिचित हैं और रेडमाइन के लिए प्लगइन्स विकसित करना शुरू करना चाहते हैं।

सबसे पहले, यह सभी Redmine प्लगइन्स को दो श्रेणियों में विभाजित करने के लायक है:

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

सब कुछ थोड़ा और अधिक जटिल है जब प्लगइन को अंतर्निहित कार्यक्षमता को बदलने की आवश्यकता होती है!

आइए उस टीम से शुरू करें जो Redmine प्लगइन के लिए फ़ोल्डर संरचना बनाती है। हमारे प्लगइन को लक्ज़री बटन कहा जाता है। Redmine के रूट फोल्डर में जाएं, कमांड को रन करें जो फोल्डर स्ट्रक्चर बनाता है:

$cd /usr/share/srv-redmine/redmine-2.3 $rails generate redmine_plugin LuxuryButtons 

कमांड को निष्पादित करने के बाद, Luxury_buttons फ़ोल्डर को प्लगइन्स फ़ोल्डर में निम्न संरचना के साथ दिखाई देना चाहिए:

Lib फ़ोल्डर में, आपको तुरंत एक फ़ोल्डर जोड़ना चाहिए जो प्लगइन के नाम से मेल खाता है, अर्थात। Luxury_buttons फ़ोल्डर (बाद में पैच फ़ोल्डर के रूप में संदर्भित)। इस फ़ोल्डर में, भविष्य में, विभिन्न रेडमाइन विधियों की पैच फाइलें होंगी।

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

जब एक प्लगइन को किसी दृश्य में कुछ जोड़ने की आवश्यकता होती है।

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



क्यों इतनी बुरी तरह से करने के लिए:

• अपने दृष्टिकोण की प्रासंगिकता की निरंतर निगरानी करने के लिए आप खुद को प्रयासरत करते हैं। यदि इस दृश्य में Redmine के नए संस्करण में कुछ परिवर्तन होता है, तो आप इस कार्यक्षमता को खो देंगे। एक दृश्य की प्रासंगिकता पर नज़र रखना बहुत मुश्किल है।
• यदि एक और प्लगइन दिखाई देता है जो समान दृश्य को फिर से लिखता है, तो या तो आपका दृश्य या किसी अन्य प्लगइन का दृश्य लागू होगा। आवेदन करने के लिए कौन सा दृश्य प्लगइन्स के आदेश पर निर्भर करता है।

इसलिए, वैकल्पिक तरीकों का उपयोग करना बेहतर है।

hooky

एक दृश्य में एक हुक कोड की एक पंक्ति है जो आपको एक दृश्य में अपनी सामग्री को एम्बेड करने की अनुमति देता है। एक हुक खोजने के लिए, आपको बस सभी Redmine फ़ाइलों में "हुक" की खोज करने की आवश्यकता है, या आप इस प्लेट का उपयोग कर सकते हैं।

हुक हुक

हम सभी दृश्य हुक कनेक्शनों को एक फ़ाइल में संग्रहीत करने का प्रयास करते हैं। इस फ़ाइल को इस तरह init.rb में शामिल किया जाना चाहिए:

 require 'luxury_buttons/view_hooks' 

फ़ाइल की सामग्री ही इस प्रकार हो सकती है:

 module LuxuryButtons module LuxuryButtons class Hooks < Redmine::Hook::ViewListener render_on( :view_issues_form_details_top, :partial => 'lu_buttons/view_issues_form_details_top') render_on( :view_layouts_base_html_head, :partial => 'lu_buttons/page_header') render_on( :view_issues_show_description_bottom, :partial => "lu_buttons/button_bar" ) render_on( :view_issues_history_journal_bottom, :partial => "lu_buttons/journal_detail") end end end 

पहले मॉड्यूल का नाम प्लगइन के नाम से मेल खाना चाहिए, दूसरा - पैच फ़ोल्डर के नाम के साथ।

क्लास के अंदर ऐसे फंक्शन्स होते हैं, जिनमें यह दिखाया जाता है कि किस हुक को रेंडर करना है।

यदि दो प्लगइन्स एक ही हुक का उपयोग करेंगे, तो पहले और दूसरे दोनों प्लगइन्स की सामग्री दृश्य में दिखाई देगी। यानी हुक एक दूसरे को फिर से लिखना नहीं है।

हुक के साथ दो समस्याएं हैं:

• एक हुक नहीं हो सकता है।
• कभी-कभी आपको दृश्य से कुछ हटाने की आवश्यकता होती है, और हुक आपको केवल जोड़ने की अनुमति देता है।

जिस तरह से हमने इन समस्याओं को हल करने के लिए पाया है वह पृष्ठ पर सामग्री को संशोधित करने के लिए jQuery का उपयोग करना है जब दृश्य पहले ही प्रदान किया गया है।

इसके लिए, सबसे आसान तरीका "view_layouts_base_html_head" हुक का उपयोग करना है, यह आपको पेज हेडर में सामग्री डालने की अनुमति देता है। हमें कुछ DOM तत्वों को काटने या जोड़ने के तर्क के साथ js फ़ाइल को जोड़ने के लिए एक लिंक सम्मिलित करने की आवश्यकता है। ताकि यह js-file उन पृष्ठों पर लोड न हो, जिन पर इसकी आवश्यकता नहीं है, इसके लोड को सशर्त अभिव्यक्ति में लोड करना बेहतर है। यानी एक्शन और कंट्रोलर द्वारा फाइल डाउनलोड को काट दिया गया। उदाहरण के लिए:

  <% if controller_name == 'issues' && action_name == 'update' %> <%= javascript_include_tag :luxury_buttons_common, :plugin => :luxury_buttons %> <% end %> 

प्लगइन की संपत्ति / जावास्क्रिप्ट फ़ोल्डर में फ़ाइल "Luxury_buttons_common.js" होनी चाहिए:

 jQuery(document).ready(function(){ //       }); 

कभी-कभी, यह js फ़ाइल कनेक्शन स्ट्रिंग को "view_layouts_base_html_head" हुक के माध्यम से एम्बेड करने के लिए अधिक सक्षम है, लेकिन एक विशिष्ट हुक के माध्यम से जो सीमित संख्या में पृष्ठों पर सामग्री की आवश्यकता होती है। उदाहरण के लिए, यदि हमें कार्य पृष्ठ पर कुछ जोड़ना या काटना है, तो हम "view_issues_form_details_bottom" हुक का उपयोग कर सकते हैं।

इस मामले में, ताकि फ़ाइल दस्तावेज़ निकाय से कनेक्ट न हो, लेकिन शीर्ष लेख के लिए, आपको निर्माण का उपयोग करने की आवश्यकता है:

 <% content_for :header_tags do %> <%= javascript_include_tag :luxury_buttons_common, :plugin => :luxury_buttons %> <% end %> 

सच है, प्लगइन्स में "content_for" विधि के साथ, संस्करण से संस्करण तक कठिनाइयां उत्पन्न होती हैं ।

मॉडल, नियंत्रक और सहायकों के तरीकों को कैसे बदलें।

बदलते हुए (पैचिंग) तरीके कई मायनों में बदलते विचारों के समान हैं और समान समस्याएं लाते हैं।

नियंत्रक और मॉडल में हुक

नियंत्रक और मॉडल में भी हुक हैं। वे अलग तरह से जुड़ते हैं। Init.rb में एक रेखा होनी चाहिए जो एक विशिष्ट हुक को जोड़ती है। उदाहरण के लिए, एक हुक जिसे नए कार्य को सहेजने से पहले कहा जाता है:

 require 'luxury_buttons/controller_issues_new_before_save_hook' 

पैच निर्देशिका में फ़ाइल "कंट्रोलर_इंसू_न्यू_बेअर_सैव_हूक। आरबी" होनी चाहिए, उदाहरण के लिए, निम्नलिखित सामग्री के साथ:

 module LuxuryButtons class ControllerIssuesNewBeforeSaveHook < Redmine::Hook::ViewListener def controller_issues_new_before_save(context={}) if context[:params] && context[:params][:issue] if (not context[:params][:issue][:assigned_to_id].nil?) and context[:params][:issue][:assigned_to_id].to_s=='' context[:issue].assigned_to_id = context[:issue].author_id if context[:issue].new_record? and Setting.plugin_luxury_buttons['assign_to_author'] end end '' end end end 

मॉड्यूल का नाम प्लगइन के नाम, फ़ाइल के नाम के साथ वर्ग के नाम से मेल खाना चाहिए।

इस मामले में, हमें लेखक को एक नया कार्य सौंपने की संभावना का एहसास होता है।

पैच विधि

जैसा कि विचारों में, रेडमाइन में आवश्यक हुक हमेशा नहीं होते हैं। और फिर आपको मॉडल, सहायक या नियंत्रक के तरीकों को पैच करने की आवश्यकता है।

सबसे पहले, आपको init.rb में पैच फ़ाइल को शामिल करना होगा। उदाहरण के लिए, हमें समस्या मॉडल की read_only_attribute_names विधि को पैच करना होगा।

 Rails.application.config.to_prepare do Issue.send(:include, LuxuryButtons::IssuePatch) end 

पैच फ़ोल्डर में फ़ाइल "issue_patch.rb" होनी चाहिए, लगभग निम्न सामग्री:

 module LuxuryButtons module IssuePatch def self.included(base) base.extend(ClassMethods) base.send(:include, InstanceMethods) base.class_eval do alias_method_chain :read_only_attribute_names, :luxury_buttons end end module ClassMethods end module InstanceMethods def read_only_attribute_names_with_luxury_buttons(user) attribute = read_only_attribute_names_without_luxury_buttons(user) if Setting.plugin_luxury_buttons['hidden_fields_into_new_issue_form'] && new_record? hidden_fields = Setting.plugin_luxury_buttons['hidden_fields_into_new_issue_form'] attribute += hidden_fields attribute end attribute end end end end 

डिज़ाइन

 alias_method_chain :read_only_attribute_names, :luxury_buttons 

हम दो read_only_attribute_names_with_l गणित_buttons पढ़ते हैं और read_only_attribute_names_without_l गणित_buttons विधियाँ पढ़ते हैं।

पहला तरीका अब मानक read_only_attribute_names मॉडल विधि के बजाय कहा जाएगा, दूसरा तरीका standard read_only_attribute_names विधि के लिए एक उपनाम है।

दो विधियों को मिलाकर, आप मानक Redmine विधि को पैच कर सकते हैं। हमारे उदाहरण में, हम पहले मानक Redmine विधि कहते हैं, जो मानों की एक सरणी लौटाता है, और फिर, इस सरणी में मान जोड़ें।

यदि नए संस्करण में मानक Redmine विधि में कुछ परिवर्तन होता है, तो संभावना है कि हमारा पैच सही ढंग से काम करेगा, अगर हम बस मानक Redmine विधि को फिर से लिखते हैं और इसमें अपना तर्क जोड़ते हैं, तो यह बहुत अधिक है।

महत्वपूर्ण! Redmine के उपयोगकर्ता मॉडल को पैच करने के साथ कुछ समस्याएं हैं। सही पैचिंग के लिए, आपको निम्नलिखित फ़ाइलों को स्पष्ट रूप से शामिल करना होगा:

 require_dependency 'project' require_dependency 'principal' require_dependency 'user' 

लेख में वह सब कुछ नहीं है जो मैं Redmine के लिए प्लगइन्स लिखने के बारे में कहना चाहूंगा। मैंने मूल पद्धतियों और नुकसान को इकट्ठा करने की कोशिश की। आशा है कि लेख उपयोगी होगा।