Tingali, dugay na nga wala magkinahanglan ug espesyal nga pasiuna. Daghang mga tawo ang pamilyar sa Eclipse salamat sa mga gamit sa pagpalambo sa Eclipse Java (). Kini ang sikat nga open-source nga Java IDE nga kadaghanan sa mga developer nakig-uban sa pulong nga "Eclipse". Bisan pa, ang Eclipse pareho nga usa ka gipalapdan nga plataporma alang sa pag-integrate sa mga himan sa pag-uswag (Eclipse Platform), ug daghang mga IDE nga gitukod base niini, lakip ang JDT. Ang Eclipse mao ang Eclipse Project, ang top-level nga proyekto nga nag-coordinate sa pagpalambo sa Eclipse Platform ug sa JDT, ug ang Eclipse SDK, ang gihatag nga resulta sa maong kalamboan. Sa katapusan, ang Eclipse usa ka bukas nga gigikanan nga Foundation nga adunay daghang komunidad sa mga proyekto, dili tanan niini gisulat sa Java o adunay kalabotan sa mga himan sa pag-uswag (pananglitan, mga proyekto и ). Ang kalibutan sa Eclipse lainlain kaayo.
Niini nga artikulo, nga usa ka kinatibuk-ang panan-aw sa kinaiyahan, sulayan namon nga tan-awon ang pipila nga mga sukaranan sa arkitektura sa Eclipse ingon usa ka plataporma alang sa pagtukod sa hiniusa nga mga himan sa pag-uswag ug paghatag usa ka inisyal nga ideya sa mga sangkap sa Eclipse nga nahimong pundasyon sa teknolohiya. plataporma alang sa "bag-ong Configurator" 1C: Enterprise. . Siyempre, ang ingon nga pagrepaso dili kalikayan nga labi ka taphaw ug labi ka limitado, lakip ang tungod kay kami nagpunting dili lamang sa mga nag-develop sa Eclipse ingon ang target nga mamiminaw. Bisan pa, nanghinaut kami nga bisan ang mga eksperyensiyado nga mga developer sa Eclipse makapangita makapaikag nga kasayuran sa artikulo. Pananglitan, maghisgot kita bahin sa usa sa "mga sekreto sa Eclipse", usa ka medyo bag-o ug gamay nga nahibal-an nga proyekto. , nga gitukod ug gisuportahan sa 1C.
Pasiuna sa Eclipse Architecture
Atong tan-awon una ang pipila ka kinatibuk-ang aspeto sa arkitektura sa Eclipse gamit ang pananglitan (JDT). Ang pagpili sa JDT isip ehemplo dili aksidente. Kini ang una nga integrated development environment nga makita sa Eclipse. Ang uban nga *DT Eclipse nga mga proyekto, sama sa Eclipse C/C++ Development Tooling (CDT), gimugna sa ulahi ug nanghulam sa duha ka batakang mga prinsipyo sa arkitektura ug indibidwal nga mga tipik sa source code gikan sa JDT. Ang sukaranan sa arkitektura nga gilatid sa JDT may kalabutan hangtod karon alang sa halos bisan unsang IDE nga gitukod sa ibabaw sa Eclipse Platform, lakip ang 1C: Enterprise Development Tools.
Una sa tanan, kinahanglan nga matikdan nga ang Eclipse gihulagway sa usa ka medyo tin-aw nga layering sa arkitektura, nga adunay pagbulag sa pag-andar nga independente sa lengguwahe gikan sa pag-andar nga gidisenyo aron suportahan ang piho nga mga sinultian sa programming, ug ang pagbulag sa mga sangkap nga "kinauyokan" nga UI gikan sa mga sangkap nga kauban. uban sa pagsuporta sa user interface.
Busa, ang Eclipse Platform naghubit sa usa ka komon, imprastraktura nga independente sa pinulongan, ug ang mga galamiton sa pagpalambo sa Java nagdugang sa usa ka bug-os nga bahin nga Java IDE sa Eclipse. Ang Eclipse Platform ug ang JDT naglangkob sa daghang mga sangkap, nga ang matag usa iya sa usa ka UI-independent nga "kinauyokan" o usa ka layer sa UI (Figure 1).
bugas. 1. Eclipse Platform ug JDT
Atong ilista ang mga nag-unang sangkap sa Eclipse Platform:
- Runtime - Gihubit ang imprastraktura sa plugin. Ang Eclipse gihulagway sa usa ka modular nga arkitektura. Sa tinuud, ang Eclipse usa ka koleksyon sa "mga punto sa extension" ug "mga extension".
- Lugar sa trabahoan - Nagdumala sa usa o daghang mga proyekto. Ang usa ka proyekto naglangkob sa mga folder ug mga file nga direkta nga mapa sa file system.
- Standard Widget Toolkit (SWT) - Naghatag sukaranan nga mga elemento sa user interface nga gisagol sa operating system.
- JNawong - Naghatag daghang UI frameworks nga gitukod sa ibabaw sa SWT.
- Workbench - Gihubit ang paradigm sa Eclipse UI: mga editor, mga panan-aw, mga panan-aw.
Kinahanglang isulti nga ang Eclipse Platform naghatag usab daghang uban pang mapuslanon nga mga sangkap alang sa pagtukod sa hiniusa nga mga himan sa pag-uswag, lakip ang Debug, Pagtandi, Pagpangita, ug Team. Espesyal nga paghisgot kinahanglan nga himoon sa JFace Text - ang basehan sa pagtukod sa "smart editors" sa source code. Ikasubo, bisan ang usa ka pintas nga pagsusi sa kini nga mga sangkap, ingon man ang mga sangkap sa layer sa UI, dili mahimo sa sulud sa kini nga artikulo, mao nga sa nahabilin sa kini nga seksyon limitahan namon ang among kaugalingon sa usa ka kinatibuk-ang pagtan-aw sa mga nag-unang "kinauyokan" nga sangkap sa ang Eclipse Platform ug JDT.
Core Runtime
Ang imprastraktura sa Eclipse plugin gibase sa ug gihatag sa proyekto . Ang matag Eclipse plugin usa ka OSGi bundle. Ang espesipikasyon sa OSGi naghubit, ilabina, sa mga mekanismo alang sa pag-bersyon ug resolusyon sa dependency. Dugang sa kini nga mga sumbanan nga mekanismo, gipaila sa Equinox ang konsepto mga punto sa pagpalapad. Ang matag plugin mahimong maghubit sa kaugalingon nga mga punto sa extension, ug usab magpaila sa dugang nga gamit ("mga extension") sa sistema gamit ang mga extension point nga gihubit sa parehas o uban pang mga plugin. Ang bisan unsang detalyado nga paghubit sa mga mekanismo sa OSGi ug Equinox lapas sa kasangkaran niini nga artikulo. Atong timan-an lang nga ang modularization sa Eclipse kay total (bisan unsang subsystem, lakip ang Runtime, naglangkob sa usa o daghan pang plugins), ug halos tanan sa Eclipse kay extension. Dugang pa, kini nga mga prinsipyo gilakip sa arkitektura sa Eclipse dugay na sa wala pa ang pagpaila sa OSGi (niadtong panahona gigamit nila ang ilang kaugalingon nga teknolohiya, parehas sa OSGi).
Panguna nga Workspace
Halos bisan unsang integrated development environment nga gitukod sa ibabaw sa Eclipse Platform nagtrabaho sa Eclipse workspace. Kini ang workspace nga kasagaran adunay source code sa aplikasyon nga gihimo sa IDE. Direkta nga mapa ang workspace sa file system ug naglangkob sa mga proyekto nga adunay mga folder ug mga file. Kini nga mga proyekto, mga folder, ug mga file gitawag kahinguhaan workspace. Ang pagpatuman sa workspace sa Eclipse nagsilbing cache nga may kalabotan sa file system, nga nagpaposible nga mapadali ang pag-agi sa punoan sa kapanguhaan. Dugang pa, ang workspace naghatag daghang dugang nga mga serbisyo, lakip ang и .
Ang Core Resources component (org.eclipse.core.resources plugin) maoy responsable sa pagsuporta sa workspace ug sa mga kahinguhaan niini. Sa partikular, kini nga component naghatag ug programmatic access sa workspace sa porma mga modelo sa kapanguhaan. Aron epektibong magtrabaho sa kini nga modelo, ang mga kliyente nanginahanglan usa ka yano nga paagi aron mapresentar ang usa ka link sa usa ka kapanguhaan. Sa kini nga kaso, gusto nga itago ang butang nga direkta nga nagtipig sa kahimtang sa kapanguhaan sa modelo gikan sa pag-access sa kliyente. Kung dili, sa kaso sa, pananglitan, pagtangtang sa usa ka file, ang kliyente mahimo’g magpadayon sa paghupot sa usa ka butang nga wala na sa modelo, uban ang mga nagsunod nga mga problema. Gisulbad sa Eclipse kini nga problema gamit ang usa ka butang nga gitawag Pagdumala kahinguhaan. Ang pagdumala naglihok isip usa ka yawe (kini nahibal-an lamang ang agianan sa kapanguhaan sa workspace) ug hingpit nga nagkontrol sa pag-access sa internal nga modelo nga butang, nga direktang nagtipig sa impormasyon mahitungod sa kahimtang sa kapanguhaan. Kini nga disenyo usa ka kalainan sa sumbanan .
bugas. Ang Figure 2 naghulagway sa Handle/Body idiom nga gigamit sa resource model. Ang interface sa IResource nagrepresentar sa kuptanan sa usa ka kapanguhaan ug usa ka API, dili sama sa Resource nga klase, nga nagpatuman niini nga interface, ug ang ResourceInfo nga klase, nga nagrepresentar sa lawas, nga dili mga API. Among gihatagan og gibug-aton nga ang gunitanan nahibalo lamang sa agianan paingon sa kahinguhaan nga may kalabotan sa gamut sa workspace ug walay sumpay sa impormasyon sa kahinguhaan. Ang mga butang sa impormasyon sa kahinguhaan nagporma og gitawag nga "element tree". Kini nga istruktura sa datos hingpit nga nahimo sa memorya. Aron makit-an ang pananglitan sa impormasyon sa kahinguhaan nga katugbang sa usa ka kuptanan, ang punoan sa elemento giagian sumala sa agianan nga gitipigan sa kana nga kuptanan.
bugas. 2. IResource ug ResourceInfo
Sama sa atong makita sa ulahi, ang batakang disenyo sa modelo sa kahinguhaan (mahimo natong tawgon kini nga nakabase sa gunitanan) gigamit sa Eclipse alang usab sa ubang mga modelo. Sa pagkakaron, atong ilista ang pipila ka talagsaong mga kabtangan niini nga disenyo:
- Ang gunitanan usa ka butang nga bili. Ang mga butang nga bili kay dili mausab nga mga butang kansang pagkaparehas wala gibase sa pagkatawo. Ang ingon nga mga butang mahimong luwas nga magamit ingon usa ka yawe sa mga hashed nga sudlanan. Daghang mga higayon sa kuptanan mahimong maghisgot sa parehas nga kapanguhaan. Aron itandi kini, kinahanglan nimo nga gamiton ang equals(Object) nga pamaagi.
- Gihubit sa Handle ang pamatasan sa usa ka kapanguhaan, apan wala’y sulud nga kasayuran bahin sa kahimtang sa kapanguhaan (ang bugtong datos nga gitipigan niini mao ang "yabe", ang agianan padulong sa kapanguhaan).
- Ang Handle mahimong magtumong sa usa ka kapanguhaan nga wala (bisan usa ka kapanguhaan nga wala pa nahimo, o usa ka kapanguhaan nga natangtang na). Ang paglungtad sa usa ka kapanguhaan mahimong masusi gamit ang IResource.exists() nga pamaagi.
- Ang ubang mga operasyon mahimong ipatuman base lamang sa impormasyon nga gitipigan sa kuptanan mismo (gitawag nga kuptanan-lamang nga mga operasyon). Ang mga pananglitan mao ang IResource.getParent(), getFullPath(), etc. Ang kahinguhaan dili kinahanglan nga maglungtad aron molampos ang ingon nga operasyon. Ang mga operasyon nga nanginahanglan usa ka kapanguhaan nga maglungtad aron magmalampuson maghulog sa usa ka CoreException kung wala ang kapanguhaan.
Ang Eclipse naghatag usa ka episyente nga mekanismo alang sa pagpahibalo sa mga pagbag-o sa kapanguhaan sa workspace (Figure 3). Mahimong mabag-o ang mga kapanguhaan ingon usa ka sangputanan sa mga aksyon nga gihimo sa sulod mismo sa Eclipse IDE o ingon usa ka sangputanan sa pag-synchronize sa file system. Sa duha nga mga kaso, ang mga kliyente nga nag-subscribe sa mga pahibalo gihatagan og detalyado nga kasayuran bahin sa mga pagbag-o sa porma sa "mga delta sa kapanguhaan". Ang usa ka delta naghulagway sa mga kausaban tali sa duha ka estado sa usa ka workspace resource (sub-) tree ug kini mismo usa ka kahoy, ang matag node niini naghulagway sa usa ka pagbag-o sa usa ka kapanguhaan ug adunay usa ka lista sa mga delta sa sunod nga lebel nga naghulagway sa mga kausaban sa child resources.
bugas. 3. IResourceChangeEvent ug IResourceDelta
Ang mekanismo sa pagpahibalo base sa mga delta sa kahinguhaan adunay mga mosunod nga mga kinaiya:
- Ang usa ka pagbag-o ug daghang mga pagbag-o gihulagway gamit ang parehas nga istruktura, tungod kay ang delta gitukod gamit ang prinsipyo sa recursive nga komposisyon. Ang mga kliyente sa subscriber mahimong magproseso sa mga abiso sa pagbag-o sa kapanguhaan gamit ang recursive nga pagkanaog pinaagi sa usa ka punoan sa delta.
- Ang delta adunay kompleto nga impormasyon bahin sa mga pagbag-o sa kahinguhaan, lakip ang paglihok niini ug/o mga pagbag-o sa mga "marker" nga kauban niini (pananglitan, ang mga sayup sa pag-compile girepresentahan ingon mga marker).
- Tungod kay ang mga reperensya sa kahinguhaan gihimo pinaagi sa kuptanan, ang delta natural nga mahimong maghisgot sa usa ka hilit nga kapanguhaan.
Sama sa atong makita sa dili madugay, ang mga nag-unang sangkap sa disenyo sa mekanismo sa pagbag-o sa pagbag-o sa modelo sa kapanguhaan adunay kalabotan usab alang sa ubang mga modelo nga nakabase sa kuptanan.
JDT Core
Ang modelo sa kapanguhaan sa workspace sa Eclipse usa ka sukaranan nga modelo nga agnostic sa pinulongan. Ang JDT Core component (plugin org.eclipse.jdt.core) naghatag ug API para sa pag-navigate ug pag-analisar sa workspace structure gikan sa Java perspective, ang gitawag nga "Java model" (modelo sa Java). Kini nga API gihubit sa termino sa Java nga mga elemento, sukwahi sa nagpahiping resource model API, nga gihubit sa termino sa mga folder ug mga file. Ang mga nag-unang interface sa Java element tree gipakita sa Fig. 4.
bugas. 4. Mga Elemento sa Modelo sa Java
Ang modelo sa Java naggamit sa parehas nga kuptanan / idiom sa lawas ingon nga modelo sa kapanguhaan (Figure 5). Ang IJavaElement mao ang kuptanan, ug ang JavaElementInfo nagdula sa papel sa lawas. Ang interface sa IJavaElement naghubit sa usa ka protocol nga komon sa tanang elemento sa Java. Ang pipila sa mga pamaagi niini kay handle-only: getElementName(), getParent(), etc. Ang JavaElementInfo nga butang nagtipig sa kahimtang sa katugbang nga elemento: ang istruktura ug mga hiyas niini.
bugas. 5. IJavaElement ug JavaElementInfo
Ang modelo sa Java adunay pipila ka mga kalainan sa pagpatuman sa batakang disenyo sa gunitanan/lawas kon itandi sa modelo sa kapanguhaan. Ingon sa gihisgutan sa ibabaw, sa modelo sa kapanguhaan, ang punoan sa elemento, kansang mga node mga butang nga impormasyon sa kapanguhaan, hingpit nga naa sa memorya. Apan ang modelo sa Java mahimong adunay mas dako nga gidaghanon sa mga elemento kay sa punoan sa kapanguhaan, tungod kay kini nagrepresentar usab sa internal nga istruktura sa .java ug .class nga mga file: mga tipo, field, ug mga pamaagi.
Aron malikayan ang hingpit nga pag-materialize sa tibuok nga kahoy sa mga elemento sa memorya, ang pagpatuman sa modelo sa Java naggamit sa limitado nga gidak-on nga LRU cache sa impormasyon sa elemento, diin ang yawe mao ang pagdumala sa IJavaElement. Ang mga butang nga impormasyon sa elemento gihimo kung gipangayo samtang ang punoan sa elemento gi-navigate. Sa kini nga kaso, ang labing gamay nga gigamit nga mga butang gipapahawa gikan sa cache, ug ang konsumo sa panumduman sa modelo nagpabilin nga limitado sa gitakda nga gidak-on sa cache. Kini usa pa nga bentaha sa disenyo nga nakabase sa gunitanan, nga hingpit nga nagtago sa mga detalye sa pagpatuman gikan sa code sa kliyente.
Ang mekanismo sa pagpahibalo sa mga pagbag-o sa mga elemento sa Java sa kinatibuk-an susama sa mekanismo sa pagsubay sa mga pagbag-o sa mga kapanguhaan sa workspace nga gihisgutan sa ibabaw. Ang usa ka kliyente nga gusto nga mag-monitor sa mga pagbag-o sa modelo sa Java nag-subscribe sa mga pahibalo, nga girepresentahan ingon usa ka butang nga ElementChangedEvent nga adunay usa ka IJavaElementDelta (Figure 6).
bugas. 6. ElementChangedEvent ug IJavaElementDelta
Ang modelo sa Java walay impormasyon bahin sa mga lawas sa pamaagi o resolusyon sa ngalan, busa alang sa detalyadong pagtuki sa code nga gisulat sa Java, ang JDT Core naghatag ug dugang (dili-handle-based) nga modelo: (abstract nga syntax tree, AST). Ang AST nagrepresentar sa resulta sa pag-parse sa tinubdan nga teksto. Ang mga node sa AST katumbas sa mga elemento sa istruktura sa module sa gigikanan (mga deklarasyon, operator, ekspresyon, ug uban pa.) ang porma sa mga link sa gitawag nga bindings. Ang mga binding mao ang mga butang nga nagrepresentar sa ginganlan nga mga entidad, sama sa mga tipo, pamaagi, ug mga variable, nga nahibal-an sa compiler. Dili sama sa mga AST node, nga nagporma og usa ka kahoy, ang mga binding nagsuporta sa cross-referencing ug kasagaran nagporma og graph. Ang abstract nga klase nga ASTNode mao ang sagad nga base nga klase alang sa tanan nga mga AST node. Ang mga subclass sa ASTNode katumbas sa piho nga syntactic nga mga konstruksyon sa Java nga pinulongan.
Tungod kay ang mga punoan sa syntax makahurot ug daghang memorya, usa lang ka AST ang gitago sa JDT alang sa aktibong editor. Dili sama sa modelo sa Java, ang AST kasagarang gitan-aw nga usa ka "intermediate," "temporaryo" nga modelo kansang mga miyembro kinahanglan dili huptan nga gi-refer sa mga kliyente sa gawas sa konteksto sa operasyon nga nagdala sa paghimo sa AST.
Ang nalista nga tulo ka mga modelo (Java model, AST, bindings) naghiusa nga nahimong basehan sa pagtukod sa "intelligent development tools" sa JDT, lakip ang usa ka gamhanan nga Java editor nga adunay nagkalain-laing "katabang", nagkalain-laing mga aksyon alang sa pagproseso sa source code (lakip ang pag-organisar sa usa ka listahan sa importasyon. mga ngalan ug pag-format sumala sa gipahiangay nga istilo), mga himan sa pagpangita ug pag-refactor. Sa kini nga kaso, ang modelo sa Java adunay usa ka espesyal nga papel, tungod kay kini ang gigamit ingon sukaranan alang sa usa ka biswal nga representasyon sa istruktura sa aplikasyon nga gipalambo (pananglitan, sa Package Explorer, Outline, Search, Call Hierarchy, ug Type Hierarchy).
Ang mga sangkap sa Eclipse nga gigamit sa 1C: Mga Gamit sa Pagpauswag sa Negosyo
Sa Fig. Gipakita sa Figure 7 ang mga sangkap sa Eclipse nga nahimong pundasyon sa plataporma sa teknolohiya para sa 1C: Enterprise Development Tools.
bugas. 7. Eclipse isip plataporma para sa 1C:Enterprise Development Tools
Platform sa Eclipse naghatag ug batakang imprastraktura. Gitan-aw namon ang pipila ka mga aspeto sa kini nga imprastraktura sa miaging seksyon.
(EMF) naghatag ug kinatibuk-ang paagi sa pagmodelo sa structured data. Ang EMF gihiusa sa Eclipse Platform, apan mahimo usab nga gamiton nga gilain sa mga regular nga aplikasyon sa Java. Kasagaran, ang mga bag-ong developer sa Eclipse nahibal-an na ang EMF, bisan kung wala pa nila hingpit nga nasabtan ang mga kakuti sa Eclipse Platform. Usa sa mga hinungdan alang sa ingon nga takus nga pagkapopular mao ang unibersal nga disenyo, nga naglakip, taliwala sa ubang mga butang, usa ka hiniusa nga meta-level nga API, nga nagtugot kanimo sa pagtrabaho sa bisan unsang modelo sa EMF sa usa ka kinatibuk-ang paagi. Ang sukaranan nga mga pagpatuman alang sa modelo nga mga butang nga gihatag sa EMF ug ang subsystem alang sa pagmugna sa code sa modelo nga gibase sa meta-modelo nga makadugang sa katulin sa pag-uswag ug pagkunhod sa gidaghanon sa mga sayup. Naglangkob usab ang EMF og mga mekanismo alang sa pag-serialize sa mga modelo, pagsubay sa mga pagbag-o sa modelo, ug daghan pa.
Sama sa bisan unsa nga tinuod nga kinatibuk-ang katuyoan nga himan, ang EMF angay alang sa pagsulbad sa usa ka halapad nga mga problema sa pagmodelo, apan pipila ka mga klase sa mga modelo (pananglitan, ang mga modelo nga nakabase sa kuptanan nga gihisgutan sa ibabaw) mahimo’g magkinahanglan ug labi ka espesyal nga mga himan sa pagmodelo. Ang paghisgot bahin sa EMF usa ka dili mapasalamaton nga buluhaton, labi na sa sulod sa limitado nga mga limitasyon sa usa ka artikulo, tungod kay kini ang hilisgutan sa usa ka lahi nga libro, ug medyo baga. Atong timan-an lamang nga ang taas nga kalidad nga sistema sa mga generalization nga nagpahipi sa EMF nagtugot sa pagkahimugso sa usa ka tibuok nga han-ay sa mga proyekto nga gipahinungod sa pagmodelo, nga gilakip sa top-level nga proyekto kauban ang EMF mismo. Usa sa maong proyekto mao ang Eclipse Xtext.
naghatag ug "text modeling" nga imprastraktura. Gigamit ang Xtext alang sa pag-parse sa tinubdan nga teksto ug EMF alang sa pagrepresentar sa resulta nga ASG (abstract semantic graph, nga sa esensya usa ka kombinasyon sa AST ug bindings), gitawag usab nga "semantic model". Ang gramatika sa pinulongan nga gimodelo sa Xtext gihulagway sa kaugalingong pinulongan sa Xtext. Gitugotan ka niini dili lamang sa paghimo og usa ka deskripsyon sa gramatika alang sa ANTLR, apan aron makakuha usab usa ka mekanismo sa serialization sa AST (ie. Sa laing bahin, ang gramatika nga pinulongan nga gigamit sa Xtext dili kaayo flexible kaysa, ingnon ta, ang gramatika nga pinulongan nga gigamit sa ANTLR. Busa, usahay gikinahanglan nga "iduko" ang gipatuman nga pinulongan ngadto sa Xtext, nga kasagaran dili usa ka problema kung maghisgot kita mahitungod sa usa ka pinulongan nga naugmad gikan sa wala, apan mahimong dili madawat alang sa mga pinulongan nga adunay natukod na nga syntax. Bisan pa niini, ang Xtext sa pagkakaron mao ang pinakahamtong, adunahan sa feature, ug versatile nga himan sa Eclipse alang sa pagtukod sa mga programming language ug mga himan sa pagpalambo alang kanila. Sa partikular, kini usa ka sulundon nga himan alang sa paspas nga prototyping (pinulongan nga espesipiko sa domain, DSL). Dugang pa sa nahisgutan sa ibabaw nga "pinulongan nga kinauyokan" base sa ANTLR ug EMF, ang Xtext naghatag ug daghang mapuslanong mas taas nga lebel nga mga sangkap, lakip na ang mga mekanismo sa pag-indeks, incremental nga pagtukod, usa ka "smart editor", ug daghan pa, apan wala'y gunitanan- base sa mga modelo sa pinulongan. Sama sa EMF, ang Xtext usa ka hilisgutan nga takus sa usa ka bulag nga libro, ug halos dili na kita makasulti bisan kadali bahin sa tanan nga mga kapabilidad niini karon.
1C: Ang Enterprise Development Tools aktibong naggamit sa EMF mismo ug sa ubay-ubay nga uban pang proyekto sa Eclipse Modeling. Sa partikular, ang Xtext usa sa mga pundasyon sa mga himan sa pag-uswag alang sa ingon nga 1C: Mga sinultian sa negosyo sama sa built-in nga programming language ug pangutana nga lengguwahe. Ang laing sukaranan alang sa kini nga mga himan sa pag-uswag mao ang Eclipse Handly nga proyekto, nga atong hisgutan sa mas detalyado (sa mga sangkap sa Eclipse nga gilista, kini ang labing gamay nga nahibal-an).
, usa ka subproject sa top-level nga proyekto sa Eclipse Technology, mitumaw isip resulta sa inisyal nga kontribusyon sa code sa Eclipse Foundation nga gihimo sa 1C niadtong 2014. Sukad niadto, ang 1C nagpadayon sa pagsuporta sa pagpalambo sa proyekto: Ang mga handly committers mga empleyado sa kompanya. Ang proyekto gamay ra, apan kini nag-okupar sa usa ka talagsaon nga niche sa Eclipse: ang panguna nga katuyoan niini mao ang pagsuporta sa pagpauswag sa mga modelo nga nakabase sa kuptanan.
Ang sukaranang mga prinsipyo sa arkitektura sa mga modelo nga nakabase sa gunitanan, sama sa idiom sa gunitanan/lawas, gihisgutan sa ibabaw gamit ang modelo sa kapanguhaan ug ang modelo sa Java isip mga pananglitan. Namatikdan usab nga ang modelo sa kapanguhaan ug ang modelo sa Java hinungdanon nga mga pundasyon alang sa Eclipse Java development tools (JDT). Ug tungod kay halos tanan nga *DT Eclipse nga mga proyekto adunay arkitektura nga susama sa JDT, dili kini usa ka dako nga pagpasobra sa pag-ingon nga ang mga modelo nga nakabase sa kuptanan nagpailalom sa daghan, kung dili ang tanan nga mga IDE nga gitukod sa ibabaw sa Eclipse Platform. Pananglitan, ang Eclipse C/C++ Development Tooling (CDT) adunay modelo nga C/C++ nga gibase sa kuptanan nga adunay parehas nga papel sa arkitektura sa CDT sama sa gihimo sa modelo sa Java sa JDT.
Sa wala pa ang Handly, ang Eclipse wala magtanyag ug espesyal nga mga librarya alang sa paghimo og mga modelo sa pinulongan nga nakabase sa gunitanan. Ang mga modelo nga naglungtad karon gihimo labi na pinaagi sa direkta nga pagpahiangay sa code sa modelo sa Java (aka copy/paste), sa mga kaso diin kini nagtugot Eclipse Public License (EPL). (Dayag, kini kasagaran dili usa ka legal nga isyu alang sa, ingnon ta, ang mga proyekto sa Eclipse mismo, apan dili alang sa mga closed source nga mga produkto.) Dugang pa sa iyang kinaiyanhon nga kapakyasan, kini nga teknik nagpaila sa iladong mga problema: ang pagkopya sa code nga gipaila sa dihang nagpahiangay sa mga sayop, ug uban pa. Ang mas grabe mao nga ang resulta nga mga modelo nagpabilin nga "mga butang sa ilang kaugalingon" ug wala magpahimulos sa potensyal alang sa panaghiusa. Apan ang paglain sa komon nga mga konsepto ug mga protocol alang sa mga modelo sa pinulongan nga nakabase sa pagdumala mahimong mosangpot sa pagmugna og mga magamit pag-usab nga mga sangkap alang sa pagtrabaho uban kanila, susama sa nahitabo sa kaso sa EMF.
Dili kay wala masabtan sa Eclipse kini nga mga isyu. Balik sa 2005 , nagsumaryo sa kasinatian sa pagpalambo sa CDT prototype, ang panginahanglan sa paghimo sa usa ka komon nga imprastraktura alang sa mga modelo sa pinulongan, lakip na ang kuptanan-based nga mga modelo. Apan, sama sa kanunay nga mahitabo, tungod sa mas taas nga prayoridad nga mga buluhaton, ang pagpatuman niini nga mga ideya wala gayud makaabot niini. Samtang, ang factorization sa *DT code mao gihapon ang usa sa mga atrasadong topiko sa Eclipse.
Sa usa ka piho nga diwa, ang Handly nga proyekto gidisenyo aron masulbad ang gibana-bana nga parehas nga mga problema sama sa EMF, apan alang sa mga modelo nga nakabase sa kuptanan, ug labi na sa mga sinultian (ie, nagrepresentar sa mga elemento sa istruktura sa pipila nga sinultian nga programming). Ang mga nag-unang tumong nga gitakda sa pagdesinyo sa Handly gilista sa ubos:
- Pag-ila sa mga nag-unang abstraction sa hilisgutan nga dapit.
- Pagkunhod sa paningkamot ug pagpauswag sa kalidad sa pagpatuman sa mga modelo sa pinulongan nga gibase sa pagdumala pinaagi sa paggamit pag-usab sa code.
- Paghatag og usa ka hiniusang meta-level nga API sa mga resulta nga mga modelo, nga nagpaposible sa paghimo sa komon nga mga sangkap sa IDE nga nagtrabaho sa mga modelo nga nakabase sa gunitanan sa pinulongan.
- Flexibility ug scalability.
- Paghiusa sa Xtext (sa usa ka bulag nga layer).
Aron ipasiugda ang komon nga mga konsepto ug protocol, ang kasamtangan nga mga pagpatuman sa mga modelo nga gibase sa pagdumala sa pinulongan gisusi. Ang mga nag-unang interface ug sukaranan nga mga pagpatuman nga gihatag sa Handly gipakita sa Fig. 8.
bugas. 8. Komon nga mga interface ug batakang pagpatuman sa Handly nga mga elemento
Ang interface sa IElement nagrepresentar sa kuptanan sa usa ka elemento ug kasagaran sa mga elemento sa tanan nga Handly-based nga mga modelo. Ang abstract class nga Elemento nagpatuman sa generalized handle/body mechanism (Fig. 9).
bugas. 9. IElemento ug generic nga pagdumala / pagpatuman sa lawas
Dugang pa, ang Handly naghatag og usa ka kinatibuk-ang mekanismo alang sa pagpahibalo mahitungod sa mga kausaban sa mga elemento sa modelo (Fig. 10). Sama sa imong makita, kini kaylap nga susama sa mga mekanismo sa pagpahibalo nga gipatuman sa modelo sa kapanguhaan ug sa modelo sa Java, ug naggamit sa IElementDelta aron paghatag og usa ka hiniusa nga representasyon sa impormasyon sa pagbag-o sa elemento.
bugas. 10. Kinatibuk-ang mga interface ug batakang pagpatuman sa Handly notification mechanism
Ang Handly nga bahin nga gihisgutan sa ibabaw (Fig. 9 ug 10) mahimong gamiton sa pagrepresentar sa halos bisan unsang mga modelo nga gibase sa kuptanan. Alang sa paghimo linguistic mga modelo, ang proyekto nagtanyag og dugang nga gamit - sa partikular, komon nga mga interface ug mga batakang pagpatuman alang sa mga elemento sa source text structure, ang gitawag nga tinubdan nga mga elemento (Fig. 8). Ang interface sa ISourceFile nagrepresentar sa usa ka gigikanan nga file, ug ang ISourceConstruct nagrepresentar sa usa ka elemento sa sulud sa gigikanan nga file. Ang abstract nga mga klase SourceFile ug SourceConstruct nagpatuman sa mga kinatibuk-ang mekanismo aron pagsuporta sa pagtrabaho sa mga source file ug sa ilang mga elemento, pananglitan, pagtrabaho sa mga buffer sa teksto, pagbugkos sa mga koordinasyon sa usa ka elemento sa tinubdan nga teksto, pagpasig-uli sa mga modelo sa kasamtangan nga sulod sa usa ka nagtrabaho nga kopya buffer. , ug uban pa. Ang pagpatuman niini nga mga mekanismo kasagaran usa ka hagit, ug ang Handly makapakunhod pag-ayo sa paningkamot sa pagpalambo sa mga modelo sa pinulongan nga nakabase sa kuptanan pinaagi sa paghatag og taas nga kalidad nga mga batakang pagpatuman.
Dugang pa sa kinauyokan nga mga mekanismo nga gilista sa ibabaw, ang Handly naghatag og imprastraktura para sa mga buffer sa teksto ug mga snapshot, suporta alang sa pag-integrate sa mga source code editors (lakip ang out-of-the-box integration sa Xtext editor), ingon man usab sa pipila ka komon nga mga component sa UI nga pagtrabaho uban sa source code editors. Handy nga mga modelo sama sa outline framework. Sa pag-ilustrar sa mga kapabilidad niini, ang proyekto naghatag og daghang mga pananglitan, lakip ang pagpatuman sa Java model sa Handly. (Kon itandi sa bug-os nga pagpatuman sa Java nga modelo sa JDT, kini nga modelo gituyo nga medyo gipasimple para sa mas klaro.)
Sama sa nahisgutan sa sayo pa, ang usa ka mayor nga pokus sa panahon sa inisyal nga laraw ni Handly ug sa sunod nga pag-uswag mao ug nagpadayon sa pagka-scalability ug pagka-flexible.
Sa prinsipyo, ang mga modelo nga nakabase sa gunitanan maayo kaayo "sa disenyo". Pananglitan, ang handle/body idiom nagtugot kanimo nga limitahan ang gidaghanon sa memorya nga gigamit sa usa ka modelo. Apan adunay usab mga nuances. Mao nga, kung gisulayan ang Handly alang sa scalability, usa ka problema ang nakit-an sa pagpatuman sa mekanismo sa pagpahibalo - kung daghang mga elemento ang nabag-o, ang pagtukod sa mga delta nagkinahanglag daghang oras. Nahibal-an nga ang parehas nga problema naa sa modelo sa JDT Java, diin ang katugbang nga code kaniadto gipahiangay. Giayo namo ang bug sa Handly ug giandam ang susamang patch para sa JDT, nga mapasalamaton nga nadawat. Usa lang kini ka pananglitan kung diin ang pagpaila sa Handly sa mga naglungtad nga mga pagpatuman sa modelo mahimo’g mapuslanon, tungod kay sa kini nga kaso mahimo’g ayohon ang ingon nga bug sa usa lang ka lugar.
Aron mahimo ang pagpatuman sa Handly ngadto sa kasamtangan nga mga pagpatuman sa modelo nga teknikal nga mahimo, ang librarya kinahanglan nga adunay mahinungdanon nga pagka-flexible. Ang panguna nga problema mao ang pagpadayon sa paatras nga pagkaangay sa tibuuk nga modelo sa API. Nasulbad kini nga problema sa pinaagi sa tin-aw nga pagbulag sa piho nga modelo nga API, gihubit ug hingpit nga kontrolado sa developer, gikan sa hiniusang meta-level API nga gihatag sa librarya. Kini dili lamang naghimo niini nga teknikal nga posible nga ipatuman ang Handly ngadto sa kasamtangan nga mga implementasyon, apan naghatag usab sa bag-ong modelo nga developer og dakong kagawasan sa dihang nagdesinyo sa API.
Ang pagka-flexible adunay ubang mga aspeto usab. Pananglitan, ang Handly nagpahamtang ug halos walay mga pagdili sa istruktura sa modelo ug mahimong gamiton sa pagmodelo sa kinatibuk-ang katuyoan ug domain-specific nga mga pinulongan. Kung nagtukod sa istruktura sa gigikanan nga file, ang Handly wala magreseta sa bisan unsang partikular nga porma sa representasyon sa AST ug, sa prinsipyo, wala kinahanglana ang presensya sa usa ka AST mismo, sa ingon gisiguro ang pagkaangay sa halos bisan unsang mekanismo sa pag-parse. Sa katapusan, gisuportahan sa Handly ang bug-os nga panagsama sa workspace sa Eclipse, apan mahimo usab nga direkta nga magtrabaho sa mga file system salamat sa panagsama niini sa (EFS).
Karon nga bersyon nigawas sa December 2016. Bisan pa sa kamatuoran nga ang proyekto sa pagkakaron anaa sa usa ka kahimtang sa paglumlum ug ang API wala pa sa katapusan naayo, ang Handly gigamit na sa duha ka dagkong komersyal nga mga produkto nga mikuha sa risgo sa paglihok isip "sayo nga mga tigsagop", ug, kinahanglan kong isulti, ayaw pa pagmahay.
Sama sa gihisgutan sa ibabaw, usa niini nga mga produkto mao ang 1C: Enterprise Development Tools, diin ang Handly gigamit gikan sa sinugdanan aron sa pagmodelo sa mga elemento sa taas nga lebel nga istruktura sa ingon nga 1C: Enterprise nga mga pinulongan sama sa built-in nga programming language ug query nga pinulongan. . Ang laing produkto dili kaayo nailhan sa kadaghanan. Kini , usa ka integrated design environment alang sa application-specific instruction-set processor (ASIP), nga gigamit sa sulod sa Czech company nga Codasip mismo ug sa mga kliyente niini, lakip ang , , , . Gigamit sa Codasip ang Handly sa produksiyon sukad sa 2015, sugod sa bersyon nga Handly 0.2. Ang pinakabag-o nga pagpagawas sa Codasip Studio naggamit sa bersyon 0.5, nga gipagawas kaniadtong Hunyo 2016. Si Ondřej Ilčík, nga nanguna sa pag-uswag sa IDE sa Codasip, nakigkontak sa proyekto, nga naghatag hinungdanon nga feedback alang sa "third party adopter". Nakapangita pa gani siya og pipila ka libre nga oras aron direktang makaapil sa pagpalambo sa proyekto, nga nag-implementar og UI layer (~4000 lines of code) para sa usa sa Handly nga mga ehemplo, usa ka Java model. Ang mas detalyado nga first-hand nga impormasyon bahin sa paggamit sa Handly sa mga nagsagop makita sa panid proyekto.
Naglaum kami nga pagkahuman sa pagpagawas sa bersyon 1.0 nga adunay garantiya sa kalig-on sa API ug ang proyekto nga mobiya sa estado sa paglumlum, ang Handly adunay bag-ong mga nagsagop. Sa kasamtangan, ang proyekto nagpadayon sa pagsulay ug dugang nga pagpalambo sa API, nga nagpagawas sa duha ka "major" nga pagpagawas kada tuig - sa Hunyo (sama nga petsa sa dungan nga pagpagawas sa Eclipse) ug Disyembre, nga naghatag og usa ka matag-an nga iskedyul nga mahimong masaligan sa mga nagsagop. Mahimo usab namon nga idugang nga ang "bug rate" sa proyekto nagpabilin sa kanunay nga ubos nga lebel ug ang Handly nagtrabaho nga kasaligan sa mga produkto sa una nga mga nagsagop sukad sa una nga mga bersyon. Aron masusi pa ang Eclipse Handly, mahimo nimong gamiton и .
Source: www.habr.com