Líklega, hefur fyrir löngu ekki þurft sérstaka kynningu. Margir kannast við Eclipse þökk sé Eclipse Java þróunarverkfærunum (). Það er þessi vinsæli opinn uppspretta Java IDE sem flestir forritarar tengja við orðið „Eclipse“. Hins vegar er Eclipse bæði stækkanlegur vettvangur til að samþætta þróunarverkfæri (Eclipse Platform) og fjöldi IDE sem byggðar eru á grundvelli hans, þar á meðal JDT. Eclipse er bæði Eclipse Project, efsta stigi verkefnisins sem samhæfir þróun Eclipse Platform og JDT, og Eclipse SDK, skilað afrakstur þeirrar þróunar. Að lokum, Eclipse er opinn uppspretta stofnun með gríðarstórt samfélag verkefna, sem ekki eru öll skrifuð í Java eða tengd þróunarverkfærum (til dæmis verkefnum и ). Heimur Eclipse er mjög fjölbreyttur.
Í þessari grein, sem er yfirlit í eðli sínu, munum við reyna að skoða nokkur grunnatriði Eclipse arkitektúrsins sem vettvang til að byggja upp samþætt þróunarverkfæri og gefa fyrstu hugmynd um Eclipse íhlutina sem mynda grunninn að tækninni. vettvangur fyrir „nýja Configurator“ 1C: Enterprise. . Auðvitað verður slík endurskoðun óhjákvæmilega að mestu yfirborðskennd og frekar takmörkuð, þar á meðal vegna þess að við einblínum ekki aðeins á Eclipse forritara sem markhóp. Hins vegar vonum við að jafnvel reyndir Eclipse forritarar geti fundið áhugaverðar upplýsingar í greininni. Til dæmis munum við tala um eitt af „leyndarmálum Eclipse“, tiltölulega nýtt og lítt þekkt verkefni , sem var stofnað og stutt af 1C.
Kynning á Eclipse Architecture
Við skulum fyrst skoða nokkrar almennar hliðar Eclipse arkitektúrsins með því að nota dæmið (JDT). Val á JDT sem dæmi er ekki tilviljun. Þetta er fyrsta samþætta þróunarumhverfið sem birtist í Eclipse. Önnur *DT Eclipse verkefni, eins og Eclipse C/C++ Development Tooling (CDT), voru búin til síðar og fá bæði grunn byggingarreglur og einstök frumkóðabrot að láni frá JDT. Grundvallaratriði arkitektúrsins sem mælt er fyrir um í JDT eru viðeigandi enn þann dag í dag fyrir næstum hvaða IDE sem er byggð ofan á Eclipse pallinum, þar á meðal 1C:Enterprise Development Tools.
Í fyrsta lagi skal tekið fram að Eclipse einkennist af nokkuð skýru byggingarlagi, með aðskilnaði tungumálsóháðrar virkni frá virkni sem er hönnuð til að styðja við tiltekin forritunarmál, og aðskilnað HÍ óháðra „kjarna“ íhluta frá íhlutum tengdum með notendaviðmóti sem styður.
Þannig skilgreinir Eclipse Platform sameiginlegan, tungumálóháðan innviði og Java þróunarverkfærin bæta fullkomnu Java IDE við Eclipse. Bæði Eclipse Platform og JDT samanstanda af nokkrum hlutum, sem hver um sig tilheyrir annað hvort UI-óháðum „kjarna“ eða UI-lagi (Mynd 1).
Hrísgrjón. 1. Eclipse Platform og JDT
Við skulum telja upp helstu þætti Eclipse vettvangsins:
- Runtime - Skilgreinir viðbætur innviði. Eclipse einkennist af einingaarkitektúr. Í meginatriðum er Eclipse safn af „framlengingarpunktum“ og „viðbótum“.
- Vinnusvæði - Stjórnar einu eða fleiri verkefnum. Verkefni samanstendur af möppum og skrám sem eru kortlagðar beint á skráarkerfið.
- Hefðbundið græjuverkfærasett (SWT) - Býður upp á helstu notendaviðmótsþætti sem eru samþættir stýrikerfinu.
- JFace — Býður upp á fjölda notendaviðmóta sem eru byggðir ofan á SWT.
- vinnubekkur — Skilgreinir Eclipse UI hugmyndafræði: ritstjórar, skoðanir, sjónarhorn.
Það verður að segjast að Eclipse pallurinn býður einnig upp á marga aðra gagnlega hluti til að byggja upp samþætt þróunarverkfæri, þar á meðal kembiforrit, samanburð, leit og teymi. Sérstaklega skal minnst á JFace Text - grunninn að því að byggja upp „snjalla ritstjóra“ frumkóða. Því miður er jafnvel lausleg athugun á þessum íhlutum, sem og HÍ laghlutunum, ekki möguleg innan umfangs þessarar greinar, svo í restinni af þessum hluta munum við takmarka okkur við yfirlit yfir helstu „kjarna“ þættina í Eclipse Platform og JDT.
Core Runtime
Innviði Eclipse viðbótarinnar er byggður á og veitt af verkefninu . Hver Eclipse viðbót er OSGi búnt. OSGi forskriftin skilgreinir einkum aðferðir til útgáfu og upplausnar ósjálfstæðis. Auk þessara staðlaða aðferða kynnir Equinox hugmyndina stækkunarpunkta. Hver viðbót getur skilgreint sína eigin framlengingarpunkta og einnig kynnt viðbótarvirkni ("viðbætur") í kerfið með því að nota framlengingarpunkta sem eru skilgreindir af sömu eða öðrum viðbætur. Sérhver nákvæm lýsing á OSGi og Equinox aðferðum er utan gildissviðs þessarar greinar. Við skulum aðeins hafa í huga að einingavæðing í Eclipse er algjör (hvert undirkerfi, þar á meðal Runtime, samanstendur af einni eða fleiri viðbótum), og næstum allt í Eclipse er viðbót. Þar að auki voru þessar meginreglur felldar inn í Eclipse arkitektúrinn löngu fyrir kynningu á OSGi (á þeim tíma notuðu þeir sína eigin tækni, svipað og OSGi).
Kjarna vinnusvæði
Næstum hvaða samþætt þróunarumhverfi sem er byggt ofan á Eclipse pallinum virkar með Eclipse vinnusvæði. Það er vinnusvæðið sem venjulega inniheldur frumkóða forritsins sem þróað er í IDE. Vinnusvæði kortast beint í skráarkerfið og samanstendur af verkefnum sem innihalda möppur og skrár. Þessi verkefni, möppur og skrár eru kölluð auðlindir vinnurými. Vinnusvæðisútfærslan í Eclipse þjónar sem skyndiminni í tengslum við skráarkerfið, sem gerir það mögulegt að flýta verulega fyrir yfirferð auðlindatrésins. Að auki veitir vinnurými fjölda viðbótarþjónustu, þ.á.m и .
Core Resources hluti (org.eclipse.core.resources tappi) ber ábyrgð á að styðja við vinnusvæðið og tilföng þess. Sérstaklega veitir þessi hluti forritaðan aðgang að vinnusvæðinu á formi auðlindalíkön. Til að vinna á áhrifaríkan hátt með þetta líkan þurfa viðskiptavinir einfalda leið til að kynna tengil á auðlind. Í þessu tilviki væri æskilegt að fela hlutinn sem geymir beint ástand auðlindarinnar í líkaninu fyrir aðgangi viðskiptavinarins. Að öðrum kosti, ef um er að ræða til dæmis að eyða skrá, gæti viðskiptavinurinn haldið áfram að halda hlut sem er ekki lengur í líkaninu, með þeim vandamálum sem fylgdu. Eclipse leysir þetta vandamál með því að nota eitthvað sem heitir annast auðlind. Handle virkar sem lykill (það þekkir aðeins slóðina að auðlindinni á vinnusvæðinu) og stjórnar algjörlega aðgangi að innri líkanhlutnum, sem geymir beint upplýsingar um stöðu auðlindarinnar. Þessi hönnun er afbrigði af mynstrinu .
Hrísgrjón. Mynd 2 sýnir handtak/líkamsmálið eins og það er notað á auðlindalíkanið. IResource viðmótið táknar handfang auðlindar og er API, ólíkt Resource class, sem útfærir þetta viðmót, og ResourceInfo class, sem táknar líkamann, sem eru ekki API. Við leggjum áherslu á að handfang þekkir aðeins slóðina að auðlindinni miðað við rót vinnusvæðisins og inniheldur ekki tengil á auðlindaupplýsingar. Auðlindaupplýsingahlutir mynda svokallað „þáttatré“. Þessi gagnauppbygging er algjörlega að veruleika í minni. Til að finna auðlindaupplýsingatilvikið sem samsvarar handfangi er farið yfir frumefnistréð í samræmi við slóðina sem geymd er í því handfangi.
Hrísgrjón. 2. IResource og ResourceInfo
Eins og við munum sjá síðar er grunnhönnun auðlindalíkans (við gætum kallað það handfangsmiðað) einnig notuð í Eclipse fyrir aðrar gerðir. Í bili skulum við lista nokkra af sérkennum eiginleikum þessarar hönnunar:
- Handfang er gildishlutur. Verðmæti hlutir eru óbreytanlegir hlutir þar sem jafnræði þeirra byggist ekki á sjálfsmynd. Hægt er að nota slíka hluti á öruggan hátt sem lykil í hassgámum. Mörg tilvik handfangs geta vísað til sömu tilföngsins. Til að bera þau saman þarftu að nota equals(Object) aðferðina.
- Handle skilgreinir hegðun auðlindar, en inniheldur ekki upplýsingar um stöðu auðlindarinnar (einu gögnin sem það geymir eru „lykillinn“, slóðin að auðlindinni).
- Handle getur átt við auðlind sem er ekki til (annaðhvort auðlind sem hefur ekki enn verið búin til eða auðlind sem hefur þegar verið eytt). Hægt er að athuga tilvist auðlindar með því að nota IResource.exists() aðferðina.
- Sumar aðgerðir er hægt að útfæra eingöngu á grundvelli upplýsinga sem geymdar eru í handfanginu sjálfu (svokallaðar handfangsaðgerðir). Dæmi eru IResource.getParent(), getFullPath() o.s.frv. Auðlindin þarf ekki að vera til til að slík aðgerð heppnist. Aðgerðir sem krefjast þess að tilföng sé til til að ná árangri kasta CoreException ef tilföngin eru ekki til.
Eclipse býður upp á skilvirkan búnað til að tilkynna breytingar á tilföngum á vinnusvæði (Mynd 3). Tilföng geta breyst annað hvort vegna aðgerða sem framkvæmdar eru innan Eclipse IDE sjálfrar eða vegna samstillingar við skráarkerfið. Í báðum tilfellum fá viðskiptavinir sem gerast áskrifendur að tilkynningum ítarlegar upplýsingar um breytingarnar í formi „auðlindadelta“. Delta lýsir breytingum á milli tveggja stöðu auðlinda (undir) tré vinnusvæðis og er sjálft tré, þar sem hver hnútur lýsir breytingu á auðlind og inniheldur lista yfir deltas á næsta stigi sem lýsa breytingum á undirtilföngum.
Hrísgrjón. 3. IResourceChangeEvent og IResourceDelta
Tilkynningakerfið sem byggir á auðlindaþáttum hefur eftirfarandi eiginleika:
- Einni breytingu og mörgum breytingum er lýst með sömu uppbyggingu, þar sem delta er byggt með reglunni um endurkvæma samsetningu. Viðskiptavinir áskrifenda geta unnið úr tilkynningum um auðlindabreytingar með því að nota endurkvæma niðurkomu í gegnum tré af deltas.
- Delta inniheldur heildarupplýsingar um breytingar á auðlindinni, þar á meðal hreyfingu hennar og/eða breytingar á „merkjum“ sem tengjast henni (til dæmis eru samsetningarvillur sýndar sem merki).
- Þar sem auðlindatilvísanir eru gerðar í gegnum handfangið getur delta náttúrulega vísað til fjarlægrar auðlindar.
Eins og við munum brátt sjá, eru helstu þættir hönnunar tilkynningakerfis um breytingar á auðlindalíkani einnig viðeigandi fyrir önnur handfangsbundin líkön.
JDT kjarna
Eclipse vinnusvæði auðlindalíkanið er grundvallarmál-agnostic líkan. JDT Core hluti (plugin org.eclipse.jdt.core) býður upp á API til að fletta og greina vinnusvæðisskipulagið frá Java sjónarhorni, svokallað „Java líkan“ (Java líkan). Þetta API er skilgreint með tilliti til Java þátta, öfugt við undirliggjandi auðlindalíkan API, sem er skilgreint út frá möppum og skrám. Helstu viðmót Java frumefnatrésins eru sýnd á mynd. 4.
Hrísgrjón. 4. Java Model Elements
Java líkanið notar sama handfangs-/líkamsmál og auðlindalíkanið (mynd 5). IJavaElement er handfangið og JavaElementInfo gegnir hlutverki líkamans. IJavaElement viðmótið skilgreinir samskiptareglur sem eru sameiginlegar öllum Java þáttum. Sumar aðferðir þess eru eingöngu meðhöndlun: getElementName(), getParent(), osfrv. JavaElementInfo hluturinn geymir ástand samsvarandi þáttar: uppbyggingu hans og eiginleika.
Hrísgrjón. 5. IJavaElement og JavaElementInfo
Java líkanið hefur nokkurn mun á útfærslu grunnhönnunar handfangs/líkams miðað við auðlindalíkanið. Eins og fram kemur hér að ofan, í auðlindalíkaninu, er frumefnistréð, þar sem hnútar eru auðlindaupplýsingar hlutir, að öllu leyti í minni. En Java líkanið getur haft umtalsvert fleiri þætti en auðlindatréð, vegna þess að það táknar einnig innri uppbyggingu .java og .class skráa: tegundir, reiti og aðferðir.
Til að koma í veg fyrir að allt tréð af þáttum verði að fullu að veruleika í minni, notar Java líkanútfærslan LRU skyndiminni af takmörkuðu stærð með upplýsingum um frumefni, þar sem lykillinn er handfang IJavaElement. frumefnisupplýsingahlutir eru búnir til þegar óskað er eftir því sem frumefnistréð er siglt. Í þessu tilviki er þeim hlutum sem minnst eru notaðir hent úr skyndiminni og minnisnotkun líkansins er áfram takmörkuð við tilgreinda skyndiminnisstærð. Þetta er annar kostur við hönnun sem byggir á handfangi, sem felur slíkar útfærsluupplýsingar algjörlega fyrir kóða viðskiptavinarins.
Fyrirkomulagið til að tilkynna breytingar á Java þáttum er almennt svipað og fyrirkomulagið til að rekja breytingar á vinnusvæðisauðlindum sem fjallað er um hér að ofan. Viðskiptavinur sem vill fylgjast með breytingum á Java líkaninu gerist áskrifandi að tilkynningum, sem eru sýndar sem ElementChangedEvent hlutur sem inniheldur IJavaElementDelta (mynd 6).
Hrísgrjón. 6. ElementChangedEvent og IJavaElementDelta
Java líkanið inniheldur ekki upplýsingar um aðferðarhluta eða upplausn nafna, þannig að fyrir nákvæma greiningu á kóða sem skrifaður er í Java, býður JDT Core upp á viðbótarlíkan (sem byggir ekki á handfangi): (abstrakt setningafræðitré, AST). AST táknar niðurstöðu þáttunar frumtextans. AST hnútar samsvara þáttum í uppbyggingu frumeiningarinnar (yfirlýsingar, rekstraraðilar, orðasambönd o.s.frv.) og innihalda upplýsingar um hnit samsvarandi þáttar í frumtextanum, sem og (sem valkostur) upplýsingar um nafnaupplausn í form tengla á svokallaða bindingar. Bindingar eru hlutir sem tákna nafngreindar einingar, svo sem tegundir, aðferðir og breytur, sem þýðandinn þekkir. Ólíkt AST hnútum, sem mynda tré, styðja bindingar víxlvísanir og mynda yfirleitt línurit. Ágripsflokkurinn ASTNode er sameiginlegur grunnflokkur allra AST hnúta. ASTNode undirflokkar samsvara tilteknum setningafræðilegum byggingu Java tungumálsins.
Vegna þess að setningafræðitré geta neytt umtalsvert magn af minni, vistar JDT aðeins eina AST fyrir virka ritstjórann. Ólíkt Java líkaninu er venjulega litið á AST sem „millistig,“ „tímabundið“ líkan þar sem viðskiptavinir ættu ekki að vísa til meðlima utan samhengis aðgerðarinnar sem leiddi til stofnunar AST.
Módelin þrjú (Java líkan, AST, bindingar) mynda saman grunninn að því að byggja upp „greind þróunarverkfæri“ í JDT, þar á meðal öflugan Java ritstjóra með ýmsum „hjálparaðilum“, ýmsar aðgerðir til að vinna frumkóða (þar á meðal að skipuleggja innflutningslista nöfn og snið í samræmi við sérsniðna stíl), leitar- og endurstillingartæki. Í þessu tilviki gegnir Java líkanið sérstöku hlutverki, þar sem það er það sem er notað sem grunnur fyrir sjónræna framsetningu á uppbyggingu forritsins sem verið er að þróa (til dæmis í Package Explorer, Outline, Search, Call Hierarchy, og Tegund stigveldi).
Eclipse íhlutir notaðir í 1C:Enterprise Developments Tools
Í mynd. Mynd 7 sýnir Eclipse íhlutina sem mynda grunninn að tæknivettvangi fyrir 1C:Enterprise Development Tools.
Hrísgrjón. 7. Eclipse sem vettvangur fyrir 1C:Enterprise Development Tools
Eclipse pallur veitir grunninnviði. Við skoðuðum nokkra þætti þessa innviða í fyrri hlutanum.
(EMF) veitir almenna leið til að búa til líkan af skipulögðum gögnum. EMF er samþætt við Eclipse Platform, en einnig er hægt að nota það sérstaklega í venjulegum Java forritum. Oft eru nýir Eclipse forritarar þegar vel kunnir EMF, þó að þeir skilji ekki enn til fulls ranghala Eclipse Platformsins. Ein af ástæðunum fyrir svo verðskulduðum vinsældum er alhliða hönnunin, sem inniheldur meðal annars sameinað meta-level API, sem gerir þér kleift að vinna með hvaða EMF líkan sem er á almennan hátt. Grunnútfærslur fyrir líkanhluti sem EMF býður upp á og undirkerfið til að búa til líkankóða sem byggir á meta-líkaninu auka verulega þróunarhraða og fækka villum. EMF inniheldur einnig aðferðir til að raðgreina líkön, rekja breytingar á líkaninu og margt fleira.
Eins og öll raunveruleg almenn tól, er EMF hentugur til að leysa margs konar líkanavandamál, en sumir flokkar líkana (til dæmis handfangstengdu módelin sem fjallað er um hér að ofan) gætu þurft sérhæfðari líkanaverkfæri. Að tala um EMF er vanþakklátt verkefni, sérstaklega innan takmarkaðra marka einnar greinar, þar sem þetta er efni í sérstakri bók og frekar þykka. Við skulum aðeins athuga að hágæða kerfi alhæfinga sem liggur að baki EMF gerði kleift að búa til fjölda verkefna tileinkað líkanagerð, sem eru innifalin í efsta stigi verkefnisins ásamt EMF sjálfum. Eitt slíkt verkefni er Eclipse Xtext.
veitir "textalíkön" innviði. Xtext notar til að flokka frumtextann og EMF til að tákna ASG sem myndast (abstrakt merkingarrit, sem er í raun sambland af AST og bindingum), einnig kallað „merkingarlíkanið“. Málfræði tungumálsins sem Xtext hefur fyrirmynd er lýst á eigin tungumáli Xtext. Þetta gerir þér ekki aðeins kleift að búa til málfræðilýsingu fyrir ANTLR, heldur einnig til að fá AST raðgreiningarkerfi (þ.e. Xtext veitir bæði flokkun og afgreiningu), samhengisvísbendingu og fjölda annarra tungumálahluta. Á hinn bóginn er málfræðimálið sem notað er í Xtext minna sveigjanlegt en til dæmis málfræðimálið sem notað er í ANTLR. Þess vegna er stundum nauðsynlegt að „beygja“ útfærða tungumálið yfir í Xtext, sem er venjulega ekki vandamál ef við erum að tala um að tungumál sé þróað frá grunni, en gæti verið óviðunandi fyrir tungumál með þegar staðfesta setningafræði. Þrátt fyrir þetta er Xtext sem stendur þroskaðasta, eiginleikaríkasta og fjölhæfasta tólið í Eclipse til að byggja upp forritunarmál og þróunarverkfæri fyrir þau. Sérstaklega er það tilvalið tæki fyrir hraða frumgerð (lénssértækt tungumál, DSL). Til viðbótar við ofangreindan „tungumálakjarna“ sem byggir á ANTLR og EMF, býður Xtext upp á marga gagnlega íhluti á hærra stigi, þar á meðal flokkunarkerfi, stigvaxandi byggingu, „snjall ritstjóra“ og margt, margt fleira, en sleppir handfangi- byggt tungumálalíkön. Eins og EMF er Xtext efni sem er verðugt sérstakrar bókar og við getum varla talað stuttlega um alla möguleika þess núna.
1C:Enterprise Development Tools nota virkan bæði EMF sjálft og fjölda annarra Eclipse Modeling verkefna. Sérstaklega er Xtext ein af undirstöðum þróunarverkfæra fyrir slík 1C:Enterprise tungumál sem innbyggt forritunarmál og fyrirspurnarmál. Annar grundvöllur fyrir þessum þróunarverkfærum er Eclipse Handly verkefnið, sem við munum ræða nánar (af Eclipse íhlutunum sem taldir eru upp er það samt minnst þekkt).
, undirverkefni Eclipse Technology efstu verkefnisins, varð til vegna upphafs kóðaframlags til Eclipse Foundation sem 1C gerði árið 2014. Síðan þá hefur 1C haldið áfram að styðja við þróun verkefnisins: Handvirkir skuldbindingar eru starfsmenn fyrirtækisins. Verkefnið er lítið, en það á frekar einstakan sess í Eclipse: Meginmarkmið þess er að styðja við þróun handfangsbundinna líkana.
Fjallað var um helstu byggingarreglur handfangsmiðaðra líkana, eins og handfang/líkamsmálið, hér að ofan með því að nota auðlindalíkanið og Java líkanið sem dæmi. Það tók einnig fram að bæði auðlindalíkanið og Java líkanið eru mikilvægar undirstöður Eclipse Java þróunarverkfæranna (JDT). Og þar sem næstum öll *DT Eclipse verkefnin eru með svipaðan arkitektúr og JDT, væri ekki ofmælt að segja að handfangstengd líkön liggi að baki mörgum, ef ekki öllum IDE sem eru byggð ofan á Eclipse pallinum. Til dæmis er Eclipse C/C++ þróunarverkfæri (CDT) með handfangstengt C/C++ líkan sem gegnir sama hlutverki í CDT arkitektúrnum og Java líkanið gerir í JDT.
Áður en Handly bauð Eclipse ekki upp á sérhæfð bókasöfn til að byggja handfangstengd tungumálalíkön. Líkönin sem nú eru til voru aðallega búin til með því að aðlaga Java líkankóðann beint (aka copy/paste), í þeim tilvikum þar sem það leyfir Eclipse Public License (EPL). (Augljóslega er þetta yfirleitt ekki lagalegt álitaefni fyrir td Eclipse verkefnin sjálft, en ekki fyrir lokaðar vörur.) Til viðbótar við eðlislæga tilviljun, kynnir þessi tækni vel þekkt vandamál: tvíföldun kóða kynnt af þegar aðlagast villum, o.s.frv. Það sem verra er er að módelin sem myndast eru áfram „hlutir í sjálfu sér“ og nýta ekki möguleikann á sameiningu. En að einangra algeng hugtök og samskiptareglur fyrir handfangstengd tungumálalíkön gæti leitt til þess að hægt væri að búa til endurnýtanlega hluti til að vinna með þau, svipað og gerðist þegar um EMF var að ræða.
Það er ekki það að Eclipse hafi ekki skilið þessi mál. Aftur árið 2005 , draga saman reynsluna af þróun CDT frumgerðarinnar, nauðsyn þess að búa til sameiginlegan innviði fyrir tungumálalíkön, þar með talið handfangsmiðuð líkön. En eins og oft vill verða, vegna verkefna sem eru forgangsverkefni, náði framkvæmd þessara hugmynda aldrei fram að ganga. Á sama tíma er þáttaskipti á *DT kóða enn eitt af vanþróuðu efninu í Eclipse.
Í vissum skilningi er Handly verkefnið hannað til að leysa um það bil sömu vandamál og EMF, en fyrir handfangstengd líkön, og fyrst og fremst tungumál (þ.e. tákna þætti í uppbyggingu einhvers forritunarmáls). Helstu markmiðin sem sett eru við hönnun Handly eru talin upp hér að neðan:
- Greining á helstu útdrætti efnissviðsins.
- Draga úr fyrirhöfn og bæta gæði innleiðingar á handfangstengdum tungumálalíkönum með endurnotkun kóða.
- Að útvega sameinað meta-level API fyrir módel sem myndast, sem gerir það mögulegt að búa til algenga IDE íhluti sem vinna með tungumálahandfangsbyggðum líkönum.
- Sveigjanleiki og sveigjanleiki.
- Samþætting við Xtext (í sérstöku lagi).
Til að varpa ljósi á algeng hugtök og samskiptareglur voru núverandi útfærslur á líkönum sem byggjast á tungumálahandfangi greindar. Helstu viðmót og grunnútfærslur sem Handly veitir eru sýndar á mynd. 8.
Hrísgrjón. 8. Algeng viðmót og grunnútfærslur á Handly þáttum
IElement viðmótið táknar handfang þáttar og er sameiginlegt fyrir þætti allra handvirkra gerða. Óhlutbundinn flokkur Element útfærir almenna handfangs-/líkamsbúnaðinn (mynd 9).
Hrísgrjón. 9. IElement og almenn handfang/líkamsútfærsla
Að auki veitir Handly almennt kerfi til að tilkynna um breytingar á líkanþáttum (mynd 10). Eins og þú sérð er það í stórum dráttum svipað tilkynningakerfi sem er útfært í auðlindalíkaninu og Java líkaninu og notar IElementDelta til að veita samræmda framsetningu á upplýsingum um frumefnisbreytingar.
Hrísgrjón. 10. Almenn viðmót og grunnútfærslur á Handly tilkynningakerfi
Handly hlutann sem fjallað er um hér að ofan (Mynd 9 og 10) er hægt að nota til að tákna næstum hvaða handfangsbundnar gerðir. Til að búa til málfræðilega módel býður verkefnið upp á viðbótarvirkni - einkum sameiginleg viðmót og grunnútfærslur fyrir þætti frumtextabyggingarinnar, svokallaða frumþætti (mynd 8). ISourceFile viðmótið táknar frumskrá og ISourceConstruct táknar frumefni í frumskránni. Ágripsflokkarnir SourceFile og SourceConstruct innleiða almennar aðferðir til að styðja við að vinna með frumskrár og þætti þeirra, til dæmis að vinna með textabuffa, binda við hnit staks í frumtextanum, samræma líkön við núverandi innihald vinnuafrits biðminni. , o.s.frv. Innleiðing þessara aðferða er yfirleitt töluverð áskorun og Handly getur dregið verulega úr fyrirhöfn við að þróa handfangstengd tungumálalíkön með því að bjóða upp á hágæða grunnútfærslur.
Til viðbótar við kjarnaaðferðirnar sem taldar eru upp hér að ofan, býður Handly upp á innviði fyrir textabuffa og skyndimyndir, stuðning við samþættingu við frumkóðaritla (þar á meðal samþættingu út úr kassanum við Xtext ritstjórann), auk nokkurra algengra notendaviðmóta sem vinna með frumkóða ritstjórum. Handvirk líkön eins og útlínuramma. Til að sýna getu þess gefur verkefnið nokkur dæmi, þar á meðal útfærslu á Java líkaninu í Handly. (Í samanburði við fulla útfærslu Java líkansins í JDT er þetta líkan viljandi einfaldað til að fá meiri skýrleika.)
Eins og áður hefur komið fram var mikil áhersla við upphafshönnun Handly og síðari þróun á sveigjanleika og sveigjanleika.
Í grundvallaratriðum skalast handfangstengdar gerðir nokkuð vel „eftir hönnun“. Til dæmis, handfangs-/líkamsmálið gerir þér kleift að takmarka magn minnis sem líkan notar. En það eru líka blæbrigði. Svona, þegar Handly var prófað fyrir sveigjanleika, uppgötvaðist vandamál við innleiðingu tilkynningakerfisins - þegar miklum fjölda þátta var breytt tók of langan tíma að smíða deltas. Það kom í ljós að sama vandamál var til staðar í JDT Java líkaninu, sem samsvarandi kóða var einu sinni aðlagaður. Við laguðum villuna í Handly og útbjuggum svipaðan plástur fyrir JDT sem fékk þakkir. Þetta er aðeins eitt dæmi þar sem hugsanlega gæti verið gagnlegt að kynna Handly í núverandi líkanaútfærslum, því í þessu tilfelli væri hægt að laga slíka villu á einum stað.
Til að gera innleiðingu Handly í núverandi líkanaútfærslum tæknilega framkvæmanlega verður bókasafnið að hafa umtalsverðan sveigjanleika. Helsta vandamálið er að viðhalda afturábakssamhæfi yfir API líkanið. Þetta vandamál var leyst í með því að aðgreina skýrt módelsértækt API, skilgreint og fullkomlega stjórnað af þróunaraðilanum, frá sameinuðu meta-stigi API sem bókasafnið gefur. Þetta gerir það ekki aðeins tæknilega mögulegt að innleiða Handly í núverandi útfærslur, heldur gefur nýja líkanframleiðandanum einnig verulegt frelsi þegar hann hannar API.
Sveigjanleiki hefur líka aðra þætti. Til dæmis setur Handly nánast engar takmarkanir á uppbyggingu líkansins og er hægt að nota það til að líkja bæði almennum og lénssértækum tungumálum. Við smíði uppbyggingar frumskrárinnar ávísar Handly ekki neinni sérstakri mynd af AST framsetningu og krefst í grundvallaratriðum ekki einu sinni tilvist AST sjálfs og tryggir þannig samhæfni við nánast hvaða þáttunarkerfi sem er. Að lokum styður Handly fulla samþættingu við Eclipse vinnusvæði, en getur einnig unnið beint með skráarkerfum þökk sé samþættingu þess við (EFS).
Núverandi útgáfa kom út í desember 2016. Þrátt fyrir þá staðreynd að verkefnið sé nú í ræktunarástandi og API hefur ekki enn verið endanlega lagað, er Handly nú þegar notað í tveimur stórum viðskiptavörum sem tóku áhættuna á að starfa sem „early adopters“ og, ég verð að segja, sé ekki eftir því ennþá.
Eins og fram kemur hér að ofan er ein af þessum vörum 1C:Enterprise Development Tools, þar sem Handly er notað frá upphafi til að móta þætti í háþróaðri uppbyggingu slíkra 1C:Enterprise tungumála sem innbyggt forritunarmál og fyrirspurnarmál. . Önnur vara er minna þekkt fyrir almenning. Þetta , samþætt hönnunarumhverfi fyrir ASIP (application-specific instruction-set processor), notað bæði innan tékkneska fyrirtækisins Codasip sjálfs og af viðskiptavinum þess, þ.m.t. , , , . Codasip hefur notað Handly í framleiðslu síðan 2015 og byrjaði með útgáfu Handly 0.2. Nýjasta útgáfan af Codasip Studio notar útgáfu 0.5, gefin út í júní 2016. Ondřej Ilčík, sem stýrir IDE þróun hjá Codasip, er í sambandi við verkefnið og veitir mikilvæg endurgjöf fyrir hönd „þriðju aðila sem ættleiðir“. Hann gat meira að segja fundið sér frítíma til að taka beinan þátt í þróun verkefnisins og innleiða UI lag (~4000 línur af kóða) fyrir eitt af Handly dæmunum, Java líkan. Nánari upplýsingar frá fyrstu hendi um notkun ættleiðenda á Handly má finna á síðunni verkefni.
Við vonum að eftir útgáfu útgáfu 1.0 með tryggingu fyrir API stöðugleika og verkefnið sem yfirgefur ræktunarástandið, muni Handly fá nýja notendur. Í millitíðinni heldur verkefnið áfram að prófa og bæta forritaskilin enn frekar, gefa út tvær „stórar“ útgáfur á ári - í júní (sama dagsetning og samtímis Eclipse útgáfu) og desember, sem gefur fyrirsjáanlega áætlun sem notendur geta reitt sig á. Við getum líka bætt því við að „villuhlutfall“ verkefnisins er stöðugt lágt og Handly hefur unnið á áreiðanlegan hátt í vörum snemma notenda frá fyrstu útgáfum. Til að kanna Eclipse Handly frekar geturðu notað и .
Heimild: www.habr.com