यहां आप प्लग-इन इंजीनियरिंग के सिद्धांत के साथ पहला लेख पढ़ सकते हैं।

और इस भाग में मैं आपको बताऊंगा कि प्लगइन के निर्माण के दौरान हमें किन समस्याओं का सामना करना पड़ा और हमने उन्हें कैसे हल करने की कोशिश की।

मैं किस बारे में बात करूंगा?

• व्यावहारिक भाग
  
  • बहु यूआई
  • प्लगइन्स में डि
  • कोड जनरेशन
  • कोड संशोधन
• आगे क्या करना है?
  
  • टिप्स
  • पूछे जाने वाले प्रश्न

बहु यूआई

पहली चीज़ जो हमें करने की ज़रूरत थी वह थी एक मल्टी-पेज UI। हमने पहले जटिल फॉर्म को चेकमार्क, इनपुट फ़ील्ड के एक समूह के साथ बनाया। थोड़ी देर बाद, हमने मॉड्यूल की एक सूची का चयन करने की क्षमता को जोड़ने का फैसला किया जिसे उपयोगकर्ता नए मॉड्यूल से जोड़ सकता है। और हम उस एप्लिकेशन मॉड्यूल को भी चुनना चाहते हैं, जिसके लिए हम निर्मित मॉड्यूल को कनेक्ट करने की योजना बनाते हैं।

एक रूप पर इतने सारे नियंत्रण रखना बहुत सुविधाजनक नहीं है, इसलिए उन्होंने तीन अलग-अलग पृष्ठ, तीन अलग-अलग कुकी कटर बनाए। संक्षेप में, जादूगर संवाद।

लेकिन प्लगइन्स में मल्टी-पेज यूआई बनाने के बाद से बहुत दर्दनाक है, मैं कुछ तैयार करना चाहता था। और IDEA के आंतों में, हमने विजार्डडायलॉग नामक एक वर्ग की खोज की।

यह एक नियमित संवाद पर एक आवरण वर्ग है, जो स्वतंत्र रूप से विज़ार्ड में उपयोगकर्ता की प्रगति की निगरानी कर रहा है, और आवश्यक बटन (पिछला, अगला, समाप्त, आदि) दिखा रहा है। एक विशेष WizardModel, विज़ार्डडायलॉग से जुड़ा है, जिसमें अलग-अलग विज़ार्डस्टेप्स जोड़े गए हैं। प्रत्येक विज़ार्डस्टेप एक अलग रूप है।

अपने सरलतम रूप में, संवाद का कार्यान्वयन निम्नानुसार है:

class MyWizardDialog( model: MyWizardModel, private val onFinishButtonClickedListener: (MyWizardModel) -> Unit ): WizardDialog<MyWizardModel>(true, true, model) { override fun onWizardGoalAchieved() { super.onWizardGoalAchieved() onFinishButtonClickedListener.invoke(myModel) } } 

हम WizardDialog वर्ग से इनहेरिट करेंगे , हमारे WizardModel के वर्ग के साथ पैरामीटर करें। इस वर्ग में एक विशेष कॉलबैक ( onWizardGoalAchieve ) है, जो हमें बताता है कि उपयोगकर्ता विज़ार्ड से अंत तक गया और "फिनिश" बटन पर क्लिक किया।
यह ध्यान रखना महत्वपूर्ण है कि इस वर्ग के भीतर से केवल विज़ार्डमॉडल तक पहुंचने का अवसर है। इसका मतलब यह है कि विज़ार्ड के पारित होने के दौरान उपयोगकर्ता द्वारा एकत्र किए जाने वाले सभी डेटा, आपको विज़ार्डमॉडल में जोड़ना होगा।

 class MyWizardModel: WizardModel("Title for my wizard") { init { this.add(MyWizardStep1()) this.add(MyWizardStep2()) this.add(MyWizardStep3()) } } 

मॉडल निम्नानुसार है: हम विज़ार्डमॉडल वर्ग से विरासत में प्राप्त करते हैं और बिल्ट-इन ऐड मेथड का उपयोग करके डायल करने के लिए अलग विजार्डस्टेप्स जोड़ते हैं ।

 class MyWizardStep1: WizardStep<MyWizardModel>() { private lateinit var contentPanel: JPanel override fun prepare(state: WizardNavigationState?): JComponent { return contentPanel } } 

विजार्डस्टेप्स भी सरल हैं: विजार्डस्टेप वर्ग से विरासत में मिला , इसे हमारे मॉडल वर्ग के साथ मानकीकृत करें , और, सबसे महत्वपूर्ण बात, तैयार विधि को ओवरराइड करें, जो आपके भविष्य के रूप के मूल घटक को लौटाता है।

सरल शब्दों में, यह वास्तव में ऐसा दिखता है। लेकिन वास्तविक दुनिया में, सबसे अधिक संभावना है कि आपका रूप कुछ इस तरह का होगा:

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

निष्कर्ष

यदि आपको एक बहु-पृष्ठ UI की आवश्यकता है, तो विज़ार्डडायलॉग का उपयोग करें - यह आसान होगा।

हम अगले विषय पर चलते हैं - प्लग इन में DI।

प्लगइन्स में डि

एक प्लगइन के अंदर निर्भरता इंजेक्शन की आवश्यकता क्यों हो सकती है?
पहला कारण प्लगइन के अंदर वास्तुकला का संगठन है।

ऐसा लगता है, आमतौर पर प्लगइन के अंदर किसी तरह की वास्तुकला का निरीक्षण क्यों किया जाता है? एक प्लग-इन एक उपयोगिता चीज है, एक बार जब मैंने इसे लिखा था, और मैं सब कुछ भूल गया था।
हां, लेकिन नहीं।
जब आपका प्लगइन बढ़ता है, जब आप बहुत सारे कोड लिखते हैं, तो संरचित कोड का सवाल अपने आप उठता है। यहां DI काम आ सकता है।

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

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

इन स्तरों में से प्रत्येक का अपना अमूर्तन है जिसे घटक कहा जाता है। आवश्यक स्तर के घटक को इस स्तर की वस्तु के अनुसार प्रति बनाया जाता है। इसलिए ApplicationComponent को अनुप्रयोग वर्ग के प्रत्येक उदाहरण के लिए एक बार बनाया जाता है, जो Project Instances के लिए ProjectComponent के समान है, और इसी तरह।

DI ढांचे का उपयोग करने के लिए क्या करने की आवश्यकता है?

सबसे पहले, एक वर्ग बनाएं जो आवश्यक इंटरफ़ेस घटकों में से एक को लागू करता है - उदाहरण के लिए, एक वर्ग जो अनुप्रयोगकंप्लेंट , या प्रोजेक्टकंपोनेंट , या मॉड्यूलकंप्लेंट को लागू करता है । उसी समय, हमारे पास उस स्तर की एक वस्तु को इंजेक्ट करने का अवसर है जिसका इंटरफ़ेस हम कार्यान्वित कर रहे हैं। यह, उदाहरण के लिए, ProjectComponent में आप Project वर्ग के ऑब्जेक्ट को इंजेक्ट कर सकते हैं।

 class MyAppComponent( val application: Application, val anotherApplicationComponent: AnotherAppComponent ): ApplicationComponent class MyProjectComponent( val project: Project, val anotherProjectComponent: AnotherProjectComponent, val myAppComponent: MyAppComponent ): ProjectComponent class MyModuleComponent( val module: Module, val anotherModuleComponent: AnotherModuleComponent, val myProjectComponent: MyProjectComponent, val myAppComponent: MyAppComponent ): ModuleComponent 

दूसरे, समान स्तर या उच्चतर के अन्य घटकों को इंजेक्ट करना संभव है। उदाहरण के लिए, ProjectComponent में आप अन्य ProjectComponent या ApplicationComponent को इंजेक्ट कर सकते हैं। यह वह जगह है जहां आप "एलियन" घटकों के उदाहरणों तक पहुंच सकते हैं।

उसी समय, IDEA गारंटी देता है कि संपूर्ण निर्भरता ग्राफ को सही तरीके से इकट्ठा किया जाएगा, सभी ऑब्जेक्ट्स सही क्रम में बनाए जाएंगे और सही ढंग से संशोधित होंगे।

अगली बात यह है कि plugin.xml फ़ाइल में घटक को पंजीकृत करें। जैसे ही आप घटक घटकों में से एक को लागू करते हैं (उदाहरण के लिए, अनुप्रयोगकंपोनेंट ), IDEA तुरंत plugin.xml में अपने घटक को पंजीकृत करने की पेशकश करेगा।

 <idea-plugin> ... <project-components> <component> <interface-class> com.experiment.MyProjectComponent </interface-class> <implementation-class> com.experiments.MyProjectComponentImpl </implementation-class> </component> </project-components> </idea-plugin> 

यह कैसे किया जाता है? एक विशेष <प्रोजेक्ट-घटक> टैग प्रकट होता है ( <एप्लिकेशन-घटक> , <मॉड्यूल-घटक> - स्तर के आधार पर)। इसके अंदर एक टैग है , इसमें दो और टैग हैं: <इंटरफ़ेस-क्लास> , जहां आपके घटक का इंटरफ़ेस नाम इंगित किया गया है, और <कार्यान्वयन-वर्ग> , जहां कार्यान्वयन वर्ग इंगित किया गया है। एक और एक ही वर्ग एक घटक या इसके कार्यान्वयन का एक इंटरफ़ेस हो सकता है, इसलिए आप एकल <कार्यान्वयन-वर्ग> टैग के साथ कर सकते हैं।

अंतिम बात यह है कि घटक को संबंधित वस्तु से प्राप्त किया जाता है, अर्थात, हमें एप्लिकेशन इंस्टेंस से ApplicationComponent मिलता है, ProjectComponent प्रोजेक्ट से मिलता है , आदि।

 val myAppComponent = application.getComponent(MyAppComponent::class.java) val myProjectComponent = project.getComponent(MyProjectComponent::class.java) val myModuleComponent = module.getComponent(MyModuleComponent::class.java) 

निष्कर्ष

1. आईडीईए के अंदर एक डीआई फ्रेमवर्क है - अपने दम पर कुछ भी खींचने की आवश्यकता नहीं है: न तो डैगर और न ही स्प्रिंग। हालांकि, ज़ाहिर है, आप कर सकते हैं।
2. इस DI के साथ, आप तैयार किए गए घटकों तक पहुंच सकते हैं, और यह रस ही है।

तीसरे कार्य - कोड जनरेशन पर चलते हैं।

कोड जनरेशन

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

टेम्पलेट्स

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

 apply plugin: 'com.android.library' <if (isKotlinProject) { apply plugin: 'kotlin-android' apply plugin: 'kotlin-kapt' <if (isModuleWithUI) { apply plugin: 'kotlin-android-extensions' }> }> ... android { ... <if (isMoxyEnabled) { kapt { arguments { arg("moxyReflectorPackage", '<include var="packageName">') } } }> ... } ... dependencies { compileOnly project(':common') compileOnly project(':core-utils') <for (moduleName in enabledModules) { compileOnly project('<include var="moduleName">') }> ... } 

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

 <if (isKotlinProject) { apply plugin: 'kotlin-android' apply plugin: 'kotlin-kapt' <if (isModuleWithUI) { apply plugin: 'kotlin-android-extensions' }> }> 

दूसरी चीज जो हम चाहते हैं, वह इस टेम्पलेट के अंदर एक चर का उपयोग करने की क्षमता है। उदाहरण के लिए, जब हम Moxy के लिए kapt कॉन्फ़िगर करते हैं, तो हम एनोटेशन प्रोसेसर के तर्क के रूप में पैकेज का नाम सम्मिलित करना चाहते हैं।

 kapt { arguments { arg("moxyReflectorPackage", '<include var="packageName">') } } 

एक और चीज जो हमें चाहिए वह है टेम्पलेट के अंदर लूप को संभालने की क्षमता। उस फॉर्म को याद रखें जहां हमने उन मॉड्यूल की सूची का चयन किया है जिन्हें हम नए मॉड्यूल से कनेक्ट करना चाहते हैं? हम एक लूप में उनके चारों ओर जाना चाहते हैं और एक ही पंक्ति जोड़ते हैं।

 <for (moduleName in enabledModules) { compileOnly project('<include var="moduleName">') }> 

इस प्रकार, हमने कोड जनरेटर के लिए तीन शर्तें सामने रखीं:

• हम शर्तों का उपयोग करना चाहते हैं
• परिवर्तनीय मूल्यों को प्रतिस्थापित करने की क्षमता
• हमें पैटर्न में छोरों की आवश्यकता है

कोड जनरेटर

कोड जनरेटर को लागू करने के लिए विकल्प क्या हैं? उदाहरण के लिए, आप अपना स्वयं का कोड जनरेटर लिख सकते हैं। उदाहरण के लिए, उबेर के लोगों ने ऐसा किया: उन्होंने अपनी खुद की प्लग-इन रिबल्स (तथाकथित आर्किटेक्चरल यूनिट्स) बनाने के लिए लिखी । वे अपनी स्वयं की टेम्पलेट भाषा के साथ आए, जिसमें उन्होंने केवल चर डालने की क्षमता का उपयोग किया। उन्होंने जनरेटर के स्तर पर स्थितियों को लाया। लेकिन हमने सोचा कि हम ऐसा नहीं करेंगे।

दूसरा विकल्प IDEA में निर्मित FileTemplateManager उपयोगिता वर्ग का उपयोग करना है, लेकिन मैं ऐसा करने की सिफारिश नहीं करूंगा। क्योंकि उसके पास एक इंजन के रूप में वेलोसिटी है , जिसमें जावा ऑब्जेक्ट को टेम्प्लेट में अग्रेषित करने में कुछ समस्याएं हैं। इसके अलावा, FileTemplateManager बॉक्स से जावा या XML के अलावा अन्य फ़ाइलों को उत्पन्न नहीं कर सकता है। और हमें ग्रूवी फाइलें, कोटलिन, प्रोगार्ड और अन्य प्रकार की फाइलें उत्पन्न करने की आवश्यकता थी।

तीसरा विकल्प था ... FreeMarker । यदि आपके पास फ्री - मेकर टेम्पलेट हैं, तो उन्हें फेंकने में जल्दबाजी न करें - वे प्लगइन के अंदर आपके लिए उपयोगी हो सकते हैं।

क्या किया जाना चाहिए, प्लगइन के अंदर FreeMarker का उपयोग करने के लिए क्या करना है? सबसे पहले, फ़ाइल टेम्पलेट जोड़ें। आप / रिसोर्स फ़ोल्डर के अंदर / टेम्प्लेट फ़ोल्डर बना सकते हैं और हमारे सभी टेम्प्लेट को सभी फाइलों के लिए जोड़ सकते हैं - प्रेजेंटेटर, टुकड़े आदि।

उसके बाद, आपको FreeMarker लाइब्रेरी पर निर्भरता जोड़ने की आवश्यकता होगी। चूंकि प्लगइन ग्रैडल का उपयोग करता है, एक निर्भरता जोड़ना सीधा है।

 dependencies { ... compile 'org.freemarker:freemarker:2.3.28' } 

उसके बाद, हमारे प्लगइन के अंदर FreeMarker कॉन्फ़िगर करें। मैं आपको सलाह देता हूं कि आप इस कॉन्फ़िगरेशन को यहां कॉपी करें - यह अत्याचार, पीड़ा, इसे कॉपी करें और सब कुछ बस काम करता है।

 class TemplatesFactory(val project: Project) : ProjectComponent { private val freeMarkerConfig by lazy { Configuration(Configuration.VERSION_2_3_28).apply { setClassForTemplateLoading( TemplatesFactory::class.java, "/templates" ) defaultEncoding = Charsets.UTF_8.name() templateExceptionHandler = TemplateExceptionHandler.RETHROW_HANDLER logTemplateExceptions = false wrapUncheckedExceptions = true } } ... 

यह FreeMarker का उपयोग करके फ़ाइलें बनाने का समय है। ऐसा करने के लिए, हमें इसके नाम से कॉन्फ़िगरेशन से एक टेम्पलेट मिलता है और नियमित रूप से FileWriter का उपयोग करके डिस्क पर सीधे वांछित पाठ के साथ एक फ़ाइल बनाते हैं।

 class TemplatesFactory(val project: Project) : ProjectComponent { ... fun generate( pathToFile: String, templateFileName: String, data: Map<String, Any> ) { val template = freeMarkerConfig.getTemplate(templateFileName) FileWriter(pathToFile, false).use { writer -> template.process(data, writer) } } } 

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

निष्कर्ष - यह सही है, फ़ाइलें बनाएँ, पीएसआई की संरचना को ध्यान में रखते हुए।

फ़ाइलों के लिए एक PSI संरचना बनाएँ

आरंभ करने के लिए, चलो PsiDirectory का उपयोग करके फ़ोल्डर संरचना को देखा । प्रोजेक्ट की आरंभ निर्देशिका को एक्सटेंशन फ़ंक्शंस अनुमानप्रयोगदिर और toPsiDirectory का उपयोग करके प्राप्त किया जा सकता है:

 val projectPsiDirectory = project.guessProjectDir()?.toPsiDirectory(project) 

बाद की निर्देशिकाओं को या तो PsiDirectory findSubdirectory वर्ग विधि का उपयोग करके पाया जा सकता है, या createSubdirectory विधि का उपयोग करके बनाया जा सकता है।

 val coreModuleDir = projectPsiDirectory.findSubdirectory("core") val newModulePsiDir = coreModuleDir.createSubdirectory(config.mainParams.moduleName) 

मैं यह भी सलाह देता हूं कि आप एक ऐसा मानचित्र बनाएं जिसमें से आप स्ट्रिंग कुंजी का उपयोग करके सभी PsiDirectory फ़ोल्डर संरचनाएं प्राप्त कर सकते हैं, और फिर इनमें से किसी भी फ़ोल्डर में बनाई गई फ़ाइलों को जोड़ सकते हैं।

 //   PsiDirectory   package name: // ru.hh.feature_worknear → ru / hh / feature_worknear createPackageNameFolder(config) // data this["data"] = this["package"]?.createSubdirectory("data") // ... 

फोल्डर बनाया। हम PsiFile का उपयोग करके PsiFiles बनाएंगे । इस वर्ग में एक विशेष विधि है, जिसे createFileFromText कहा जाता है। विधि इनपुट के रूप में तीन मापदंडों को स्वीकार करती है: नाम (स्ट्रिंग फ़ाइलनाम), पाठ (स्ट्रिंग पाठ) और आउटपुट फ़ाइल का प्रकार (फ़ाइल टाइप फ़ाइल टाइप)। तीन मापदंडों में से दो स्पष्ट हैं कि इसे कहाँ प्राप्त किया जाए: हम स्वयं नाम जानते हैं, हमें फ्रीमार्कर से पाठ मिलता है। और कहाँ FileType पाने के लिए? और यह सब क्या है?

फ़ाइल-प्रकार

FileType एक विशेष वर्ग है जो फ़ाइल के प्रकार को दर्शाता है। "बॉक्स" से हमारे पास केवल दो FileType उपलब्ध हैं: Java-files और XML-files के लिए क्रमशः JavaFileType और XmlFileType। लेकिन सवाल यह उठता है: बिल्ड के लिए प्रकार कहाँ प्राप्त करने के लिए। कोटलिन फ़ाइलों के लिए, कोस्टगिल फ़ाइलों के लिए, प्रिटगॉर के लिए, आखिरकार !?

सबसे पहले, इनमें से अधिकांश फ़ाइल टाइप को अन्य प्लगइन्स से लिया जा सकता है जो पहले से ही किसी के द्वारा लिखे गए हैं। GroovyFileType को Groovy plugin , KotlinFileType से Kotlin प्लगइन , एंड्रॉइड प्लगइन से प्रोगार्ड से लिया जा सकता है।

हम अपने लिए दूसरे प्लगइन की निर्भरता कैसे जोड़ते हैं? हम gradle-intellij-plugin का उपयोग करते हैं। यह प्लगइन के build.gradle फ़ाइल में एक विशेष इंटेलीज ब्लॉक जोड़ता है, जिसके अंदर एक विशेष गुण है - प्लगइन्स । इस संपत्ति में, आप प्लगइन पहचानकर्ताओं की सूची सूचीबद्ध कर सकते हैं, जिस पर हम निर्भर रहना चाहते हैं।

 // build.gradle  intellij { … plugins = ['android', 'Groovy', 'kotlin'] } 

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

दूसरे, आपको plugin.xml फ़ाइल पर निर्भरता विवरण जोड़ना होगा। यह टैग का उपयोग करके किया जाता है ।

 <idea-plugin> ... <depends>org.jetbrains.android</depends> <depends>org.jetbrains.kotlin</depends> <depends>org.intellij.groovy</depends> </idea-plugin> 

हम परियोजना को सिंक्रनाइज़ करने के बाद, हम अन्य प्लगइन्स से निर्भरता को कस लेंगे, और हम उनका उपयोग करने में सक्षम होंगे।

लेकिन क्या होगा अगर हम अन्य प्लगइन्स पर निर्भर नहीं होना चाहते हैं? इस मामले में, हम जिस प्रकार की फ़ाइल की आवश्यकता है, उसके लिए एक स्टब बना सकते हैं। ऐसा करने के लिए, पहले एक वर्ग बनाएं जो भाषा वर्ग से विरासत में आएगा। हमारी प्रोग्रामिंग लैंग्वेज की विशिष्ट पहचानकर्ता को इस वर्ग (हमारे मामले में - "ru.hh.plugins.Ignore ) पर पास किया जाएगा। "

 class IgnoreLanguage private constructor() : Language("ru.hh.plugins.Ignore", "ignore", null), InjectableLanguage { companion object { val INSTANCE = IgnoreLanguage() } override fun getDisplayName(): String { return "Ignore() ($id)" } } 

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

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

 class IgnoreFileType(language: Language) : LanguageFileType(language) { companion object { val INSTANCE = IgnoreFileType(IgnoreLanguage.INSTANCE) } override fun getName(): String = "gitignore file" override fun getDescription(): String = "gitignore files" override fun getDefaultExtension(): String = "gitignore" override fun getIcon(): Icon? = null } 

फ़ाइल बनाना समाप्त करें

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

 data class TemplateData( val templateFileName: String, val outputFileName: String, val outputFileType: FileType, val outputFilePsiDirectory: PsiDirectory? ) 

फिर हम FreeMarker पर लौटते हैं - हम इसे से टेम्पलेट फ़ाइल प्राप्त करते हैं, StringWriter का उपयोग करके हम पाठ प्राप्त करते हैं, PsiFileFactory में हम वांछित पाठ और प्रकार के साथ PsiFile उत्पन्न करते हैं। बनाई गई फ़ाइल को वांछित निर्देशिका में जोड़ा जाता है।

 fun createFromTemplate(data: FileTemplateData, properties: Map<String, Any>): PsiFile { val template = freeMarkerConfig.getTemplate(data.templateFileName) val text = StringWriter().use { writer -> template.process(properties, writer) writer.buffer.toString() } return psiFileFactory.createFileFromText(data.outputFileName, data.outputFileType, text) } 

इस प्रकार, पीएसआई संरचना को ध्यान में रखा जाता है, और आईडीईए, साथ ही अन्य प्लगइन्स, देखेंगे कि हमने क्या किया है। इससे एक लाभ हो सकता है: उदाहरण के लिए, यदि Git के लिए प्लगइन देखता है कि आपने एक नई फ़ाइल जोड़ी है, तो यह स्वचालित रूप से एक डायलॉग बॉक्स प्रदर्शित करेगा जिसमें पूछा जाएगा कि क्या आप इन फ़ाइलों को Git में जोड़ना चाहते हैं?

कोड पीढ़ी के निष्कर्ष

• पाठ फ़ाइलें FreeMarker द्वारा उत्पन्न की जा सकती हैं। बहुत सहज है।
• फाइलें बनाते समय, आपको पीएसआई संरचना पर विचार करने की आवश्यकता होती है, अन्यथा सब कुछ गलत हो जाएगा।
• यदि आप PsiFileFactory का उपयोग करके फ़ाइलें जनरेट करना चाहते हैं, तो आपको कहीं-कहीं FileType ढूंढना होगा।

खैर, अब हम आखिरी, सबसे स्वादिष्ट व्यावहारिक भाग की ओर मुड़ते हैं - यह कोड का एक संशोधन है।

कोड संशोधन

वास्तव में, केवल कोड उत्पन्न करने के लिए एक प्लगइन बनाना बकवास है, क्योंकि आप अन्य उपकरणों के साथ कोड उत्पन्न कर सकते हैं, और एक ही FreeMarker । लेकिन FreeMarker क्या नहीं कर सकता कोड को संशोधित करता है।

हमारी चेकलिस्ट में कोड को संशोधित करने से संबंधित कई कार्य हैं, आइए सबसे सरल एक से शुरू करें - settings.gradle फ़ाइल को संशोधित करें।

संशोधन सेटिंग्स

मैं आपको याद दिलाता हूं कि हम क्या करना चाहते हैं: हमें इस फ़ाइल में कुछ लाइनों को जोड़ने की आवश्यकता है जो नए बनाए गए मॉड्यूल के लिए पथ का वर्णन करेंगे:

 // settings.gradle include ':analytics project(':analytics').projectDir = new File(settingsDir, 'core/framework-metrics/analytics) ... include ':feature-worknear' project(':feature-worknear').projectDir = new File(settingsDir, 'feature/feature-worknear') 

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

खैर, आदर्श रूप से, निश्चित रूप से, यह पीएसआई संरचना के माध्यम से बेहतर है - यह अधिक विश्वसनीय है।

टूथपिक के लिए केप्ट ट्यूनिंग

एक बार फिर, मैं आपको समस्या की याद दिलाता हूं: एप्लिकेशन मॉड्यूल में बिल्ड.ग्रेड फ़ाइल है, और इसके अंदर एनोटेशन प्रोसेसर के लिए सेटिंग्स हैं। और हम अपने बनाए गए मॉड्यूल के पैकेज को एक विशिष्ट स्थान पर जोड़ना चाहते हैं।

हमारा लक्ष्य एक विशिष्ट PsiElement की खोज करना है , जिसके बाद हम अपनी लाइन को जोड़ने की योजना बनाते हैं। तत्व की खोज PsiFile के लिए खोज से शुरू होती है, जो एप्लिकेशन मॉड्यूल की बिल्ड.ग्रेड फ़ाइल को दर्शाता है। और इसके लिए आपको उस मॉड्यूल को खोजने की आवश्यकता है जिसके अंदर हम फ़ाइल की तलाश करेंगे।

 val appModule = ModuleManager.getInstance(project) .modules.toList() .first { it.name == "headhunter-applicant" } 

अगला, उपयोगिता वर्ग FilenameIndex का उपयोग करके , आप खोज क्षेत्र के रूप में पाए गए मॉड्यूल को निर्दिष्ट करते हुए, इसके नाम से PsiFile पा सकते हैं।

 val buildGradlePsiFile = FilenameIndex.getFilesByName( appModule.project, "build.gradle", appModule.moduleContentScope ).first() 

हम PsiFile खोजने के बाद, हम PsiElement की खोज शुरू कर सकते हैं। , – PSI Viewer . IDEA , PSI- .

- (, build.gradle) , PSI- .

– , PsiFile -.

. PsiFile . .

 val toothpickRegistryPsiElement = buildGradlePsiFile.originalFile .collectDescendantsOfType<GrAssignmentExpression>() .firstOrNull { it.text.startsWith("arguments") } ?.lastChild ?.children?.firstOrNull { it.text.startsWith("toothpick_registry_children_package_names") } ?.collectDescendantsOfType<GrListOrMap>() ?.first() ?: return 

?.. ? PSI-. GrAssignmentExpression , , arguments = [ … ] . , toothpick_registry_children_package_names = [...] , Groovy-.

PsiElement , . . .

PSI- , PsiElementFactory , . Java-? Java-. Groovy? GroovyPsiElementFactory . और इसी तरह।

PsiElementFactory . Groovy Kotlin , .

 val factory = GroovyPsiElementFactory.getInstance(buildGradlePsiFile.project) val packageName = config.mainParams.packageName val newArgumentItem = factory.createStringLiteralForReference(packageName) 

PsiElement .

 targetPsiElement.add(newArgumentItem) 

kapt- Moxy application

-, , – kapt- Moxy application . : @RegisterMoxyReflectorPackages .

, : PsiFile , PsiElement , … , PsiElement -.

: , @RegisterMoxyReflectorPackages , value , .

, . , PsiManager , PsiClass .

 val appModule = ModuleManager.getInstance(project) .modules.toList() .first { it.name == "headhunter-applicant" } val psiManager = PsiManager.getInstance(appModule.project) val annotationPsiClass = ClassUtil.findPsiClass( psiManager, "com.arellomobile.mvp.RegisterMoxyReflectorPackages" ) ?: return 

AnnotatedMembersSearch , .

 val annotatedPsiClass = AnnotatedMembersSearch.search( annotationPsiClass, appModule.moduleContentScope ).findAll() ?.firstOrNull() ?: return 

, PsiElement , value. , .

 val annotationPsiElement = (annotatedPsiClass .annotations .first() as KtLightAnnotationForSourceEntry ).kotlinOrigin val packagesPsiElements = annotationPsiElement .collectDescendantsOfType<KtValueArgumentList>() .first() .collectDescendantsOfType<KtValueArgument>() val updatedPackagesList = packagesPsiElements .mapTo(mutableListOf()) { it.text } .apply { this += "\"${config.packageName}\"" } val newAnnotationValue = updatedPackagesList.joinToString(separator = ",\n") 

KtPsiFactory PsiElement – .

 val kotlinPsiFactory = KtPsiFactory(project) val newAnnotationPsiElement = kotlinPsiFactory.createAnnotationEntry( "@RegisterMoxyReflectorPackages(\n$newAnnotationValue\n)" ) val replaced = annotationPsiElement.replace(newAnnotationPsiElement) 

.

? code style. , IDEA : CodeStyleManager.

 CodeStyleManager.getInstance(module.project).reformat(replacedElement) 

- , .

• , PSI-, .
• , PSI , , PsiElement-.

?

.

• – , .
• . . : .
• ? . , IDEA , . , . — - , GitHub . , , .
• - – IntelliJ IDEA . , Util Manager , , , .
• : . , runIde , IDEA, . , hh.ru, .

वह सब है। , , – .

पूछे जाने वाले प्रश्न

• ?

, . , 2 3 .

• IDEA , - ?

, IDEA IDEA SDK , deprecated, , . SDK- , , .

• ?

– gitignore . - .

• ?

Android Studio Mac OS, Ubuntu, . , Windows, .