Miskien, hat al lang gjin spesjale ynlieding nedich. In protte minsken binne bekend mei Eclipse troch de Eclipse Java-ûntwikkelingsark (). It is dizze populêre iepen boarne Java IDE dy't de measte ûntwikkelders assosjearje mei it wurd "Eclipse". Eclipse is lykwols sawol in útwreidber platfoarm foar it yntegrearjen fan ûntwikkelingsark (Eclipse Platform), en in oantal IDE's boud op syn basis, ynklusyf JDT. Eclipse is sawol it Eclipse Project, it projekt op topnivo dat de ûntwikkeling fan it Eclipse Platform en de JDT koördinearret, en de Eclipse SDK, it levere resultaat fan dy ûntwikkeling. Uteinlik is Eclipse in iepen boarne Foundation mei in enoarme mienskip fan projekten, dy't net allegear binne skreaun yn Java of relatearre oan ûntwikkelingsark (bygelyks projekten) и ). De wrâld fan Eclipse is heul ferskaat.
Yn dit artikel, dat oersjoch is yn 'e natuer, sille wy besykje te sjen nei guon fan' e basis fan 'e Eclipse-arsjitektuer as in platfoarm foar it bouwen fan yntegreare ûntwikkelingsark en in earste idee te jaan fan' e Eclipse-komponinten dy't de basis foarmje fan 'e technology platfoarm foar de "nije Configurator" 1C: Enterprise. . Fansels sil sa'n resinsje ûnûntkomber foar in grut part oerflakkich en frij beheind wêze, ynklusyf om't wy ús net allinich rjochtsje op Eclipse-ûntwikkelders as doelpublyk. Wy hoopje lykwols dat sels betûfte Eclipse-ûntwikkelders ynteressante ynformaasje kinne fine yn it artikel. Wy sille bygelyks prate oer ien fan 'e "geheimen fan Eclipse", in relatyf nij en net folle bekend projekt , dat waard oprjochte en stipe troch 1C.
Yntroduksje ta Eclipse Architecture
Litte wy earst wat algemiene aspekten fan 'e Eclipse-arsjitektuer sjen mei it foarbyld (JDT). De kar fan JDT as foarbyld is net tafallich. Dit is de earste yntegreare ûntwikkelingsomjouwing dy't ferskynt yn Eclipse. Oare * DT Eclipse-projekten, lykas Eclipse C / C ++ Development Tooling (CDT), waarden letter makke en liene sawol basis arsjitektoanyske prinsipes as yndividuele boarnekoadefragminten fan JDT. De fûneminten fan 'e arsjitektuer fêstlein yn JDT binne relevant oant hjoed de dei foar hast elke IDE boud boppe op it Eclipse Platform, ynklusyf 1C: Enterprise Development Tools.
Alderearst moat it opmurken wurde dat Eclipse wurdt karakterisearre troch in frij dúdlike arsjitektoanyske lagen, mei de skieding fan taalûnôfhinklike funksjonaliteit fan funksjonaliteit ûntworpen om spesifike programmeartalen te stypjen, en de skieding fan UI-ûnôfhinklike "kearn" komponinten fan komponinten ferbûn mei stypjende brûkersynterface.
Sa definiearret it Eclipse Platform in mienskiplike, taalûnôfhinklike ynfrastruktuer, en de Java-ûntwikkelingsark foegje in folsleine Java IDE ta oan Eclipse. Sawol it Eclipse Platform as de JDT besteane út ferskate komponinten, dy't elk hearre ta in UI-ûnôfhinklike "kearn" as in UI-laach (figuer 1).
Rys. 1. Eclipse Platfoarm en JDT
Litte wy de haadkomponinten fan it Eclipse-platfoarm listje:
- Runtime - Beskiedt de plugin-ynfrastruktuer. Eclipse wurdt karakterisearre troch in modulêre arsjitektuer. Yn essinsje is Eclipse in samling fan "útwreidingspunten" en "útwreidingen".
- Wurkromte - Beheart ien of mear projekten. In projekt bestiet út mappen en bestannen dy't direkt oan it bestânsysteem yn kaart brocht wurde.
- Standert Widget Toolkit (SWT) - Biedt basis eleminten fan brûkersynterface yntegrearre mei it bestjoeringssysteem.
- JFace - Biedt in oantal UI-kaders boud boppe op SWT.
- Workbench - Beskiedt it Eclipse UI-paradigma: bewurkers, werjeften, perspektiven.
It moat sein wurde dat it Eclipse Platform ek in protte oare nuttige komponinten leveret foar it bouwen fan yntegreare ûntwikkelingsark, ynklusyf Debug, Compare, Search, and Team. Spesjaal fermelding moat makke wurde fan JFace Text - de basis foar it bouwen fan "smart editors" fan boarnekoade. Spitigernôch is sels in flugge ûndersyk fan dizze komponinten, lykas de UI-laachkomponinten, net mooglik binnen it berik fan dit artikel, dus yn 'e rest fan dizze seksje sille wy ús beheine ta in oersjoch fan' e wichtichste "kearn" komponinten fan it Eclipse Platform en JDT.
Core Runtime
De Eclipse plugin ynfrastruktuer is basearre op en levere troch it projekt . Elke Eclipse-plugin is in OSGi-bondel. De OSGi-spesifikaasje definieart yn it bysûnder meganismen foar ferzje- en ôfhinklikensresolúsje. Neist dizze standertmeganismen yntrodusearret Equinox it konsept útwreiding punten. Eltse plugin kin definiearje syn eigen útwreiding punten, en ek yntrodusearje ekstra funksjonaliteit ("útwreidings") oan it systeem mei help fan útwreiding punten definiearre troch deselde of oare plugins. Elke detaillearre beskriuwing fan 'e OSGi- en Equinox-meganismen is bûten it berik fan dit artikel. Lit ús allinich notearje dat modularisaasje yn Eclipse totaal is (elk subsysteem, ynklusyf Runtime, bestiet út ien of mear plugins), en hast alles yn Eclipse is in útwreiding. Boppedat waarden dizze prinsipes ynbêde yn 'e Eclipse-arsjitektuer lang foar de ynfiering fan OSGi (op dat stuit brûkten se har eigen technology, op in protte manieren fergelykber mei OSGi).
Core Workspace
Hast elke yntegreare ûntwikkelingsomjouwing boud boppe op it Eclipse Platform wurket mei Eclipse wurkromte. It is de wurkromte dy't normaal de boarnekoade befettet fan 'e applikaasje ûntwikkele yn' e IDE. Wurkromte mapt direkt nei it bestânsysteem en bestiet út projekten dy't mappen en bestannen befetsje. Dizze projekten, mappen en bestannen wurde neamd middels wurkromte. De ymplemintaasje fan 'e wurkromte yn Eclipse tsjinnet as cache yn relaasje ta it bestânsysteem, wat it mooglik makket om de trochgong fan' e boarnebeam signifikant te rapperjen. Dêrneist biedt wurkromte in oantal ekstra tsjinsten, ynklusyf и .
De komponint Core Resources (org.eclipse.core.resources plugin) is ferantwurdlik foar it stypjen fan de wurkromte en har boarnen. Benammen dizze komponint jout programmatyske tagong ta de wurkromte yn 'e foarm boarne modellen. Om effektyf te wurkjen mei dit model, hawwe kliïnten in ienfâldige manier nedich om in keppeling nei in boarne te presintearjen. Yn dit gefal soe it winsklik wêze om it objekt te ferbergjen dat direkt de steat fan 'e boarne yn it model bewarret fan tagong fan kliïnten. Oars, yn it gefal fan bygelyks it wiskjen fan in bestân, soe de kliïnt in objekt dat net mear yn it model sit, mei de dêropfolgjende problemen bliuwe kinne. Eclipse lost dit probleem op mei wat neamd omgean helpmiddel. Handle fungearret as in kaai (it allinne wit it paad nei de boarne yn 'e wurkromte) en folslein kontrolearret tagong ta de ynterne model foarwerp, dat direkt bewarret ynformaasje oer de steat fan de boarne. Dit ûntwerp is in fariaasje fan it patroan .
Rys. Figuer 2 yllustrearret de Handle / Body idioom as tapast op de boarne model. De IResource-ynterface fertsjintwurdiget it handgreep fan in boarne en is in API, yn tsjinstelling ta de Resource-klasse, dy't dizze ynterface ymplementearret, en de ResourceInfo-klasse, dy't it lichem fertsjintwurdiget, dy't gjin API's binne. Wy beklamje dat handle allinich it paad nei de boarne ken relatyf oan 'e wurkromte root en gjin keppeling nei boarneynfo befettet. Boarneynfo-objekten foarmje in saneamde "elemintbeam". Dizze gegevensstruktuer is folslein materialisearre yn it ûnthâld. Om de boarne-ynfo-eksimplaar te finen dy't oerienkomt mei in handgreep, wurdt de elemintbeam trochkrúst neffens it paad dat yn dat handgreep is opslein.
Rys. 2. IResource en ResourceInfo
Lykas wy letter sille sjen, wurdt it basisûntwerp fan it boarnemodel (wy kinne it handgreep-basearre neame) ek brûkt yn Eclipse foar oare modellen. Litte wy no wat fan 'e ûnderskiedende eigenskippen fan dit ûntwerp listje:
- Handle is in wearde foarwerp. Weardeobjekten binne ûnferoarlike objekten wêrfan de gelikensens net basearre is op identiteit. Sokke objekten kinne feilich brûkt wurde as kaai yn hashed konteners. Meardere eksimplaren fan handgreep kinne ferwize nei deselde boarne. Om se te fergelykjen, moatte jo de metoade equals (Object) brûke.
- Handle definiearret it gedrach fan in boarne, mar befettet gjin ynformaasje oer de steat fan 'e boarne (de ienige gegevens dy't it bewarret is de "kaai", it paad nei de boarne).
- Handle kin ferwize nei in boarne dy't net bestiet (of in boarne dy't noch net oanmakke is, of in boarne dy't al wiske is). It bestean fan in boarne kin wurde kontrolearre mei de metoade IResource.exists ().
- Guon operaasjes kinne wurde útfierd allinnich basearre op ynformaasje opslein yn de handgreep sels (saneamde handle-allinne operaasjes). Foarbylden binne IResource.getParent(), getFullPath(), ensfh. De boarne hoecht net te bestean foar sa'n operaasje om te slagjen. Operaasjes dy't in boarne nedich hawwe om te bestean om te slagjen, smyt in CoreException as de boarne net bestiet.
Eclipse leveret in effisjint meganisme foar it notifikaasje fan wizigingen fan wurkromteboarnen (figuer 3). Boarnen kinne feroarje as gefolch fan aksjes útfierd binnen de Eclipse IDE sels of as gefolch fan syngronisaasje mei it bestânsysteem. Yn beide gefallen wurde kliïnten dy't abonnearje op notifikaasjes foarsjoen fan detaillearre ynformaasje oer de feroarings yn 'e foarm fan "boarne deltas". In delta beskriuwt feroarings tusken twa steaten fan in wurkromte boarne (sub-) beam en is sels in beam, elk knooppunt fan dat beskriuwt in feroaring oan in boarne en befettet in list mei deltas op it folgjende nivo dy't beskriuwe feroarings oan bern middels.
Rys. 3. IResourceChangeEvent en IResourceDelta
It notifikaasjemeganisme basearre op boarne delta's hat de folgjende skaaimerken:
- In inkele feroaring en in protte feroarings wurde beskreaun mei deselde struktuer, om't de delta is boud mei it prinsipe fan rekursive komposysje. Abonneekliïnten kinne notifikaasjes foar boarneferoaring ferwurkje mei rekursive deltabeam-ôfstamming.
- De delta befettet folsleine ynformaasje oer feroarings oan de boarne, ynklusyf syn beweging en / of feroarings yn de "markers" ferbûn mei it (Bygelyks, kompilaasje flaters wurde fertsjintwurdige as markers).
- Sûnt boarne ferwizings wurde makke troch de handgreep, kin delta fansels ferwize nei in ôfstân boarne.
Sa't wy gau sille sjen, binne de wichtichste komponinten fan it ûntwerp fan it notifikaasjemeganisme foar feroaring fan boarnemodel ek relevant foar oare modellen basearre op handgreep.
JDT Core
It Eclipse-wurkromte-boarnemodel is in fûneminteel taalagnostysk model. De JDT Core-komponint (plugin org.eclipse.jdt.core) leveret in API foar it navigearjen en analysearjen fan de wurkromtestruktuer út in Java-perspektyf, it saneamde "Java-model" (Java model). Dizze API is definieare yn termen fan Java-eleminten, yn tsjinstelling ta it ûnderlizzende boarnemodel API, dat wurdt definieare yn termen fan mappen en bestannen. De haadynterfaces fan 'e Java-elemintbeam wurde werjûn yn Fig. 4.
Rys. 4. Java Model Elements
It Java-model brûkt itselde handgreep-/lichem-idioom as it boarnemodel (figuer 5). IJavaElement is de handgreep, en JavaElementInfo spilet de rol fan it lichem. De IJavaElement-ynterface definiearret in protokol mienskiplik foar alle Java-eleminten. Guon fan har metoaden binne allinich handgreep: getElementName(), getParent(), ensfh. It JavaElementInfo-objekt bewarret de steat fan it oerienkommende elemint: syn struktuer en attributen.
Rys. 5. IJavaElement en JavaElementInfo
It Java-model hat wat ferskillen yn 'e ymplemintaasje fan' e basishandgreep / lichemsûntwerp yn ferliking mei it boarnemodel. Lykas hjirboppe opmurken, is yn it boarnemodel de elemintbeam, wêrfan de knooppunten boarneynfo-objekten binne, folslein yn it ûnthâld befette. Mar it Java-model kin in signifikant grutter oantal eleminten hawwe as de boarnebeam, om't it ek de ynterne struktuer fan .java- en .class-bestannen fertsjintwurdiget: typen, fjilden en metoaden.
Om foar te kommen dat de hiele beam fan eleminten yn it ûnthâld folslein materialiseart, brûkt de ymplemintaasje fan Java-model in beheinde grutte LRU-cache fan elemintynfo, wêrby't de kaai is handgreep IJavaElement. elemint info objekten wurde oanmakke op oanfraach as de elemint beam wurdt navigearre. Yn dit gefal wurde de minst faak brûkte items út 'e cache ferwidere, en it ûnthâldferbrûk fan it model bliuwt beheind ta de opjûne cachegrutte. Dit is in oar foardiel fan handgreep-basearre ûntwerp, dy't sokke ymplemintaasjedetails folslein ferberget fan 'e kliïntkoade.
It meganisme foar it notifisearjen fan feroarings oan Java-eleminten is yn 't algemien fergelykber mei it meganisme foar it folgjen fan feroaringen oan wurkromteboarnen dy't hjirboppe besprutsen binne. In kliïnt dy't wizigingen yn it Java-model kontrolearje wol, abonnearret op notifikaasjes, dy't wurde fertsjintwurdige as in ElementChangedEvent-objekt dat in IJavaElementDelta befettet (figuer 6).
Rys. 6. ElementChangedEvent en IJavaElementDelta
It Java-model befettet gjin ynformaasje oer metoade-lichems of nammeresolúsje, dus foar detaillearre analyze fan koade skreaun yn Java, leveret JDT Core in ekstra (net-handgreep-basearre) model: (abstrakte syntaksisbeam, AST). AST stiet foar it resultaat fan it parsearjen fan de boarnetekst. AST-knooppunten oerienkomme mei eleminten fan 'e struktuer fan' e boarnemodule (deklaraasjes, operators, útdrukkingen, ensfh.) en befetsje ynformaasje oer de koördinaten fan it oerienkommende elemint yn 'e boarnetekst, lykas (as opsje) ynformaasje oer nammeresolúsje yn de foarm fan keppelings nei saneamde binings. Bindingen binne objekten dy't neamde entiteiten fertsjintwurdigje, lykas typen, metoaden en fariabelen, bekend by de kompilator. Oars as AST-knooppunten, dy't in beam foarmje, stypje bindingen krúsferwizing en foarmje algemien in grafyk. De abstrakte klasse ASTNode is de mienskiplike basisklasse foar alle AST-knooppunten. ASTNode-subklassen oerienkomme mei spesifike syntaktyske konstruksjes fan 'e Java-taal.
Om't syntaksisbeammen in wichtige hoemannichte ûnthâld kinne konsumearje, cache JDT mar ien AST foar de aktive bewurker. Oars as it Java-model, wurdt de AST typysk besjoen as in "tusken", "tydlik" model, wêrfan de eleminten wêrfan kliïnten gjin ferwizings moatte hâlde bûten de kontekst fan 'e operaasje dy't late ta de skepping fan' e AST.
De neamde trije modellen (Java-model, AST, bindingen) foarmje tegearre de basis foar it bouwen fan "yntelligente ûntwikkelingsark" yn JDT, ynklusyf in krêftige Java-bewurker mei ferskate "helpers", ferskate aksjes foar it ferwurkjen fan boarnekoade (ynklusyf it organisearjen fan in list mei ymportearjen nammen en opmaak neffens de oanpaste styl), syk- en refactoring-ark. Yn dit gefal spilet it Java-model in spesjale rol, om't it wurdt brûkt as basis foar in fisuele foarstelling fan 'e struktuer fan' e applikaasje dy't ûntwikkele wurdt (bygelyks yn Package Explorer, Outline, Search, Call Hierarchy, en Type hierarchy).
Eclipse komponinten brûkt yn 1C: Enterprise Development Tools
Yn Fig. Figuer 7 lit de Eclipse-komponinten sjen dy't de basis foarmje fan it technologyplatfoarm foar 1C: Enterprise Development Tools.
Rys. 7. Eclipse as platfoarm foar 1C: Enterprise Development Tools
Eclipse Platfoarm jout basisynfrastruktuer. Wy seagen guon aspekten fan dizze ynfrastruktuer yn 'e foarige paragraaf.
(EMF) jout in algemien middel foar it modellearjen fan strukturearre gegevens. EMF is yntegrearre mei it Eclipse Platform, mar kin ek apart brûkt wurde yn reguliere Java-applikaasjes. Hiel faak binne nije Eclipse-ûntwikkelders al goed bekend mei EMF, hoewol se de yngewikkeldheden fan it Eclipse Platform noch net folslein begripe. Ien fan 'e redenen foar sa'n goed fertsjinne populariteit is it universele ûntwerp, dat ûnder oaren in unifoarme meta-nivo API omfettet, wêrtroch jo op in algemiene manier kinne wurkje mei elk EMF-model. De basis ymplemintaasjes foar modelobjekten levere troch EMF en it subsysteem foar it generearjen fan modelkoade basearre op it meta-model ferheegje de ûntwikkelingssnelheid signifikant en ferminderje it oantal flaters. EMF befettet ek meganismen foar serializing modellen, tracking feroarings oan it model, en folle mear.
Lykas elk ark foar wirklik algemien doel, is EMF geskikt foar it oplossen fan in breed skala oan modelleringsproblemen, mar guon klassen fan modellen (Bygelyks de hjirboppe besprutsen modellen basearre op hânfetten) kinne mear spesjalisearre modelleringsark fereaskje. Prate oer EMF is in ûntankbere taak, foaral binnen de beheinde grinzen fan ien artikel, om't dit it ûnderwerp is fan in apart boek, en in nochal dik. Lit ús allinich opmerke dat it heechweardige systeem fan generalisaasjes ûnder de EMF de berte tastien hat fan in heule oanbod fan projekten wijd oan modellering, dy't opnommen binne yn it projekt op topnivo tegearre mei de EMF sels. Ien sa'n projekt is Eclipse Xtext.
biedt in ynfrastruktuer foar "tekstmodellering". Xtext brûkt foar it parsearjen fan de boarnetekst en EMF foar it fertsjintwurdigjen fan de resultearjende ASG (abstrakte semantyske grafyk, dy't yn wêzen in kombinaasje fan AST en bindingen is), ek wol it "semantyske model" neamd. De grammatika fan de troch Xtext modelearre taal wurdt beskreaun yn Xtext syn eigen taal. Hjirmei kinne jo net allinich in grammatikabeskriuwing foar ANTLR generearje, mar ek in AST-serialisaasjemeganisme te krijen (d.w.s. Xtext leveret sawol in parser as in unparser), in kontekstoanwizing en in oantal oare taalkomponinten. Oan 'e oare kant is de grammatikataal brûkt yn Xtext minder fleksibel as bygelyks de grammatikataal brûkt yn ANTLR. Dêrom is it soms nedich om de ymplementearre taal te "bûgen" nei Xtext, wat normaal gjin probleem is as wy it hawwe oer in taal dy't fanôf it begjin ûntwikkele wurdt, mar kin net akseptabel wêze foar talen mei in al fêststelde syntaksis. Nettsjinsteande dit is Xtext op it stuit it meast folwoeksen, funksje-rike en alsidige ark yn Eclipse foar it bouwen fan programmeartalen en ûntwikkelingsark foar har. Benammen is it in ideaal ark foar rappe prototyping (domeinspesifike taal, DSL). Neist de hjirboppe neamde "taalkearn" basearre op ANTLR en EMF, biedt Xtext in protte brûkbere komponinten op heger nivo, ynklusyf yndeksearjende meganismen, inkrementele konstruksje, in "smart editor", en folle, folle mear, mar ferlit handgreep- basearre taalmodellen. Lykas EMF is Xtext in ûnderwerp dat in apart boek wurdich is, en wy kinne no amper sels koart prate oer al syn mooglikheden.
1C: Enterprise Development Tools brûke aktyf sawol EMF sels as in oantal oare Eclipse Modeling-projekten. Benammen Xtext is ien fan 'e fûneminten fan ûntwikkelingsynstruminten foar sokke 1C: Enterprise-talen as de ynboude programmeartaal en querytaal. In oare basis foar dizze ûntwikkelingsark is it Eclipse Handly-projekt, dat wy yn mear detail sille beprate (fan 'e neamde Eclipse-komponinten is it noch it minst bekend).
, in subprojekt fan it Eclipse Technology-topnivo-projekt, ûntstie as gefolch fan in earste koadebydrage oan 'e Eclipse Foundation makke troch 1C yn 2014. Sûnt dy tiid hat 1C de ûntwikkeling fan it projekt trochgien: Handly committers binne meiwurkers fan it bedriuw. It projekt is lyts, mar it beslacht in frijwat unike niche yn Eclipse: har haaddoel is om de ûntwikkeling fan modellen op hânfetten te stypjen.
De basis arsjitektoanyske prinsipes fan modellen basearre op hânfetten, lykas it handgreep / lichem idioom, waarden hjirboppe besprutsen mei it boarnemodel en it Java-model as foarbylden. It merkte ek op dat sawol it boarnemodel as it Java-model wichtige fûneminten binne foar de Eclipse Java-ûntwikkelingsark (JDT). En om't hast alle * DT Eclipse-projekten in arsjitektuer hawwe dy't fergelykber is mei JDT, soe it net in grutte oerdriuwing wêze om te sizzen dat handle-basearre modellen ûnderlizze in protte, as net alle IDE's dy't boppe op it Eclipse Platform boud binne. Bygelyks, de Eclipse C / C ++ Development Tooling (CDT) hat in handle-basearre C / C ++ model dat spilet deselde rol yn 'e CDT-arsjitektuer as it Java-model docht yn' e JDT.
Foardat Handly hat Eclipse gjin spesjale bibleteken oanbean foar it bouwen fan handgreep-basearre taalmodellen. De modellen dy't op it stuit besteane binne foaral makke troch de Java-modelkoade direkt oan te passen (aka kopiearje / plakke), yn gefallen dêr't it tastien Eclipse Public License (EPL). (Fansels is dit meastentiids gjin juridysk probleem foar bygelyks Eclipse-projekten sels, mar net foar produkten mei sletten boarnen.) Neist syn ynherinte willekeur, bringt dizze technyk bekende problemen yn: koadeduplikaasje yntrodusearre troch by it oanpassen oan flaters, ensfh. Wat slimmer is, is dat de resultearjende modellen "dingen op harsels" bliuwe en net profitearje fan it potinsjeel foar ienwurding. Mar it isolearjen fan mienskiplike konsepten en protokollen foar handgreep-basearre taalmodellen kin liede ta it meitsjen fan werbrûkbere komponinten foar it wurkjen mei har, fergelykber mei wat barde yn it gefal fan EMF.
It is net dat Eclipse dizze problemen net begrepen. Werom yn 2005 , gearfetting fan 'e ûnderfining fan it ûntwikkeljen fan it CDT-prototype, de needsaak om in mienskiplike ynfrastruktuer te meitsjen foar taalmodellen, ynklusyf modellen basearre op hânfetten. Mar, lykas faaks bart, fanwege taken mei hegere prioriteit, is de ymplemintaasje fan dizze ideeën noait rûn. Underwilens is faktorisaasje fan *DT-koade noch ien fan 'e ûnderûntwikkele ûnderwerpen yn Eclipse.
Yn in beskate sin is it Handly-projekt ûntworpen om sawat deselde problemen op te lossen as EMF, mar foar modellen basearre op hânfetten, en benammen taal (dat wol sizze, eleminten fan 'e struktuer fan guon programmeartaal fertsjintwurdigje). De haaddoelen ynsteld by it ûntwerpen fan Handly wurde hjirûnder neamd:
- Identifikaasje fan 'e wichtichste abstraksjes fan it fakgebiet.
- It ferminderjen fan ynspanning en it ferbetterjen fan de kwaliteit fan ymplemintaasje fan handgreep-basearre taalmodellen troch koade wergebrûk.
- It leverjen fan in unifoarme meta-nivo API oan 'e resultearjende modellen, wêrtroch't it mooglik is om mienskiplike IDE-komponinten te meitsjen dy't wurkje mei taalhandtak-basearre modellen.
- Fleksibiliteit en skalberens.
- Yntegraasje mei Xtext (yn in aparte laach).
Om mienskiplike begripen en protokollen te markearjen, waarden besteande ymplemintaasjes fan op taalhandtak basearre modellen analysearre. De haadynterfaces en basisymplementaasjes levere troch Handly wurde werjûn yn Fig. 8.
Rys. 8. Mienskiplike Schnittstellen en basis ymplemintaasjes fan Handly eleminten
De IElement-ynterface stiet foar de handgreep fan in elemint en is mienskiplik foar eleminten fan alle Handly-basearre modellen. De abstrakte klasse Element ymplemintearret de generalisearre handgreep / body meganisme (figuer 9).
Rys. 9. IElement en generic handle / body ymplemintaasje
Dêrneist jout Handly in generalisearre meganisme foar in notify oer feroarings yn model eleminten (figuer 10). Sa't jo sjen kinne, is it yn 't algemien te fergelykjen mei de notifikaasjemeganismen dy't ymplementearre binne yn it boarnemodel en it Java-model, en brûkt IElementDelta om in unifoarme fertsjintwurdiging fan elemintferoaringsynformaasje te leverjen.
Rys. 10. Algemiene ynterfaces en basis ymplemintaasjes fan de Handly notifikaasje meganisme
De Handly diel besprutsen hjirboppe (figuer 9 en 10) kin brûkt wurde foar in fertsjintwurdigje hast alle handle-basearre modellen. Foar it meitsjen taalkundige modellen biedt it projekt ekstra funksjonaliteit - benammen mienskiplike ynterfaces en basisymplemintaasjes foar eleminten fan 'e boarnetekststruktuer, de saneamde boarne eleminten (ôfb. 8). De ISourceFile-ynterface fertsjintwurdiget in boarnebestân, en ISourceConstruct fertsjintwurdiget in elemint binnen it boarnebestân. De abstrakte klassen SourceFile en SourceConstruct implementearje generalisearre meganismen om it wurkjen mei boarnebestannen en har eleminten te stypjen, bygelyks wurkjen mei tekstbuffers, ferbinen oan de koördinaten fan in elemint yn 'e boarnetekst, modellen fermoedsoenje mei de hjoeddeistige ynhâld fan in wurkkopiebuffer , ensfh. It ymplementearjen fan dizze meganismen is meastal in útdaging, en Handly kin de muoite fan it ûntwikkeljen fan handgreep-basearre taalmodellen signifikant ferminderje troch it leverjen fan heechweardige basisymplementaasjes.
Njonken de hjirboppe neamde kearnmeganismen leveret Handly in ynfrastruktuer foar tekstbuffers en snapshots, stipe foar yntegraasje mei boarnekoade-bewurkers (ynklusyf out-of-the-box-yntegraasje mei de Xtext-bewurker), lykas ek guon mienskiplike UI-komponinten dy't wurkje mei boarne koade bewurkers Handly modellen lykas outline framework. Om syn mooglikheden te yllustrearjen, jout it projekt ferskate foarbylden, ynklusyf in ymplemintaasje fan it Java-model yn Handly. (Yn ferliking mei de folsleine ymplemintaasje fan it Java-model yn JDT, is dit model mei opsetsin wat ferienfâldige foar gruttere dúdlikens.)
Lykas earder opmurken, wie en bliuwt in grutte fokus tidens Handly's earste ûntwerp en folgjende ûntwikkeling op skalberens en fleksibiliteit.
Yn prinsipe skaalje modellen op basis fan hannel frij goed "troch ûntwerp". Bygelyks, de handgreep / lichem idioom kinne jo beheine it bedrach fan ûnthâld konsumearre troch in model. Mar der binne ek nuânses. Sa, by it testen fan Handly foar skalberens, waard in probleem ûntdutsen yn 'e ymplemintaasje fan it notifikaasjemeganisme - doe't in grut oantal eleminten waard feroare, naam it bouwen fan delta's te folle tiid. It die bliken dat itselde probleem oanwêzich wie yn it JDT Java-model, wêrfan de oerienkommende koade ienris oanpast waard. Wy hawwe de brek yn Handly reparearre en in ferlykbere patch foar JDT taret, dy't tankber ûntfongen waard. Dit is mar ien foarbyld wêr't it yntrodusearjen fan Handly yn besteande model-ymplemintaasjes potinsjeel nuttich kin wêze, om't yn dit gefal sa'n brek op mar ien plak kin wurde reparearre.
Om it útfieren fan Handly yn besteande model-ymplemintaasjes technysk mooglik te meitsjen, moat de bibleteek signifikante fleksibiliteit hawwe. It wichtichste probleem is om efterútkompatibiliteit te behâlden oer it API-model. Dit probleem waard oplost yn troch dúdlik skieden fan de model-spesifike API, definiearre en folslein kontrolearre troch de ûntwikkelder, út de ferienige meta-nivo API levere troch de bibleteek. Dit makket it net allinich technysk mooglik om Handly te ymplementearjen yn besteande ymplemintaasjes, mar jout ek de nije modelûntwikkelder wichtige frijheid by it ûntwerpen fan de API.
Fleksibiliteit hat ek oare aspekten. Bygelyks, Handly set hast gjin beheinings op oan 'e struktuer fan it model en kin brûkt wurde om sawol algemien-doel- as domein-spesifike talen te modellearjen. By it konstruearjen fan de struktuer fan it boarnebestân skriuwt Handly gjin bepaalde foarm fan AST-fertsjintwurdiging foar en fereasket yn prinsipe net iens de oanwêzigens fan in AST sels, sadat de kompatibiliteit garandearret mei hast alle parsemeganismen. Uteinlik stipet Handly folsleine yntegraasje mei Eclipse wurkromte, mar kin ek direkt wurkje mei bestânsystemen troch syn yntegraasje mei (EFS).
Aktuele ferzje kaam út yn desimber 2016. Nettsjinsteande it feit dat it projekt op it stuit yn in steat fan ynkubaasje is en de API noch net definityf fêst is, wurdt Handly al brûkt yn twa grutte kommersjele produkten dy't it risiko namen om as "early adopters" op te treden, en, ik moat sizze, ha der noch gjin spyt fan.
Lykas hjirboppe opmurken, is ien fan dizze produkten 1C: Enterprise Development Tools, wêrby't Handly fan it begjin ôf brûkt wurdt om eleminten fan 'e struktuer op hege nivo fan sokke 1C: Enterprise-talen te modellearjen as de ynboude programmeartaal en querytaal . In oar produkt is minder bekend by it grutte publyk. Dit , in yntegreare ûntwerpomjouwing foar applikaasje-spesifike ynstruksje-set-prosessor (ASIP), brûkt sawol binnen it Tsjechyske bedriuw Codasip sels as troch har kliïnten, ynklusyf , , , . Codasip brûkt Handly yn produksje sûnt 2015, begjinnend mei ferzje Handly 0.2. De lêste release fan Codasip Studio brûkt ferzje 0.5, útbrocht yn juny 2016. Ondřej Ilčík, dy't IDE-ûntwikkeling liedt by Codasip, is yn kontakt mei it projekt, en leveret fitale feedback út namme fan 'e "adopter fan tredden". Hy koe sels wat frije tiid fine om direkt mei te dwaan oan 'e ûntwikkeling fan it projekt, troch in UI-laach (~ 4000 rigels koade) te ymplementearjen foar ien fan 'e Handly-foarbylden, in Java-model. Mear detaillearre ynformaasje út earste hân oer it gebrûk fan Handly troch adopters is te finen op 'e side projekt.
Wy hoopje dat nei de frijlitting fan ferzje 1.0 mei in garânsje fan API-stabiliteit en it projekt dat de ynkubaasjestân ferlit, Handly nije adopters sil hawwe. Yn 'e tuskentiid giet it projekt troch mei it testen en fierder ferbetterjen fan de API, wêrtroch't twa "wichtige" releases per jier frijlitte - yn juny (deselde datum as de simultane Eclipse-release) en desimber, en leveret in foarsisber skema dat adopters kinne fertrouwe op. Wy kinne ek tafoegje dat it "bug-rate" fan it projekt op in konsekwint leech nivo bliuwt en Handly hat sûnt de earste ferzjes betrouber wurke yn 'e produkten fan iere adopters. Om fierder te ferkennen Eclipse Handly, kinne jo brûke и .
Boarne: www.habr.com