Marahil
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.
Panimula sa Eclipse Architecture
Tingnan muna natin ang ilang pangkalahatang aspeto ng arkitektura ng Eclipse gamit ang halimbawa
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
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:
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.
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.
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).
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
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
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
Kasalukuyang bersyon
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
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