Vjerovatno, odavno nije trebalo posebno predstavljanje. Mnogi ljudi su upoznati sa Eclipse 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 integraciju razvojnih alata (Eclipse Platforma) i niz IDE-ova izgrađenih na njenoj osnovi, uključujući JDT. Eclipse je i Eclipse projekat, projekat najvišeg nivoa koji koordinira razvoj Eclipse platforme i JDT-a, i Eclipse SDK, isporučeni rezultat tog razvoja. Konačno, Eclipse je fondacija otvorenog koda s ogromnom zajednicom projekata, od kojih nisu svi napisani na Javi ili povezani s razvojnim alatima (na primjer, projekti и ). Svet Eclipse je veoma raznolik.
U ovom članku, koji je pregledne prirode, pokušat ćemo sagledati neke od osnova Eclipse arhitekture kao platforme za izgradnju integriranih razvojnih alata i dati početnu ideju o komponentama Eclipsea koje čine temelj tehnologije. platforma za “novi konfigurator” 1C: Enterprise. . Naravno, takav pregled će neizbježno biti uglavnom površan i prilično ograničen, uključujući i zato što se fokusiramo ne samo na Eclipse programere kao ciljnu 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 Eclipse", relativno novom i malo poznatom projektu , koju je osnovao i podržava 1C.
Uvod u Eclipse arhitekturu
Hajde da prvo pogledamo neke opšte aspekte Eclipse arhitekture koristeći primer (JDT). Izbor JDT-a kao primjera nije slučajan. Ovo je prvo integrisano razvojno okruženje koje se pojavljuje u Eclipse-u. Drugi *DT Eclipse projekti, kao što je Eclipse C/C++ razvojni alat (CDT), nastali su kasnije i pozajmljuju i osnovne arhitektonske principe i pojedinačne fragmente izvornog koda od JDT-a. Osnove arhitekture postavljene u JDT relevantne su do danas za skoro svaki IDE izgrađen na vrhu Eclipse platforme, uključujući 1C:Enterprise Development Tools.
Prije svega, treba napomenuti da Eclipse karakterizira prilično jasno arhitektonsko slojevitost, s odvajanjem funkcionalnosti nezavisne od jezika od funkcionalnosti dizajnirane da podrže specifične programske jezike, i odvajanjem „jezgrenih“ komponenti nezavisnih od korisničkog interfejsa od povezanih komponenti. sa podržanim korisničkim interfejsom.
Dakle, Eclipse platforma definiše zajedničku infrastrukturu nezavisnu od jezika, a Java razvojni alati dodaju potpuno opremljen Java IDE Eclipseu. I Eclipse platforma i JDT se sastoje od nekoliko komponenti, od kojih svaka pripada „jezgri“ nezavisnom od korisničkog interfejsa ili sloju korisničkog interfejsa (slika 1).
Rice. 1. Eclipse platforma i JDT
Nabrojimo glavne komponente Eclipse platforme:
- Runtime — Definira infrastrukturu dodataka. Eclipse karakterizira modularna arhitektura. U suštini, Eclipse je kolekcija "produžnih tačaka" i "ekstenzija".
- Radni prostor — Upravlja jednim ili više projekata. Projekat se sastoji od fascikli i datoteka koje su mapirane direktno u sistem datoteka.
- Standardni komplet alata za widget (SWT) - Pruža osnovne elemente korisničkog interfejsa integrisane sa operativnim sistemom.
- JFace — Pruža niz UI okvira izgrađenih na vrhu SWT-a.
- radna tezga — Definira Eclipse UI paradigmu: urednici, pogledi, perspektive.
Mora se reći da Eclipse platforma takođe pruža mnoge druge korisne komponente za izgradnju integrisanih razvojnih alata, uključujući otklanjanje grešaka, upoređivanje, pretragu i tim. Posebno treba spomenuti JFace Text – osnovu za izgradnju “pametnih uređivača” 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, tako da ćemo se u ostatku ovog odjeljka ograničiti na pregled glavnih "jezgri" komponenti Eclipse platforma i JDT.
Core Runtime
Infrastruktura dodataka Eclipse je zasnovana na i predviđeno projektom . Svaki Eclipse dodatak je OSGi paket. OSGi specifikacija definira, posebno, mehanizme za upravljanje verzijama i rješavanje ovisnosti. Pored ovih standardnih mehanizama, Equinox uvodi koncept tačke proširenja. Svaki dodatak može definirati vlastite točke proširenja, a također uvesti dodatnu funkcionalnost („proširenja“) u sistem koristeći tačke proširenja definirane istim ili drugim dodacima. Svaki detaljan opis mehanizama OSGi i Equinox je izvan okvira ovog članka. Napomenimo samo da je modularizacija u Eclipseu potpuna (bilo koji podsistem, uključujući Runtime, sastoji se od jednog ili više dodataka), a skoro sve u Eclipseu je ekstenzija. Štaviše, ovi principi su bili ugrađeni u arhitekturu Eclipse mnogo prije uvođenja OSGi-a (u to vrijeme su koristili vlastitu tehnologiju, mnogo sličnu OSGi-u).
Core Workspace
Skoro svako integrisano razvojno okruženje izgrađeno na Eclipse platformi radi sa Eclipse radnim prostorom. To je radni prostor koji obično sadrži izvorni kod aplikacije razvijene u IDE-u. Radni prostor se mapira direktno na sistem datoteka i sastoji se od projekata koji sadrže fascikle i datoteke. Ovi projekti, fascikle i datoteke se pozivaju resurse radni prostor. Implementacija radnog prostora u Eclipse-u služi kao keš memorija u odnosu na sistem datoteka, što omogućava 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) je odgovorna za podršku radnog prostora i njegovih resursa. Konkretno, ova komponenta omogućava programski pristup radnom prostoru u obrascu modeli resursa. Da bi efikasno radili sa ovim modelom, klijentima je potreban jednostavan način da predstave vezu do resursa. U ovom slučaju, bilo bi poželjno sakriti objekat koji direktno pohranjuje stanje resursa u modelu od pristupa klijenta. U suprotnom, u slučaju, na primjer, brisanja fajla, klijent bi mogao nastaviti da drži objekt koji više nije u modelu, sa nastalim problemima. Eclipse rješava ovaj problem koristeći nešto što se zove rukovati resurs. Handle se ponaša kao ključ (zna samo put do resursa u radnom prostoru) i potpuno kontrolira pristup internom objektu modela, koji direktno pohranjuje informacije o stanju resursa. Ovaj dizajn je varijacija uzorka .
Rice. Slika 2 ilustruje idiom Handle/Body primijenjen na model resursa. IResource sučelje predstavlja ručku resursa i API je, za razliku od klase Resource, koja implementira ovo sučelje, i klase ResourceInfo, koja predstavlja tijelo, a koje nisu API-ji. Naglašavamo da ručka zna samo put do resursa u odnosu na korijen radnog prostora i ne sadrži vezu do informacija o resursu. Podaci o resursima formiraju takozvano „stablo elemenata“. Ova struktura podataka je u potpunosti materijalizovana u memoriji. Da bi se pronašla instanca informacija o resursu koja odgovara rukohvatu, stablo elemenata se prelazi prema putanji pohranjenoj u tom ručku.
Rice. 2. IResource i ResourceInfo
Kao što ćemo kasnije vidjeti, osnovni dizajn modela resursa (mogli bismo ga nazvati baziran na ručki) koristi se u Eclipse-u i za druge modele. Za sada, nabrojimo neke od karakterističnih svojstava ovog dizajna:
- Handle je objekt vrijednosti. Objekti vrijednosti su nepromjenjivi objekti čija jednakost nije zasnovana na identitetu. Takvi objekti se mogu bezbedno koristiti kao ključ u heširanim kontejnerima. Više instanci ručke može referencirati isti resurs. Da biste ih uporedili, trebate koristiti metodu equals(Object).
- Handle definira ponašanje resursa, ali ne sadrži informacije o stanju resursa (jedini podaci koje pohranjuje je "ključ", put do resursa).
- Handle se može odnositi na resurs koji ne postoji (ili resurs koji još nije kreiran, ili resurs koji je već obrisan). Postojanje resursa može se provjeriti korištenjem IResource.exists() metode.
- Neke operacije se mogu implementirati isključivo na osnovu informacija pohranjenih u samom ručku (tzv. operacije samo za rukovanje). Primjeri su IResource.getParent(), getFullPath(), itd. Resurs ne mora postojati da bi takva operacija uspjela. Operacije koje zahtijevaju postojanje resursa da bi uspjele bacaju CoreException ako resurs ne postoji.
Eclipse pruža efikasan mehanizam za obavještavanje o promjenama resursa radnog prostora (slika 3). Resursi se mogu promijeniti ili kao rezultat radnji izvedenih unutar samog Eclipse IDE-a ili kao rezultat sinhronizacije sa sistemom datoteka. U oba slučaja, klijentima koji se pretplate na obavještenja dostavljaju se 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 listu delta na sljedećem nivou koje opisuju promjene podređenih resursa.
Rice. 3. IResourceChangeEvent i IResourceDelta
Mehanizam obavještavanja zasnovan na deltama resursa ima sljedeće karakteristike:
- Jedna promjena i mnoge promjene su opisane koristeći istu strukturu, budući da je delta izgrađena korištenjem principa rekurzivne kompozicije. Pretplatnički klijenti mogu obraditi obavještenja o promjeni resursa koristeći rekurzivno spuštanje kroz stablo delta.
- Delta sadrži potpune informacije o promjenama na resursu, uključujući njegovo kretanje i/ili promjene u “markerima” povezanim s njim (na primjer, greške kompilacije su predstavljene kao markeri).
- Budući da se reference resursa prave preko ručke, delta može prirodno referencirati udaljeni resurs.
Kao što ćemo uskoro vidjeti, glavne komponente dizajna mehanizma obavještavanja o promjeni modela resursa također su relevantne za druge modele zasnovane na ručkama.
JDT Core
Model resursa radnog prostora Eclipse je osnovni model koji ne zavisi od jezika. Komponenta JDT Core (dodatak org.eclipse.jdt.core) pruža API za navigaciju i analizu strukture radnog prostora iz Java perspektive, takozvani “Java model” (Java model). Ovaj API je definisan u terminima Java elemenata, za razliku od osnovnog API modela resursa, koji je definisan u terminima foldera i datoteka. Glavni interfejsi stabla Java elemenata prikazani su na Sl. 4.
Rice. 4. Elementi Java modela
Java model koristi isti idiom ručke/tela kao i model resursa (slika 5). IJavaElement je ručka, a JavaElementInfo igra ulogu tijela. Interfejs IJavaElement 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.
Rice. 5. IJavaElement i JavaElementInfo
Java model ima neke razlike u implementaciji osnovnog dizajna ručke/tela u poređenju sa modelom resursa. Kao što je gore navedeno, u modelu resursa, stablo elemenata, čiji su čvorovi objekti informacija o resursu, u potpunosti je sadržano u memoriji. Ali Java model može imati znatno veći broj elemenata od stabla resursa, jer takođe predstavlja internu strukturu .java i .class datoteka: tipove, polja i metode.
Da bi se izbjegla potpuna materijalizacija cijelog stabla elemenata u memoriji, implementacija Java modela koristi LRU keš informacija o elementima ograničene veličine, gdje je ključ handle IJavaElement. informacioni objekti o elementima se kreiraju na zahtjev dok se kreće po stablu elemenata. U ovom slučaju, stavke koje se najmanje često koriste se izbacuju iz keša, a potrošnja memorije modela ostaje ograničena na specificiranu veličinu keša. Ovo je još jedna prednost dizajna zasnovanog na ručkama, koji u potpunosti skriva takve detalje implementacije od klijentskog koda.
Mehanizam za obavještavanje o promjenama Java elemenata je općenito sličan mehanizmu za praćenje promjena u resursima radnog prostora o kojem se raspravljalo gore. Klijent koji želi da prati promjene u Java modelu prijavljuje se na obavijesti, koje su predstavljene kao ElementChangedEvent objekat koji sadrži IJavaElementDelta (slika 6).
Rice. 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 (ne zasnovan na ruci): (stablo apstraktne sintakse, AST). AST predstavlja rezultat raščlanjivanja 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 obliku linkova na tzv vezovi. Vezivanja su objekti koji predstavljaju imenovane entitete, kao što su tipovi, metode i varijable, poznati kompajleru. Za razliku od AST čvorova, koji formiraju stablo, vezivanja podržavaju unakrsno upućivanje i općenito formiraju graf. Apstraktna klasa ASTNode je zajednička osnovna klasa za sve AST čvorove. Podklase ASTNode odgovaraju specifičnim sintaksičkim konstrukcijama Java jezika.
Budući da stabla sintakse mogu zauzeti značajnu količinu memorije, JDT kešira samo jedan AST za aktivni uređivač. Za razliku od Java modela, AST se obično posmatra kao "srednji", "privremeni" model čije članove klijenti ne bi trebali držati na referencama izvan konteksta operacije koja je dovela do stvaranja AST-a.
Navedena tri modela (Java model, AST, veze) zajedno čine osnovu za izgradnju „inteligentnih razvojnih alata“ u JDT-u, uključujući moćni Java editor sa raznim „pomoćnicima“, raznim radnjama za obradu izvornog koda (uključujući organizovanje liste uvoza). imena i formatiranje prema prilagođenom stilu), alate za pretraživanje i refaktoriranje. U ovom slučaju Java model igra posebnu ulogu, jer se upravo on koristi kao osnova za vizuelni prikaz strukture aplikacije koja se razvija (na primjer, u Package Exploreru, Outlineu, Search, Call Hierarchy i Hijerarhija tipa).
Eclipse komponente koje se koriste u alatima za razvoj 1C:Enterprise Developments
Na sl. Slika 7 prikazuje komponente Eclipse koje čine osnovu tehnološke platforme za 1C:Enterprise Development Tools.
Rice. 7. Eclipse kao platforma za razvojne alate 1C:Enterprise
Eclipse Platform obezbjeđuje osnovnu infrastrukturu. Pogledali smo neke aspekte ove infrastrukture u prethodnom odjeljku.
(EMF) pruža opšta sredstva za modeliranje strukturiranih podataka. EMF je integrisan sa Eclipse platformom, ali se može koristiti i zasebno u redovnim Java aplikacijama. Često su novi Eclipse programeri već dobro upoznati s EMF-om, iako još uvijek ne razumiju u potpunosti zamršenosti Eclipse platforme. Jedan od razloga za tako zasluženu popularnost je univerzalni dizajn, koji uključuje, između ostalog, unificirani meta-nivo API, koji vam omogućava da radite sa bilo kojim EMF modelom na opći način. Osnovne implementacije za objekte modela koje obezbeđuje EMF i podsistem za generisanje koda modela na osnovu 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 alat istinski opšte namjene, EMF je prikladan za rješavanje širokog spektra problema modeliranja, ali neke klase modela (na primjer, modeli zasnovani na ručki o kojima se raspravljalo gore) mogu zahtijevati specijalizovanije alate za modeliranje. Govoriti o EMF-u je nezahvalan zadatak, posebno u ograničenim okvirima jednog članka, jer je to tema posebne knjige, i to prilično debele. Napomenimo samo da je visokokvalitetan sistem generalizacija na kojem se temelji EMF omogućio rađanje čitavog niza projekata posvećenih modeliranju, koji su uključeni u projekat najvišeg nivoa. zajedno sa samim EMF-om. Jedan takav projekat je Eclipse Xtext.
pruža infrastrukturu za "modeliranje teksta". Xtext koristi za raščlanjivanje izvornog teksta i EMF-a za predstavljanje rezultujućeg ASG-a (apstraktnog semantičkog grafa, koji je u suštini kombinacija AST-a i povezivanja), koji se takođe naziva “semantički model”. Gramatika jezika koji je modelirao Xtext opisana je na vlastitom jeziku Xtext-a. Ovo vam omogućava ne samo da generišete gramatički opis za ANTLR, već i da dobijete mehanizam AST serijalizacije (tj. Xtext obezbeđuje i parser i unparser), nagoveštaj konteksta i niz drugih komponenti jezika. S druge strane, gramatički jezik koji se koristi u Xtextu je manje fleksibilan od, recimo, gramatičkog jezika koji se koristi u ANTLR-u. Stoga je ponekad potrebno implementirani jezik „savijati“ 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 izgradnju programskih jezika i razvojnih alata za njih. Konkretno, to je idealan alat za brzu izradu prototipa (jezik specifičan za domenu, DSL). Pored gore pomenutog „jezičkog jezgra“ zasnovanog na ANTLR-u i EMF-u, Xtext pruža mnoge korisne komponente višeg nivoa, uključujući mehanizme indeksiranja, inkrementalnu konstrukciju, „pametan uređivač“ i još mnogo, mnogo više, ali izostavlja upravljanje- zasnovani na jezičkim modelima. Kao i EMF, Xtext je tema vrijedna posebne knjige, a o svim njegovim mogućnostima trenutno teško možemo čak i ukratko govoriti.
1C: Alati za razvoj preduzeća aktivno koriste i sam EMF i niz drugih projekata Eclipse modeliranja. Konkretno, Xtext je jedan od temelja razvojnih alata za takve 1C:Enterprise jezike kao što su ugrađeni programski jezik i jezik upita. Još jedna osnova za ove razvojne alate je Eclipse Handly projekat, o kojem ćemo detaljnije govoriti (od navedenih komponenti Eclipse, on je još uvijek najmanje poznat).
, potprojekat projekta najvišeg nivoa Eclipse Technology, nastao je kao rezultat inicijalnog doprinosa kodu Eclipse fondaciji od strane 1C 2014. godine. Od tada, 1C nastavlja da podržava razvoj projekta: Handly committers su zaposleni u kompaniji. Projekat je mali, ali zauzima prilično jedinstvenu nišu u Eclipse-u: njegov glavni cilj je podrška razvoju modela zasnovanih na ručkama.
Osnovni arhitektonski principi modela zasnovanih na ručki, kao što je idiom ručka/telo, razmatrani su iznad koristeći model resursa i Java model kao primere. Takođe je napomenulo da su i model resursa i Java model važne osnove za Eclipse Java razvojne alate (JDT). A pošto skoro svi *DT Eclipse projekti imaju arhitekturu sličnu JDT-u, ne bi bilo pretjerano reći da modeli zasnovani na ručkama leže u osnovi mnogih, ako ne i svih IDE-ova izgrađenih na vrhu Eclipse platforme. Na primjer, Eclipse C/C++ razvojni alat (CDT) ima C/C++ model baziran na ručkama koji igra istu ulogu u CDT arhitekturi kao Java model u JDT-u.
Prije Handlyja, Eclipse nije nudio specijalizirane biblioteke za izgradnju jezičkih modela zasnovanih na ručkama. Modeli koji trenutno postoje nastali su uglavnom direktnim prilagođavanjem koda Java modela (aka copy/paste), u slučajevima kada to dozvoljava Eclipse javna licenca (EPL). (Očigledno, ovo obično nije pravno pitanje za, recimo, sam Eclipse projekte, ali ne i za proizvode zatvorenog koda.) Pored svoje inherentne nasumice, ova tehnika uvodi dobro poznate probleme: dupliciranje koda koje uvodi prilikom prilagođavanja greškama, itd. Najgore je to što rezultirajući modeli ostaju „stvari po sebi“ i ne iskorištavaju potencijal za ujedinjenje. Ali izolovanje zajedničkih koncepata i protokola za jezičke modele zasnovane na ručkama moglo bi dovesti do stvaranja komponenti za višekratnu upotrebu za rad sa njima, slično onome što se dogodilo u slučaju EMF-a.
Nije da Eclipse nije razumio ove probleme. Još 2005. godine , sumirajući iskustvo razvoja CDT prototipa, potreba za stvaranjem zajedničke infrastrukture za jezičke modele, uključujući modele zasnovane na ručkama. Ali, kao što se često dešava, zbog prioritetnih zadataka, implementacija ovih ideja nikada nije stigla. U međuvremenu, faktorizacija *DT koda je još uvijek jedna od nedovoljno razvijenih tema u Eclipseu.
U određenom smislu, Handly projekat je dizajniran za rješavanje približno istih problema kao i EMF, ali za modele zasnovane na ručkama, i to prvenstveno jezičke (tj. koji predstavljaju elemente strukture nekog programskog jezika). Glavni ciljevi postavljeni prilikom dizajniranja Handlyja su navedeni u nastavku:
- Identifikacija glavnih apstrakcija predmetnog područja.
- Smanjenje napora i poboljšanje kvaliteta implementacije jezičkih modela zasnovanih na ručkama kroz ponovnu upotrebu koda.
- Pružanje jedinstvenog meta-nivoa API-ja za rezultirajuće modele, omogućavajući stvaranje zajedničkih IDE komponenti koje rade sa modelima zasnovanim na jezičkim ručkama.
- Fleksibilnost i skalabilnost.
- Integracija sa Xtextom (u posebnom sloju).
Da bi se istakli zajednički koncepti i protokoli, analizirane su postojeće implementacije modela zasnovanih na jezičkim ručkama. Glavni interfejsi i osnovne implementacije koje pruža Handly prikazani su na Sl. 8.
Rice. 8. Uobičajeni interfejsi i osnovne implementacije Handly elemenata
Interfejs IElement predstavlja rukohvat elementa i zajednički je elementima svih modela zasnovanih na ruci. Apstraktna klasa Element implementira generalizovani mehanizam ručke/tela (slika 9).
Rice. 9. Implementacija IElementa i generičke ručke/tijela
Pored toga, Handly pruža generalizovani mehanizam za obavještavanje o promjenama u elementima modela (slika 10). Kao što možete vidjeti, on je u velikoj mjeri sličan mehanizmima obavještavanja implementiranim u modelu resursa i Java modelu, i koristi IElementDelta da pruži objedinjeni prikaz informacija o promjeni elementa.
Rice. 10. Opšti interfejsi i osnovne implementacije Handly mehanizma notifikacije
Dio Handly koji je gore razmotren (slike 9 i 10) može se koristiti za predstavljanje gotovo svih modela zasnovanih na ručkama. Za stvaranje lingvistički modelima, projekat nudi dodatne funkcionalnosti – posebno zajedničke interfejse i osnovne implementacije za elemente strukture izvornog teksta, tzv. izvorni elementi (Sl. 8). Interfejs ISourceFile predstavlja izvornu datoteku, a ISourceConstruct predstavlja element unutar izvorne datoteke. Apstraktne klase SourceFile i SourceConstruct implementiraju generalizirane mehanizme za podršku rada sa izvornim datotekama i njihovim elementima, na primjer, rad sa tekstualnim baferima, vezivanje za koordinate elementa u izvornom tekstu, usklađivanje modela sa trenutnim sadržajem bafera radne kopije , itd. Implementacija ovih mehanizama je obično veliki izazov, a Handly može značajno smanjiti napore u razvoju jezičkih modela zasnovanih na ručkama tako što će obezbijediti visokokvalitetne implementacije baze.
Uz gore navedene osnovne mehanizme, Handly pruža infrastrukturu za međuspremnike teksta i snimke, podršku za integraciju sa uređivačima izvornog koda (uključujući integraciju izvan kutije sa Xtext editorom), kao i neke uobičajene komponente korisničkog sučelja koje rad sa uređivačima izvornog koda Ručni modeli kao što je okvirni okvir. Da bi ilustrovao svoje mogućnosti, projekat pruža nekoliko primera, uključujući implementaciju Java modela u Handly. (U poređenju sa potpunom implementacijom Java modela u JDT, ovaj model je namerno donekle pojednostavljen radi veće jasnoće.)
Kao što je ranije navedeno, glavni fokus tokom Handlyjevog početnog dizajna i kasnijeg razvoja bio je i nastavlja biti na skalabilnosti i fleksibilnosti.
U principu, modeli zasnovani na ručkama su prilično dobro skalirani "po dizajnu". Na primjer, idiom ručke/tijela omogućava vam da ograničite količinu memorije koju model troši. Ali postoje i nijanse. Tako je prilikom testiranja Handlyja na skalabilnost otkriven problem u implementaciji mehanizma notifikacije – kada je promijenjen veliki broj elemenata, konstruiranje delta je oduzimalo previše vremena. Ispostavilo se da je isti problem prisutan i u JDT Java modelu, iz kojeg je svojevremeno adaptiran odgovarajući kod. Ispravili smo grešku u Handly-u i pripremili sličnu zakrpu za JDT, koja je sa zahvalnošću primljena. Ovo je samo jedan primjer gdje bi uvođenje Handlyja u postojeće implementacije modela moglo biti potencijalno korisno, jer bi u ovom slučaju takva greška mogla biti ispravljena na samo jednom mjestu.
Da bi implementacija Handlyja u postojeće implementacije modela bila tehnički izvodljiva, biblioteka mora imati značajnu fleksibilnost. Glavni problem je održavanje kompatibilnosti unazad kroz API model. Ovaj problem je riješen u jasnim odvajanjem API-ja specifičnog za model, definisanog i potpuno kontrolisanog od strane programera, od unificiranog API-ja meta nivoa koji obezbeđuje biblioteka. Ovo ne samo da čini tehnički mogućim implementaciju Handly-a u postojeće implementacije, već također daje programeru 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 domen. Kada konstruiše strukturu izvornog fajla, Handly ne propisuje nikakav poseban oblik AST reprezentacije i, u principu, ne zahteva čak ni prisustvo samog AST-a, čime se obezbeđuje kompatibilnost sa gotovo bilo kojim mehanizmom raščlanjivanja. Konačno, Handly podržava potpunu integraciju sa Eclipse radnim prostorom, ali može raditi i direktno sa sistemima datoteka zahvaljujući integraciji sa (EFS).
Trenutna verzija izašao u decembru 2016. Unatoč činjenici da je projekt trenutno u stanju inkubacije i da API još uvijek 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, nemoj još požaliti.
Kao što je gore navedeno, jedan od ovih proizvoda su 1C:Enterprise Development Tools, gdje se Handly koristi od samog početka za modeliranje elemenata strukture visokog nivoa takvih 1C:Enterprise jezika kao što su ugrađeni programski jezik i jezik upita. . Još jedan proizvod je manje poznat široj javnosti. Ovo , integrisano dizajnersko okruženje za procesor skupa instrukcija specifičan za aplikaciju (ASIP), koji se koristi kako u samoj češkoj kompaniji Codasip tako i od strane njenih klijenata, uključujući , , , . Codasip koristi Handly u proizvodnji od 2015. godine, počevši od verzije Handly 0.2. Najnovije izdanje Codasip Studio-a koristi verziju 0.5, objavljenu u junu 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 “treće strane usvojitelja”. Čak je bio u mogućnosti da nađe slobodnog vremena da direktno učestvuje u razvoju projekta, implementirajući sloj korisničkog interfejsa (~4000 linija koda) za jedan od Handly primera, Java model. Detaljnije informacije iz prve ruke o korištenju Handlyja od strane usvojitelja mogu se pronaći na stranici projekat.
Nadamo se da će nakon izdavanja verzije 1.0 sa garancijom stabilnosti API-ja i izlaska projekta iz stanja inkubacije, Handly imati nove usvojitelje. U međuvremenu, projekat nastavlja da testira i dalje unapređuje API, objavljujući dva "glavna" izdanja godišnje - u junu (isti datum kao i istovremeno izdanje Eclipsea) i decembru, pružajući predvidljiv raspored na koji se korisnici mogu osloniti. Također možemo dodati da je “stopa grešaka” projekta i dalje na konstantno niskom nivou i Handly pouzdano radi u proizvodima ranih korisnika od prvih verzija. Za dalje istraživanje Eclipse Handly možete koristiti и .
izvor: www.habr.com