Tõenäoliselt pole ammu erilist tutvustamist vajanud. Paljud inimesed tunnevad Eclipse'i tänu Eclipse Java arendustööriistadele (). Just seda populaarset avatud lähtekoodiga Java IDE-d seostab enamik arendajaid sõnaga "Eclipse". Eclipse on aga nii laiendatav platvorm arendustööriistade (Eclipse Platform) integreerimiseks kui ka mitmed selle baasil ehitatud IDE-d, sealhulgas JDT. Eclipse on nii Eclipse'i projekt, tipptasemel projekt, mis koordineerib Eclipse'i platvormi ja JDT arendamist, kui ka Eclipse SDK, selle arenduse tulemus. Lõpuks on Eclipse avatud lähtekoodiga sihtasutus, millel on tohutu projektide kogukond, millest kõik pole Java keeles kirjutatud ega seotud arendustööriistadega (nt projektid и ). Eclipse'i maailm on väga mitmekesine.
Selles olemuselt ülevaatlikus artiklis püüame vaadelda mõningaid Eclipse'i arhitektuuri kui integreeritud arendustööriistade loomise platvormi põhitõdesid ja anda esmase ettekujutuse Eclipse'i komponentidest, mis moodustavad tehnoloogia aluse. platvorm "uue konfiguraatori" 1C: Enterprise jaoks. . Loomulikult on selline ülevaade paratamatult suures osas pealiskaudne ja üsna piiratud, sealhulgas seetõttu, et me ei keskendu ainult Eclipse'i arendajatele kui sihtrühmale. Loodame siiski, et isegi kogenud Eclipse'i arendajad leiavad artiklist huvitavat teavet. Näiteks räägime ühest "Eclipse'i saladusest", suhteliselt uuest ja vähetuntud projektist , mille asutas ja toetas 1C.
Sissejuhatus Eclipse'i arhitektuuri
Vaatame esmalt näite abil mõningaid Eclipse'i arhitektuuri üldisi aspekte (JDT). JDT valik näitena ei ole juhuslik. See on esimene integreeritud arenduskeskkond, mis Eclipse'is ilmub. Teised *DT Eclipse'i projektid, nagu Eclipse C/C++ Development Tooling (CDT), loodi hiljem ja need laenavad JDT-lt nii arhitektuuri põhiprintsiipe kui ka üksikuid lähtekoodi fragmente. JDT-s sätestatud arhitektuuri põhialused on tänapäevani asjakohased peaaegu kõigi Eclipse'i platvormile ehitatud IDE jaoks, sealhulgas 1C: Enterprise Development Tools.
Esiteks tuleb märkida, et Eclipse'i iseloomustab üsna selge arhitektuurne kihilisus, mille puhul on eraldatud keelest sõltumatud funktsioonid spetsiifiliste programmeerimiskeelte toetamiseks mõeldud funktsioonidest ning kasutajaliidesest sõltumatud põhikomponendid on eraldatud seotud komponentidest. toetava kasutajaliidesega.
Seega määratleb Eclipse'i platvorm ühise, keelest sõltumatu infrastruktuuri ja Java arendustööriistad lisavad Eclipse'ile täisfunktsionaalsusega Java IDE. Nii Eclipse'i platvorm kui ka JDT koosnevad mitmest komponendist, millest igaüks kuulub kas kasutajaliidesest sõltumatusse "tuuma" või kasutajaliidese kihti (joonis 1).
Riis. 1. Eclipse Platform ja JDT
Loetleme Eclipse'i platvormi põhikomponendid:
- Runtime — Määrab pistikprogrammi infrastruktuuri. Eclipse'i iseloomustab modulaarne arhitektuur. Põhimõtteliselt on Eclipse "laienduspunktide" ja "laienduste" kogum.
- Tööruum — haldab ühte või mitut projekti. Projekt koosneb kaustadest ja failidest, mis on vastendatud otse failisüsteemiga.
- Standardne vidinate tööriistakomplekt (SWT) - Pakub põhilisi kasutajaliidese elemente, mis on integreeritud operatsioonisüsteemiga.
- JFace — Pakub mitmeid SWT-le ehitatud kasutajaliidese raamistikke.
- Workbench — Määratleb Eclipse'i kasutajaliidese paradigma: toimetajad, vaated, vaated.
Peab ütlema, et Eclipse'i platvorm pakub ka palju muid kasulikke komponente integreeritud arendustööriistade loomiseks, sealhulgas silumine, võrdlemine, otsing ja meeskond. Eraldi tuleks ära mainida JFace Text – lähtekoodi “nutikate toimetajate” loomise alus. Kahjuks ei ole selle artikli raames võimalik isegi nende komponentide, aga ka kasutajaliidese kihi komponentide pealiskaudne uurimine, seega piirdume selle jaotise ülejäänud osas ülevaatega Eclipse'i platvorm ja JDT.
Põhitööaeg
Eclipse'i pistikprogrammi infrastruktuur põhineb ja mida pakub projekt . Iga Eclipse'i pistikprogramm on OSGi pakett. OSGi spetsifikatsioon määratleb eelkõige versioonide loomise ja sõltuvuse lahendamise mehhanismid. Lisaks nendele standardmehhanismidele tutvustab Equinox seda kontseptsiooni laienduspunktid. Iga pistikprogramm saab määrata oma laienduspunktid ja lisada süsteemile lisafunktsioone (“laiendusi”), kasutades samade või muude pistikprogrammide määratletud laienduspunkte. OSGi ja Equinoxi mehhanismide üksikasjalik kirjeldus ei kuulu selle artikli ulatusse. Pangem vaid tähele, et Eclipse'i modulariseerimine on täielik (iga alamsüsteem, sealhulgas Runtime, koosneb ühest või mitmest pistikprogrammist) ja peaaegu kõik Eclipse'is on laiendus. Pealegi olid need põhimõtted Eclipse'i arhitektuuris juba ammu enne OSGi kasutuselevõttu (sel ajal kasutasid nad oma tehnoloogiat, mis sarnanes paljuski OSGi-ga).
Põhitööruum
Peaaegu iga Eclipse'i platvormi peale ehitatud integreeritud arenduskeskkond töötab Eclipse'i tööruumiga. See on tööruum, mis sisaldab tavaliselt IDE-s arendatud rakenduse lähtekoodi. Tööala kaardistab otse failisüsteemi ja koosneb projektidest, mis sisaldavad kaustu ja faile. Neid projekte, kaustu ja faile nimetatakse ressursse tööruum. Eclipse'i tööruumi juurutamine toimib failisüsteemiga seoses vahemäluna, mis võimaldab oluliselt kiirendada ressursipuu läbimist. Lisaks pakub tööruum mitmeid lisateenuseid, sh и .
Põhiressursside komponent (org.eclipse.core.resources plugin) vastutab tööruumi ja selle ressursside toetamise eest. Eelkõige pakub see komponent programmilist juurdepääsu vormi tööruumile ressursimudelid. Selle mudeliga tõhusaks töötamiseks vajavad kliendid lihtsat viisi ressursi lingi esitamiseks. Sel juhul oleks soovitav kliendi juurdepääsu eest peita objekt, mis mudelis ressursi olekut otseselt salvestab. Vastasel juhul võib klient näiteks faili kustutamise korral säilitada objekti, mida enam mudelis ei ole, koos sellest tulenevate probleemidega. Eclipse lahendab selle probleemi nn käepide ressurss. Käepide toimib võtmena (teab ainult ressursi teed tööruumis) ja kontrollib täielikult juurdepääsu sisemudeli objektile, mis salvestab otseselt teavet ressursi oleku kohta. See disain on mustri variatsioon .
Riis. Joonis 2 illustreerib käepideme/keha idioomi ressursimudelile rakendatuna. IResource liides esindab ressursi käepidet ja on API, erinevalt klassist Resource, mis seda liidest rakendab, ja klassist ResourceInfo, mis esindab keha, mis ei ole API-d. Rõhutame, et käepide teab ainult ressursi teed tööruumi juure suhtes ega sisalda linki ressursi teabele. Ressursi infoobjektid moodustavad nn elemendipuu. See andmestruktuur realiseerub täielikult mällu. Käepidemele vastava ressursiteabe eksemplari leidmiseks läbitakse elemendipuu vastavalt sellele käepidemele salvestatud teele.
Riis. 2. IResource ja ResourceInfo
Nagu hiljem näeme, kasutatakse Eclipse'is ressursimudeli põhikujundust (võime seda nimetada käepidemepõhiseks) ka teiste mudelite jaoks. Praegu loetleme mõned selle kujunduse iseloomulikud omadused:
- Käepide on väärtusobjekt. Väärtusobjektid on muutumatud objektid, mille võrdsus ei põhine identiteedil. Selliseid objekte saab turvaliselt kasutada võtmena räsitud konteinerites. Mitu käepideme eksemplari võivad viidata samale ressursile. Nende võrdlemiseks peate kasutama võrdub (Object) meetodit.
- Käepide määratleb ressursi käitumise, kuid ei sisalda teavet ressursi oleku kohta (ainsad andmed, mida see salvestab, on "võti", ressursi tee).
- Käepide võib viidata ressursile, mida pole olemas (kas ressurss, mida pole veel loodud, või ressurss, mis on juba kustutatud). Ressursi olemasolu saab kontrollida meetodi IResource.exists() abil.
- Mõningaid toiminguid saab rakendada ainult käepidemesse salvestatud teabe põhjal (nn ainult käepidemega toimingud). Näited on IResource.getParent(), getFullPath() jne. Sellise toimingu õnnestumiseks ei pea ressurss olemas olema. Toimingud, mille õnnestumiseks on vaja ressurssi, annavad CoreExceptioni, kui ressurssi pole olemas.
Eclipse pakub tõhusat mehhanismi tööruumi ressursimuutustest teavitamiseks (joonis 3). Ressursid võivad muutuda kas Eclipse IDE-s endas tehtud toimingute või failisüsteemiga sünkroonimise tulemusena. Mõlemal juhul antakse teavitustega liitunud klientidele üksikasjalikku teavet muudatuste kohta “ressursside delta” kujul. Delta kirjeldab muudatusi tööruumi ressursi (alam)puu kahe oleku vahel ja on ise puu, mille iga sõlm kirjeldab ressursi muudatust ja sisaldab järgmise taseme deltade loendit, mis kirjeldavad alamressursside muudatusi.
Riis. 3. IResourceChangeEvent ja IResourceDelta
Ressursi deltadel põhineval teavitusmehhanismil on järgmised omadused.
- Ühte muudatust ja paljusid muudatusi kirjeldatakse sama struktuuri abil, kuna delta on üles ehitatud rekursiivse kompositsiooni põhimõttel. Abonendikliendid saavad töödelda ressursimuutuste teatisi, kasutades deltapuu kaudu rekursiivset laskumist.
- Delta sisaldab täielikku teavet ressursi muudatuste kohta, sealhulgas selle liikumise ja/või muudatuste kohta sellega seotud “markerites” (näiteks kompileerimisvead on esitatud markeritena).
- Kuna ressursside viited tehakse käepideme kaudu, võib delta loomulikult viidata kaugressursile.
Nagu varsti näeme, on ressursimudeli muutustest teavitamise mehhanismi ülesehituse põhikomponendid olulised ka teiste käepidemepõhiste mudelite puhul.
JDT tuum
Eclipse'i tööruumi ressursimudel on põhiline keeleagnostiline mudel. JDT Core'i komponent (plugin org.eclipse.jdt.core) pakub API-d tööruumi struktuuri navigeerimiseks ja analüüsimiseks Java vaatenurgast, nn Java mudelit (Java mudel). See API on määratletud Java elementidena, erinevalt aluseks olevast ressursimudeli API-st, mis on määratletud kaustade ja failide järgi. Java elementide puu peamised liidesed on näidatud joonisel fig. 4.
Riis. 4. Java mudeli elemendid
Java mudel kasutab sama käepideme/keha idioomi kui ressursi mudel (joonis 5). IJavaElement on käepide ja JavaElementInfo mängib keha rolli. IJavaElement liides määratleb protokolli, mis on ühine kõigile Java elementidele. Mõned selle meetodid on ainult käepidemega: getElementName(), getParent() jne. JavaElementInfo objekt salvestab vastava elemendi oleku: selle struktuuri ja atribuudid.
Riis. 5. IJavaElement ja JavaElementInfo
Java mudelil on mõned erinevused põhikäepideme/kere disaini rakendamises võrreldes ressursimudeliga. Nagu eespool märgitud, sisaldub ressursimudelis elemendipuu, mille sõlmed on ressursi teabeobjektid, täielikult mälus. Kuid Java mudelil võib olla oluliselt suurem arv elemente kui ressursipuul, kuna see esindab ka java ja klassi failide sisemist struktuuri: tüüpe, välju ja meetodeid.
Et vältida kogu mälus olevate elementide puu täielikku realiseerumist, kasutab Java mudeli rakendamine piiratud suurusega elemenditeabe LRU vahemälu, kus võtmeks on käepide IJavaElement. elemenditeabe objektid luuakse nõudmisel elementide puus navigeerimise ajal. Sel juhul tõstetakse vahemälust välja kõige harvemini kasutatavad üksused ja mudeli mälutarve jääb määratud vahemälu suuruse piiresse. See on veel üks käepidemepõhise disaini eelis, mis peidab sellised rakenduse üksikasjad kliendi koodi eest täielikult.
Java elementide muudatustest teavitamise mehhanism on üldiselt sarnane ülalkirjeldatud tööruumi ressursside muudatuste jälgimise mehhanismiga. Klient, kes soovib jälgida Java mudeli muudatusi, tellib teatised, mis on kujutatud objektina ElementChangedEvent, mis sisaldab IJavaElementDeltat (joonis 6).
Riis. 6. ElementChangedEvent ja IJavaElementDelta
Java-mudel ei sisalda teavet meetodikehade ega nimede eraldusvõime kohta, seega pakub JDT Core Java-s kirjutatud koodi üksikasjalikuks analüüsiks täiendava (käepidemeta) mudeli: (abstraktne süntaksipuu, AST). AST tähistab lähteteksti sõelumise tulemust. AST-sõlmed vastavad lähtemooduli struktuuri elementidele (deklaratsioonid, operaatorid, avaldised jne) ja sisaldavad teavet vastava elemendi koordinaatide kohta lähtetekstis, samuti (valikuna) teavet nimede lahendamise kohta linkide vorm nn köited. Sidemed on objektid, mis esindavad kompilaatorile teada olevaid nimelisi üksusi, nagu tüübid, meetodid ja muutujad. Erinevalt AST-sõlmedest, mis moodustavad puu, toetavad sidemed ristviiteid ja moodustavad üldiselt graafiku. Abstraktne klass ASTNode on kõigi AST-sõlmede ühine baasklass. ASTNode alamklassid vastavad Java keele spetsiifilistele süntaktilistele konstruktsioonidele.
Kuna süntaksipuud võivad tarbida märkimisväärsel hulgal mälu, salvestab JDT aktiivse redaktori jaoks vahemällu ainult ühe AST. Erinevalt Java mudelist vaadeldakse AST-i tavaliselt "vahepealse", "ajutise" mudelina, mille liikmetele ei tohiks kliendid viidata väljaspool AST-i loomiseni viinud operatsiooni konteksti.
Loetletud kolm mudelit (Java mudel, AST, sidumised) moodustavad koos aluse JDT-s "intelligentsete arendustööriistade" ehitamiseks, sealhulgas võimas Java-redaktor koos erinevate "abimeestega", mitmesugused toimingud lähtekoodi töötlemiseks (sh importimise loendi korraldamine). nimed ja vorming vastavalt kohandatud stiilile), otsingu- ja ümbertöötlustööriistad. Sel juhul mängib Java-mudel erilist rolli, kuna just seda kasutatakse arendatava rakenduse struktuuri visuaalse esituse alusena (näiteks Package Exploreris, Outline'is, Searchis, Call Hierarhias ja Tüüp Hierarhia).
Eclipse'i komponendid, mida kasutatakse 1C:Enterprise Developments Toolsis
Joonisel fig. Joonisel 7 on näidatud Eclipse'i komponendid, mis moodustavad 1C:Enterprise Development Toolsi tehnoloogiaplatvormi aluse.
Riis. 7. Eclipse kui platvorm 1C:Enterprise Development Toolsi jaoks
Eclipse platvorm pakub põhiinfrastruktuuri. Vaatasime eelmises jaotises selle infrastruktuuri mõningaid aspekte.
(EMF) pakub üldist vahendit struktureeritud andmete modelleerimiseks. EMF on integreeritud Eclipse'i platvormiga, kuid seda saab kasutada ka tavalistes Java rakendustes eraldi. Üsna sageli on uued Eclipse'i arendajad juba EMF-iga hästi kursis, kuigi nad ei mõista veel täielikult Eclipse'i platvormi keerukust. Sellise väljateenitud populaarsuse üheks põhjuseks on universaalne disain, mis sisaldab muuhulgas ühtset meta-taseme API-t, mis võimaldab üldjoontes töötada mis tahes EMF-i mudeliga. EMF-i pakutavad mudeliobjektide põhirakendused ja metamudelil põhineva mudelikoodi genereerimise alamsüsteem suurendavad oluliselt arenduskiirust ja vähendavad vigade arvu. EMF sisaldab ka mehhanisme mudelite järjestamiseks, mudeli muudatuste jälgimiseks ja palju muud.
Nagu iga tõeliselt üldotstarbeline tööriist, sobib ka EMF paljude modelleerimisprobleemide lahendamiseks, kuid mõned mudelite klassid (näiteks ülalkirjeldatud käepidemepõhised mudelid) võivad vajada spetsiifilisemaid modelleerimistööriistu. EMF-ist rääkimine on tänamatu ülesanne, eriti ühe artikli piires, kuna see on eraldi raamatu teema ja üsna paks. Märgime vaid, et EMF-i aluseks olev kvaliteetne üldistuste süsteem võimaldas sündida tervel hulgal modelleerimisele pühendatud projekte, mis on tipptasemel projektis. koos EMF-iga. Üks selline projekt on Eclipse Xtext.
pakub "teksti modelleerimise" infrastruktuuri. Xtext kasutab lähteteksti ja EMF-i parsimiseks saadud ASG (abstraktne semantiline graaf, mis on sisuliselt AST ja sidemete kombinatsioon), mida nimetatakse ka "semantiliseks mudeliks" esitamiseks. Xtexti modelleeritud keele grammatikat kirjeldatakse Xtexti enda keeles. See võimaldab teil mitte ainult genereerida ANTLR-i grammatikakirjeldust, vaid hankida ka AST-i serialiseerimismehhanismi (st Xtext pakub nii parserit kui ka parserit), konteksti vihjet ja mitmeid muid keelekomponente. Teisest küljest on Xtextis kasutatav grammatikakeel vähem paindlik kui näiteks ANTLR-is kasutatav grammatikakeel. Seetõttu on mõnikord vaja rakendatud keelt Xteksti "painutada", mis ei ole tavaliselt probleem, kui räägime nullist arendatavast keelest, kuid võib olla vastuvõetamatu juba kehtestatud süntaksiga keelte jaoks. Sellele vaatamata on Xtext praegu Eclipse'i kõige küpsem, funktsioonirikkam ja mitmekülgsem tööriist programmeerimiskeelte ja nende jaoks mõeldud arendustööriistade loomiseks. Eelkõige on see ideaalne tööriist kiireks prototüüpimiseks (domeenispetsiifiline keel, DSL). Lisaks ülalmainitud ANTLR-il ja EMF-il põhinevale "keele tuumale", pakub Xtext palju kasulikke kõrgema taseme komponente, sealhulgas indekseerimismehhanisme, järkjärgulist konstruktsiooni, "nutikat redaktorit" ja palju-palju muud, kuid jätab välja käepideme põhinevad keelemudelid. Sarnaselt EMF-iga on ka Xtext omaette raamatut väärt teema, mille kõigist võimalustest ei jõua praegu isegi lühidalt rääkida.
1C:Enterprise Development Tools kasutab aktiivselt nii EMF-i ennast kui ka mitmeid teisi Eclipse'i modelleerimisprojekte. Eelkõige on Xtext üks selliste 1C: Enterprise keelte arendustööriistade aluseid nagu sisseehitatud programmeerimiskeel ja päringukeel. Teine nende arendustööriistade alus on projekt Eclipse Handly, millest räägime üksikasjalikumalt (loetletud Eclipse'i komponentidest on see endiselt kõige vähem tuntud).
, tipptaseme projekti Eclipse Technology alamprojekt, mis tekkis 1. aastal 2014C poolt Eclipse Foundationile tehtud esialgse koodipanuse tulemusena. Sellest ajast alates on 1C jätkanud projekti arendamise toetamist: Käelised kohustused on ettevõtte töötajad. Projekt on väike, kuid hõivab Eclipse'is üsna ainulaadse niši: selle peamine eesmärk on toetada käepidemepõhiste mudelite arendamist.
Käepidemepõhiste mudelite, näiteks käepideme/kere idioomi, arhitektuurilisi põhiprintsiipe käsitleti eespool, kasutades näidetena ressursimudelit ja Java mudelit. Samuti märgiti, et nii ressursimudel kui ka Java mudel on Eclipse Java arendustööriistade (JDT) olulised alused. Ja kuna peaaegu kõigil *DT Eclipse'i projektidel on JDT-ga sarnane arhitektuur, poleks liialdus öelda, et käepidemepõhised mudelid on paljude, kui mitte kõigi Eclipse'i platvormi peale ehitatud IDE-de aluseks. Näiteks Eclipse C/C++ arendustööriistadel (CDT) on käepidemepõhine C/C++ mudel, mis mängib CDT arhitektuuris sama rolli nagu Java mudel JDT-s.
Enne Handlyt ei pakkunud Eclipse spetsiaalseid teeke käepidemepõhiste keelemudelite loomiseks. Praegu olemasolevad mudelid loodi peamiselt Java mudelikoodi otsese kohandamise teel (ehk kopeeri/kleebi), juhtudel, kui see võimaldab Eclipse'i avalik litsents (EPL). (Ilmselt ei ole see tavaliselt juriidiline probleem näiteks Eclipse'i projektide enda puhul, kuid mitte suletud lähtekoodiga toodete puhul.) Lisaks oma loomupärasele juhuslikkusele toob see tehnika kaasa tuntud probleeme: koodi dubleerimine, mis tekib vigadega kohanemisel, jne. Veelgi hullem on see, et saadud mudelid jäävad "asjadeks iseeneses" ega kasuta ära ühendamise potentsiaali. Kuid üldkasutatavate kontseptsioonide ja protokollide eraldamine käepidemepõhiste keelemudelite jaoks võib viia nendega töötamiseks korduvkasutatavate komponentide loomiseni, nagu juhtus EMF-i puhul.
Asi pole selles, et Eclipse ei mõistnud neid probleeme. Tagasi aastal 2005 , võttes kokku CDT prototüübi arendamise kogemused, vajadus luua keelemudelite, sealhulgas käepidemepõhiste mudelite jaoks ühine infrastruktuur. Kuid nagu sageli juhtub, ei jõutud nende ideede elluviimiseni kõrgema prioriteediga ülesannete tõttu kunagi. Samal ajal on *DT-koodi faktoriseerimine endiselt üks Eclipse'i vähearenenud teemadest.
Teatud mõttes on Handly projekt mõeldud ligikaudu samade probleemide lahendamiseks, mis EMF, kuid käepidemepõhiste mudelite ja eelkõige keelemudelite jaoks (st esindavad mõne programmeerimiskeele struktuuri elemente). Peamised Handly projekteerimisel seatud eesmärgid on loetletud allpool:
- Ainevaldkonna peamiste abstraktsioonide väljaselgitamine.
- Käepidemepõhiste keelemudelite jõupingutuste vähendamine ja kvaliteedi parandamine koodi taaskasutuse kaudu.
- Saadud mudelitele ühtse metataseme API pakkumine, mis võimaldab luua ühiseid IDE-komponente, mis töötavad keelekäepidemepõhiste mudelitega.
- Paindlikkus ja mastaapsus.
- Integratsioon Xtextiga (eraldi kihina).
Levinud mõistete ja protokollide esiletõstmiseks analüüsiti olemasolevaid keelekäepidemepõhiste mudelite rakendusi. Handly pakutavad peamised liidesed ja põhirakendused on näidatud joonisel fig. 8.
Riis. 8. Handly elementide ühised liidesed ja põhirakendused
IElementi liides esindab elemendi käepidet ja on ühine kõikide Handly-põhiste mudelite elementidele. Abstraktne klass Element rakendab üldistatud käepideme/kere mehhanismi (joonis 9).
Riis. 9. IEelement ja üldine käepide/kere rakendamine
Lisaks pakub Handly üldistatud mehhanismi mudelielementide muutustest teavitamiseks (joonis 10). Nagu näete, on see üldjoontes sarnane ressursimudelis ja Java mudelis rakendatud teavitusmehhanismidega ning kasutab IElementDeltat, et pakkuda elementide muutmise teabe ühtset esitust.
Riis. 10. Handly teavitusmehhanismi üldised liidesed ja põhirakendused
Eespool käsitletud Handly osa (joonis 9 ja 10) saab kasutada peaaegu kõigi käepidemetel põhinevate mudelite esitamiseks. Loomiseks keeleline mudelid, pakub projekt lisafunktsionaalsust - eelkõige ühiseid liideseid ja põhilisi teostusi lähteteksti struktuuri elementidele, nn. lähteelemendid (joonis 8). Liides ISourceFile esindab lähtefaili ja ISourceConstruct esindab lähtefaili elementi. Abstraktsed klassid SourceFile ja SourceConstruct rakendavad üldistatud mehhanisme, et toetada tööd lähtefailide ja nende elementidega, näiteks töötamine tekstipuhvriga, sidumine lähteteksti elemendi koordinaatidega, mudelite ühildamine töökoopiapuhvri praeguse sisuga. , jne. Nende mehhanismide rakendamine on tavaliselt üsna suur väljakutse ja Handly võib märkimisväärselt vähendada käepidemepõhiste keelemudelite väljatöötamist, pakkudes kvaliteetseid baasrakendusi.
Lisaks ülalloetletud põhimehhanismidele pakub Handly infrastruktuuri tekstipuhvrite ja hetktõmmiste jaoks, tuge integreerimiseks lähtekoodiredaktoriga (sealhulgas valmis integreerimine Xteksti redaktoriga), samuti mõningaid tavalisi kasutajaliidese komponente, mis Töötage lähtekoodi redaktoritega. Käepärased mudelid, nagu näiteks raamistik. Selle võimaluste illustreerimiseks pakub projekt mitmeid näiteid, sealhulgas Java mudeli rakendamist Handlys. (Võrreldes Java mudeli täieliku rakendamisega JDT-s, on seda mudelit suurema selguse huvides tahtlikult mõnevõrra lihtsustatud.)
Nagu varem märgitud, keskenduti Handly esialgse disaini ja sellele järgneva arenduse ajal ja on jätkuvalt skaleeritavusele ja paindlikkusele.
Põhimõtteliselt skaleeruvad käepidemepõhised mudelid “disainiga” üsna hästi. Näiteks käepideme/kere idioom võimaldab piirata mudeli tarbitava mälu hulka. Kuid on ka nüansse. Nii avastati Handly skaleeritavuse testimisel probleem teavitusmehhanismi juurutamises - suure hulga elementide muutmisel võttis deltade konstrueerimine liiga palju aega. Selgus, et sama probleem oli ka JDT Java mudelil, millest kunagi kohandati vastav kood. Parandasime vea Handlys ja valmistasime JDT jaoks sarnase plaastri, mis võeti tänuga vastu. See on vaid üks näide, kus Handly juurutamine olemasolevatesse mudelite juurutustesse võib olla kasulik, sest sel juhul saab sellise vea parandada vaid ühes kohas.
Et muuta Handly juurutamine olemasolevatesse mudelite juurutustesse tehniliselt teostatavaks, peab raamatukogul olema märkimisväärne paindlikkus. Peamine probleem on API-mudeli tagasiühilduvuse säilitamine. See probleem lahendati aastal eraldades selgelt arendaja määratletud ja täielikult juhitava mudelispetsiifilise API teegi pakutavast ühtsest metataseme API-st. See ei võimalda mitte ainult tehniliselt võimalikuks Handly juurutamist olemasolevatesse rakendustesse, vaid annab uue mudeli arendajale ka märkimisväärse vabaduse API kujundamisel.
Paindlikkusel on ka teisi aspekte. Näiteks Handly ei sea peaaegu mingeid piiranguid mudeli struktuurile ja seda saab kasutada nii üldotstarbeliste kui ka domeenispetsiifiliste keelte modelleerimiseks. Lähtefaili struktuuri koostamisel ei näe Handly ette mingit konkreetset AST-esituse vormi ega nõua põhimõtteliselt isegi AST-i enda olemasolu, tagades seega ühilduvuse peaaegu kõigi parsimismehhanismidega. Lõpuks toetab Handly täielikku integreerimist Eclipse'i tööruumiga, kuid suudab tänu integreerimisele ka failisüsteemidega otse töötada. (EFS).
Praegune versioon ilmus detsembris 2016. Hoolimata asjaolust, et projekt on praegu inkubatsioonifaasis ja API-liidest pole veel lõplikult parandatud, kasutatakse Handlyt juba kahes suures kommertstootes, mis võtsid riski tegutseda "varajase kasutuselevõtjana" ja pean ütlema, ei kahetse seda veel.
Nagu eespool märgitud, on üks neist toodetest 1C:Enterprise Development Tools, kus Handlyt kasutatakse algusest peale selliste 1C:Enterprise keelte kõrgetasemelise struktuuri elementide modelleerimiseks sisseehitatud programmeerimiskeele ja päringukeelena. . Veel üks toode on laiemale avalikkusele vähem tuntud. See , rakendusspetsiifilise juhiskomplekti protsessori (ASIP) integreeritud disainikeskkond, mida kasutavad nii Tšehhi ettevõte Codasip ise kui ka selle kliendid, sealhulgas , , , . Codasip on Handlyt tootmises kasutanud alates 2015. aastast alates Handly versioonist 0.2. Codasip Studio uusim väljalase kasutab versiooni 0.5, mis ilmus juunis 2016. Ondřej Ilčík, kes juhib Codasipi IDE arendust, on projektiga ühenduses, pakkudes olulist tagasisidet "kolmanda osapoole kasutuselevõtja" nimel. Ta suutis isegi leida vaba aega, et otseselt projekti arenduses osaleda, rakendades ühe Handly näite, Java mudeli jaoks kasutajaliidese kihti (~4000 koodirida). Täpsemat vahetut teavet Handly kasutamise kohta adopteerijate poolt leiate lehelt projekt.
Loodame, et pärast API stabiilsuse garantiiga versiooni 1.0 väljaandmist ja projekti inkubatsiooniolekust väljumist on Handlyl uued kasutajad. Vahepeal jätkab projekt API testimist ja täiustamist, avaldades aastas kaks "suurt" väljalaset – juunis (samal kuupäeval kui samaaegne Eclipse'i väljalase) ja detsembris, pakkudes prognoositavat ajakava, millele kasutajad saavad loota. Võime ka lisada, et projekti "vigade määr" püsib pidevalt madalal tasemel ja Handly on esimestest versioonidest saadik varajaste kasutajate toodetes töötanud usaldusväärselt. Eclipse Handly edasiseks uurimiseks võite kasutada и .
Allikas: www.habr.com