Vjerojatno, odavno ne treba posebno predstavljati. Mnogi ljudi su upoznati s Eclipseom zahvaljujući Eclipse Java razvojnim alatima (). Upravo ovaj popularni Java IDE otvorenog koda većina programera povezuje s riječju "Eclipse". Međutim, Eclipse je i proširiva platforma za integriranje razvojnih alata (Eclipse Platforma) i niz IDE-ova izgrađenih na njezinoj osnovi, uključujući JDT. Eclipse je i Eclipse Project, projekt najviše razine koji koordinira razvoj Eclipse Platforme i JDT-a, i Eclipse SDK, isporučeni rezultat tog razvoja. Konačno, Eclipse je zaklada otvorenog koda s ogromnom zajednicom projekata, od kojih nisu svi napisani u Javi ili povezani s razvojnim alatima (na primjer, projekti и ). Svijet Eclipsea vrlo je raznolik.
U ovom članku, koji je po prirodi pregled, pokušat ćemo sagledati neke od osnova Eclipse arhitekture kao platforme za izgradnju integriranih razvojnih alata i dati početnu ideju o Eclipse komponentama koje čine temelj tehnologije platforma za “novi konfigurator” 1C: Enterprise. . Naravno, takva će recenzija neizbježno biti uvelike površna i prilično ograničena, uključujući i to što se ne fokusiramo samo na Eclipse programere kao ciljanu publiku. Međutim, nadamo se da će čak i iskusni Eclipse programeri moći pronaći zanimljive informacije u članku. Na primjer, govorit ćemo o jednoj od “tajni Eclipsea”, relativno novom i malo poznatom projektu , koju je osnovao i podržava 1C.
Uvod u Eclipse arhitekturu
Pogledajmo prvo neke opće aspekte Eclipse arhitekture koristeći primjer (JDT). Izbor JDT-a kao primjera nije slučajan. Ovo je prvo integrirano razvojno okruženje koje se pojavljuje u Eclipseu. Drugi *DT Eclipse projekti, kao što je Eclipse C/C++ razvojni alat (CDT), stvoreni su kasnije i posuđuju i osnovne arhitektonske principe i pojedinačne fragmente izvornog koda iz JDT-a. Osnove arhitekture postavljene u JDT-u relevantne su do danas za gotovo svaki IDE izgrađen na Eclipse platformi, uključujući 1C:Enterprise razvojne alate.
Prije svega, treba napomenuti da Eclipse karakterizira prilično jasna arhitektonska slojevitost, s odvajanjem funkcionalnosti neovisne o jeziku od funkcionalnosti osmišljene za podršku određenim programskim jezicima, te odvajanjem "jezgrenih" komponenti neovisnih o korisničkom sučelju od povezanih komponenti s pratećim korisničkim sučeljem.
Stoga Eclipse Platforma definira zajedničku infrastrukturu neovisnu o jeziku, a Java razvojni alati dodaju Java IDE s punim značajkama u Eclipse. I Eclipse Platforma i JDT sastoje se od nekoliko komponenti, od kojih svaka pripada "jezgri" neovisnoj o korisničkom sučelju ili sloju korisničkog sučelja (Slika 1).
Riža. 1. Platforma Eclipse i JDT
Nabrojimo glavne komponente Eclipse platforme:
- dužina trajanja — Definira infrastrukturu dodataka. Eclipse karakterizira modularna arhitektura. U biti, Eclipse je zbirka "točaka proširenja" i "proširenja".
- Radni prostor — Vodi jedan ili više projekata. Projekt se sastoji od mapa i datoteka koje su mapirane izravno u datotečni sustav.
- Standardni alat za widgete (SWT) - Omogućuje osnovne elemente korisničkog sučelja integrirane s operativnim sustavom.
- JFace — Pruža niz okvira korisničkog sučelja izgrađenih na SWT-u.
- Radna tezga — Definira paradigmu korisničkog sučelja Eclipse: uređivači, prikazi, perspektive.
Mora se reći da Eclipse Platforma također nudi mnoge druge korisne komponente za izgradnju integriranih razvojnih alata, uključujući Debug, Compare, Search i Team. Posebno treba spomenuti JFace Text - osnovu za izgradnju "pametnih editora" izvornog koda. Nažalost, čak ni površno ispitivanje ovih komponenti, kao i komponenti sloja korisničkog sučelja, nije moguće u okviru ovog članka, pa ćemo se u ostatku ovog odjeljka ograničiti na pregled glavnih "teznih" komponenti platformu Eclipse i JDT.
Core Runtime
Infrastruktura dodatka Eclipse temelji se na a predviđeno projektom . Svaki Eclipse dodatak je OSGi paket. OSGi specifikacija definira, posebno, mehanizme za verziju i rješavanje ovisnosti. Uz ove standardne mehanizme, Equinox uvodi koncept točke proširenja. Svaki dodatak može definirati vlastite točke proširenja, a također uvesti dodatnu funkcionalnost ("proširenja") u sustav koristeći točke proširenja definirane istim ili drugim dodacima. Svaki detaljan opis OSGi i Equinox mehanizama je izvan opsega ovog članka. Napomenimo samo da je modularizacija u Eclipsu potpuna (svaki podsustav, uključujući Runtime, sastoji se od jednog ili više dodataka), a gotovo sve u Eclipsu je ekstenzija. Štoviše, ovi su principi bili ugrađeni u Eclipse arhitekturu davno prije uvođenja OSGi-ja (tada su koristili vlastitu tehnologiju, vrlo sličnu OSGi-ju).
Osnovni radni prostor
Gotovo svako integrirano razvojno okruženje izgrađeno na Eclipse platformi radi s Eclipse radnim prostorom. To je radni prostor koji obično sadrži izvorni kod aplikacije razvijene u IDE-u. Radni prostor preslikava se izravno na datotečni sustav i sastoji se od projekata koji sadrže mape i datoteke. Ti se projekti, mape i datoteke nazivaju resursi radni prostor. Implementacija radnog prostora u Eclipseu služi kao predmemorija u odnosu na datotečni sustav, što omogućuje značajno ubrzanje obilaska stabla resursa. Osim toga, radni prostor pruža niz dodatnih usluga, uključujući и .
Komponenta Core Resources (org.eclipse.core.resources dodatak) odgovorna je za podršku radnom prostoru i njegovim resursima. Konkretno, ova komponenta omogućuje programski pristup radnom prostoru u obrascu modeli resursa. Kako bi učinkovito radili s ovim modelom, klijentima je potreban jednostavan način predstavljanja poveznice na resurs. U ovom slučaju bilo bi poželjno sakriti objekt koji izravno pohranjuje stanje resursa u modelu od klijentskog pristupa. U suprotnom, u slučaju npr. brisanja datoteke, klijent bi mogao nastaviti držati objekt koji više nije u modelu, s posljedičnim problemima. Eclipse rješava ovaj problem koristeći nešto što se zove rukovati resurs. Handle djeluje kao ključ (zna samo put do resursa u radnom prostoru) i potpuno kontrolira pristup objektu internog modela, koji izravno pohranjuje informacije o stanju resursa. Ovaj dizajn je varijacija uzorka .
Riža. Slika 2 ilustrira idiom Ručka/Tijelo primijenjen na model resursa. IResource sučelje predstavlja rukovanje resursom i API je, za razliku od Resource klase, koja implementira ovo sučelje, i ResourceInfo klase, koja predstavlja tijelo, a koji nisu API-ji. Naglašavamo da ručka zna samo put do resursa u odnosu na korijen radnog prostora i ne sadrži poveznicu na informacije o resursu. Informacijski objekti resursa tvore takozvano "stablo elemenata". Ova struktura podataka je potpuno materijalizirana u memoriji. Da bi se pronašla instanca informacija o resursu koja odgovara ručki, stablo elementa prelazi se prema putanji pohranjenoj u toj ručki.
Riža. 2. IResource i ResourceInfo
Kao što ćemo kasnije vidjeti, osnovni dizajn modela resursa (mogli bismo ga nazvati temeljen na ručki) koristi se u Eclipseu i za druge modele. Za sada nabrojimo neka od karakterističnih svojstava ovog dizajna:
- Ručka je vrijednosni objekt. Vrijednosni objekti su nepromjenjivi objekti čija se jednakost ne temelji na identitetu. Takvi se objekti mogu sigurno koristiti kao ključevi u raspršenim spremnicima. Višestruke instance handle mogu referencirati isti resurs. Za njihovu usporedbu potrebno je koristiti metodu equals(Object).
- Handle definira ponašanje resursa, ali ne sadrži informacije o stanju resursa (jedini podatak koji pohranjuje je "ključ", put do resursa).
- Ručka se može odnositi na resurs koji ne postoji (bilo resurs koji još nije stvoren ili resurs koji je već izbrisan). Postojanje resursa može se provjeriti pomoću metode IResource.exists().
- Neke se operacije mogu implementirati isključivo na temelju informacija pohranjenih u samoj ručici (tzv. operacije samo za hvatanje). Primjeri su IResource.getParent(), getFullPath() itd. Resurs ne mora postojati da bi takva operacija uspjela. Operacije koje zahtijevaju postojanje resursa da bi uspjele izbaciti CoreException ako resurs ne postoji.
Eclipse pruža učinkovit mehanizam za obavještavanje o promjenama resursa radnog prostora (Slika 3). Resursi se mogu promijeniti bilo kao rezultat radnji koje se izvode unutar samog Eclipse IDE-a ili kao rezultat sinkronizacije sa sustavom datoteka. U oba slučaja klijenti koji se pretplate na obavijesti dobivaju detaljne informacije o promjenama u obliku „delta resursa“. Delta opisuje promjene između dva stanja (pod)stabla resursa radnog prostora i sama je stablo, čiji svaki čvor opisuje promjenu resursa i sadrži popis delta na sljedećoj razini koje opisuju promjene podređenih resursa.
Riža. 3. IResourceChangeEvent i IResourceDelta
Mehanizam obavijesti temeljen na delti resursa ima sljedeće karakteristike:
- Jedna promjena i mnoge promjene opisane su istom strukturom, jer je delta izgrađena prema principu rekurzivne kompozicije. Pretplatnički klijenti mogu obraditi obavijesti o promjeni resursa korištenjem rekurzivnog spuštanja kroz stablo delta.
- Delta sadrži potpune informacije o promjenama resursa, uključujući njegovo kretanje i/ili promjene u "markerima" koji su s njim povezani (na primjer, pogreške kompilacije predstavljene su kao markeri).
- Budući da se reference resursa izrađuju kroz ručicu, delta može prirodno referencirati udaljeni resurs.
Kao što ćemo uskoro vidjeti, glavne komponente dizajna mehanizma obavijesti o promjeni modela resursa također su relevantne za druge modele koji se temelje na ručki.
Jezgra JDT
Model resursa radnog prostora Eclipse temeljni je model koji ne ovisi o jeziku. Komponenta JDT Core (plugin org.eclipse.jdt.core) pruža API za navigaciju i analizu strukture radnog prostora iz perspektive Jave, takozvani "Java model" (Java model). Ovaj API definiran je u smislu Java elemenata, za razliku od temeljnog API-ja modela resursa, koji je definiran u smislu mapa i datoteka. Glavna sučelja stabla Java elemenata prikazana su na sl. 4.
Riža. 4. Elementi Java modela
Java model koristi isti idiom ručka/tijelo kao model resursa (Slika 5). IJavaElement je ručka, a JavaElementInfo igra ulogu tijela. IJavaElement sučelje definira protokol zajednički za sve Java elemente. Neke od njegovih metoda su samo za rukovanje: getElementName(), getParent(), itd. Objekt JavaElementInfo pohranjuje stanje odgovarajućeg elementa: njegovu strukturu i atribute.
Riža. 5. IJavaElement i JavaElementInfo
Java model ima neke razlike u implementaciji osnovnog dizajna ručke/tijela u usporedbi s modelom resursa. Kao što je gore navedeno, u modelu resursa, stablo elemenata, čiji su čvorovi informacijski objekti resursa, u potpunosti je sadržano u memoriji. Ali Java model može imati znatno veći broj elemenata od stabla resursa, jer također predstavlja unutarnju strukturu .java i .class datoteka: vrste, polja i metode.
Kako bi se izbjeglo potpuno materijaliziranje cijelog stabla elemenata u memoriji, implementacija Java modela koristi LRU predmemoriju ograničene veličine informacija o elementu, gdje je ključ ručka IJavaElement. objekti s informacijama o elementima kreiraju se na zahtjev dok se krećete po stablu elemenata. U ovom slučaju, stavke koje se najmanje koriste izbacuju se iz predmemorije, a potrošnja memorije modela ostaje ograničena na navedenu veličinu predmemorije. Ovo je još jedna prednost dizajna temeljenog na ručki, koji potpuno skriva takve detalje implementacije od koda klijenta.
Mehanizam za obavještavanje o promjenama na Java elementima općenito je sličan mehanizmu za praćenje promjena na resursima radnog prostora o kojima se govorilo gore. Klijent koji želi pratiti promjene u Java modelu pretplaćuje se na obavijesti, koje su predstavljene kao ElementChangedEvent objekt koji sadrži IJavaElementDelta (Slika 6).
Riža. 6. ElementChangedEvent i IJavaElementDelta
Java model ne sadrži informacije o tijelima metoda ili rezoluciji imena, tako da za detaljnu analizu koda napisanog u Javi, JDT Core pruža dodatni model (koji se ne temelji na rukovanju): (stablo apstraktne sintakse, AST). AST predstavlja rezultat analize izvornog teksta. AST čvorovi odgovaraju elementima strukture izvornog modula (deklaracije, operatori, izrazi, itd.) i sadrže informacije o koordinatama odgovarajućeg elementa u izvornom tekstu, kao i (kao opciju) informacije o rezoluciji imena u oblik poveznica na tzv vezovi. Vezovi su objekti koji predstavljaju imenovane entitete, kao što su tipovi, metode i varijable, poznati kompajleru. Za razliku od AST čvorova, koji tvore stablo, povezivanja podržavaju unakrsno referenciranje i općenito tvore graf. Apstraktna klasa ASTNode je zajednička osnovna klasa za sve AST čvorove. Podklase ASTNode odgovaraju specifičnim sintaktičkim konstruktima jezika Java.
Budući da stabla sintakse mogu zauzeti značajnu količinu memorije, JDT sprema samo jedan AST za aktivni uređivač. Za razliku od Java modela, AST se obično promatra kao "srednji", "privremeni" model čije članove klijenti ne bi trebali spominjati izvan konteksta operacije koja je dovela do stvaranja AST-a.
Navedena tri modela (Java model, AST, povezivanja) zajedno čine osnovu za izgradnju "inteligentnih razvojnih alata" u JDT-u, uključujući moćni Java editor s raznim "pomagačima", raznim radnjama za obradu izvornog koda (uključujući organiziranje popisa uvoznih imena i oblikovanje prema prilagođenom stilu), alate za pretraživanje i refaktoriranje. U ovom slučaju Java model igra posebnu ulogu, budući da se upravo on koristi kao osnova za vizualni prikaz strukture aplikacije koja se razvija (npr. u Package Exploreru, Outlineu, Searchu, Call Hierarchy i Hijerarhija tipa).
Eclipse komponente koje se koriste u 1C:Enterprise Developments Tools
Na sl. Slika 7 prikazuje Eclipse komponente koje čine temelj tehnološke platforme za 1C:Enterprise Development Tools.
Riža. 7. Eclipse kao platforma za 1C:Enterprise Development Tools
Platforma Eclipse pruža osnovnu infrastrukturu. Pogledali smo neke aspekte ove infrastrukture u prethodnom odjeljku.
(EMF) pruža opći način modeliranja strukturiranih podataka. EMF je integriran s Eclipse platformom, ali se može koristiti i zasebno u uobičajenim Java aplikacijama. Često su novi Eclipse programeri već dobro upoznati s EMF-om, iako još ne razumiju u potpunosti zamršenost Eclipse Platforme. Jedan od razloga takve zaslužene popularnosti je univerzalni dizajn, koji uključuje, između ostalog, jedinstveni API meta-razine, koji vam omogućuje rad s bilo kojim EMF modelom na opći način. Osnovne implementacije za objekte modela koje pruža EMF i podsustav za generiranje koda modela na temelju meta-modela značajno povećavaju brzinu razvoja i smanjuju broj grešaka. EMF također sadrži mehanizme za serijalizaciju modela, praćenje promjena na modelu i još mnogo toga.
Kao i svaki istinski alat opće namjene, EMF je prikladan za rješavanje širokog spektra problema modeliranja, ali neke klase modela (na primjer, modeli koji se temelje na ručki o kojima smo raspravljali gore) mogu zahtijevati više specijaliziranih alata za modeliranje. Govoriti o EMF-u je nezahvalan posao, pogotovo u ograničenim okvirima jednog članka, budući da je to tema posebne knjige, i to prilično debele. Napomenimo samo da je visokokvalitetni sustav generalizacija na kojem se temelji EMF omogućio rađanje čitavog niza projekata posvećenih modeliranju, koji su uključeni u projekt najviše razine. zajedno sa samim EMF-om. Jedan takav projekt je Eclipse Xtext.
pruža infrastrukturu "modeliranja teksta". Xtext koristi za raščlanjivanje izvornog teksta i EMF za predstavljanje rezultirajućeg ASG-a (apstraktni semantički graf, koji je u biti kombinacija AST-a i povezivanja), koji se naziva i "semantički model". Gramatika jezika modeliranog Xtextom opisana je na vlastitom jeziku Xtexta. To vam omogućuje ne samo generiranje gramatičkog opisa za ANTLR, već i dobivanje AST mehanizma serijalizacije (tj. Xtext pruža i parser i unparser), kontekstni savjet i niz drugih jezičnih komponenti. S druge strane, gramatički jezik koji se koristi u Xtext-u manje je fleksibilan od, recimo, gramatičkog jezika koji se koristi u ANTLR-u. Stoga je ponekad potrebno implementirani jezik “saviti” u Xtext, što obično nije problem ako govorimo o jeziku koji se razvija od nule, ali može biti neprihvatljivo za jezike s već uspostavljenom sintaksom. Unatoč tome, Xtext je trenutno najzreliji, najbogatiji i najsvestraniji alat u Eclipseu za izradu programskih jezika i razvojnih alata za njih. Konkretno, idealan je alat za brzu izradu prototipova (jezik specifičan za domenu, DSL). Uz gore spomenutu "jezgru jezika" temeljenu na ANTLR i EMF, Xtext pruža mnoge korisne komponente više razine, uključujući mehanizme indeksiranja, inkrementalnu konstrukciju, "pametni uređivač" i još mnogo, mnogo više, ali izostavlja handle- temeljene na jezičnim modelima. Kao i EMF, Xtext je tema vrijedna posebne knjige, ao svim njegovim mogućnostima teško da sada možemo čak i kratko govoriti.
1C:Enterprise Development Tools aktivno koristi i sam EMF i niz drugih Eclipse Modeling projekata. Konkretno, Xtext je jedan od temelja razvojnih alata za takve jezike 1C:Enterprise kao što su ugrađeni programski jezik i jezik upita. Još jedna osnova za ove razvojne alate je projekt Eclipse Handly, o kojem ćemo detaljnije govoriti (od navedenih Eclipse komponenti, on je još uvijek najmanje poznat).
, potprojekt projekta najviše razine Eclipse Technology, nastao kao rezultat početnog doprinosa koda Eclipse Foundationu koji je dao 1C 2014. godine. Od tada, 1C nastavlja podržavati razvoj projekta: Handly komiteri su zaposlenici tvrtke. Projekt je malen, ali zauzima prilično jedinstvenu nišu u Eclipseu: njegov glavni cilj je podržati razvoj modela koji se temelje na ručki.
Osnovni arhitektonski principi modela temeljenih na ručki, kao što je idiom ručka/tijelo, raspravljeni su gore koristeći model resursa i Java model kao primjere. Također je navedeno da su i model resursa i Java model važni temelji za razvojne alate Eclipse Java (JDT). A budući da gotovo svi *DT Eclipse projekti imaju arhitekturu sličnu JDT-u, ne bi bilo veliko pretjerivanje reći da su modeli temeljeni na ručicama temelj mnogih, ako ne i svih IDE-ova izgrađenih na vrhu Eclipse Platforme. Na primjer, Eclipse C/C++ Development Tooling (CDT) ima C/C++ model baziran na ručki koji igra istu ulogu u CDT arhitekturi kao Java model u JDT-u.
Prije Handlyja, Eclipse nije nudio specijalizirane biblioteke za izgradnju jezičnih modela temeljenih na ručki. Modeli koji trenutno postoje stvoreni su uglavnom izravnom prilagodbom koda Java modela (aka copy/paste), u slučajevima kada dopušta Eclipse javna licenca (EPL). (Očito, ovo obično nije pravno pitanje za, recimo, same Eclipse projekte, ali ne i za proizvode zatvorenog koda.) Osim svoje inherentne slučajnosti, ova tehnika uvodi dobro poznate probleme: dupliciranje koda uvedeno prilikom prilagodbe pogreškama, itd. Još je gore što rezultirajući modeli ostaju “stvari za sebe” i ne iskorištavaju potencijal unifikacije. Ali izdvajanje zajedničkih koncepata i protokola za jezične modele temeljene na ručki moglo bi dovesti do stvaranja komponenti za višekratnu upotrebu za rad s njima, slično onome što se dogodilo u slučaju EMF-a.
Nije da Eclipse nije razumio te probleme. Davne 2005. godine , sažimajući iskustvo razvoja CDT prototipa, potreba za stvaranjem zajedničke infrastrukture za jezične modele, uključujući modele temeljene na ručki. No, kako to često biva, zbog prioritetnih zadataka, do realizacije ovih ideja nije došlo. U međuvremenu, faktorizacija *DT koda je još uvijek jedna od nedovoljno razvijenih tema u Eclipseu.
U određenom smislu, projekt Handly je dizajniran za rješavanje približno istih problema kao i EMF, ali za modele temeljene na handle-u, i to prvenstveno jezične (tj. koji predstavljaju elemente strukture nekog programskog jezika). Glavni ciljevi postavljeni prilikom dizajniranja Handlyja navedeni su u nastavku:
- Identifikacija glavnih apstrakcija predmetnog područja.
- Smanjenje napora i poboljšanje kvalitete implementacije jezičnih modela temeljenih na rukovanju kroz ponovnu upotrebu koda.
- Pružanje unificiranog API-ja meta-razine rezultirajućim modelima, što omogućuje stvaranje zajedničkih IDE komponenti koje rade s modelima koji se temelje na ručki jezika.
- Fleksibilnost i skalabilnost.
- Integracija s Xtextom (u posebnom sloju).
Kako bi se istaknuli zajednički koncepti i protokoli, analizirane su postojeće implementacije modela koji se temelje na jezičnoj ručki. Glavna sučelja i osnovne implementacije koje nudi Handly prikazani su na sl. 8.
Riža. 8. Uobičajena sučelja i osnovne implementacije Handly elemenata
IElement sučelje predstavlja ručku elementa i zajedničko je elementima svih modela temeljenih na Handlyju. Apstraktna klasa Element implementira generalizirani mehanizam ručka/tijelo (slika 9).
Riža. 9. IElement i generička implementacija ručke/tijela
Osim toga, Handly nudi generalizirani mehanizam za obavještavanje o promjenama u elementima modela (Sl. 10). Kao što možete vidjeti, općenito je sličan mehanizmima obavijesti implementiranim u modelu resursa i Java modelu i koristi IElementDelta za pružanje objedinjenog prikaza informacija o promjeni elementa.
Riža. 10. Opća sučelja i osnovne implementacije Handly mehanizma obavijesti
Dio Handly o kojem se govori gore (sl. 9 i 10) može se koristiti za predstavljanje gotovo svih modela koji se temelje na ručki. Za stvaranje lingvistički modelima, projekt nudi dodatnu funkcionalnost - posebice zajednička sučelja i osnovne implementacije za elemente strukture izvornog teksta, tzv. izvorni elementi (slika 8). ISourceFile sučelje predstavlja izvornu datoteku, a ISourceConstruct predstavlja element unutar izvorne datoteke. Apstraktne klase SourceFile i SourceConstruct implementiraju generalizirane mehanizme za podršku rada s izvornim datotekama i njihovim elementima, na primjer, rad s tekstualnim međuspremnicima, vezanje na koordinate elementa u izvornom tekstu, usklađivanje modela s trenutnim sadržajem međuspremnika radne kopije itd. Implementacija ovih mehanizama obično je priličan izazov, a Handly može značajno smanjiti napor u razvoju jezičnih modela temeljenih na rukovanju pružanjem visokokvalitetnih osnovnih implementacija.
Osim gore navedenih temeljnih mehanizama, Handly pruža infrastrukturu za tekstualne međuspremnike i snimke, podršku za integraciju s uređivačima izvornog koda (uključujući integraciju izvan okvira s uređivačem Xtext), kao i neke uobičajene komponente korisničkog sučelja koje rad s uređivačima izvornog koda Ručni modeli kao što je nacrt okvira. Kako bi ilustrirao svoje mogućnosti, projekt daje nekoliko primjera, uključujući implementaciju Java modela u Handlyju. (U usporedbi s potpunom implementacijom Java modela u JDT, ovaj model je namjerno donekle pojednostavljen radi veće jasnoće.)
Kao što je ranije navedeno, glavni fokus tijekom Handlyjevog početnog dizajna i kasnijeg razvoja bio je i nastavlja biti na skalabilnost i fleksibilnost.
U principu, modeli koji se temelje na ručki prilično dobro skaliraju "po dizajnu". Na primjer, idiom ručka/tijelo omogućuje vam da ograničite količinu memorije koju troši model. Ali postoje i nijanse. Tako je prilikom testiranja Handlyja na skalabilnost otkriven problem u implementaciji mehanizma obavijesti - kada se promijenio veliki broj elemenata, konstrukcija delta je oduzimala previše vremena. Ispostavilo se da je isti problem prisutan u JDT Java modelu, iz kojeg je svojedobno prilagođen odgovarajući kod. Ispravili smo grešku u Handlyju i pripremili sličnu zakrpu za JDT, koja je primljena sa zahvalnošću. Ovo je samo jedan primjer gdje bi uvođenje Handlyja u postojeće implementacije modela moglo biti potencijalno korisno, jer bi se u ovom slučaju takva greška mogla ispraviti na samo jednom mjestu.
Da bi implementacija Handlyja u postojeće implementacije modela bila tehnički izvediva, knjižnica mora imati značajnu fleksibilnost. Glavni problem je održati kompatibilnost unatrag kroz API model. Ovaj problem je riješen u jasnim odvajanjem API-ja specifičnog za model, definiranog i potpuno kontroliranog od strane programera, od unificiranog API-ja na meta-razini koji pruža biblioteka. Ovo ne samo da čini tehnički mogućim implementirati Handly u postojeće implementacije, već također daje razvojnom programu novog modela značajnu slobodu pri dizajniranju API-ja.
Fleksibilnost ima i druge aspekte. Na primjer, Handly ne nameće gotovo nikakva ograničenja na strukturu modela i može se koristiti za modeliranje jezika opće namjene i jezika specifičnih za domenu. Prilikom konstruiranja strukture izvorne datoteke, Handly ne propisuje nikakav poseban oblik AST reprezentacije i, u načelu, čak ne zahtijeva ni prisutnost samog AST-a, čime se osigurava kompatibilnost s gotovo svim mehanizmom parsiranja. Konačno, Handly podržava potpunu integraciju s radnim prostorom Eclipse, ali također može raditi izravno sa sustavima datoteka zahvaljujući integraciji s (EFS).
Trenutna verzija izašao u prosincu 2016. Unatoč činjenici da je projekt trenutno u fazi inkubacije i da API još nije konačno popravljen, Handly se već koristi u dva velika komercijalna proizvoda koji su preuzeli rizik da djeluju kao "rani korisnici", i, moram reći, nemojte još požaliti.
Kao što je gore navedeno, jedan od tih proizvoda su 1C:Enterprise Development Tools, gdje se Handly koristi od samog početka za modeliranje elemenata strukture visoke razine takvih 1C:Enterprise jezika kao što su ugrađeni programski jezik i jezik upita . Još jedan proizvod manje je poznat široj javnosti. Ovaj , okruženje integriranog dizajna za procesor skupa instrukcija specifičan za aplikaciju (ASIP), koji se koristi i unutar same češke tvrtke Codasip i od strane njenih klijenata, uključujući , , , . Codasip koristi Handly u proizvodnji od 2015., počevši od verzije Handly 0.2. Najnovije izdanje Codasip Studija koristi verziju 0.5, objavljenu u lipnju 2016. Ondřej Ilčík, koji vodi razvoj IDE-a u Codasipu, u kontaktu je s projektom, pružajući vitalne povratne informacije u ime "usvajača treće strane". Čak je uspio pronaći malo slobodnog vremena da izravno sudjeluje u razvoju projekta, implementirajući sloj korisničkog sučelja (~4000 redaka koda) za jedan od Handlyjevih primjera, Java model. Detaljnije informacije iz prve ruke o korištenju Handlyja od strane posvojitelja možete pronaći na stranici projekt.
Nadamo se da će nakon izlaska verzije 1.0 s jamstvom stabilnosti API-ja i izlaska projekta iz stanja inkubacije, Handly imati nove korisnike. U međuvremenu, projekt nastavlja s testiranjem i daljnjim poboljšanjem API-ja, objavljujući dva "glavna" izdanja godišnje - u lipnju (na isti datum kao i istovremeno izdanje Eclipse) i prosincu, pružajući predvidljiv raspored na koji se korisnici mogu osloniti. Također možemo dodati da je "stopa pogrešaka" projekta i dalje na dosljedno niskoj razini i da Handly pouzdano radi u proizvodima ranih korisnika od prvih verzija. Da biste dodatno istražili Eclipse Handly, možete koristiti и .
Izvor: www.habr.com