luultavasti ei ole pitkään aikaan vaatinut erityistä esittelyä. Monet ihmiset tuntevat Eclipsen Eclipse Java -kehitystyökalujen ansiosta (). Juuri tämä suosittu avoimen lähdekoodin Java IDE, jonka useimmat kehittäjät yhdistävät sanaan "Eclipse". Eclipse on kuitenkin sekä laajennettava alusta kehitystyökalujen integrointiin (Eclipse Platform) että useita sen pohjalta rakennettuja IDE:itä, mukaan lukien JDT. Eclipse on sekä Eclipse Project, huipputason projekti, joka koordinoi Eclipse Platformin ja JDT:n kehitystä, että Eclipse SDK, tuon kehityksen tulos. Lopuksi, Eclipse on avoimen lähdekoodin säätiö, jossa on valtava projektiyhteisö, joista kaikki eivät ole kirjoitettu Java-kielellä tai liity kehitystyökaluihin (esim. и ). Eclipsen maailma on hyvin monipuolinen.
Tässä artikkelissa, joka on luonteeltaan yleiskatsaus, yritämme tarkastella joitakin Eclipse-arkkitehtuurin perusteita alustana integroitujen kehitystyökalujen rakentamiselle ja antaa alustavan käsityksen Eclipse-komponenteista, jotka muodostavat tekniikan perustan. alusta "uudelle Configurator" 1C: Enterpriselle. . Tällainen arvostelu on tietysti väistämättä suurelta osin pinnallinen ja melko rajallinen, muun muassa siksi, että emme keskity vain Eclipsen kehittäjiin kohdeyleisönä. Toivomme kuitenkin, että jopa kokeneet Eclipse-kehittäjät voivat löytää mielenkiintoista tietoa artikkelista. Puhumme esimerkiksi yhdestä "Eclipsen salaisuuksista", suhteellisen uudesta ja vähän tunnetusta projektista , jonka perusti ja tuki 1C.
Johdatus Eclipse-arkkitehtuuriin
Katsotaanpa ensin joitain Eclipse-arkkitehtuurin yleisiä näkökohtia esimerkin avulla (JDT). JDT:n valinta esimerkkinä ei ole sattumaa. Tämä on ensimmäinen integroitu kehitysympäristö, joka ilmestyy Eclipseen. Muita *DT Eclipse -projekteja, kuten Eclipse C/C++ Development Tooling (CDT), luotiin myöhemmin ja ne lainaavat sekä arkkitehtonisia perusperiaatteita että yksittäisiä lähdekoodin fragmentteja JDT:ltä. JDT:ssä määritellyt arkkitehtuurin perusteet ovat relevantteja tähän päivään lähes kaikille Eclipse Platformin päälle rakennetuille IDE:ille, mukaan lukien 1C:Enterprise Development Tools.
Ensinnäkin on syytä huomata, että Eclipselle on ominaista melko selkeä arkkitehtoninen kerros, jossa kieliriippumattomat toiminnot on erotettu toiminnallisuuksista, jotka on suunniteltu tukemaan tiettyjä ohjelmointikieliä, ja käyttöliittymästä riippumattomat "ydinkomponentit" erotetaan niihin liittyvistä komponenteista. tukevalla käyttöliittymällä.
Siten Eclipse Platform määrittelee yhteisen, kielistä riippumattoman infrastruktuurin, ja Java-kehitystyökalut lisäävät Eclipseen täysin varustetun Java IDE:n. Sekä Eclipse Platform että JDT koostuvat useista komponenteista, joista kukin kuuluu joko käyttöliittymästä riippumattomaan "ytimeen" tai käyttöliittymäkerrokseen (kuva 1).
Riisi. 1. Eclipse Platform ja JDT
Listataan Eclipse Platformin pääkomponentit:
- Runtime — Määrittää laajennusinfrastruktuurin. Eclipselle on ominaista modulaarinen arkkitehtuuri. Pohjimmiltaan Eclipse on kokoelma "laajennuspisteitä" ja "laajennuksia".
- Työtila — Hallitsee yhtä tai useampaa projektia. Projekti koostuu kansioista ja tiedostoista, jotka on yhdistetty suoraan tiedostojärjestelmään.
- Standard Widget Toolkit (SWT) - Tarjoaa käyttöjärjestelmään integroidut peruskäyttöliittymäelementit.
- JFace — Tarjoaa useita SWT:n päälle rakennettuja käyttöliittymäkehyksiä.
- Työpöytä — Määrittää Eclipse UI -paradigman: editorit, näkymät, perspektiivit.
On sanottava, että Eclipse Platform tarjoaa myös monia muita hyödyllisiä komponentteja integroitujen kehitystyökalujen rakentamiseen, mukaan lukien Debug, Compare, Search ja Team. Erityisesti tulee mainita JFace Text - lähdekoodin "älykkäiden editorien" rakentamisen perusta. Valitettavasti edes pintapuolinen näiden komponenttien ja käyttöliittymäkerroksen osien tarkastelu ei ole mahdollista tämän artikkelin puitteissa, joten tämän osan loppuosassa rajoitamme yleiskatsaukseen Eclipse Platform ja JDT.
Core Runtime
Eclipse-laajennusinfrastruktuuri perustuu ja hankkeen tarjoama . Jokainen Eclipse-laajennus on OSGi-paketti. OSGi-spesifikaatio määrittelee erityisesti versiointi- ja riippuvuusratkaisumekanismit. Näiden vakiomekanismien lisäksi Equinox esittelee konseptin laajennuspisteitä. Jokainen laajennus voi määrittää omat laajennuspisteensä ja myös tuoda järjestelmään lisätoimintoja ("laajennuksia") samojen tai muiden laajennusten määrittämien laajennuspisteiden avulla. Yksityiskohtainen kuvaus OSGi- ja Equinox-mekanismeista ei kuulu tämän artikkelin piiriin. Huomattakoon vain, että Eclipsen modularisointi on täydellistä (mikä tahansa alijärjestelmä, mukaan lukien Runtime, koostuu yhdestä tai useammasta laajennuksesta), ja melkein kaikki Eclipsessä on laajennusta. Lisäksi nämä periaatteet upotettiin Eclipse-arkkitehtuuriin kauan ennen OSGi:n käyttöönottoa (silloin he käyttivät omaa tekniikkaansa, joka oli paljon samanlaista kuin OSGi).
Ydintyötila
Lähes mikä tahansa Eclipse Platformin päälle rakennettu integroitu kehitysympäristö toimii Eclipse-työtilan kanssa. Se on työtila, joka yleensä sisältää IDE:ssä kehitetyn sovelluksen lähdekoodin. Työtila kartoitetaan suoraan tiedostojärjestelmään ja koostuu projekteista, jotka sisältävät kansioita ja tiedostoja. Näitä projekteja, kansioita ja tiedostoja kutsutaan resursseja työtila. Eclipsen työtilatoteutus toimii välimuistina suhteessa tiedostojärjestelmään, mikä mahdollistaa resurssipuun läpikulkua merkittävästi nopeuttaen. Lisäksi työtila tarjoaa useita lisäpalveluita, mm и .
Core Resources -komponentti (org.eclipse.core.resources-laajennus) vastaa työtilan ja sen resurssien tukemisesta. Erityisesti tämä komponentti tarjoaa ohjelmallisen pääsyn lomakkeen työtilaan resurssimallit. Jotta asiakkaat voivat työskennellä tehokkaasti tämän mallin kanssa, he tarvitsevat yksinkertaisen tavan esittää linkki resurssiin. Tässä tapauksessa olisi toivottavaa piilottaa asiakkaan pääsyltä objekti, joka tallentaa suoraan mallin resurssin tilan. Muussa tapauksessa esimerkiksi tiedoston poistamisen tapauksessa asiakas voi jatkaa hallussaan objektia, joka ei enää ole mallissa, ja siitä aiheutuu ongelmia. Eclipse ratkaisee tämän ongelman käyttämällä jotain ns kahva resurssi. Kahva toimii avaimena (se tietää vain polun työtilassa olevaan resurssiin) ja hallitsee täysin pääsyä sisäiseen malliobjektiin, joka tallentaa suoraan tietoa resurssin tilasta. Tämä malli on mallin muunnelma .
Riisi. Kuva 2 havainnollistaa Handle/Body idiomia sovellettuna resurssimalliin. IResource-liitäntä edustaa resurssin kahvaa ja on API, toisin kuin Resource-luokka, joka toteuttaa tämän rajapinnan, ja ResourceInfo-luokka, joka edustaa runkoa, jotka eivät ole API. Korostamme, että kahva tietää vain polun resurssiin suhteessa työtilan juureen, eikä se sisällä linkkiä resurssitietoihin. Resurssitieto-objektit muodostavat niin sanotun "elementtipuun". Tämä tietorakenne on täysin materialisoitunut muistiin. Kahvaa vastaavan resurssitieto-ilmentymän löytämiseksi elementtipuu kulkee kyseiseen kahvaan tallennetun polun mukaan.
Riisi. 2. IResource ja ResourceInfo
Kuten myöhemmin näemme, resurssimallin perusrakennetta (saamme kutsua sitä kahvapohjaiseksi) käytetään Eclipsessä myös muissa malleissa. Listataan nyt joitain tämän mallin tunnusomaisia ominaisuuksia:
- Kahva on arvoobjekti. Arvooliot ovat muuttumattomia objekteja, joiden yhtäläisyys ei perustu identiteettiin. Tällaisia esineitä voidaan käyttää turvallisesti avaimena tiivistetyissä säiliöissä. Useat kahvan esiintymät voivat viitata samaan resurssiin. Vertaaksesi niitä, sinun on käytettävä equals(Object) -menetelmää.
- Kahva määrittelee resurssin toiminnan, mutta ei sisällä tietoa resurssin tilasta (ainoa data, jonka se tallentaa, on "avain", polku resurssiin).
- Kahva voi viitata resurssiin, jota ei ole olemassa (joko resurssiin, jota ei ole vielä luotu, tai resurssiin, joka on jo poistettu). Resurssin olemassaolo voidaan tarkistaa IResource.exists()-metodilla.
- Jotkin toiminnot voidaan toteuttaa pelkästään itse kahvaan tallennettujen tietojen perusteella (ns. kahvaa käsittelevät toiminnot). Esimerkkejä ovat IResource.getParent(), getFullPath() jne. Resurssin ei tarvitse olla olemassa, jotta tällainen toiminto onnistuisi. Toiminnot, jotka edellyttävät resurssin olemassaoloa onnistuakseen, aiheuttavat CoreExceptionin, jos resurssia ei ole olemassa.
Eclipse tarjoaa tehokkaan mekanismin työtilan resurssien muutoksista ilmoittamiseen (kuva 3). Resurssit voivat muuttua joko itse Eclipse IDE:ssä suoritettujen toimien seurauksena tai tiedostojärjestelmän kanssa tapahtuvan synkronoinnin seurauksena. Molemmissa tapauksissa ilmoituksia tilaaville asiakkaille tarjotaan yksityiskohtaista tietoa muutoksista "resurssideltojen" muodossa. Delta kuvaa muutoksia työtilan resurssi- (ali-)puun kahden tilan välillä ja on itse puu, jonka jokainen solmu kuvaa resurssin muutosta ja sisältää luettelon seuraavan tason deltaista, jotka kuvaavat aliresurssien muutoksia.
Riisi. 3. IResourceChangeEvent ja IResourceDelta
Resurssideltoihin perustuvalla ilmoitusmekanismilla on seuraavat ominaisuudet:
- Yksittäinen muutos ja monta muutosta kuvataan samalla rakenteella, koska delta on rakennettu rekursiivisen koostumuksen periaatteella. Tilaajaasiakkaat voivat käsitellä resurssien muutosilmoituksia käyttämällä rekursiivista laskeutumista deltapuun kautta.
- Delta sisältää täydelliset tiedot resurssin muutoksista, mukaan lukien sen liikkeestä ja/tai muutoksista siihen liittyvissä "merkitsijöissä" (esimerkiksi käännösvirheet esitetään markkereina).
- Koska resurssiviittaukset tehdään kahvan kautta, delta voi luonnollisesti viitata etäresurssiin.
Kuten pian näemme, resurssimallin muutosilmoitusmekanismin suunnittelun pääkomponentit ovat relevantteja myös muille kahvapohjaisille malleille.
JDT ydin
Eclipse-työtilan resurssimalli on peruskieliagnostinen malli. JDT Core -komponentti (plugin org.eclipse.jdt.core) tarjoaa API:n työtilan rakenteen navigointiin ja analysointiin Java-näkökulmasta, niin sanotun "Java-mallin" (Java malli). Tämä API määritellään Java-elementtien perusteella, toisin kuin taustalla oleva resurssimallin API, joka määritellään kansioiden ja tiedostojen perusteella. Java-elementtipuun päärajapinnat on esitetty kuvassa. 4.
Riisi. 4. Java-mallin elementit
Java-malli käyttää samaa kahva/runko-idiomia kuin resurssimalli (kuva 5). IJavaElement on kahva, ja JavaElementInfo esittää kehon roolia. IJavaElement-rajapinta määrittelee protokollan, joka on yhteinen kaikille Java-elementeille. Jotkut sen menetelmistä ovat vain käsitteleviä: getElementName(), getParent() jne. JavaElementInfo-objekti tallentaa vastaavan elementin tilan: sen rakenteen ja attribuutit.
Riisi. 5. IJavaElement ja JavaElementInfo
Java-mallissa on joitain eroja peruskahvan/rungon toteutuksessa resurssimalliin verrattuna. Kuten edellä todettiin, resurssimallissa elementtipuu, jonka solmut ovat resurssitieto-objekteja, sisältyy kokonaan muistiin. Mutta Java-mallissa voi olla huomattavasti enemmän elementtejä kuin resurssipuussa, koska se edustaa myös .java- ja .class-tiedostojen sisäistä rakennetta: tyyppejä, kenttiä ja menetelmiä.
Jotta vältetään koko elementtipuun toteutuminen muistissa, Java-mallin toteutus käyttää rajoitetun kokoista elementtitietojen LRU-välimuistia, jossa avain on kahva IJavaElement. elementtitieto-objekteja luodaan pyynnöstä, kun elementtipuuta navigoidaan. Tässä tapauksessa vähiten käytetyt kohteet poistetaan välimuistista ja mallin muistinkulutus rajoitetaan määritettyyn välimuistin kokoon. Tämä on toinen kahvapohjaisen suunnittelun etu, joka piilottaa tällaiset toteutustiedot täysin asiakaskoodista.
Java-elementtien muutoksista ilmoittamisen mekanismi on yleensä samanlainen kuin edellä käsitelty työtilaresurssien muutosten seurantamekanismi. Asiakas, joka haluaa seurata Java-mallin muutoksia, tilaa ilmoitukset, jotka esitetään ElementChangedEvent-objektina, joka sisältää IJavaElementDeltan (kuva 6).
Riisi. 6. ElementChangedEvent ja IJavaElementDelta
Java-malli ei sisällä tietoa menetelmärungoista tai nimien erottelusta, joten Java-kielellä kirjoitetun koodin yksityiskohtaista analysointia varten JDT Core tarjoaa ylimääräisen (ei-kahvapohjaisen) mallin: (abstrakti syntaksipuu, AST). AST edustaa lähdetekstin jäsentämisen tulosta. AST-solmut vastaavat lähdemoduulin rakenteen elementtejä (ilmoitukset, operaattorit, lausekkeet jne.) ja sisältävät tietoa vastaavan elementin koordinaateista lähdetekstissä sekä (valinnaisena) tietoa nimenratkaisusta linkkien muodossa ns siteet. Sidoitukset ovat objekteja, jotka edustavat kääntäjän tuntemia nimettyjä kokonaisuuksia, kuten tyyppejä, menetelmiä ja muuttujia. Toisin kuin AST-solmut, jotka muodostavat puun, sidokset tukevat ristiviittauksia ja muodostavat yleensä graafin. Abstrakti luokka ASTNode on yhteinen perusluokka kaikille AST-solmuille. ASTNode-alaluokat vastaavat tiettyjä Java-kielen syntaktisia rakenteita.
Koska syntaksipuut voivat kuluttaa huomattavan määrän muistia, JDT tallentaa välimuistiin vain yhden AST:n aktiiviselle editorille. Toisin kuin Java-malli, AST nähdään tyypillisesti "väliaikaisena", "väliaikaisena" mallina, jonka elementteihin asiakkaiden ei tulisi viitata AST:n luomiseen johtaneen toiminnan kontekstin ulkopuolelle.
Listatut kolme mallia (Java-malli, AST, sidokset) muodostavat yhdessä perustan "älykkäiden kehitystyökalujen" rakentamiselle JDT:ssä, mukaan lukien tehokas Java-editori erilaisilla "apuohjelmilla", erilaisilla toimilla lähdekoodin käsittelyyn (mukaan lukien tuontiluettelon järjestäminen). nimet ja muotoilu mukautetun tyylin mukaan), haku- ja uudelleenmuodostustyökalut. Tässä tapauksessa Java-mallilla on erityinen rooli, koska sitä käytetään visuaalisen esityksen perustana kehitettävän sovelluksen rakenteesta (esimerkiksi Package Explorerissa, Outlinessa, Searchissa, Call Hierarchyssa ja Tyyppi Hierarkia).
1C:Enterprise Developments Toolsissa käytetyt Eclipse-komponentit
Kuvassa Kuvassa 7 esitetään Eclipse-komponentit, jotka muodostavat 1C:Enterprise Development Toolsin teknologia-alustan perustan.
Riisi. 7. Eclipse alustana 1C:Enterprise Development Toolsille
Eclipse-alusta tarjoaa perusinfrastruktuurin. Tarkastelimme joitain tämän infrastruktuurin näkökohtia edellisessä osiossa.
(EMF) tarjoaa yleisen tavan mallintaa strukturoitua dataa. EMF on integroitu Eclipse Platformiin, mutta sitä voidaan käyttää myös erikseen tavallisissa Java-sovelluksissa. Melko usein uudet Eclipse-kehittäjät tuntevat jo hyvin EMF:n, vaikka he eivät vielä täysin ymmärrä Eclipse Platformin monimutkaisuutta. Yksi syy tällaiseen ansaituun suosioon on universaali muotoilu, joka sisältää muun muassa yhtenäisen metatason API:n, jonka avulla voit työskennellä minkä tahansa EMF-mallin kanssa yleisesti. EMF:n tarjoamat malliobjektien perustoteutukset ja metamalliin perustuva mallikoodin generointialijärjestelmä nopeuttavat merkittävästi kehitystä ja vähentävät virheiden määrää. EMF sisältää myös mekanismeja mallien sarjoittamiseksi, mallin muutosten seuraamiseksi ja paljon muuta.
Kuten kaikki aidosti yleiskäyttöiset työkalut, EMF soveltuu monenlaisten mallinnusongelmien ratkaisemiseen, mutta jotkin malliluokat (esimerkiksi edellä käsitellyt kahvapohjaiset mallit) saattavat vaatia erikoistuneempia mallinnustyökaluja. EMF:stä puhuminen on kiittämätöntä tehtävää, varsinkin yhden artikkelin rajatuissa rajoissa, koska tämä on erillisen kirjan aiheena ja melko paksussa. Huomattakoon vain, että EMF:n taustalla oleva laadukas yleistysjärjestelmä mahdollisti koko joukon mallintamiseen omistettuja projekteja, jotka sisältyvät huipputason projektiin. itse EMF:n kanssa. Yksi tällainen projekti on Eclipse Xtext.
tarjoaa "tekstin mallinnuksen" infrastruktuurin. Xtext käyttää lähdetekstin ja EMF:n jäsentämiseen tuloksena olevan ASG:n (abstrakti semanttinen graafi, joka on olennaisesti AST:n ja sidosten yhdistelmä), jota kutsutaan myös "semanttiseksi malliksi" edustamiseksi. Xtextin mallintaman kielen kielioppi on kuvattu Xtextin omalla kielellä. Tämän avulla voit luoda ANTLR:n kielioppikuvauksen lisäksi myös AST-serialisointimekanismin (eli Xtext tarjoaa sekä jäsentimen että erottimen), kontekstin vihjeen ja joukon muita kielikomponentteja. Toisaalta Xtextissä käytetty kielioppikieli on vähemmän joustava kuin esimerkiksi ANTLR:n kielioppikieli. Siksi joskus on tarpeen "taivuttaa" toteutettu kieli Xtextiksi, mikä ei yleensä ole ongelma, jos puhumme kielestä, jota kehitetään tyhjästä, mutta se voi olla mahdotonta hyväksyä kielille, joilla on jo vakiintunut syntaksi. Tästä huolimatta Xtext on tällä hetkellä Eclipsen kypsin, monipuolisin ja monipuolisin työkalu ohjelmointikielten ja niiden kehitystyökalujen rakentamiseen. Erityisesti se on ihanteellinen työkalu nopeaan prototyyppien luomiseen (verkkotunnuskohtainen kieli, DSL). Yllä mainitun ANTLR- ja EMF-pohjaisen "kieliytimen" lisäksi Xtext tarjoaa monia hyödyllisiä korkeamman tason komponentteja, mukaan lukien indeksointimekanismit, inkrementaalinen rakenne, "älykäs editori" ja paljon muuta, mutta jättää käsittelemättä perustuvia kielimalleja. Kuten EMF, myös Xtext on erillisen kirjan arvoinen aihe, ja sen kaikista ominaisuuksista tuskin voi nyt edes lyhyesti puhua.
1C:Enterprise Development Tools käyttää aktiivisesti sekä itse EMF:ää että useita muita Eclipse-mallinnusprojekteja. Erityisesti Xtext on yksi kehitystyökalujen perusta sellaisille 1C:Enterprise-kielille, kuten sisäänrakennettu ohjelmointikieli ja kyselykieli. Toinen perusta näille kehitystyökaluille on Eclipse Handly -projekti, josta keskustelemme tarkemmin (luetelluista Eclipse-komponenteista se on edelleen vähiten tunnettu).
, Eclipse Technologyn huipputason projektin aliprojekti, joka syntyi 1C:n vuonna 2014 tekemän alkuperäisen koodipanoksen seurauksena Eclipse Foundationille. Siitä lähtien 1C on jatkanut projektin kehittämisen tukemista: Kätevät sitoutujat ovat yrityksen työntekijöitä. Projekti on pieni, mutta sillä on melko ainutlaatuinen markkinarako Eclipsessä: sen päätavoitteena on tukea kahvapohjaisten mallien kehitystä.
Kahvapohjaisten mallien arkkitehtonisia perusperiaatteita, kuten kahva/runko-idiomia, käsiteltiin edellä käyttäen esimerkkinä resurssimallia ja Java-mallia. Se totesi myös, että sekä resurssimalli että Java-malli ovat tärkeä perusta Eclipse Java -kehitystyökaluille (JDT). Ja koska lähes kaikissa *DT Eclipse -projekteissa on JDT:n kaltainen arkkitehtuuri, ei olisi liioittelua sanoa, että kahvapohjaiset mallit ovat monien, ellei kaikkien Eclipse Platformin päälle rakennettujen IDE:iden taustalla. Esimerkiksi Eclipse C/C++ Development Toolingissa (CDT) on kahvapohjainen C/C++-malli, jolla on sama rooli CDT-arkkitehtuurissa kuin Java-mallilla JDT:ssä.
Ennen Handlya Eclipse ei tarjonnut erikoiskirjastoja kahvapohjaisten kielimallien rakentamiseen. Nykyiset mallit on luotu pääasiassa muokkaamalla suoraan Java-mallikoodia (alias kopioi/liitä), tapauksissa, joissa se sallii Eclipse Public License (EPL). (Tämä ei tietenkään ole yleensä oikeudellinen ongelma esimerkiksi itse Eclipse-projekteille, mutta ei suljetun lähdekoodin tuotteille.) Luontaisen sattumanvaraisuutensa lisäksi tämä tekniikka tuo mukanaan tunnettuja ongelmia: koodin päällekkäisyyksiä, jotka johtuvat virheisiin sopeutumisesta, jne. Pahinta on, että tuloksena saadut mallit pysyvät "asioita itsessään" eivätkä hyödynnä yhdistymismahdollisuuksia. Mutta yleisten käsitteiden ja protokollien eristäminen kahvapohjaisille kielimalleille voisi johtaa uudelleenkäytettävien komponenttien luomiseen niiden kanssa työskentelyä varten, kuten tapahtui EMF:n tapauksessa.
Kyse ei ole siitä, että Eclipse ei ymmärtänyt näitä asioita. Takaisin vuonna 2005 tiivistää CDT-prototyypin kehittämisestä saadut kokemukset, tarve luoda yhteinen infrastruktuuri kielimalleille, mukaan lukien kahvapohjaiset mallit. Mutta kuten usein tapahtuu, korkeamman prioriteetin tehtävien vuoksi näiden ideoiden toteuttaminen ei koskaan päässyt siihen. Samaan aikaan *DT-koodin tekijöihin lisääminen on edelleen yksi Eclipsen alikehittyneistä aiheista.
Tietyssä mielessä Handly-projekti on suunniteltu ratkaisemaan suunnilleen samoja ongelmia kuin EMF, mutta kahvapohjaisille malleille ja ensisijaisesti kielimalleille (eli jonkin ohjelmointikielen rakenteen elementtejä edustaville). Handlyn suunnittelussa asetetut päätavoitteet on lueteltu alla:
- Aihealueen tärkeimpien abstraktioiden tunnistaminen.
- Vähentää työtä ja parantaa kahvapohjaisten kielimallien toteutuksen laatua koodin uudelleenkäytön avulla.
- Yhtenäisen metatason API tarjoaminen tuloksena oleville malleille, mikä mahdollistaa yhteisten IDE-komponenttien luomisen, jotka toimivat kielikahvapohjaisten mallien kanssa.
- Joustavuus ja skaalautuvuus.
- Integrointi Xtextin kanssa (erillinen kerros).
Yleisten käsitteiden ja protokollien esille tuomiseksi analysoitiin olemassa olevia kielikahvapohjaisten mallien toteutuksia. Handlyn tarjoamat päärajapinnat ja perustoteutukset on esitetty kuvassa. 8.
Riisi. 8. Handly-elementtien yhteiset rajapinnat ja perustoteutukset
IElement-rajapinta edustaa elementin kahvaa ja on yhteinen kaikille Handly-pohjaisten mallien elementeille. Abstrakti luokka Element toteuttaa yleisen kädensija/runkomekanismin (kuva 9).
Riisi. 9. IEelementti ja yleinen kahva/runko-toteutus
Lisäksi Handly tarjoaa yleisen mekanismin mallin elementtien muutoksista ilmoittamiseen (kuva 10). Kuten näet, se on suurelta osin samanlainen kuin resurssimallissa ja Java-mallissa toteutetut ilmoitusmekanismit, ja se käyttää IElementDeltaa elementtien muutostietojen yhtenäisen esityksen tarjoamiseen.
Riisi. 10. Handly-ilmoitusmekanismin yleiset rajapinnat ja perustoteutukset
Yllä käsiteltyä Handly-osaa (kuvat 9 ja 10) voidaan käyttää edustamaan lähes mitä tahansa kahvapohjaisia malleja. Luomiseen kielellinen mallit, projekti tarjoaa lisätoimintoja - erityisesti yhteisiä rajapintoja ja perustoteutuksia lähdetekstirakenteen elementeille, ns. lähdeelementtejä (Kuva 8). ISourceFile-liitäntä edustaa lähdetiedostoa ja ISourceConstruct edustaa lähdetiedoston elementtiä. Abstraktit luokat SourceFile ja SourceConstruct toteuttavat yleistettyjä mekanismeja lähdetiedostojen ja niiden elementtien kanssa työskentelyn tukemiseksi, esimerkiksi työskentely tekstipuskureiden kanssa, sitoutuminen lähdetekstin elementin koordinaatteihin, mallien yhteensovittaminen työkopiopuskurin nykyisen sisällön kanssa. , jne. Näiden mekanismien käyttöönotto on yleensä melkoinen haaste, ja Handly voi merkittävästi vähentää kahvapohjaisten kielimallien kehittämistä tarjoamalla korkealaatuisia perustoteutuksia.
Yllä lueteltujen ydinmekanismien lisäksi Handly tarjoaa infrastruktuurin tekstipuskureille ja tilannevedoksille, tuen integraatiolle lähdekoodieditorien kanssa (mukaan lukien integrointi Xtext-editorin kanssa) sekä joitakin yleisiä käyttöliittymäkomponentteja, jotka Työskentele lähdekoodieditorien kanssa. Käteviä malleja, kuten ääriviivakehystä. Havainnollistaakseen sen kykyjä projekti tarjoaa useita esimerkkejä, mukaan lukien Java-mallin toteutuksen Handlyssa. (Verrattuna Java-mallin täydelliseen toteutukseen JDT:ssä, tätä mallia on tarkoituksella yksinkertaistettu jonkin verran selvyyden lisäämiseksi.)
Kuten aiemmin todettiin, Handlyn alkuperäisen suunnittelun ja myöhemmän kehityksen aikana pääpaino oli ja on edelleen skaalautuvuus ja joustavuus.
Periaatteessa kahvapohjaiset mallit skaalautuvat melko hyvin "suunnittelun mukaan". Esimerkiksi kahvan/rungon idiomin avulla voit rajoittaa mallin käyttämän muistin määrää. Mutta on myös vivahteita. Siten Handlyn skaalautuvuutta testattaessa havaittiin ongelma ilmoitusmekanismin toteutuksessa - kun suuri määrä elementtejä muutettiin, deltojen rakentaminen vei liikaa aikaa. Kävi ilmi, että sama ongelma oli JDT Java -mallissa, josta vastaava koodi oli aikoinaan sovitettu. Korjasimme virheen Handlyssa ja valmistelimme vastaavan korjaustiedoston JDT:lle, joka otettiin kiitollisena vastaan. Tämä on vain yksi esimerkki, jossa Handlyn lisääminen olemassa oleviin mallitoteutuksiin voisi olla hyödyllistä, koska tässä tapauksessa tällainen bugi voitaisiin korjata vain yhdestä paikasta.
Jotta Handlyn toteuttaminen olemassa oleviin mallitoteutuksiin olisi teknisesti mahdollista, kirjastossa on oltava huomattavaa joustavuutta. Suurin ongelma on säilyttää taaksepäin yhteensopivuus API-mallissa. Tämä ongelma ratkesi vuonna erottamalla selkeästi mallikohtainen API, jonka kehittäjä määrittelee ja hallitsee täysin, kirjaston tarjoamasta yhtenäisestä metatason API:sta. Tämä ei ainoastaan mahdollista teknisesti Handlyn toteuttamista olemassa oleviin toteutuksiin, vaan antaa myös uuden mallin kehittäjälle huomattavan vapauden API:n suunnittelussa.
Joustavuudella on myös muita puolia. Esimerkiksi Handly ei aseta juuri mitään rajoituksia mallin rakenteelle ja sitä voidaan käyttää sekä yleiskäyttöisten että toimialuekohtaisten kielten mallintamiseen. Lähdetiedoston rakennetta rakentaessaan Handly ei määrää mitään erityistä AST-esitysmuotoa eikä periaatteessa edes vaadi itse AST:n läsnäoloa, mikä varmistaa yhteensopivuuden lähes minkä tahansa jäsennysmekanismin kanssa. Lopuksi Handly tukee täyttä integraatiota Eclipse-työtilan kanssa, mutta voi myös toimia suoraan tiedostojärjestelmien kanssa integroinnin ansiosta (EFS).
Nykyinen versio ilmestyi joulukuussa 2016. Huolimatta siitä, että projekti on tällä hetkellä inkubaatiotilassa eikä APIa ole vielä lopullisesti korjattu, Handlya käytetään jo kahdessa suuressa kaupallisessa tuotteessa, jotka ottivat riskin toimia "varhaisina käyttäjinä", ja minun on sanottava, että älä kadu sitä vielä.
Kuten edellä todettiin, yksi näistä tuotteista on 1C:Enterprise Development Tools, jossa Handlyä käytetään alusta alkaen mallintamaan elementtejä tällaisten 1C:Enterprise-kielten korkean tason rakenteesta, kuten sisäänrakennettu ohjelmointikieli ja kyselykieli. . Toinen tuote on vähemmän tunnettu suurelle yleisölle. Tämä , integroitu suunnitteluympäristö sovelluskohtaiselle ohjesarjaprosessorille (ASIP), jota käyttävät sekä tšekkiläinen Codasip itse että sen asiakkaat, mukaan lukien , , , . Codasip on käyttänyt Handlyä tuotannossa vuodesta 2015 lähtien Handly 0.2 -versiosta alkaen. Codasip Studion uusin versio käyttää versiota 0.5, joka julkaistiin kesäkuussa 2016. Ondřej Ilčík, joka johtaa IDE-kehitystä Codasipissa, on yhteydessä projektiin ja antaa elintärkeää palautetta "kolmannen osapuolen omaksujan" puolesta. Hän pystyi jopa löytämään vapaa-aikaa osallistuakseen suoraan projektin kehittämiseen toteuttaen käyttöliittymäkerroksen (~4000 koodiriviä) yhdelle Handly-esimerkistä, Java-mallista. Tarkempaa ensikäden tietoa omaksujien Handlyn käytöstä löytyy sivulta projekti.
Toivomme, että sovellusliittymän vakauden takaavan version 1.0 julkaisun ja inkubaatiotilasta poistuneen projektin jälkeen Handly saa uusia käyttäjiä. Sillä välin projekti jatkaa API:n testaamista ja parantamista edelleen julkaisemalla kaksi "suuria" julkaisua vuodessa - kesäkuussa (sama päivä kuin samanaikainen Eclipse-julkaisu) ja joulukuussa, mikä tarjoaa ennakoitavan aikataulun, johon omaksujat voivat luottaa. Voimme myös lisätä, että projektin "vikaprosentti" pysyy jatkuvasti alhaisella tasolla ja Handly on toiminut luotettavasti varhaisten käyttäjien tuotteissa ensimmäisistä versioista lähtien. Voit tutkia Eclipse Handlyä tarkemmin käyttämällä и .
Lähde: will.com