Marahil matagal nang hindi nangangailangan ng espesyal na pagpapakilala. Maraming tao ang pamilyar sa Eclipse salamat sa Eclipse Java development tools (). Ito ang sikat na open-source na Java IDE na iniuugnay ng karamihan sa mga developer sa salitang "Eclipse". Gayunpaman, ang Eclipse ay parehong napapalawak na platform para sa pagsasama ng mga tool sa pag-unlad (Eclipse Platform), at ilang mga IDE na binuo batay dito, kabilang ang JDT. Ang Eclipse ay parehong Eclipse Project, ang pinakamataas na antas ng proyekto na nag-uugnay sa pagbuo ng Eclipse Platform at ang JDT, at ang Eclipse SDK, ang naihatid na resulta ng pag-unlad na iyon. Sa wakas, ang Eclipse ay isang open-source na Foundation na may malaking komunidad ng mga proyekto, hindi lahat ay nakasulat sa Java o nauugnay sa mga tool sa pag-unlad (halimbawa, mga proyekto ΠΈ ). Ang mundo ng Eclipse ay lubhang magkakaibang.
Sa artikulong ito, na isang pangkalahatang-ideya sa kalikasan, susubukan naming tingnan ang ilan sa mga pangunahing kaalaman ng arkitektura ng Eclipse bilang isang platform para sa pagbuo ng pinagsama-samang mga tool sa pag-unlad at magbigay ng isang paunang ideya ng mga bahagi ng Eclipse na bumubuo sa pundasyon ng teknolohiya. platform para sa "bagong Configurator" 1C: Enterprise. . Siyempre, ang naturang pagsusuri ay hindi maiiwasang maging mababaw at sa halip ay limitado, kabilang ang dahil hindi lang kami tumutuon sa mga developer ng Eclipse bilang target na madla. Gayunpaman, umaasa kami na kahit na ang mga nakaranas ng mga developer ng Eclipse ay makakahanap ng kawili-wiling impormasyon sa artikulo. Halimbawa, pag-uusapan natin ang tungkol sa isa sa mga "lihim ng Eclipse", isang medyo bago at hindi kilalang proyekto , na itinatag at sinusuportahan ng 1C.
Panimula sa Eclipse Architecture
Tingnan muna natin ang ilang pangkalahatang aspeto ng arkitektura ng Eclipse gamit ang halimbawa (JDT). Ang pagpili ng JDT bilang isang halimbawa ay hindi sinasadya. Ito ang unang pinagsama-samang development environment na lumabas sa Eclipse. Ang iba pang mga *DT Eclipse na proyekto, tulad ng Eclipse C/C++ Development Tooling (CDT), ay ginawa sa ibang pagkakataon at hiniram ang parehong mga pangunahing prinsipyo ng arkitektura at indibidwal na mga fragment ng source code mula sa JDT. Ang mga batayan ng arkitektura na inilatag sa JDT ay may kaugnayan sa araw na ito para sa halos anumang IDE na binuo sa ibabaw ng Eclipse Platform, kabilang ang 1C:Enterprise Development Tools.
Una sa lahat, dapat tandaan na ang Eclipse ay nailalarawan sa pamamagitan ng isang medyo malinaw na architectural layering, na may paghihiwalay ng language-independent functionality mula sa functionality na idinisenyo upang suportahan ang mga partikular na programming language, at ang paghihiwalay ng UI-independent na "core" na mga bahagi mula sa mga bahaging nauugnay. na may sumusuportang user interface.
Kaya, ang Eclipse Platform ay tumutukoy sa isang pangkaraniwan, wika-independiyenteng imprastraktura, at ang mga tool sa pagpapaunlad ng Java ay nagdaragdag ng isang ganap na tampok na Java IDE sa Eclipse. Parehong ang Eclipse Platform at ang JDT ay binubuo ng ilang bahagi, na ang bawat isa ay kabilang sa alinman sa UI-independent na "core" o isang UI layer (Figure 1).
kanin. 1. Eclipse Platform at JDT
Ilista natin ang mga pangunahing bahagi ng Eclipse Platform:
- Runtime β Tinutukoy ang imprastraktura ng plugin. Ang Eclipse ay nailalarawan sa pamamagitan ng isang modular na arkitektura. Sa esensya, ang Eclipse ay isang koleksyon ng mga "extension point" at "extension".
- workspace β Namamahala ng isa o higit pang mga proyekto. Ang isang proyekto ay binubuo ng mga folder at file na direktang naka-map sa file system.
- Standard Widget Toolkit (SWT) - Nagbibigay ng mga pangunahing elemento ng user interface na isinama sa operating system.
- JFace β Nagbibigay ng ilang UI framework na binuo sa ibabaw ng SWT.
- Workbench β Tinutukoy ang paradigm ng Eclipse UI: mga editor, view, perspective.
Dapat sabihin na ang Eclipse Platform ay nagbibigay din ng maraming iba pang kapaki-pakinabang na bahagi para sa pagbuo ng pinagsama-samang mga tool sa pag-unlad, kabilang ang Debug, Paghambingin, Paghahanap, at Koponan. Espesyal na banggitin ang JFace Text - ang batayan para sa pagbuo ng "matalinong mga editor" ng source code. Sa kasamaang-palad, kahit na ang isang mabilis na pagsusuri sa mga bahaging ito, pati na rin ang mga bahagi ng layer ng UI, ay hindi posible sa loob ng saklaw ng artikulong ito, kaya sa natitirang bahagi ng seksyong ito ay lilimitahan natin ang ating sarili sa isang pangkalahatang-ideya ng mga pangunahing "core" na bahagi ng ang Eclipse Platform at JDT.
Core Runtime
Ang imprastraktura ng Eclipse plugin ay nakabatay sa at ibinigay ng proyekto . Ang bawat Eclipse plugin ay isang OSGi bundle. Tinutukoy ng OSGi specification, sa partikular, ang mga mekanismo para sa pag-bersyon at paglutas ng dependency. Bilang karagdagan sa mga karaniwang mekanismong ito, ipinakilala ng Equinox ang konsepto mga punto ng pagpapalawak. Maaaring tukuyin ng bawat plugin ang sarili nitong mga extension point, at magpakilala din ng karagdagang functionality (βmga extensionβ) sa system gamit ang mga extension point na tinukoy ng pareho o iba pang mga plugin. Ang anumang detalyadong paglalarawan ng mga mekanismo ng OSGi at Equinox ay lampas sa saklaw ng artikulong ito. Tandaan lamang natin na ang modularization sa Eclipse ay kabuuan (anumang subsystem, kabilang ang Runtime, ay binubuo ng isa o higit pang mga plugin), at halos lahat ng bagay sa Eclipse ay isang extension. Bukod dito, ang mga prinsipyong ito ay naka-embed sa arkitektura ng Eclipse bago ang pagpapakilala ng OSGi (sa oras na iyon ay ginamit nila ang kanilang sariling teknolohiya, na halos kapareho sa OSGi).
Core Workspace
Halos anumang pinagsamang development environment na binuo sa ibabaw ng Eclipse Platform ay gumagana sa Eclipse workspace. Ito ang workspace na karaniwang naglalaman ng source code ng application na binuo sa IDE. Direktang nagmamapa ang workspace sa file system at binubuo ng mga proyekto, na naglalaman ng mga folder at file. Ang mga proyekto, folder, at file na ito ay tinatawag mapagkukunan workspace. Ang pagpapatupad ng workspace sa Eclipse ay nagsisilbing isang cache na may kaugnayan sa file system, na ginagawang posible na makabuluhang mapabilis ang pagtawid sa resource tree. Bilang karagdagan, ang workspace ay nagbibigay ng ilang karagdagang serbisyo, kabilang ang ΠΈ .
Ang bahagi ng Core Resources (org.eclipse.core.resources plugin) ay responsable para sa pagsuporta sa workspace at mga mapagkukunan nito. Sa partikular, ang bahaging ito ay nagbibigay ng programmatic na access sa workspace sa form mga modelo ng mapagkukunan. Upang gumana nang epektibo sa modelong ito, kailangan ng mga kliyente ng isang simpleng paraan upang ipakita ang isang link sa isang mapagkukunan. Sa kasong ito, kanais-nais na itago ang bagay na direktang nag-iimbak ng estado ng mapagkukunan sa modelo mula sa pag-access ng kliyente. Kung hindi, sa kaso ng, halimbawa, ang pagtanggal ng file, ang kliyente ay maaaring magpatuloy na humawak ng isang bagay na wala na sa modelo, kasama ang mga kasunod na problema. Niresolba ng Eclipse ang problemang ito gamit ang tinatawag na isang bagay pangasiwaan mapagkukunan. Ang Handle ay gumaganap bilang isang susi (alam lamang nito ang landas patungo sa mapagkukunan sa workspace) at ganap na kinokontrol ang pag-access sa object ng panloob na modelo, na direktang nag-iimbak ng impormasyon tungkol sa estado ng mapagkukunan. Ang disenyo na ito ay isang pagkakaiba-iba ng pattern .
kanin. Ang Figure 2 ay naglalarawan ng Handle/Body idiom bilang inilapat sa resource model. Ang interface ng IResource ay kumakatawan sa hawakan ng isang mapagkukunan at isang API, hindi katulad ng Resource class, na nagpapatupad ng interface na ito, at ang ResourceInfo class, na kumakatawan sa katawan, na hindi mga API. Binibigyang-diin namin na alam lang ng handle ang path sa resource na nauugnay sa workspace root at hindi naglalaman ng link sa resource info. Ang mga bagay sa impormasyon ng mapagkukunan ay bumubuo ng tinatawag na "element tree". Ang istraktura ng data na ito ay ganap na na-materialize sa memorya. Upang mahanap ang instance ng impormasyon ng mapagkukunan na tumutugma sa isang handle, ang puno ng elemento ay binabagtas ayon sa landas na nakaimbak sa handle na iyon.
kanin. 2. IResource at ResourceInfo
Tulad ng makikita natin sa ibang pagkakataon, ang pangunahing disenyo ng modelo ng mapagkukunan (maaari nating tawaging nakabatay sa hawakan) ay ginagamit din sa Eclipse para sa iba pang mga modelo. Sa ngayon, ilista natin ang ilan sa mga natatanging katangian ng disenyong ito:
- Ang hawakan ay isang bagay na may halaga. Ang mga value object ay mga hindi nababagong bagay na ang pagkakapantay-pantay ay hindi batay sa pagkakakilanlan. Ang mga naturang bagay ay maaaring ligtas na magamit bilang susi sa mga na-hash na lalagyan. Maraming pagkakataon ng handle ang maaaring mag-reference sa parehong mapagkukunan. Upang ihambing ang mga ito, kailangan mong gamitin ang equals(Object) method.
- Tinutukoy ng Handle ang pag-uugali ng isang mapagkukunan, ngunit hindi naglalaman ng impormasyon tungkol sa estado ng mapagkukunan (ang tanging data na iniimbak nito ay ang "susi", ang landas patungo sa mapagkukunan).
- Maaaring tumukoy ang Handle sa isang mapagkukunan na hindi umiiral (alinman sa isang mapagkukunan na hindi pa nagagawa, o isang mapagkukunan na natanggal na). Ang pagkakaroon ng isang mapagkukunan ay maaaring suriin gamit ang IResource.exists() na pamamaraan.
- Ang ilang mga operasyon ay maaaring ipatupad batay lamang sa impormasyong nakaimbak sa mismong hawakan (tinatawag na mga operasyong hawakan lamang). Ang mga halimbawa ay IResource.getParent(), getFullPath(), atbp. Hindi kailangang umiral ang mapagkukunan para magtagumpay ang naturang operasyon. Ang mga operasyong nangangailangan ng resource na umiral upang magtagumpay ay magtapon ng CoreException kung wala ang resource.
Nagbibigay ang Eclipse ng mahusay na mekanismo para sa pag-abiso sa mga pagbabago sa mapagkukunan ng workspace (Larawan 3). Maaaring magbago ang mga mapagkukunan bilang resulta ng mga pagkilos na isinagawa sa loob mismo ng Eclipse IDE o bilang resulta ng pag-synchronize sa file system. Sa parehong mga kaso, ang mga kliyente na nag-subscribe sa mga abiso ay binibigyan ng detalyadong impormasyon tungkol sa mga pagbabago sa anyo ng "mga deltas ng mapagkukunan". Ang isang delta ay naglalarawan ng mga pagbabago sa pagitan ng dalawang estado ng isang workspace resource (sub-)tree at ito mismo ay isang puno, ang bawat node ay naglalarawan ng pagbabago sa isang resource at naglalaman ng isang listahan ng mga delta sa susunod na antas na naglalarawan ng mga pagbabago sa child resources.
kanin. 3. IResourceChangeEvent at IResourceDelta
Ang mekanismo ng abiso batay sa resource deltas ay may mga sumusunod na katangian:
- Ang isang solong pagbabago at maraming mga pagbabago ay inilarawan gamit ang parehong istraktura, dahil ang delta ay binuo gamit ang prinsipyo ng recursive na komposisyon. Maaaring iproseso ng mga kliyente ng subscriber ang mga notification sa pagbabago ng mapagkukunan gamit ang recursive descent sa pamamagitan ng tree of deltas.
- Ang delta ay naglalaman ng kumpletong impormasyon tungkol sa mga pagbabago sa mapagkukunan, kabilang ang paggalaw nito at/o mga pagbabago sa "mga marker" na nauugnay dito (halimbawa, ang mga error sa compilation ay kinakatawan bilang mga marker).
- Dahil ang mga sanggunian sa mapagkukunan ay ginawa sa pamamagitan ng hawakan, ang delta ay maaaring natural na sumangguni sa isang malayong mapagkukunan.
Tulad ng makikita natin sa lalong madaling panahon, ang mga pangunahing bahagi ng disenyo ng mekanismo ng abiso sa pagbabago ng modelo ng mapagkukunan ay may kaugnayan din para sa iba pang mga modelong nakabatay sa hawakan.
JDT Core
Ang modelo ng mapagkukunan ng workspace ng Eclipse ay isang pangunahing modelo ng wika-agnostic. Ang bahagi ng JDT Core (plugin org.eclipse.jdt.core) ay nagbibigay ng API para sa pag-navigate at pagsusuri sa istraktura ng workspace mula sa pananaw ng Java, ang tinatawag na "Java model" (modelo ng Java). Ang API na ito ay tinukoy sa mga tuntunin ng mga elemento ng Java, kumpara sa pinagbabatayan na modelo ng mapagkukunang API, na tinukoy sa mga tuntunin ng mga folder at file. Ang mga pangunahing interface ng Java element tree ay ipinapakita sa Fig. 4.
kanin. 4. Mga Elemento ng Modelong Java
Ang modelo ng Java ay gumagamit ng parehong handle/body idiom bilang modelo ng mapagkukunan (Larawan 5). Ang IJavaElement ay ang hawakan, at ang JavaElementInfo ay gumaganap ng papel ng katawan. Ang interface ng IJavaElement ay tumutukoy sa isang protocol na karaniwan sa lahat ng mga elemento ng Java. Ang ilan sa mga pamamaraan nito ay handle-only: getElementName(), getParent(), atbp. Ang JavaElementInfo object ay nag-iimbak ng estado ng kaukulang elemento: ang istraktura at mga katangian nito.
kanin. 5. IJavaElement at JavaElementInfo
Ang modelo ng Java ay may ilang pagkakaiba sa pagpapatupad ng pangunahing disenyo ng hawakan/katawan kumpara sa modelo ng mapagkukunan. Gaya ng nabanggit sa itaas, sa resource model, ang element tree, na ang mga node ay mga resource info object, ay ganap na nakapaloob sa memorya. Ngunit ang modelo ng Java ay maaaring magkaroon ng mas malaking bilang ng mga elemento kaysa sa resource tree, dahil kinakatawan din nito ang panloob na istruktura ng .java at .class na mga file: mga uri, field, at pamamaraan.
Upang maiwasang ganap na maisakatuparan ang buong puno ng mga elemento sa memorya, ang pagpapatupad ng modelo ng Java ay gumagamit ng isang limitadong laki ng LRU cache ng impormasyon ng elemento, kung saan ang susi ay humahawak sa IJavaElement. Ang mga bagay na impormasyon ng elemento ay nilikha kapag hinihiling habang ang puno ng elemento ay na-navigate. Sa kasong ito, ang hindi gaanong madalas na ginagamit na mga item ay pinaalis mula sa cache, at ang paggamit ng memorya ng modelo ay nananatiling limitado sa tinukoy na laki ng cache. Ito ay isa pang bentahe ng disenyong nakabatay sa hawakan, na ganap na nagtatago ng mga detalye ng pagpapatupad mula sa code ng kliyente.
Ang mekanismo para sa pag-abiso ng mga pagbabago sa mga elemento ng Java ay sa pangkalahatan ay katulad ng mekanismo para sa pagsubaybay sa mga pagbabago sa mga mapagkukunan ng workspace na tinalakay sa itaas. Ang isang kliyente na nagnanais na subaybayan ang mga pagbabago sa modelo ng Java ay nag-subscribe sa mga abiso, na kinakatawan bilang isang bagay na ElementChangedEvent na naglalaman ng isang IJavaElementDelta (Larawan 6).
kanin. 6. ElementChangedEvent at IJavaElementDelta
Ang modelo ng Java ay hindi naglalaman ng impormasyon tungkol sa mga katawan ng pamamaraan o resolusyon ng pangalan, kaya para sa detalyadong pagsusuri ng code na nakasulat sa Java, ang JDT Core ay nagbibigay ng karagdagang (hindi nakabatay sa hawakan) na modelo: (abstract na syntax tree, AST). Kinakatawan ng AST ang resulta ng pag-parse ng source text. Ang mga AST node ay tumutugma sa mga elemento ng istraktura ng source module (mga deklarasyon, operator, expression, atbp.) at naglalaman ng impormasyon tungkol sa mga coordinate ng kaukulang elemento sa source text, pati na rin (bilang isang opsyon) na impormasyon tungkol sa paglutas ng pangalan sa ang anyo ng mga link sa tinatawag na bindings. Ang mga binding ay mga bagay na kumakatawan sa mga pinangalanang entity, gaya ng mga uri, pamamaraan, at variable, na kilala ng compiler. Hindi tulad ng mga AST node, na bumubuo ng isang puno, sinusuportahan ng mga binding ang cross-referencing at sa pangkalahatan ay bumubuo ng isang graph. Ang abstract class na ASTNode ay ang karaniwang base class para sa lahat ng AST node. Ang mga subclass ng ASTNode ay tumutugma sa mga partikular na syntactic na konstruksyon ng wikang Java.
Dahil ang mga puno ng syntax ay maaaring kumonsumo ng malaking halaga ng memorya, ang JDT ay nag-cache lamang ng isang AST para sa aktibong editor. Hindi tulad ng modelo ng Java, ang AST ay karaniwang tinitingnan bilang isang "intermediate", "pansamantalang" modelo, ang mga elemento kung saan ang mga kliyente ay hindi dapat magkaroon ng mga sanggunian sa labas ng konteksto ng operasyon na humantong sa paglikha ng AST.
Ang nakalistang tatlong modelo (Java model, AST, bindings) ay magkasamang bumubuo ng batayan para sa pagbuo ng "intelligent development tools" sa JDT, kabilang ang isang makapangyarihang Java editor na may iba't ibang "helpers", iba't ibang mga aksyon para sa pagproseso ng source code (kabilang ang pag-aayos ng isang listahan ng pag-import mga pangalan at pag-format ayon sa naka-customize na istilo), mga tool sa paghahanap at refactoring. Sa kasong ito, ang modelo ng Java ay gumaganap ng isang espesyal na papel, dahil ito ang ginagamit bilang batayan para sa isang visual na representasyon ng istraktura ng application na binuo (halimbawa, sa Package Explorer, Outline, Search, Call Hierarchy, at Uri ng Hierarchy).
Eclipse component na ginagamit sa 1C: Enterprise Developments Tools
Sa Fig. Ipinapakita ng Figure 7 ang mga bahagi ng Eclipse na bumubuo sa pundasyon ng platform ng teknolohiya para sa 1C:Enterprise Development Tools.
kanin. 7. Eclipse bilang isang plataporma para sa 1C:Enterprise Development Tools
Platform ng Eclipse nagbibigay ng pangunahing imprastraktura. Tiningnan namin ang ilang aspeto ng imprastraktura na ito sa nakaraang seksyon.
(EMF) ay nagbibigay ng pangkalahatang paraan ng pagmomodelo ng structured na data. Ang EMF ay isinama sa Eclipse Platform, ngunit maaari ding gamitin nang hiwalay sa mga regular na Java application. Kadalasan, ang mga bagong developer ng Eclipse ay pamilyar na sa EMF, bagama't hindi pa nila lubos na nauunawaan ang mga intricacies ng Eclipse Platform. Ang isa sa mga dahilan para sa gayong karapat-dapat na katanyagan ay ang unibersal na disenyo, na kinabibilangan, bukod sa iba pang mga bagay, isang pinag-isang meta-level na API, na nagbibigay-daan sa iyong magtrabaho sa anumang modelo ng EMF sa pangkalahatang paraan. Ang mga pangunahing pagpapatupad para sa mga object ng modelo na ibinigay ng EMF at ang subsystem para sa pagbuo ng code ng modelo batay sa meta-model ay makabuluhang nagpapataas ng bilis ng pag-develop at binabawasan ang bilang ng mga error. Naglalaman din ang EMF ng mga mekanismo para sa pagse-serialize ng mga modelo, pagsubaybay sa mga pagbabago sa modelo, at marami pang iba.
Tulad ng anumang tool na talagang pangkalahatang layunin, ang EMF ay angkop para sa paglutas ng malawak na hanay ng mga problema sa pagmomodelo, ngunit ang ilang mga klase ng mga modelo (halimbawa, ang mga modelong nakabatay sa hawakan na tinalakay sa itaas) ay maaaring mangailangan ng mas espesyal na mga tool sa pagmomodelo. Ang pakikipag-usap tungkol sa EMF ay isang walang pasasalamat na gawain, lalo na sa loob ng limitadong mga limitasyon ng isang artikulo, dahil ito ang paksa ng isang hiwalay na libro, at isang medyo makapal. Tandaan lamang natin na ang mataas na kalidad na sistema ng mga generalization na pinagbabatayan ng EMF ay nagpapahintulot sa pagsilang ng isang buong hanay ng mga proyekto na nakatuon sa pagmomolde, na kasama sa pinakamataas na antas ng proyekto. kasama ang EMF mismo. Ang isang ganoong proyekto ay ang Eclipse Xtext.
nagbibigay ng imprastraktura ng "pagmomodelo ng teksto". Ginagamit ng Xtext para sa pag-parse ng source text at EMF para sa pagrepresenta sa nagreresultang ASG (abstract semantic graph, na mahalagang kumbinasyon ng AST at bindings), na tinatawag ding "semantic model". Ang gramatika ng wikang itinulad ng Xtext ay inilarawan sa sariling wika ng Xtext. Binibigyang-daan ka nito hindi lamang na bumuo ng isang paglalarawan ng gramatika para sa ANTLR, kundi pati na rin upang makakuha ng isang mekanismo ng serialization ng AST (ibig sabihin, ang Xtext ay nagbibigay ng parehong parser at isang unparser), isang pahiwatig sa konteksto, at ilang iba pang bahagi ng wika. Sa kabilang banda, ang wikang grammar na ginagamit sa Xtext ay hindi gaanong nababaluktot kaysa, halimbawa, ang wikang grammar na ginagamit sa ANTLR. Samakatuwid, kung minsan ay kinakailangan na "ibaluktot" ang ipinatupad na wika sa Xtext, na karaniwang hindi isang problema kung pinag-uusapan natin ang tungkol sa isang wika na binuo mula sa simula, ngunit maaaring hindi katanggap-tanggap para sa mga wikang may naitatag na syntax. Sa kabila nito, ang Xtext ay kasalukuyang pinaka-mature, mayaman sa feature, at versatile na tool sa Eclipse para sa pagbuo ng mga programming language at development tool para sa kanila. Sa partikular, ito ay isang perpektong tool para sa mabilis na prototyping (wika na tukoy sa domain, DSL). Bilang karagdagan sa nabanggit na "ubod ng wika" batay sa ANTLR at EMF, ang Xtext ay nagbibigay ng maraming kapaki-pakinabang na mas mataas na antas ng mga bahagi, kabilang ang mga mekanismo ng pag-index, incremental na konstruksyon, isang "matalinong editor", at marami, marami pang iba, ngunit iniiwan ang hawakan- batay sa mga modelo ng wika. Tulad ng EMF, ang Xtext ay isang paksa na karapat-dapat sa isang hiwalay na aklat, at halos hindi natin maikli ang pag-uusap tungkol sa lahat ng mga kakayahan nito sa ngayon.
1C:Enterprise Development Tools ay aktibong gumagamit ng EMF mismo at ng ilang iba pang proyekto sa Eclipse Modeling. Sa partikular, ang Xtext ay isa sa mga pundasyon ng mga tool sa pag-unlad para sa naturang 1C:Enterprise na mga wika bilang ang built-in na programming language at query language. Ang isa pang batayan para sa mga tool sa pagpapaunlad na ito ay ang proyektong Eclipse Handly, na tatalakayin natin nang mas detalyado (sa mga bahaging nakalista sa Eclipse, ito pa rin ang hindi gaanong kilala).
, isang subproject ng top-level na proyekto ng Eclipse Technology, ay lumitaw bilang resulta ng isang paunang kontribusyon sa code sa Eclipse Foundation na ginawa ng 1C noong 2014. Simula noon, patuloy na sinusuportahan ng 1C ang pagbuo ng proyekto: Ang mga handly committers ay mga empleyado ng kumpanya. Ang proyekto ay maliit, ngunit ito ay sumasakop sa isang medyo kakaibang angkop na lugar sa Eclipse: ang pangunahing layunin nito ay upang suportahan ang pagbuo ng mga modelong nakabatay sa hawakan.
Ang mga pangunahing prinsipyo sa arkitektura ng mga modelong nakabatay sa hawakan, tulad ng handle/body idiom, ay tinalakay sa itaas gamit ang modelo ng mapagkukunan at ang modelo ng Java bilang mga halimbawa. Nabanggit din nito na ang parehong modelo ng mapagkukunan at ang modelo ng Java ay mahalagang pundasyon para sa Eclipse Java development tools (JDT). At dahil halos lahat ng *DT Eclipse projects ay may arkitektura na katulad ng JDT, hindi isang malaking pagmamalabis na sabihin na ang mga modelong nakabatay sa hawakan ay sumasailalim sa marami, kung hindi lahat ng IDE na binuo sa ibabaw ng Eclipse Platform. Halimbawa, ang Eclipse C/C++ Development Tooling (CDT) ay may modelong C/C++ na nakabatay sa hawakan na gumaganap ng parehong papel sa arkitektura ng CDT gaya ng ginagawa ng modelong Java sa JDT.
Bago ang Handly, hindi nag-aalok ang Eclipse ng mga espesyal na aklatan para sa pagbuo ng mga modelo ng wika na nakabatay sa hawakan. Ang mga modelong kasalukuyang umiiral ay pangunahing nilikha sa pamamagitan ng direktang pag-angkop sa Java model code (aka copy/paste), sa mga kaso kung saan pinapayagan nito Eclipse Public License (EPL). (Malinaw, ito ay karaniwang hindi isang legal na isyu para sa, halimbawa, ang Eclipse na mga proyekto mismo, ngunit hindi para sa mga closed source na produkto.) Bilang karagdagan sa taglay nitong pagiging haphazardness, ang diskarteng ito ay nagpapakilala ng mga kilalang problema: ang pagdoble ng code na ipinakilala ng kapag nag-aangkop sa mga error, atbp. Ang mas masahol pa ay ang mga resultang modelo ay nananatiling "mga bagay sa kanilang sarili" at hindi sinasamantala ang potensyal para sa pag-iisa. Ngunit ang paghihiwalay ng mga karaniwang konsepto at protocol para sa mga modelo ng wika na nakabatay sa hawakan ay maaaring humantong sa paglikha ng mga magagamit muli na bahagi para sa pagtatrabaho sa kanila, katulad ng nangyari sa kaso ng EMF.
Hindi sa hindi naunawaan ng Eclipse ang mga isyung ito. Bumalik noong 2005 , pagbubuod ng karanasan sa pagbuo ng prototype ng CDT, ang pangangailangang lumikha ng isang karaniwang imprastraktura para sa mga modelo ng wika, kabilang ang mga modelong nakabatay sa hawakan. Ngunit, tulad ng madalas na nangyayari, dahil sa mas mataas na priyoridad na mga gawain, ang pagpapatupad ng mga ideyang ito ay hindi kailanman nakuha. Samantala, ang factorization ng *DT code ay isa pa rin sa mga hindi nabuong paksa sa Eclipse.
Sa isang tiyak na kahulugan, ang proyektong Handly ay idinisenyo upang lutasin ang humigit-kumulang kaparehong mga problema gaya ng EMF, ngunit para sa mga modelong nakabatay sa hawakan, at pangunahin sa mga wika (i.e., kumakatawan sa mga elemento ng istruktura ng ilang programming language). Ang mga pangunahing layunin na itinakda kapag nagdidisenyo ng Handly ay nakalista sa ibaba:
- Pagkilala sa mga pangunahing abstraction ng lugar ng paksa.
- Pagbabawas ng pagsisikap at pagpapahusay sa kalidad ng pagpapatupad ng mga modelo ng wikang nakabatay sa hawakan sa pamamagitan ng muling paggamit ng code.
- Ang pagbibigay ng pinag-isang meta-level na API sa mga resultang modelo, na ginagawang posible na lumikha ng mga karaniwang bahagi ng IDE na gumagana sa mga modelong nakabatay sa hawakan ng wika.
- Flexibility at scalability.
- Pagsasama sa Xtext (sa isang hiwalay na layer).
Upang i-highlight ang mga karaniwang konsepto at protocol, sinuri ang mga umiiral na pagpapatupad ng mga modelong nakabatay sa hawakan ng wika. Ang mga pangunahing interface at pangunahing pagpapatupad na ibinigay ng Handly ay ipinapakita sa Fig. 8.
kanin. 8. Mga karaniwang interface at pangunahing pagpapatupad ng mga elemento ng Handly
Ang interface ng IElement ay kumakatawan sa hawakan ng isang elemento at karaniwan sa mga elemento ng lahat ng Handly-based na mga modelo. Ang abstract class Element ay nagpapatupad ng generalised handle/body mechanism (Fig. 9).
kanin. 9. IElement at generic na handle/body na pagpapatupad
Bilang karagdagan, ang Handly ay nagbibigay ng isang pangkalahatang mekanismo para sa pag-abiso tungkol sa mga pagbabago sa mga elemento ng modelo (Larawan 10). Gaya ng nakikita mo, ito ay malawak na katulad sa mga mekanismo ng abiso na ipinatupad sa modelo ng mapagkukunan at modelo ng Java, at gumagamit ng IElementDelta upang magbigay ng pinag-isang representasyon ng impormasyon sa pagbabago ng elemento.
kanin. 10. Mga pangkalahatang interface at pangunahing pagpapatupad ng mekanismo ng Handly notification
Ang bahaging Handly na tinalakay sa itaas (Larawan 9 at 10) ay maaaring gamitin upang kumatawan sa halos anumang mga modelong nakabatay sa hawakan. Para sa paglikha linguistic mga modelo, nag-aalok ang proyekto ng karagdagang pag-andar - sa partikular, mga karaniwang interface at pangunahing pagpapatupad para sa mga elemento ng istraktura ng pinagmulang teksto, ang tinatawag na mga elemento ng pinagmulan (Larawan 8). Ang interface ng ISourceFile ay kumakatawan sa isang source file, at ISourceConstruct ay kumakatawan sa isang elemento sa loob ng source file. Ang mga abstract na klase na SourceFile at SourceConstruct ay nagpapatupad ng mga pangkalahatang mekanismo upang suportahan ang pagtatrabaho kasama ang mga source file at ang kanilang mga elemento, halimbawa, ang pagtatrabaho sa mga buffer ng teksto, pag-binding sa mga coordinate ng isang elemento sa source na teksto, pag-reconcile ng mga modelo sa kasalukuyang nilalaman ng isang gumaganang copy buffer , atbp. Ang pagpapatupad ng mga mekanismong ito ay karaniwang isang hamon, at ang Handly ay maaaring makabuluhang bawasan ang pagsusumikap sa pagbuo ng mga modelo ng wika na nakabatay sa hawakan sa pamamagitan ng pagbibigay ng mataas na kalidad na mga base na pagpapatupad.
Bilang karagdagan sa mga pangunahing mekanismo na nakalista sa itaas, ang Handly ay nagbibigay ng isang imprastraktura para sa mga buffer ng teksto at mga snapshot, suporta para sa pagsasama sa mga editor ng source code (kabilang ang out-of-the-box na pagsasama sa Xtext editor), pati na rin ang ilang karaniwang mga bahagi ng UI na makipagtulungan sa mga editor ng source code. Mga mahuhusay na modelo tulad ng outline framework. Upang ilarawan ang mga kakayahan nito, ang proyekto ay nagbibigay ng ilang mga halimbawa, kabilang ang isang pagpapatupad ng modelo ng Java sa Handly. (Kung ikukumpara sa buong pagpapatupad ng modelo ng Java sa JDT, ang modelong ito ay sadyang medyo pinasimple para sa higit na kalinawan.)
Gaya ng nabanggit kanina, ang pangunahing pokus sa paunang disenyo ng Handly at kasunod na pag-unlad ay at patuloy na nasa scalability at flexibility.
Sa prinsipyo, ang mga modelong nakabatay sa hawakan ay nagsusukat nang maayos "ayon sa disenyo". Halimbawa, binibigyang-daan ka ng handle/body idiom na limitahan ang dami ng memory na natupok ng isang modelo. Ngunit mayroon ding mga nuances. Kaya, kapag sinubukan ang Handly para sa scalability, natuklasan ang isang problema sa pagpapatupad ng mekanismo ng abiso - kapag ang isang malaking bilang ng mga elemento ay nabago, ang pagtatayo ng mga delta ay tumagal ng masyadong maraming oras. Ito ay lumabas na ang parehong problema ay naroroon sa modelo ng JDT Java, kung saan ang kaukulang code ay minsang inangkop. Inayos namin ang bug sa Handly at naghanda ng katulad na patch para sa JDT, na buong pasasalamat na natanggap. Ito ay isa lamang halimbawa kung saan ang pagpapakilala ng Handly sa mga kasalukuyang pagpapatupad ng modelo ay maaaring maging potensyal na kapaki-pakinabang, dahil sa kasong ito ay maaaring maayos ang naturang bug sa isang lugar lamang.
Upang gawing teknikal na magagawa ang pagpapatupad ng Handly sa kasalukuyang mga pagpapatupad ng modelo, ang library ay dapat magkaroon ng makabuluhang flexibility. Ang pangunahing problema ay upang mapanatili ang pabalik na pagkakatugma sa buong modelo ng API. Ang problemang ito ay nalutas sa sa pamamagitan ng malinaw na paghihiwalay sa API na partikular sa modelo, na tinukoy at ganap na kinokontrol ng developer, mula sa pinag-isang meta-level na API na ibinigay ng library. Hindi lang nito ginagawang teknikal na posible na ipatupad ang Handly sa mga kasalukuyang pagpapatupad, ngunit binibigyan din nito ang bagong modelo ng developer ng makabuluhang kalayaan kapag nagdidisenyo ng API.
Ang kakayahang umangkop ay may iba pang mga aspeto. Halimbawa, halos walang mga paghihigpit ang ipinapataw ng Handly sa istruktura ng modelo at maaaring gamitin para imodelo ang parehong pangkalahatang layunin at mga wikang partikular sa domain. Kapag nagtatayo ng istraktura ng source file, ang Handly ay hindi nagrereseta ng anumang partikular na anyo ng representasyon ng AST at, sa prinsipyo, ay hindi nangangailangan ng pagkakaroon ng isang AST mismo, kaya tinitiyak ang pagiging tugma sa halos anumang mekanismo ng pag-parse. Sa wakas, sinusuportahan ng Handly ang buong integration sa Eclipse workspace, ngunit maaari ring gumana nang direkta sa mga file system salamat sa pagsasama nito sa (EFS).
Kasalukuyang bersyon lumabas noong December 2016. Sa kabila ng katotohanan na ang proyekto ay kasalukuyang nasa isang estado ng pagpapapisa ng itlog at ang API ay hindi pa naaayos sa wakas, ang Handly ay ginagamit na sa dalawang malalaking komersyal na produkto na kinuha ang panganib na kumilos bilang "mga maagang nag-aampon", at, dapat kong sabihin, huwag mo pang pagsisihan.
Tulad ng nabanggit sa itaas, ang isa sa mga produktong ito ay 1C:Enterprise Development Tools, kung saan ang Handly ay ginagamit mula pa sa simula upang magmodelo ng mga elemento ng mataas na antas na istraktura ng naturang 1C:Enterprise na wika bilang ang built-in na programming language at query language. . Ang isa pang produkto ay hindi gaanong kilala sa pangkalahatang publiko. Ito , isang pinagsama-samang kapaligiran sa disenyo para sa application-specific instruction-set processor (ASIP), na ginagamit sa loob mismo ng kumpanyang Czech na Codasip at ng mga kliyente nito, kasama ang , , , . Ginagamit ng Codasip ang Handly sa produksyon mula noong 2015, simula sa bersyong Handly 0.2. Ang pinakabagong release ng Codasip Studio ay gumagamit ng bersyon 0.5, na inilabas noong Hunyo 2016. Si OndΕej IlΔΓk, na namumuno sa pagbuo ng IDE sa Codasip, ay nakikipag-ugnayan sa proyekto, na nagbibigay ng mahalagang feedback sa ngalan ng "third party adopter". Nakahanap pa siya ng ilang libreng oras para direktang lumahok sa pagbuo ng proyekto, na nagpapatupad ng UI layer (~4000 linya ng code) para sa isa sa mga Handly na halimbawa, isang modelo ng Java. Ang mas detalyadong unang-kamay na impormasyon tungkol sa paggamit ng Handly ng mga adopter ay matatagpuan sa pahina proyekto.
Umaasa kami na pagkatapos ng paglabas ng bersyon 1.0 na may garantiya ng katatagan ng API at ang proyektong umaalis sa incubation state, magkakaroon ng mga bagong adopter si Handly. Pansamantala, patuloy na sinusubok at pinapahusay pa ng proyekto ang API, na naglalabas ng dalawang "pangunahing" release bawat taon - sa Hunyo (kaparehong petsa ng sabay-sabay na release ng Eclipse) at Disyembre, na nagbibigay ng predictable na iskedyul na maaasahan ng mga adopter. Maaari rin naming idagdag na ang "bug rate" ng proyekto ay nananatili sa isang patuloy na mababang antas at ang Handly ay gumagana nang mapagkakatiwalaan sa mga produkto ng mga naunang nag-adopt mula pa noong unang mga bersyon. Upang higit pang galugarin ang Eclipse Handly, maaari mong gamitin ΠΈ .
Pinagmulan: www.habr.com