Waarskynlik, het nie meer 'n spesiale inleiding nodig nie. Baie mense is vertroud met Eclipse danksy die Eclipse Java-ontwikkelingsinstrumente (). Dit is hierdie gewilde oopbron Java IDE wat die meeste ontwikkelaars met die woord "Eclipse" assosieer. Eclipse is egter beide 'n uitbreidbare platform vir die integrasie van ontwikkelingsinstrumente (Eclipse Platform), en 'n aantal IDE's wat bo-op dit gebou is, insluitend JDT. Eclipse is beide die Eclipse Project, die topvlak projek wat die ontwikkeling van die Eclipse Platform en die JDT koördineer, en die Eclipse SDK, die lewerbare resultaat van daardie ontwikkeling. Ten slotte, Eclipse is 'n oopbron-stigting met 'n groot gemeenskap van projekte, wat nie almal in Java geskryf is of verband hou met ontwikkelingsinstrumente nie (byvoorbeeld projekte и ). Die wêreld van Eclipse is baie uiteenlopend.
In hierdie oorsigartikel sal ons probeer om sommige van die basiese beginsels van die Eclipse-argitektuur te oorweeg as 'n platform vir die bou van geïntegreerde ontwikkelingsinstrumente en 'n aanvanklike idee gee van die Eclipse-komponente wat die grondslag vorm van die tegnologiese platform vir die " nuwe konfigurator” 1C: Enterprise, . Natuurlik sal so 'n resensie onvermydelik grootliks oppervlakkig en taamlik beperk wees, ook omdat ons nie net Eclipse-ontwikkelaars as die teikengehoor teiken nie. Ons hoop egter dat selfs ervare Eclipse-ontwikkelaars interessante inligting in die artikel sal kan vind. Ons sal byvoorbeeld praat oor een van die "geheime van Eclipse", 'n relatief nuwe en min bekende projek tot dusver. , wat deur 1C gestig en onderhou is.
Inleiding tot die Eclipse-argitektuur
Kom ons kyk eers na 'n paar algemene aspekte van die Eclipse-argitektuur deur 'n voorbeeld te gebruik (JDT). Die keuse van JDT as voorbeeld is nie toevallig nie. Dit is die eerste IDE wat in Eclipse verskyn. Ander *DT Eclipse-projekte, soos die Eclipse C/C++ Development Tooling (CDT), is later geskep en het beide die hoof argitektoniese beginsels en bronkode-fragmente van die JDT geleen. Die grondbeginsels van die argitektuur wat in die JDT neergelê is, is tot vandag toe relevant vir byna enige IDE wat bo-op die Eclipse Platform gebou is, insluitend 1C: Enterprise Development Tools.
Eerstens moet daarop gelet word dat Eclipse gekenmerk word deur 'n redelik duidelike argitektoniese stratifikasie, met die skeiding van taalonafhanklike funksionaliteit van die funksionaliteit wat ontwerp is om spesifieke programmeertale te ondersteun, en die skeiding van UI-onafhanklike "kern" (kern) komponente van komponente wat met gebruikersondersteuning verband hou.
Byvoorbeeld, die Eclipse-platform definieer 'n gemeenskaplike, taalonafhanklike infrastruktuur, en die Java-ontwikkelingsinstrumente voeg 'n volledige Java IDE by Eclipse. Beide die Eclipse Platform en die JDT bestaan uit verskeie komponente, wat elk 'n UI-onafhanklike "kern" of 'n UI-laag is (Figuur 1).
Rys. 1. Eclipse Platform en JDT
Ons lys die hoofkomponente van die Eclipse-platform:
- Runtime - Definieer die inprop-infrastruktuur. Eclipse het 'n modulêre argitektuur. Eclipse is in wese 'n versameling van "uitbreidingspunte" en "uitbreidings".
- Werkruimte - Bestuur een of meer projekte. 'n Projek bestaan uit dopgehou en lêers wat direk na die lêerstelsel gekarteer word.
- Standaard Widget Toolkit (SWT) - Verskaf basiese gebruikerskoppelvlak-elemente wat met die bedryfstelsel geïntegreer is.
- JGesig - Bied 'n reeks UI-raamwerke wat bo-op SWT gebou is.
- Werkbank - Definieer die Eclipse UI-paradigma: redakteurs, sienings, perspektiewe.
Ek moet sê dat die Eclipse-platform baie ander nuttige komponente bied vir die bou van geïntegreerde ontwikkelingsinstrumente, waaronder Ontfouting, Vergelyk, Soek en Span. Ons moet ook JFace Text noem - die basis vir die bou van "slim redigeerders" van die bronkode. Ongelukkig is selfs 'n vlugtige hersiening van hierdie komponente, sowel as die UI-laagkomponent, nie moontlik binne die raamwerk van hierdie artikel nie, so in die res van hierdie afdeling sal ons ons beperk tot die hersiening van die hoof "kern" komponente van die Eclipse Platform en JDT.
kern looptyd
Die Eclipse Plugin Framework is gebaseer op en verskaf deur die projek . Elke Eclipse-inprop is 'n OSGi-bundel. Die OSGi-spesifikasie definieer, onder andere, weergawe- en afhanklikheidsresolusiemeganismes. Benewens hierdie standaardmeganismes, stel Equinox die konsep bekend verlengingspunte. Elke inprop kan sy eie uitbreidingspunte definieer, sowel as bykomende funksionaliteit ("uitbreidings") by die stelsel voeg deur uitbreidingspunte te gebruik wat deur dieselfde of ander inproppe gedefinieer word. Enige gedetailleerde beskrywing van die OSGi- en Equinox-meganismes is buite die bestek van hierdie artikel. Ons let net op dat modularisering in Eclipse totaal is (enige substelsel, insluitend die Runtime, bestaan uit een of meer plugins), en byna alles in Eclipse is 'n uitbreiding. Boonop is hierdie beginsels in die Eclipse-argitektuur geïnkorporeer lank voor die bekendstelling van OSGi (destyds is hul eie tegnologie gebruik, in baie opsigte soortgelyk aan OSGi).
kern werkspasie
Byna enige IDE wat bo-op die Eclipse-platform gebou is, werk saam met die Eclipse-werkspasie. Dit is die werkspasie wat gewoonlik die bronkode bevat van die toepassing wat in die IDE ontwikkel word. Werkspasie kaart direk na die lêerstelsel en bestaan uit projekte wat dopgehou en lêers bevat. Hierdie projekte, dopgehou en lêers word genoem hulpbronne werkspasie. Die implementering van werkspasie in Eclipse dien as 'n kas in verhouding tot die lêerstelsel, wat die deurkruising van hulpbronboom aansienlik kan bespoedig. Daarbenewens bied werkspasie 'n aantal bykomende dienste, insluitend и .
Die Core Resources-komponent (org.eclipse.core.resources-inprop) is verantwoordelik vir die ondersteuning van die werkspasie en sy hulpbronne. Hierdie komponent bied veral programmatiese toegang tot die werkspasie in die vorm hulpbronmodelle. Om effektief met hierdie model te werk, het kliënte 'n eenvoudige manier nodig om 'n skakel na 'n hulpbron voor te stel. Terselfdertyd sal dit wenslik wees om die voorwerp wat die toestand van die hulpbron direk in die model stoor, weg te steek vir kliënttoegang. Andersins, in die geval van byvoorbeeld die verwydering van 'n lêer, kan die kliënt voortgaan om 'n voorwerp te hou wat nie meer in die model is nie, met die daaropvolgende probleme. Eclipse los hierdie probleem op deur die sg hanteer hulpbron. Handvatsel dien as 'n sleutel (dit ken net die pad na die hulpbron in die werkspasie) en beheer heeltemal toegang tot die interne modelvoorwerp, wat inligting oor die toestand van die hulpbron direk stoor. Hierdie ontwerp is 'n variasie van die patroon .
Rys. 2 illustreer die handvatsel/liggaam-idioom soos toegepas op 'n hulpbronmodel. Die IResource-koppelvlak verteenwoordig die handvatsel van 'n hulpbron en is 'n API, anders as die Resource-klas wat hierdie koppelvlak implementeer, en die ResourceInfo-klas wat liggaam verteenwoordig, wat nie API's is nie. Ons beklemtoon dat handvatsel slegs die pad na die hulpbron ken relatief tot die werkspasiewortel en nie 'n skakel na hulpbroninligting bevat nie. Hulpbroninligting-objekte vorm wat bekend staan as 'n "elementboom". Hierdie datastruktuur word volledig in die geheue gematerialiseer. Om 'n hulpbroninligting-instansie te vind wat ooreenstem met een of ander handvatsel, word die elementboom deurkruis volgens die pad wat in daardie handvatsel gestoor is.
Rys. 2. IResource en ResourceInfo
Soos ons later sal sien, word die basiese ontwerp van die hulpbronmodel (jy kan dit handvatselgebaseerd noem) in Eclipse en vir ander modelle gebruik word. Intussen is hier 'n paar van die onderskeidende kenmerke van hierdie ontwerp:
- Handvatsel is 'n waarde-objek. Waarde-objekte is onveranderlike objekte waarvan die gelykheid nie op identiteit gebaseer is nie. Sulke voorwerpe kan veilig as 'n sleutel in gehakte houers gebruik word. Veelvuldige gevalle van handvatsel kan na dieselfde hulpbron verwys. Om hulle te vergelyk, gebruik die gelyk (Object) metode.
- Handvatsel definieer die gedrag van die hulpbron, maar bevat nie inligting oor die toestand van die hulpbron nie (die enigste data wat dit stoor is die "sleutel", die pad na die hulpbron).
- Hanteer kan verwys na 'n hulpbron wat nie bestaan nie (óf 'n hulpbron wat nog nie geskep is nie, óf 'n hulpbron wat reeds uitgevee is). Die bestaan van 'n hulpbron kan nagegaan word met behulp van die IResource.exists() metode.
- Sommige bewerkings kan geïmplementeer word uitsluitlik op grond van die inligting wat in die handvatsel self gestoor is (die sogenaamde handvatsel-alleen-operasies). Voorbeelde is IResource.getParent(), getFullPath(), ens. Die hulpbron hoef nie te bestaan vir so 'n operasie om te slaag nie. Bewerkings wat vereis dat die hulpbron bestaan om suksesvol te wees, gooi 'n uitsondering (CoreException) as die hulpbron nie bestaan nie.
Eclipse bied 'n doeltreffende meganisme om veranderinge aan werkspasiehulpbronne in kennis te stel (Figuur 3). Hulpbronne kan beide verander as gevolg van aksies wat in die Eclipse IDE self uitgevoer word, en as gevolg van sinchronisasie met die lêerstelsel. In beide gevalle word kliënte wat op die kennisgewings inteken, voorsien van gedetailleerde inligting oor die veranderinge in die vorm van "hulpbrondelta's" (hulpbrondelta). 'n Delta beskryf veranderinge tussen twee toestande van 'n werkruimte hulpbron (sub-) boom en is self 'n boom, waarvan elke nodus 'n verandering aan een of ander hulpbron beskryf en bevat 'n lys van volgende vlak delta's wat veranderinge aan kinderhulpbronne beskryf.
Rys. 3. IResourceChangeEvent en IResourceDelta
Die kennisgewingmeganisme gebaseer op hulpbrondeltas het die volgende kenmerke:
- 'n Enkele verandering en baie veranderinge word met dieselfde struktuur beskryf, aangesien die delta volgens die beginsel van rekursiewe samestelling gebou is. Intekenaarkliënte kan hulpbronveranderingkennisgewings verwerk deur rekursief te daal in die deltaboom.
- Die delta bevat volledige inligting oor die verandering van die hulpbron, insluitend die beweging daarvan en/of verandering van die "merkers" wat daarmee geassosieer word (merkers verteenwoordig byvoorbeeld samestellingsfoute).
- Omdat hulpbronverwysings deur die handvatsel gemaak word, kan die delta natuurlik na 'n afgeleë hulpbron verwys.
Soos ons binnekort sal sien, is die hoofontwerpelemente van die kennisgewingmeganisme vir hulpbronmodelverandering ook relevant vir ander handvatselgebaseerde modelle.
JDT kern
Die Eclipse-werkruimtehulpbronmodel is 'n fundamentele taalonafhanklike model. Die JDT Core-komponent (org.eclipse.jdt.core-inprop) verskaf 'n API om die werkspasiestruktuur vanuit 'n Java-perspektief te navigeer en te ontleed, die sogenaamde "Java-model" (java model). Hierdie API word gedefinieer in terme van Java-elemente, in teenstelling met die onderliggende hulpbronmodel API, wat in terme van dopgehou en lêers gedefinieer word. Die hoofkoppelvlakke van die Java-elementboom word in Fig. 4.
Rys. 4. Java Model Elemente
Die Java-model gebruik dieselfde handvatsel/liggaam-idioom as die hulpbronmodel (Figuur 5). IJavaElement is die handvatsel en JavaElementInfo is die liggaam. Die IJavaElement-koppelvlak definieer 'n protokol wat algemeen is vir alle Java-elemente. Sommige van sy metodes is slegs handvatsel: getElementName(), getParent(), ensovoorts. Die JavaElementInfo-objek stoor die toestand van die ooreenstemmende element: sy struktuur en eienskappe.
Rys. 5. IJavaElement en JavaElementInfo
Die Java-model het 'n paar verskille in die implementering van die basiese handvatsel/liggaamontwerp in vergelyking met die hulpbronmodel. Soos hierbo genoem, in 'n hulpbronmodel, is 'n elementboom waarvan die nodusse hulpbroninligting-objekte is, geheel en al in die geheue vervat. Maar 'n Java-model kan 'n baie groter aantal elemente as 'n hulpbronboom hê, want dit bevat ook die interne struktuur van .java- en .class-lêers: tipes, velde en metodes.
Om te verhoed dat die hele elementboom in die geheue heeltemal materialiseer, gebruik die Java-modelimplementering 'n groottebeperkte elementinligting LRU-kas, waar die sleutel hanteer IJavaElement is. Elementinligting-objekte word op aanvraag geskep soos die elementboom navigeer word. In hierdie geval word die elemente wat die minste gebruik word, uit die kas verwyder, en die geheueverbruik van die model bly beperk deur die gespesifiseerde kasgrootte. Dit is nog 'n voordeel van handvatselgebaseerde ontwerp, wat sulke implementeringbesonderhede heeltemal van kliëntkode verberg.
Die meganisme om veranderinge aan Java-elemente in kennis te stel, is oor die algemeen soortgelyk aan die meganisme om werkspasiehulpbronveranderinge na te spoor wat hierbo bespreek is. 'n Kliënt wat veranderinge in die Java-model wil naspoor, teken in op kennisgewings, wat voorgestel word as 'n ElementChangedEvent-objek wat 'n IJavaElementDelta bevat (Figuur 6).
Rys. 6.ElementChangedEvent en IJavaElementDelta
Die Java-model bevat nie inligting oor die liggaam van metodes of naamresolusie nie, so vir 'n gedetailleerde ontleding van kode wat in Java geskryf is, verskaf JDT Core 'n bykomende (nie-handvatsel-gebaseerde) model: (abstrakte sintaksboom, AST). AST verteenwoordig die resultaat van die ontleding van die oorspronklike teks. AST-nodusse stem ooreen met bronmodulestruktuurelemente (verklarings, operateurs, uitdrukkings, ens.) en bevat inligting oor die koördinate van die ooreenstemmende element in die bronteks, sowel as (opsioneel) naamresolusie-inligting in die vorm van skakels na so- geroep bindings. Bindings is voorwerpe wat benoemde entiteite verteenwoordig soos tipes, metodes en veranderlikes wat aan die samesteller bekend is. Anders as AST-nodes wat 'n boom vorm, ondersteun bindings kruisverwysings en vorm gewoonlik 'n grafiek. Die abstrakte klas ASTNode is die algemene basisklas vir alle AST nodusse. Subklasse van ASTNode stem ooreen met sekere sintaksiskonstrukte van die Java-taal.
Omdat sintaksisbome 'n aansienlike hoeveelheid geheue kan verbruik, kas die JDT slegs een AST, per aktiewe redigeerder. Anders as die Java-model, word die AST oor die algemeen beskou as 'n "intermediêre", "tydelike" model waarvan die elemente nie deur kliënte behou moet word buite die konteks van die operasie wat die AST geskep het nie.
Hierdie drie modelle (Java-model, AST, bindings) vorm saam die basis vir die bou van "intelligente ontwikkelingshulpmiddels" in JDT, insluitend 'n kragtige Java-redigeerder met verskeie "helpers", verskeie aksies vir die verwerking van bronkode (insluitend die organisering van 'n naaminvoerlys en formatering volgens die pasgemaakte styl), soek- en herfaktoreringsinstrumente. In hierdie geval speel die Java-model 'n spesiale rol, aangesien dit gebruik word as die basis vir die visuele voorstelling van die struktuur van die ontwikkelde toepassing (byvoorbeeld in die Pakketverkenner, Oorsig, Soek, Oproephiërargie en Tik hiërargie).
Eclipse-komponente wat in 1C:Enterprise Developments Tools gebruik word
Op fig. Figuur 7 toon die Eclipse-komponente wat die grondslag vorm van die tegnologieplatform vir 1C:Enterprise Development Tools.
Rys. 7. Eclipse as 'n platform vir 1C:Enterprise Development Tools
Eclipse Platform verskaf die basiese infrastruktuur. Ons het 'n paar aspekte van hierdie infrastruktuur in die vorige afdeling behandel.
(EMF) verskaf 'n algemene manier om gestruktureerde data te modelleer. EMF is geïntegreer met die Eclipse-platform, maar kan ook selfstandig in gewone Java-toepassings gebruik word. Dikwels is beginner Eclipse-ontwikkelaars reeds redelik bekend met EMF, hoewel hulle nog nie die ingewikkeldhede van die Eclipse-platform ten volle verstaan nie. Een van die redes vir sulke welverdiende gewildheid is die universele ontwerp, wat onder meer 'n verenigde meta-vlak API insluit, wat jou toelaat om met enige EMF-model in die algemeen te werk. Die basisimplementerings wat deur EMF vir modelobjekte verskaf word en die substelsel vir die generering van modelkode vanaf die metamodel verhoog die spoed van ontwikkeling aansienlik en verminder die aantal foute. EMF bevat ook meganismes om modelle te serialiseer, veranderinge in die model op te spoor, en nog baie meer.
Soos enige werklik veelsydige instrument, is EMF geskik vir 'n wye reeks modelleringstake, maar sommige klasse modelle (byvoorbeeld die handvatselgebaseerde modelle wat hierbo bespreek is) sal dalk meer gespesialiseerde modelleringsgereedskap benodig. Om oor EMF te praat is 'n ondankbare taak, veral binne die beperkte raamwerk van een artikel, aangesien dit die onderwerp van 'n aparte boek is, en nogal 'n dik een. Ons let net op dat die kwalitatiewe stelsel van veralgemenings onderliggend aan die EMF die geboorte van 'n hele reeks modelleringsprojekte moontlik gemaak het wat by die topvlakprojek ingesluit is. saam met die EMF self. Een so 'n projek is Eclipse Xtext.
bied 'n "teksmodellering"-infrastruktuur. Xtext gebruik vir die ontleding van die bronteks en EMF om die gevolglike ASG (abstrakte semantiese grafiek, wat in werklikheid 'n kombinasie van AST en bindings is), ook genoem die "semantiese model" voor te stel. Die grammatika van 'n taal wat met Xtext gemodelleer is, word in Xtext se moedertaal beskryf. Dit laat nie net toe om 'n grammatikabeskrywing vir ANTLR te genereer nie, maar ook om die AST-serialiseringsmeganisme te kry (d.w.s. Xtext verskaf beide ontleder en ontparer), kontekswenk en 'n aantal ander taalkomponente. Aan die ander kant is die grammatikabeskrywingstaal wat in Xtext gebruik word, minder buigsaam as byvoorbeeld die grammatikabeskrywingstaal in ANTLR. Daarom is dit soms nodig om die geïmplementeerde taal na Xtext te "buig", wat gewoonlik nie 'n probleem is wanneer dit kom by 'n taal wat van nuuts af ontwikkel is nie, maar onaanvaarbaar kan wees vir tale met 'n reeds gevestigde sintaksis. Ten spyte hiervan is Xtext tans die mees volwasse, kenmerkryke en veelsydige instrument in Eclipse om programmeertale en ontwikkelingsinstrumente daarvoor te bou. Dit is veral 'n ideale hulpmiddel vir vinnige prototipering. (domeinspesifieke taal, DSL). Benewens die ANTLR- en EMF-gebaseerde "taalkern" hierbo genoem, verskaf Xtext baie nuttige hoërvlakkomponente, insluitend indekseringsmeganismes, inkrementele bou, 'n "slim redigeerder" en baie, baie meer, maar laat die handvatsel uit. gebaseerde taalmodelle. Soos EMF, is Xtext 'n onderwerp wat 'n aparte boek waardig is, en ons kan nou nie eers kortliks al sy vermoëns beskryf nie.
1C: Ondernemingsontwikkelingshulpmiddels gebruik beide EMF self en 'n aantal ander Eclipse Modeling-projekte aktief. Xtext is veral een van die grondslae van ontwikkelingsinstrumente vir sulke 1C: Enterprise-tale as die ingeboude programmeertaal en navraagtaal. Nog 'n basis vir hierdie ontwikkelingsinstrumente is die Eclipse Handly-projek, waaroor ons in meer besonderhede sal stilstaan (van die Eclipse-komponente wat gelys is, is dit steeds die minste bekend).
, 'n subprojek van die Eclipse Technology-hoëvlakprojek, het ontstaan uit 'n aanvanklike kodebydrae tot die Eclipse Foundation deur 1C in 2014. Sedertdien ondersteun 1C steeds die ontwikkeling van die projek: Handige toewyders is werknemers van die maatskappy. Die projek is klein, maar dit beslaan 'n redelik unieke nis in Eclipse: sy hoofdoel is om die ontwikkeling van handvatselgebaseerde modelle te ondersteun.
Die basiese argitektoniese beginsels van handvatselgebaseerde modelle, soos die handvatsel/liggaam-idioom, is hierbo bespreek deur die hulpbronmodel en die Java-model as voorbeeld te gebruik. Dit het ook opgemerk dat beide die hulpbronmodel en die Java-model belangrike grondslae is vir die Eclipse Java-ontwikkelingsinstrumente (JDT). En aangesien byna alle Eclipse *DT-projekte 'n argitektuur soortgelyk aan JDT het, sal dit nie 'n groot oordrywing wees om te sê dat handvatselgebaseerde modelle onderliggend is aan baie, indien nie alle IDE's wat bo-op die Eclipse-platform gebou is nie. Byvoorbeeld, Eclipse C/C++ Development Tooling (CDT) het 'n handvatselgebaseerde C/C++-model wat dieselfde rol in die CDT-argitektuur speel as die Java-model in die JDT.
Voor Handly het Eclipse nie gespesialiseerde biblioteke aangebied vir die bou van handvatselgebaseerde taalmodelle nie. Modelle wat vandag bestaan, is hoofsaaklik geskep deur die Java-modelkode direk aan te pas (ook bekend as kopieer/plak), in gevalle waar dit toelaat Eclipse Public License (EPL). (Natuurlik, vir byvoorbeeld Eclipse se eie projekte, is dit gewoonlik nie 'n regskwessie nie, wat nie die geval is vir geslotebronprodukte nie.) Benewens sy kenmerkende lukraak, lei hierdie tegniek tot bekende probleme: kodeduplisering wat deur wanneer daar by foute aangepas word, ens. Nog erger, die resulterende modelle bly "dinge op sigself" en gebruik nie die bestaande potensiaal vir eenwording nie. Maar die toekenning van algemene konsepte en protokolle vir taalhandvatselgebaseerde modelle kan lei tot die skepping van herbruikbare komponente om daarmee te werk, soortgelyk aan wat in die geval van EMF gebeur het.
Dit is nie te sê dat Eclipse nie 'n begrip van hierdie probleme gehad het nie. Terug in 2005 , 'n opsomming van die ervaring van die ontwikkeling van 'n CDT-prototipe, die behoefte om 'n gemeenskaplike infrastruktuur vir taalmodelle te skep, insluitend handvatselgebaseerde modelle. Maar, soos dit dikwels gebeur, het die implementering van hierdie idees, as gevolg van hoër prioriteit take, toe nie die hande bereik nie. Intussen is kodefaktorisering van *DT-projekte steeds een van die onderontwikkelde onderwerpe in Eclipse.
In 'n sekere sin is die Handly-projek ontwerp om ongeveer dieselfde take as EMF op te los, maar vir handvatselgebaseerde modelle, en hoofsaaklik taalmodelle (dit wil sê, wat elemente van die struktuur van 'n sekere programmeertaal verteenwoordig). Die volgende is die hoofontwerpdoelwitte vir Handly:
- Isolasie van die hoofabstraksies van die vakgebied.
- Die vermindering van die moeite en die verbetering van die kwaliteit van die implementering van taalhandvatselgebaseerde modelle deur kodehergebruik.
- Die verskaffing van 'n verenigde metavlak-API aan die resulterende modelle, wat dit moontlik maak om algemene IDE-komponente te skep wat met taalhandvatselgebaseerde modelle werk.
- Buigsaamheid en skaalbaarheid.
- Integrasie met Xtext (in 'n aparte laag).
Om algemene konsepte en protokolle uit te lig, is die bestaande implementering van taalhandvatselgebaseerde modelle ontleed. Die hoofkoppelvlakke en basisimplementerings wat deur Handly verskaf word, word in Figuur 8-XNUMX getoon. XNUMX.
Rys. 8. Algemene koppelvlakke en basiese implementering van Handly-elemente
Die IElement-koppelvlak verteenwoordig die handvatsel van 'n element en is algemeen vir elemente van alle Handly-gebaseerde modelle. Die abstrakte klas Element implementeer 'n generiese handvatsel/liggaammeganisme (Figuur 9).
Rys. 9. IElement en generiese implementering van handvatsel/liggaam
Daarbenewens bied Handly 'n algemene kennisgewingmeganisme vir die verandering van modelelemente (Fig. 10). Soos u kan sien, is dit in algemene terme soortgelyk aan die kennisgewingmeganismes wat in die hulpbronmodel en die Java-model geïmplementeer is, en gebruik IElementDelta vir 'n verenigde voorstelling van elementveranderingsinligting.
Rys. 10. Algemene koppelvlakke en basiese implementering van die Handly-kennisgewingmeganisme
Die deel van Handly wat hierbo beskou word (Fig. 9 en 10) kan gebruik word om byna enige handvatsel-gebaseerde modelle voor te stel. Vir die skep linguistiese modelle, bied die projek bykomende funksionaliteit - in die besonder, algemene koppelvlakke en basisimplementerings vir bronteksstruktuurelemente, die sg. bronelemente (Fig. 8). Die ISourceFile-koppelvlak verteenwoordig 'n bronlêer, en ISourceConstruct verteenwoordig 'n element binne die bronlêer. Die abstrakte klasse SourceFile en SourceConstruct implementeer generiese meganismes om werk met bronlêers en hul elemente te ondersteun, byvoorbeeld werk met teksbuffers, binding aan elementkoördinate in die bronteks, versoening van die model met die huidige inhoud van die werkkopiebuffer, ens. . Die implementering van hierdie meganismes is gewoonlik nogal 'n uitdaging, en Handly kan die moeite om handvatselgebaseerde taalmodelle te ontwikkel aansienlik verminder deur kwaliteit basisimplementerings te verskaf.
Benewens die kernmeganismes hierbo gelys, bied Handly 'n teksbuffer en momentopname-infrastruktuur, ondersteuning vir integrasie met bronkode-redigeerders (insluitend out-of-the-box-integrasie met die Xtext-redigeerder), sowel as 'n paar algemene UI-komponente wat werk met Handly-modelle soos die buitelynraamwerk. Om sy vermoëns te illustreer, verskaf die projek verskeie voorbeelde, insluitend die implementering van die Java-model op Handly. (In vergelyking met die volledige implementering van die Java-model in die JDT, is hierdie model doelbewus ietwat vereenvoudig vir beter duidelikheid.)
Soos vroeër genoem, was en is Handly se aanvanklike ontwerp en ontwikkeling sterk gefokus op skaalbaarheid en buigsaamheid.
In beginsel skaal handvatselgebaseerde modelle goed "volgens ontwerp". Byvoorbeeld, die handvatsel/liggaam-idioom laat jou toe om die hoeveelheid geheue wat deur die model verbruik word, te beperk. Maar daar is ook nuanses. Dus, wanneer Handly getoets is vir skaalbaarheid, is 'n probleem gevind in die implementering van die kennisgewingmeganisme - wanneer 'n groot aantal elemente verander word, het die bou van delta's te veel tyd geneem. Dit het geblyk dat dieselfde probleem teenwoordig is in die JDT Java-model, waaruit die ooreenstemmende kode op een slag aangepas is. Ons het 'n fout in Handly reggemaak en 'n soortgelyke pleister vir JDT voorberei, wat met dank ontvang is. Dit is net een voorbeeld waar die implementering van Handly in bestaande modelimplementerings potensieel voordelig kan wees, aangesien dit moontlik sal wees om so 'n fout op net een plek reg te stel.
Om die inbedding van Handly in bestaande modelimplementerings tegnies haalbaar te maak, moet die biblioteek hoogs buigsaam wees. Die grootste probleem is om terugwaartse verenigbaarheid met die model API te handhaaf. Hierdie probleem is opgelos in deur die modelspesifieke API, wat deur die ontwikkelaar gedefinieer en ten volle beheer word, duidelik te skei van die verenigde metavlak-API wat deur die biblioteek verskaf word. Dit maak dit nie net tegnies moontlik om Handly in bestaande implementerings te implementeer nie, maar gee ook die ontwikkelaar van die nuwe model baie vryheid in API-ontwerp.
Buigsaamheid het ook ander aspekte. Handly plaas byvoorbeeld byna geen beperkings op die struktuur van die model nie en kan gebruik word om algemene doeltale sowel as domeinspesifieke tale te modelleer. Wanneer die bronlêerstruktuur saamgestel word, skryf Handly geen spesifieke vorm van AST-voorstelling voor nie en vereis in beginsel nie eers die teenwoordigheid van 'n AST self nie, en verseker dus versoenbaarheid met byna enige ontledingsmeganisme. Laastens ondersteun Handly volle integrasie met die Eclipse-werkspasie, maar kan ook direk met lêerstelsels werk danksy die integrasie daarvan met (EFS).
Huidige weergawe in Desember 2016 vrygestel. Ten spyte van die feit dat die projek tans in 'n toestand van inkubasie is en die API nog nie finaal reggestel is nie, word Handly reeds gebruik in twee groot kommersiële produkte wat die rol van "vroeë aannemers" gewaag het en, ek moet sê, doen nog nie spyt daaroor nie.
Soos hierbo genoem, is een van hierdie produkte 1C:Enterprise Development Tools, waar Handly van die begin af gebruik word om elemente van die hoëvlakstruktuur van sulke 1C:Enterprise-tale as 'n ingebedde programmeertaal en 'n navraagtaal te modelleer. Nog 'n produk is minder bekend aan die algemene publiek. Hierdie , 'n geïntegreerde ontwerpomgewing vir probleemgeoriënteerde verwerkers (toepassingspesifieke instruksiestelverwerker, ASIP), wat beide binne die Tsjeggiese maatskappy Codasip self en deur sy kliënte gebruik word, insluitend , , , . Codasip gebruik Handly sedert 2015 in produksie, begin met Handly 0.2. Die jongste weergawe van Codasip Studio gebruik tans weergawe 0.5 wat in Junie 2016 vrygestel is. Ondřej Ilčík, wat die ontwikkeling van die IDE by Codasip lei, is in kontak met die projek en gee kritiese terugvoer namens die "derdeparty-aannemer". Hy kon selfs 'n bietjie vrye tyd kry om direk by te dra tot die ontwikkeling van die projek deur 'n UI-laag (~4000 reëls kode) te implementeer vir een van die Handly-voorbeelde, 'n Java-model. Vir meer eerstehandse inligting oor die gebruik van Handly by adapters, sien projek.
Ons hoop dat Handly na die vrystelling van weergawe 1.0 met 'n waarborg van API-stabiliteit en die uitgang van die projek uit die inkubasietoestand ook nuwe gebruikers sal hê. Intussen gaan die projek voort om die API verder te toets en te verfyn, met twee "groot" vrystellings per jaar, in Junie (dieselfde datum as die gelyktydige Eclipse-vrystelling) en Desember, wat 'n voorspelbare skedule bied waarop gebruikers kan staatmaak. Ons kan ook byvoeg dat die "fouttempo" van die projek op 'n konstante lae vlak bly en Handly werk sedert die heel eerste weergawes betroubaar in die produkte van vroeë aannemers. Vir verdere vertroudheid met Eclipse Handly, kan jy gebruik и .
Bron: will.com