Verjetno že zdavnaj ni bilo treba posebej predstavljati. Veliko ljudi pozna Eclipse zaradi razvojnih orodij Eclipse Java (). To priljubljeno odprtokodno Java IDE večina razvijalcev povezuje z besedo "Eclipse". Vendar pa je Eclipse hkrati razširljiva platforma za integracijo razvojnih orodij (platforma Eclipse) in številni IDE-ji, zgrajeni na njeni podlagi, vključno z JDT. Eclipse je tako projekt Eclipse, projekt na najvišji ravni, ki usklajuje razvoj platforme Eclipse in JDT, kot Eclipse SDK, ki je rezultat tega razvoja. Končno je Eclipse odprtokodna fundacija z ogromno skupnostjo projektov, od katerih niso vsi napisani v Javi ali povezani z razvojnimi orodji (na primer projekti и ). Svet Eclipse je zelo raznolik.
V tem članku, ki je po naravi pregleden, bomo poskušali pogledati nekaj osnov arhitekture Eclipse kot platforme za gradnjo integriranih razvojnih orodij in dati začetno predstavo o komponentah Eclipse, ki tvorijo temelje tehnologije. platforma za "novi konfigurator" 1C: Enterprise. . Seveda bo takšen pregled neizogibno v veliki meri površen in precej omejen, tudi zato, ker se ne osredotočamo le na razvijalce Eclipse kot ciljno publiko. Vendar upamo, da bodo tudi izkušeni razvijalci Eclipse lahko našli zanimive informacije v članku. Na primer, govorili bomo o eni od "skrivnosti Eclipse", relativno novem in malo znanem projektu , ki ga je ustanovilo in podpira 1C.
Uvod v arhitekturo Eclipse
Najprej si na primeru oglejmo nekaj splošnih vidikov arhitekture Eclipse (JDT). Izbira JDT kot primera ni naključna. To je prvo integrirano razvojno okolje, ki se pojavi v Eclipsu. Drugi projekti *DT Eclipse, kot je Eclipse C/C++ Development Tooling (CDT), so bili ustvarjeni pozneje in so si iz JDT izposodili osnovna arhitekturna načela in posamezne fragmente izvorne kode. Osnove arhitekture, določene v JDT, so še danes pomembne za skoraj vse IDE, zgrajene na platformi Eclipse, vključno z 1C:Enterprise Development Tools.
Najprej je treba opozoriti, da je za Eclipse značilno dokaj jasno arhitekturno razslojevanje, z ločevanjem od jezika neodvisne funkcionalnosti od funkcionalnosti, zasnovane za podporo specifičnim programskim jezikom, in ločevanjem od uporabniškega vmesnika neodvisnih "jedrnih" komponent od povezanih komponent. s podpornim uporabniškim vmesnikom.
Tako platforma Eclipse definira skupno, jezikovno neodvisno infrastrukturo, razvojna orodja Java pa Eclipseu dodajajo Java IDE s polnimi funkcijami. Platforma Eclipse in JDT sta sestavljena iz več komponent, od katerih vsaka pripada bodisi od uporabniškega vmesnika neodvisnemu »jedru« bodisi sloju uporabniškega vmesnika (slika 1).
riž. 1. Platforma Eclipse in JDT
Naštejmo glavne komponente platforme Eclipse:
- Čas izvajanja — Določa infrastrukturo vtičnikov. Za Eclipse je značilna modularna arhitektura. V bistvu je Eclipse zbirka "razširitvenih točk" in "razširitev".
- Delovni prostor — Vodi enega ali več projektov. Projekt je sestavljen iz map in datotek, ki so preslikane neposredno v datotečni sistem.
- Standardni komplet orodij za pripomočke (SWT) - Zagotavlja osnovne elemente uporabniškega vmesnika, integrirane z operacijskim sistemom.
- JFace — Zagotavlja številna ogrodja uporabniškega vmesnika, zgrajena na vrhu SWT.
- Delovno okolje — Definira paradigmo uporabniškega vmesnika Eclipse: urejevalniki, pogledi, perspektive.
Povedati je treba, da platforma Eclipse ponuja tudi številne druge uporabne komponente za gradnjo integriranih razvojnih orodij, vključno z Debug, Compare, Search in Team. Posebej je treba omeniti JFace Text - osnovo za gradnjo "pametnih urejevalnikov" izvorne kode. Na žalost tudi bežen pregled teh komponent, kot tudi komponent plasti uporabniškega vmesnika, ni mogoč v okviru tega članka, zato se bomo v nadaljevanju tega razdelka omejili na pregled glavnih "jedrnih" komponent platformo Eclipse in JDT.
Core Runtime
Infrastruktura vtičnika Eclipse temelji na in predvidena s projektom . Vsak vtičnik Eclipse je paket OSGi. Specifikacija OSGi opredeljuje zlasti mehanizme za urejanje različic in razreševanje odvisnosti. Poleg teh standardnih mehanizmov Equinox uvaja koncept razširitvene točke. Vsak vtičnik lahko definira lastne razširitvene točke in tudi uvede dodatno funkcionalnost (»razširitve«) v sistem z uporabo razširitvenih točk, ki jih definirajo isti ali drugi vtičniki. Vsak podroben opis mehanizmov OSGi in Equinox presega obseg tega članka. Omenimo le, da je modularizacija v Eclipsu popolna (vsak podsistem, vključno z Runtimeom, je sestavljen iz enega ali več vtičnikov), skoraj vse v Eclipsu pa je razširitev. Poleg tega so bili ti principi vgrajeni v arhitekturo Eclipse že dolgo pred uvedbo OSGi (takrat so uporabljali lastno tehnologijo, precej podobno OSGi).
Osnovni delovni prostor
Skoraj vsako integrirano razvojno okolje, zgrajeno na platformi Eclipse, deluje z delovnim prostorom Eclipse. To je delovni prostor, ki običajno vsebuje izvorno kodo aplikacije, razvite v IDE. Delovni prostor se preslika neposredno v datotečni sistem in je sestavljen iz projektov, ki vsebujejo mape in datoteke. Ti projekti, mape in datoteke se imenujejo virov delovni prostor. Implementacija delovnega prostora v Eclipsu služi kot predpomnilnik glede na datotečni sistem, kar omogoča znatno pospešitev prehoda drevesa virov. Poleg tega delovni prostor ponuja številne dodatne storitve, vključno z и .
Komponenta Core Resources (org.eclipse.core.resources plugin) je odgovorna za podporo delovnega prostora in njegovih virov. Zlasti ta komponenta zagotavlja programski dostop do delovnega prostora v obrazcu modeli virov. Za učinkovito delo s tem modelom potrebujejo stranke preprost način za predstavitev povezave do vira. V tem primeru bi bilo zaželeno skriti objekt, ki neposredno shranjuje stanje vira v modelu, pred dostopom odjemalca. V nasprotnem primeru bi lahko odjemalec v primeru, na primer izbrisa datoteke, še naprej zadrževal objekt, ki ga ni več v modelu, s posledičnimi težavami. Eclipse rešuje ta problem z uporabo nečesa, kar se imenuje ročaj vir. Handle deluje kot ključ (pozna le pot do vira v delovnem prostoru) in popolnoma nadzoruje dostop do notranjega objekta modela, ki neposredno shranjuje informacije o stanju vira. Ta oblika je različica vzorca .
riž. Slika 2 ponazarja idiom ročaj/telo, uporabljen za model vira. Vmesnik IResource predstavlja ročaj vira in je API, za razliko od razreda Resource, ki implementira ta vmesnik, in razreda ResourceInfo, ki predstavlja telo, ki nista API-ja. Poudarjamo, da ročaj pozna le pot do vira glede na koren delovnega prostora in ne vsebuje povezave do informacij o viru. Informacijski objekti virov tvorijo tako imenovano "drevo elementov". Ta podatkovna struktura je popolnoma materializirana v pomnilniku. Za iskanje primerka informacij o viru, ki ustreza ročaju, se drevo elementov prečka v skladu s potjo, shranjeno v tem ročaju.
riž. 2. IResource in ResourceInfo
Kot bomo videli pozneje, se osnovna zasnova modela virov (lahko bi jo imenovali ročaj) uporablja v Eclipsu tudi za druge modele. Za zdaj naštejmo nekaj značilnih lastnosti tega dizajna:
- Ročaj je predmet vrednosti. Vrednostni objekti so nespremenljivi objekti, katerih enakost ne temelji na identiteti. Takšne predmete je mogoče varno uporabiti kot ključ v zgoščenih vsebnikih. Več primerkov ročice se lahko sklicuje na isti vir. Če jih želite primerjati, morate uporabiti metodo equals(Object).
- Ročaj določa obnašanje vira, vendar ne vsebuje informacij o stanju vira (edini podatek, ki ga hrani, je "ključ", pot do vira).
- Ročaj se lahko nanaša na vir, ki ne obstaja (bodisi vir, ki še ni bil ustvarjen, ali vir, ki je že izbrisan). Obstoj vira je mogoče preveriti z metodo IResource.exists().
- Nekatere operacije je mogoče izvesti izključno na podlagi informacij, shranjenih v samem ročaju (tako imenovane operacije samo z ročaji). Primeri so IResource.getParent(), getFullPath() itd. Ni treba, da vir obstaja, da bi taka operacija uspela. Operacije, ki za uspeh zahtevajo obstoj vira, vržejo CoreException, če vir ne obstaja.
Eclipse zagotavlja učinkovit mehanizem za obveščanje o spremembah virov delovnega prostora (slika 3). Viri se lahko spremenijo zaradi dejanj, izvedenih v samem Eclipse IDE, ali zaradi sinhronizacije z datotečnim sistemom. V obeh primerih so naročniki, ki so naročeni na obvestila, deležni podrobnih informacij o spremembah v obliki »delte virov«. Delta opisuje spremembe med dvema stanjema (pod)drevesa virov delovnega prostora in je samo drevo, katerega vsako vozlišče opisuje spremembo vira in vsebuje seznam delt na naslednji ravni, ki opisujejo spremembe podrejenih virov.
riž. 3. IResourceChangeEvent in IResourceDelta
Mehanizem obveščanja, ki temelji na deltah virov, ima naslednje značilnosti:
- Ena sama sprememba in številne spremembe so opisane z isto strukturo, saj je delta zgrajena po principu rekurzivne sestave. Naročniški odjemalci lahko obdelajo obvestila o spremembah virov z uporabo rekurzivnega spuščanja skozi drevo delt.
- Delta vsebuje popolne informacije o spremembah vira, vključno z njegovim gibanjem in/ali spremembami v »markerjih«, povezanih z njim (na primer, napake pri prevajanju so predstavljene kot markerji).
- Ker se sklicevanja na vir izvajajo prek ročaja, se lahko delta seveda sklicuje na oddaljeni vir.
Kot bomo kmalu videli, so glavne komponente zasnove mehanizma obveščanja o spremembi modela virov pomembne tudi za druge modele, ki temeljijo na ročajih.
Jedro JDT
Model virov delovnega prostora Eclipse je temeljni jezikovno neodvisen model. Komponenta JDT Core (plugin org.eclipse.jdt.core) zagotavlja API za navigacijo in analizo strukture delovnega prostora z vidika Jave, tako imenovani "model Java" (Java model). Ta API je definiran glede na elemente Java, v nasprotju z osnovnim API-jem modela virov, ki je definiran glede na mape in datoteke. Glavni vmesniki drevesa elementov Java so prikazani na sl. 4.
riž. 4. Elementi modela Java
Model Java uporablja isti idiom ročaj/telo kot model virov (slika 5). IJavaElement je ročaj, JavaElementInfo pa igra vlogo telesa. Vmesnik IJavaElement definira protokol, ki je skupen vsem elementom Java. Nekatere njegove metode so samo za ročaj: getElementName(), getParent() itd. Objekt JavaElementInfo shrani stanje ustreznega elementa: njegovo strukturo in atribute.
riž. 5. IJavaElement in JavaElementInfo
Model Java ima nekaj razlik v izvedbi osnovne zasnove ročaja/ohišja v primerjavi z modelom virov. Kot je navedeno zgoraj, je v modelu virov drevo elementov, katerega vozlišča so informacijski objekti virov, v celoti v pomnilniku. Toda model Java ima lahko bistveno večje število elementov kot drevo virov, ker predstavlja tudi notranjo strukturo datotek .java in .class: vrste, polja in metode.
Da bi se izognili popolni materializaciji celotnega drevesa elementov v pomnilniku, implementacija modela Java uporablja predpomnilnik LRU z omejeno velikostjo informacij o elementih, kjer je ključ ročaj IJavaElement. objekti z informacijami o elementih so ustvarjeni na zahtevo med krmarjenjem po drevesu elementov. V tem primeru so najmanj pogosto uporabljeni elementi izločeni iz predpomnilnika, poraba pomnilnika modela pa ostane omejena na določeno velikost predpomnilnika. To je še ena prednost zasnove na podlagi ročajev, ki takšne podrobnosti izvedbe popolnoma skrije pred kodo odjemalca.
Mehanizem za obveščanje o spremembah elementov Java je na splošno podoben mehanizmu za sledenje spremembam virov delovnega prostora, o katerem smo govorili zgoraj. Odjemalec, ki želi spremljati spremembe v modelu Java, se naroči na obvestila, ki so predstavljena kot objekt ElementChangedEvent, ki vsebuje IJavaElementDelta (slika 6).
riž. 6. ElementChangedEvent in IJavaElementDelta
Model Java ne vsebuje informacij o telesih metod ali razrešitvi imen, zato za podrobno analizo kode, napisane v Javi, JDT Core ponuja dodaten model (ki ne temelji na ročaju): (drevo abstraktne sintakse, AST). AST predstavlja rezultat razčlenjevanja izvornega besedila. Vozlišča AST ustrezajo elementom strukture izvornega modula (deklaracije, operaterji, izrazi itd.) in vsebujejo informacije o koordinatah ustreznega elementa v izvornem besedilu ter (kot možnost) informacije o razrešitvi imen v oblika povezav na t.i vezi. Veze so predmeti, ki predstavljajo imenovane entitete, kot so tipi, metode in spremenljivke, ki jih pozna prevajalnik. Za razliko od vozlišč AST, ki tvorijo drevo, vezave podpirajo navzkrižno sklicevanje in na splošno tvorijo graf. Abstraktni razred ASTNode je skupni osnovni razred za vsa vozlišča AST. Podrazredi ASTNode ustrezajo posebnim sintaktičnim konstruktom jezika Java.
Ker lahko sintaksna drevesa porabijo veliko količino pomnilnika, JDT predpomni samo en AST za aktivni urejevalnik. Za razliko od modela Java se na AST običajno gleda kot na "vmesni", "začasni" model, katerega člani se odjemalci ne bi smeli sklicevati zunaj konteksta operacije, ki je vodila do ustvarjanja AST.
Našteti trije modeli (model Java, AST, vezave) skupaj tvorijo osnovo za gradnjo »inteligentnih razvojnih orodij« v JDT, vključno z zmogljivim urejevalnikom Java z različnimi »pomočniki«, različnimi dejanji za obdelavo izvorne kode (vključno z organizacijo seznama uvoznih imena in oblikovanje v skladu s prilagojenim slogom), orodja za iskanje in refaktoriranje. V tem primeru ima model Java posebno vlogo, saj se prav on uporablja kot osnova za vizualno predstavitev strukture aplikacije, ki se razvija (na primer v Package Explorerju, Outlineu, Searchu, Call Hierarchyju in Hierarhija tipov).
Komponente Eclipse, ki se uporabljajo v 1C:Enterprise Developments Tools
Na sl. Slika 7 prikazuje komponente Eclipse, ki tvorijo temelje tehnološke platforme za 1C:Enterprise Development Tools.
riž. 7. Eclipse kot platforma za razvojna orodja 1C:Enterprise
Platforma Eclipse zagotavlja osnovno infrastrukturo. V prejšnjem razdelku smo si ogledali nekatere vidike te infrastrukture.
(EMF) zagotavlja splošno sredstvo za modeliranje strukturiranih podatkov. EMF je integriran s platformo Eclipse, vendar se lahko uporablja tudi ločeno v običajnih aplikacijah Java. Novi razvijalci Eclipse so pogosto že dobro seznanjeni z EMF, čeprav še ne razumejo popolnoma zapletenosti platforme Eclipse. Eden od razlogov za tako zasluženo priljubljenost je univerzalna zasnova, ki med drugim vključuje enoten API na metaravni, ki vam omogoča splošno delo s katerim koli modelom EMF. Osnovne implementacije za modelne objekte, ki jih zagotavlja EMF in podsistem za generiranje kode modela na osnovi metamodela, bistveno povečajo hitrost razvoja in zmanjšajo število napak. EMF vsebuje tudi mehanizme za serializacijo modelov, sledenje spremembam modela in še veliko več.
Kot vsako resnično splošno orodje je tudi EMF primerno za reševanje širokega nabora problemov modeliranja, vendar nekateri razredi modelov (na primer zgoraj obravnavani modeli na osnovi ročajev) morda zahtevajo bolj specializirana orodja za modeliranje. Govoriti o EMF je nehvaležna naloga, še posebej v omejenih okvirih enega članka, saj je to tema posebne knjige, in to precej debele. Omenimo le, da je visokokakovosten sistem posploševanja, na katerem temelji EMF, omogočil rojstvo cele vrste projektov, posvečenih modeliranju, ki so vključeni v projekt najvišje ravni. skupaj s samim EMF. Eden takih projektov je Eclipse Xtext.
zagotavlja infrastrukturo za "besedilno modeliranje". Xtext uporablja za razčlenjevanje izvornega besedila in EMF za predstavitev nastalega ASG (abstraktni semantični graf, ki je v bistvu kombinacija AST in vezav), imenovan tudi "semantični model". Slovnica jezika, ki ga modelira Xtext, je opisana v lastnem jeziku Xtext. To vam omogoča ne samo ustvarjanje slovničnega opisa za ANTLR, temveč tudi pridobivanje mehanizma za serializacijo AST (tj. Xtext nudi tako razčlenjevalnik kot razčlenjevalnik), kontekstni namig in številne druge jezikovne komponente. Po drugi strani pa je slovnični jezik, uporabljen v Xtext, manj prilagodljiv kot, recimo, slovnični jezik, uporabljen v ANTLR. Zato je včasih potrebno implementirani jezik "upogibati" v Xtext, kar običajno ni problem, če govorimo o jeziku, ki se razvija iz nič, vendar je lahko nesprejemljivo za jezike z že uveljavljeno sintakso. Kljub temu je Xtext trenutno najbolj zrelo, s funkcijami bogato in vsestransko orodje v Eclipsu za gradnjo programskih jezikov in razvojnih orodij zanje. Predvsem je idealno orodje za hitro izdelavo prototipov (domensko specifičen jezik, DSL). Poleg zgoraj omenjenega »jedra jezika«, ki temelji na ANTLR in EMF, ponuja Xtext številne uporabne komponente višje ravni, vključno z mehanizmi za indeksiranje, inkrementalno konstrukcijo, »pametnim urejevalnikom« in še veliko, veliko več, vendar izpušča ročaj- jezikovnih modelov. Tako kot EMF je tudi Xtext tema, vredna ločene knjige, o vseh njegovih zmožnostih pa skoraj ne moremo zdaj niti na kratko govoriti.
1C:Enterprise Development Tools aktivno uporablja sam EMF in številne druge projekte modeliranja Eclipse. Zlasti Xtext je eden od temeljev razvojnih orodij za takšne jezike 1C:Enterprise kot vgrajeni programski jezik in jezik poizvedb. Druga osnova za ta razvojna orodja je projekt Eclipse Handly, ki ga bomo podrobneje obravnavali (od naštetih komponent Eclipse je še vedno najmanj poznan).
, podprojekt projekta najvišje ravni Eclipse Technology, ki je nastal kot rezultat začetnega prispevka kode fundaciji Eclipse, ki ga je leta 1 prispeval 2014C. Od takrat 1C še naprej podpira razvoj projekta: Handly komiterji so zaposleni v podjetju. Projekt je majhen, vendar zavzema precej edinstveno nišo v Eclipsu: njegov glavni cilj je podpirati razvoj modelov, ki temeljijo na ročajih.
Osnovna arhitekturna načela modelov, ki temeljijo na ročajih, kot je idiom ročaj/telo, so bila obravnavana zgoraj z uporabo modela virov in modela Java kot primerov. Opozorilo je tudi, da sta tako model virov kot model Java pomembna temelja za razvojna orodja Eclipse Java (JDT). In ker imajo skoraj vsi projekti *DT Eclipse arhitekturo, ki je podobna JDT, ne bi bilo veliko pretiravanje, če bi rekli, da so modeli, ki temeljijo na ročajih, osnova mnogih, če ne vseh IDE-jev, zgrajenih na platformi Eclipse. Na primer, razvojno orodje Eclipse C/C++ (CDT) ima model C/C++, ki temelji na ročaju, ki ima v arhitekturi CDT enako vlogo kot model Java v JDT.
Pred Handlyjem Eclipse ni ponujal specializiranih knjižnic za gradnjo jezikovnih modelov, ki temeljijo na ročajih. Modeli, ki trenutno obstajajo, so bili ustvarjeni predvsem z neposredno prilagoditvijo kode modela Java (aka kopiraj/prilepi), v primerih, ko to dopušča Javna licenca Eclipse (EPL). (Očitno to običajno ni pravno vprašanje za, recimo, same projekte Eclipse, ne pa za zaprtokodne izdelke.) Poleg svoje inherentne naključnosti ta tehnika uvaja dobro znane težave: podvajanje kode, ki ga uvede pri prilagajanju napakam, itd. Še huje pa je, da nastali modeli ostajajo »stvari zase« in ne izkoriščajo možnosti poenotenja. Toda izolacija skupnih konceptov in protokolov za jezikovne modele, ki temeljijo na ročajih, bi lahko vodila do ustvarjanja komponent za večkratno uporabo za delo z njimi, podobno kot se je zgodilo v primeru EMF.
Ne gre za to, da Eclipse ne bi razumel teh vprašanj. Že leta 2005 , ki povzema izkušnje pri razvoju prototipa CDT, potrebo po ustvarjanju skupne infrastrukture za jezikovne modele, vključno z modeli, ki temeljijo na ročajih. A kot se pogosto zgodi, zaradi prioritetnih nalog do uresničitve teh zamisli nikoli ni prišlo. Medtem je faktorizacija kode *DT še vedno ena od premalo razvitih tem v Eclipsu.
V določenem smislu je projekt Handly zasnovan za reševanje približno enakih problemov kot EMF, vendar za modele, ki temeljijo na ročajih, in predvsem jezikovne (tj. Predstavljajo elemente strukture nekega programskega jezika). Spodaj so navedeni glavni cilji, zastavljeni pri oblikovanju Handlyja:
- Identifikacija glavnih abstrakcij predmetnega področja.
- Zmanjšanje napora in izboljšanje kakovosti implementacije jezikovnih modelov, ki temeljijo na ročajih, s ponovno uporabo kode.
- Zagotavljanje poenotenega API-ja na metaravni za nastale modele, kar omogoča ustvarjanje skupnih komponent IDE, ki delujejo z modeli, ki temeljijo na ročaju jezika.
- Prilagodljivost in razširljivost.
- Integracija z Xtext (v ločeni plasti).
Da bi poudarili skupne koncepte in protokole, so bile analizirane obstoječe izvedbe modelov, ki temeljijo na jezikovnem ročaju. Glavni vmesniki in osnovne izvedbe, ki jih ponuja Handly, so prikazani na sl. 8.
riž. 8. Skupni vmesniki in osnovne izvedbe elementov Handly
Vmesnik IElement predstavlja ročaj elementa in je skupen elementom vseh modelov, ki temeljijo na Handlyju. Abstraktni razred Element implementira posplošen mehanizem ročaj/telo (slika 9).
riž. 9. IElement in generična implementacija ročaja/tela
Poleg tega Handly ponuja posplošen mehanizem za obveščanje o spremembah elementov modela (slika 10). Kot lahko vidite, je na splošno podoben mehanizmom obveščanja, implementiranim v modelu virov in modelu Java, ter uporablja IElementDelta za zagotavljanje enotne predstavitve informacij o spremembi elementa.
riž. 10. Splošni vmesniki in osnovne izvedbe mehanizma obveščanja Handly
Zgoraj obravnavani del Handly (sliki 9 in 10) se lahko uporablja za predstavitev skoraj vseh modelov, ki temeljijo na ročaju. Za ustvarjanje jezikovni modelov, projekt ponuja dodatne funkcionalnosti - predvsem skupne vmesnike in osnovne izvedbe za elemente strukture izvornega besedila, t.i. izvorni elementi (slika 8). Vmesnik ISourceFile predstavlja izvorno datoteko, ISourceConstruct pa element znotraj izvorne datoteke. Abstraktna razreda SourceFile in SourceConstruct implementirata splošne mehanizme za podporo dela z izvornimi datotekami in njihovimi elementi, na primer delo z medpomnilniki besedila, vezavo na koordinate elementa v izvornem besedilu, usklajevanje modelov s trenutno vsebino medpomnilnika delovne kopije itd. Implementacija teh mehanizmov je običajno precejšen izziv in Handly lahko znatno zmanjša napor pri razvoju jezikovnih modelov, ki temeljijo na ročajih, tako da zagotovi visokokakovostne osnovne implementacije.
Poleg zgoraj naštetih osnovnih mehanizmov Handly zagotavlja infrastrukturo za besedilne medpomnilnike in posnetke, podporo za integracijo z urejevalniki izvorne kode (vključno z integracijo izven škatle z urejevalnikom Xtext), kot tudi nekatere običajne komponente uporabniškega vmesnika, ki delo z urejevalniki izvorne kode Priročni modeli, kot je oris okvira. Za ponazoritev njegovih zmogljivosti projekt ponuja več primerov, vključno z implementacijo modela Java v Handly. (V primerjavi s popolno implementacijo modela Java v JDT je ta model namenoma nekoliko poenostavljen za večjo jasnost.)
Kot smo že omenili, je bil glavni poudarek Handlyjevega začetnega načrtovanja in kasnejšega razvoja in je še vedno na razširljivosti in prilagodljivosti.
Načeloma se modeli z ročaji precej dobro prilagajajo "zasnovo". Na primer, idiom ročaj/telo vam omogoča, da omejite količino pomnilnika, ki ga porabi model. Vendar obstajajo tudi nianse. Tako je bila pri testiranju Handlyja za razširljivost odkrita težava pri implementaciji mehanizma obveščanja - ko je bilo spremenjeno veliko število elementov, je izdelava delt trajala preveč časa. Izkazalo se je, da je enaka težava prisotna v modelu JDT Java, iz katerega je bila nekoč prilagojena ustrezna koda. Odpravili smo napako v Handlyju in pripravili podoben popravek za JDT, ki je bil hvaležno sprejet. To je le en primer, kjer bi lahko bila uvedba Handlyja v obstoječe implementacije modela potencialno koristna, saj bi v tem primeru takšno napako lahko odpravili na samo enem mestu.
Da bi bila implementacija Handlyja v obstoječe implementacije modela tehnično izvedljiva, mora imeti knjižnica precejšnjo prilagodljivost. Glavna težava je ohraniti združljivost za nazaj v modelu API. Ta problem je bil rešen v z jasnim ločevanjem API-ja, specifičnega za model, ki ga definira in v celoti nadzoruje razvijalec, od enotnega API-ja na metaravni, ki ga zagotavlja knjižnica. To ne samo, da omogoča tehnično implementacijo Handlyja v obstoječe implementacije, ampak tudi daje razvijalcu novega modela veliko svobode pri oblikovanju API-ja.
Prilagodljivost ima tudi druge vidike. Na primer, Handly ne nalaga skoraj nobenih omejitev glede strukture modela in se lahko uporablja za modeliranje tako splošnih kot domensko specifičnih jezikov. Pri konstruiranju strukture izvorne datoteke Handly ne predpisuje nobene posebne oblike predstavitve AST in načeloma niti ne zahteva prisotnosti samega AST, s čimer zagotavlja združljivost s skoraj vsemi mehanizmi za razčlenjevanje. Končno, Handly podpira popolno integracijo z delovnim prostorom Eclipse, lahko pa deluje tudi neposredno z datotečnimi sistemi, zahvaljujoč integraciji z (EFS).
Trenutna verzija izšel decembra 2016. Kljub dejstvu, da je projekt trenutno v stanju inkubacije in API še ni dokončno popravljen, se Handly že uporablja v dveh velikih komercialnih izdelkih, ki sta tvegala, da delujeta kot »zgodnji uporabniki«, in, moram reči, ne obžaluj še.
Kot je navedeno zgoraj, je eden od teh izdelkov 1C:Enterprise Development Tools, kjer se Handly že od samega začetka uporablja za modeliranje elementov visokonivojske strukture takšnih jezikov 1C:Enterprise, kot sta vgrajeni programski jezik in jezik poizvedb. . Drug izdelek je širši javnosti manj znan. to , integrirano oblikovalsko okolje za aplikacijsko specifičen procesor nabora ukazov (ASIP), ki se uporablja tako v samem češkem podjetju Codasip kot pri njegovih strankah, vključno z , , , . Codasip uporablja Handly v proizvodnji od leta 2015, začenši z različico Handly 0.2. Najnovejša izdaja Codasip Studio uporablja različico 0.5, izdano junija 2016. Ondřej Ilčík, ki vodi razvoj IDE pri Codasipu, je v stiku s projektom in zagotavlja bistvene povratne informacije v imenu »tretjega uporabnika«. Uspelo mu je celo najti nekaj prostega časa za neposredno sodelovanje pri razvoju projekta, implementacijo plasti uporabniškega vmesnika (~4000 vrstic kode) za enega od primerov Handly, model Java. Podrobnejše informacije iz prve roke o uporabi Handlyja s strani posvojiteljev najdete na strani projekt.
Upamo, da bo Handly po izdaji različice 1.0 z jamstvom stabilnosti API-ja in projektu, ki bo zapustil stanje inkubacije, dobil nove uporabnike. Medtem projekt nadaljuje s preizkušanjem in nadaljnjim izboljševanjem API-ja ter izda dve "večji" izdaji na leto - junija (na isti datum kot sočasna izdaja Eclipse) in decembra, kar zagotavlja predvidljiv urnik, na katerega se lahko zanesejo uporabniki. Dodamo lahko tudi, da "stopnja napak" projekta ostaja na dosledno nizki ravni in Handly zanesljivo deluje v izdelkih prvih uporabnikov že od prvih različic. Za nadaljnje raziskovanje Eclipse Handly lahko uporabite и .
Vir: www.habr.com