Líklega,
Í þ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.
Kynning á Eclipse Architecture
Við skulum fyrst skoða nokkrar almennar hliðar Eclipse arkitektúrsins með því að nota dæmið
Í 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 á
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):
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.
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
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).
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
Í 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 í
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ð
Núverandi útgáfa
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
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