Verŝajne,
En ĉi tiu artikolo, kiu estas superrigardo en naturo, ni provos rigardi kelkajn el la bazaĵoj de la Eclipse-arkitekturo kiel platformo por konstrui integrajn evoluilojn kaj doni komencan ideon pri la Eclipse-komponentoj, kiuj formas la fundamenton de la teknologio. platformo por la "nova Konfiguranto" 1C: Enterprise.
Enkonduko al Eclipse Architecture
Ni unue rigardu kelkajn ĝeneralajn aspektojn de la Eclipse-arkitekturo uzante la ekzemplon
Antaŭ ĉio, oni devas rimarki, ke Eklipso estas karakterizita per sufiĉe klara arkitektura tavoliĝo, kun la apartigo de lingvo-sendependa funkcieco de funkcieco dizajnita por subteni specifajn programlingvojn, kaj la apartigo de UI-sendependaj "kernaj" komponentoj de komponentoj asociitaj. kun subtena uzantinterfaco.
Tiel, la Eclipse Platformo difinas komunan, lingvosendependan infrastrukturon, kaj la Java evoluiloj aldonas plenefikan Java IDE al Eclipse. Kaj la Eclipse Platform kaj la JDT konsistas el pluraj komponentoj, ĉiu el kiuj apartenas aŭ al UI-sendependa "kerno" aŭ UI-tavolo (Figuro 1).
Rizo. 1. Eclipse Platform kaj JDT
Ni listigu la ĉefajn komponantojn de la Eclipse Platform:
- Rultempa tempo — Difinas la krominfrastrukturon. Eklipso estas karakterizita per modula arkitekturo. Esence, Eclipse estas kolekto de "etendpunktoj" kaj "etendaĵoj".
- Laborspaco — Administras unu aŭ plurajn projektojn. Projekto konsistas el dosierujoj kaj dosieroj, kiuj estas mapitaj rekte al la dosiersistemo.
- Norma Fenestraĵa Ilaro (SWT) - Provizas bazajn uzantinterfacajn elementojn integritajn kun la operaciumo.
- JVizaĝo — Provizas kelkajn UI-kadrojn konstruitajn sur SWT.
- Laboro — Difinas la paradigmon de Eclipse UI: redaktiloj, vidoj, perspektivoj.
Oni devas diri, ke la Eklipso-Platformo ankaŭ provizas multajn aliajn utilajn komponantojn por konstrui integrajn evoluilojn, inkluzive Sencimigi, Komparu, Serĉi kaj Teamon. Speciala mencio estu JFace Text - la bazo por konstrui "inteligentajn redaktilojn" de fontkodo. Bedaŭrinde, eĉ mallonga ekzameno de ĉi tiuj komponantoj, same kiel la UI-tavolaj komponantoj, ne eblas en la medio de ĉi tiu artikolo, do en la resto de ĉi tiu sekcio ni limigos nin al superrigardo de la ĉefaj "kernaj" komponantoj de la Eklipso-Platformo kaj JDT.
Kerna Rultempo
La Eclipse krominfrastrukturo estas bazita sur
Kerna Laborspaco
Preskaŭ ĉiu integra evolumedio konstruita sur la Eclipse Platformo funkcias kun Eclipse laborspaco. Ĝi estas la laborspaco kiu kutime enhavas la fontkodon de la aplikaĵo disvolvita en la IDE. Laborspaco mapas rekte al la dosiersistemo kaj konsistas el projektoj, kiuj enhavas dosierujojn kaj dosierojn. Ĉi tiuj projektoj, dosierujoj kaj dosieroj estas nomitaj rimedoj laborspaco. La realigo de laborspaco en Eclipse funkcias kiel kaŝmemoro rilate al la dosiersistemo, kio ebligas signife akceli traveturadon de la rimedarbo. Krome, laborspaco disponigas kelkajn kromajn servojn, inkluzive de
La komponanto Core Resources (kromaĵo org.eclipse.core.resources) respondecas pri subteni la laborspacon kaj ĝiajn rimedojn. Aparte, ĉi tiu komponanto provizas programan aliron al la laborspaco en la formo modeloj de rimedoj. Por labori efike kun ĉi tiu modelo, klientoj bezonas simplan manieron prezenti ligon al rimedo. En ĉi tiu kazo, estus dezirinde kaŝi la objekton, kiu rekte stokas la staton de la rimedo en la modelo de klienta aliro. Alie, en la kazo de, ekzemple, forigo de dosiero, la kliento povus daŭre teni objekton, kiu ne plu estas en la modelo, kun la sekvaj problemoj. Eklipso solvas ĉi tiun problemon uzante ion nomatan pritrakti rimedo. Tenilo funkcias kiel ŝlosilo (ĝi nur konas la vojon al la rimedo en la laborspaco) kaj tute kontrolas aliron al la interna modelobjekto, kiu rekte stokas informojn pri la stato de la rimedo. Ĉi tiu dezajno estas vario de la ŝablono
Rizo. Figuro 2 ilustras la Tenilo/Korpo-idiomon kiel aplikatan al la rimedmodelo. La IResource-interfaco reprezentas la tenilon de rimedo kaj estas API, male al la Resource-klaso, kiu efektivigas ĉi tiun interfacon, kaj la ResourceInfo-klaso, kiu reprezentas la korpon, kiuj ne estas APIoj. Ni emfazas, ke tenilo nur konas la vojon al la rimedo relative al la laborspaca radiko kaj ne enhavas ligilon al rimeda informo. Rimedaj informoj-objektoj formas tiel nomatan "elementarbon". Ĉi tiu datumstrukturo estas tute realigita en memoro. Por trovi la rimedan informon okazon respondan al tenilo, la elementarbo estas traigata laŭ la vojo konservita en tiu tenilo.
Rizo. 2. IResource kaj ResourceInfo
Kiel ni vidos poste, la baza dezajno de la rimeda modelo (ni povus nomi ĝin tenilo-bazita) estas uzata en Eclipse ankaŭ por aliaj modeloj. Nuntempe, ni listigu kelkajn el la karakterizaj propraĵoj de ĉi tiu dezajno:
- Tenilo estas valorobjekto. Valorobjektoj estas neŝanĝeblaj objektoj, kies egaleco ne baziĝas sur identeco. Tiaj objektoj povas esti sekure uzataj kiel ŝlosilo en hakitaj ujoj. Multoblaj okazoj de tenilo povas referenci la saman rimedon. Por kompari ilin, vi devas uzi la metodon equals(Object).
- Tenilo difinas la konduton de rimedo, sed ne enhavas informojn pri la stato de la rimedo (la nuraj datumoj kiujn ĝi stokas estas la "ŝlosilo", la vojo al la rimedo).
- Tenilo povas rilati al rimedo kiu ne ekzistas (aŭ rimedo kiu ankoraŭ ne estis kreita, aŭ rimedo kiu jam estis forigita). La ekzisto de rimedo povas esti kontrolita per la metodo IResource.exists().
- Kelkaj operacioj povas esti efektivigitaj surbaze sole de informoj stokitaj en la tenilo mem (tielnomitaj tenilo-restriktitaj operacioj). Ekzemploj estas IResource.getParent(), getFullPath(), ktp. La rimedo ne bezonas ekzisti por ke tia operacio sukcesu. Operacioj, kiuj postulas ke rimedo ekzistu por sukcesi, ĵetas CoreException se la rimedo ne ekzistas.
Eklipso provizas efikan mekanismon por sciigi ŝanĝojn pri laborspacaj rimedoj (Figuro 3). Rimedoj povas ŝanĝiĝi aŭ kiel rezulto de agoj faritaj ene de la Eclipse IDE mem aŭ kiel rezulto de sinkronigo kun la dosiersistemo. En ambaŭ kazoj, klientoj, kiuj abonas sciigojn, ricevas detalajn informojn pri la ŝanĝoj en formo de "rimedodeltoj". Delto priskribas ŝanĝojn inter du statoj de laborspaca rimedo (sub-)arbo kaj estas mem arbo, ĉiu nodo de kiu priskribas ŝanĝon al rimedo kaj enhavas liston de deltoj ĉe la sekva nivelo kiuj priskribas ŝanĝojn al infanresursoj.
Rizo. 3. IResourceChangeEvent kaj IResourceDelta
La sciiga mekanismo bazita sur rimeddeltoj havas la sekvajn karakterizaĵojn:
- Ununura ŝanĝo kaj multaj ŝanĝoj estas priskribitaj uzante la saman strukturon, ĉar la delto estas konstruita uzante la principon de rekursiva kunmetaĵo. Abonantaj klientoj povas prilabori sciigojn pri ŝanĝaj rimedoj uzante rekursivan devenon tra arbo de deltoj.
- La delto enhavas kompletajn informojn pri ŝanĝoj al la rimedo, inkluzive de ĝia movado kaj/aŭ ŝanĝoj en la "markoj" asociitaj kun ĝi (ekzemple, kompilaj eraroj estas reprezentitaj kiel markiloj).
- Ĉar rimedreferencoj estas faritaj per la tenilo, delta povas nature referenci malproksiman rimedon.
Kiel ni baldaŭ vidos, la ĉefaj komponantoj de la dezajno de la rimeda modelo-ŝanĝa sciiga mekanismo estas ankaŭ gravaj por aliaj teniloj bazitaj en modeloj.
JDT Kerno
La Eclipse laborspaca rimedmodelo estas fundamenta lingvo-agnostika modelo. La JDT Core-komponento (kromaĵo org.eclipse.jdt.core) disponigas API por navigi kaj analizi la laborspacan strukturon de Java perspektivo, la tielnomita "Java modelo" (Java modelo). Ĉi tiu API estas difinita laŭ Java elementoj, kontraste al la subesta rimeda modelo API, kiu estas difinita laŭ dosierujoj kaj dosieroj. La ĉefaj interfacoj de la Java-elementarbo estas montritaj en Fig. 4.
Rizo. 4. Java Modelaj Elementoj
La Java-modelo uzas la saman tenilon/korpan idiomon kiel la rimedmodelo (Figuro 5). IJavaElement estas la tenilo, kaj JavaElementInfo ludas la rolon de korpo. La interfaco IJavaElement difinas protokolon komunan al ĉiuj Java-elementoj. Kelkaj el ĝiaj metodoj estas nur por tenilo: getElementName(), getParent(), ktp. La JavaElementInfo objekto konservas la staton de la responda elemento: ĝia strukturo kaj atributoj.
Rizo. 5. IJavaElement kaj JavaElementInfo
La Java modelo havas kelkajn diferencojn en la efektivigo de la baza tenilo/korpdezajno komparite kun la rimedmodelo. Kiel notite supre, en la rimedmodelo, la elementarbo, kies nodoj estas rimedinformobjektoj, estas tute enhavita en memoro. Sed la Java modelo povas havi signife pli grandan nombron da elementoj ol la rimedarbo, ĉar ĝi ankaŭ reprezentas la internan strukturon de .java kaj .class dosieroj: tipoj, kampoj kaj metodoj.
Por eviti tute konkretigi la tutan arbon de elementoj en memoro, la Java modelefektivigo uzas limigitan grandecon LRU-kaŝmemoro de elemento-informoj, kie la ŝlosilo estas tenilo IJavaElement. elemento-informobjektoj estas kreitaj laŭpeto dum la elemento-arbo estas navigita. En ĉi tiu kazo, la malplej ofte uzataj eroj estas forigitaj de la kaŝmemoro, kaj la memorkonsumo de la modelo restas limigita al la specifita kaŝmemorgrandeco. Ĉi tio estas alia avantaĝo de tenilo-bazita dezajno, kiu tute kaŝas tiajn efektivigajn detalojn de la klientokodo.
La mekanismo por sciigi ŝanĝojn al Java elementoj estas ĝenerale simila al la mekanismo por spuri ŝanĝojn al laborspacaj rimedoj diskutitaj supre. Kliento deziranta monitori ŝanĝojn en la Java modelo abonas sciigojn, kiuj estas reprezentitaj kiel ElementChangedEvent-objekto kiu enhavas IJavaElementDelta (Figuro 6).
Rizo. 6. ElementChangedEvent kaj IJavaElementDelta
La Java-modelo ne enhavas informojn pri metodokorpoj aŭ nomrezolucio, do por detala analizo de kodo skribita en Java, JDT Core disponigas kroman (ne-tenil-bazitan) modelon:
Ĉar sintaksoarboj povas konsumi signifan kvanton da memoro, JDT konservas nur unu AST por la aktiva redaktilo. Male al la Java modelo, la AST estas tipe rigardita kiel "meza", "provizora" modelo, al kies elementoj klientoj ne devus teni referencojn ekster la kunteksto de la operacio kiu kaŭzis la kreadon de la AST.
La listigitaj tri modeloj (Java modelo, AST, ligadoj) kune formas la bazon por konstrui "inteligentajn evoluilojn" en JDT, inkluzive de potenca Java redaktilo kun diversaj "helpantoj", diversaj agoj por prilaborado de fontkodo (inkluzive de organizado de listo de importado). nomoj kaj formatado laŭ la personigita stilo), serĉo kaj refactoring iloj. En ĉi tiu kazo, la Java-modelo ludas specialan rolon, ĉar ĝi estas kiu estas uzata kiel bazo por vida reprezentado de la strukturo de la evoluiga aplikaĵo (ekzemple en Package Explorer, Outline, Search, Call Hierarchy, kaj Tipo Hierarkio).
Eclipse-komponentoj uzataj en 1C:Enterprise Developments Tools
En Fig. Figuro 7 montras la Eclipse-komponentojn, kiuj formas la fundamenton de la teknologia platformo por 1C:Enterprise Development Tools.
Rizo. 7. Eklipso kiel platformo por 1C:Enterprise Development Tools
Eklipso Platformo provizas bazan infrastrukturon. Ni rigardis kelkajn aspektojn de ĉi tiu infrastrukturo en la antaŭa sekcio.
Kiel ĉiu vere ĝeneraluzebla ilo, EMF taŭgas por solvi larĝan gamon de modeligaj problemoj, sed kelkaj klasoj de modeloj (ekzemple, la tenil-bazitaj modeloj diskutitaj supre) povas postuli pli specialecajn modelilojn. Paroli pri EMF estas sendanka tasko, precipe en la limigitaj limoj de unu artikolo, ĉar tio estas temo de aparta libro, kaj sufiĉe dika. Ni nur rimarku, ke la altkvalita sistemo de ĝeneraligoj sub la EMF permesis la naskiĝon de tuta gamo da projektoj dediĉitaj al modeligado, kiuj estas inkluzivitaj en la altnivela projekto.
1C:Enterprise Development Tools aktive uzas kaj EMF mem kaj kelkajn aliajn Eclipse Modeling-projektojn. Precipe, Xtext estas unu el la fundamentoj de evoluiloj por tiaj 1C:Enterprise-lingvoj kiel la enkonstruita programlingvo kaj demandlingvo. Alia bazo por ĉi tiuj evoluiloj estas la projekto Eclipse Handly, pri kiu ni diskutos pli detale (el la listigitaj komponantoj de Eclipse, ĝi ankoraŭ estas la malplej konata).
La bazaj arkitekturaj principoj de tenil-bazitaj modeloj, kiel ekzemple la tenilo/korpidiomo, estis diskutitaj supre utiligante la rimedmodelon kaj la Java modelon kiel ekzemplojn. Ĝi ankaŭ notis ke kaj la rimedmodelo kaj la Java modelo estas gravaj fundamentoj por la Eclipse Java evoluiloj (JDT). Kaj ĉar preskaŭ ĉiuj *DT Eclipse-projektoj havas arkitekturon similan al JDT, ne estus granda troigo diri, ke tenilo-bazitaj modeloj subestas multaj, se ne ĉiuj IDEoj konstruitaj sur la Eclipse Platformo. Ekzemple, la Eclipse C/C++ Development Tooling (CDT) havas tenil-bazitan C/C++ modelon kiu ludas la saman rolon en la CDT-arkitekturo kiel la Java modelo faras en la JDT.
Antaŭ Handly, Eclipse ne ofertis specialecajn bibliotekojn por konstrui tenil-bazitajn lingvomodelojn. La modeloj kiuj ekzistas nuntempe estis kreitaj ĉefe per rekte adaptado de la Java modelkodo (alinome kopii/glui), en kazoj kie ĝi permesas Eclipse Public License (EPL). (Evidente, ĉi tio kutime ne estas laŭleĝa afero por, ekzemple, Eclipse-projektoj mem, sed ne por fermitfontaj produktoj.) Krom sia propra hazardo, tiu tekniko enkondukas konatajn problemojn: kodduobligo enkondukita de kiam adaptado al eraroj, ktp. Plej malbona estas, ke la rezultaj modeloj restas "aĵoj en si mem" kaj ne utiligas la potencialon por unuigo. Sed izoli komunajn konceptojn kaj protokolojn por tenilo-bazitaj lingvomodeloj povus konduki al la kreado de reuzeblaj komponantoj por labori kun ili, simile al kio okazis en la kazo de EMF.
Ne estas ke Eclipse ne komprenis ĉi tiujn aferojn. Reen en 2005
En certa signifo, la Handly-projekto estas dizajnita por solvi proksimume la samajn problemojn kiel EMF, sed por tenilo-bazitaj modeloj, kaj ĉefe lingvaj (t.e., reprezentantaj elementojn de la strukturo de iu programlingvo). La ĉefaj celoj fiksitaj dum desegnado de Handly estas listigitaj malsupre:
- Identigo de la ĉefaj abstraktaĵoj de la temo.
- Reduktante fortostreĉon kaj plibonigante la kvaliton de efektivigo de tenilo-bazitaj lingvomodeloj per koda reuzo.
- Disponigante unuigitan meta-nivelan API al la rezultaj modeloj, ebligante krei komunajn IDE-komponentojn kiuj funkcias kun lingvotenil-bazitaj modeloj.
- Fleksebleco kaj skaleblo.
- Integriĝo kun Xtext (en aparta tavolo).
Por elstarigi oftajn konceptojn kaj protokolojn, ekzistantaj efektivigoj de lingvotenil-bazitaj modeloj estis analizitaj. La ĉefaj interfacoj kaj bazaj efektivigoj disponigitaj fare de Handly estas montritaj en Fig. 8.
Rizo. 8. Komunaj interfacoj kaj bazaj efektivigoj de Handly-elementoj
La IElement-interfaco reprezentas la tenilon de elemento kaj estas komuna al elementoj de ĉiuj Handly-bazitaj modeloj. La abstrakta klaso Elemento efektivigas la ĝeneraligitan tenilon/korpan mekanismon (Fig. 9).
Rizo. 9. IElement kaj ĝenerala tenilo/korpa efektivigo
Krome, Handly disponigas ĝeneraligitan mekanismon por sciigi pri ŝanĝoj en modelelementoj (Fig. 10). Kiel vi povas vidi, ĝi estas larĝe simila al la sciigaj mekanismoj efektivigitaj en la rimeda modelo kaj la Java modelo, kaj uzas IElementDelta por provizi unuigitan reprezentadon de elementŝanĝaj informoj.
Rizo. 10. Ĝeneralaj interfacoj kaj bazaj efektivigoj de la Handly sciiga mekanismo
La Handly-parto diskutita supre (Fig. 9 kaj 10) povas esti uzata por reprezenti preskaŭ iujn ajn tenil-bazitajn modelojn. Por krei lingvaj modeloj, la projekto ofertas aldonan funkciecon - precipe komunajn interfacojn kaj bazajn realigojn por elementoj de la fonttekstostrukturo, la t.n. fontelementoj (Fig. 8). La ISourceFile-interfaco reprezentas fontdosieron, kaj ISourceConstruct reprezentas elementon ene de la fontdosiero. La abstraktaj klasoj SourceFile kaj SourceConstruct efektivigas ĝeneraligitajn mekanismojn por subteni laboradon kun fontdosieroj kaj iliaj elementoj, ekzemple, laborado kun tekstbufroj, ligado al la koordinatoj de elemento en la fontteksto, akordigi modelojn kun la nuna enhavo de funkcia kopia bufro. , ktp. Efektivigi ĉi tiujn mekanismojn estas kutime sufiĉe defio, kaj Handly povas signife redukti la fortostreĉon evoluigi tenil-bazitajn lingvomodelojn disponigante altkvalitajn bazajn efektivigojn.
Aldone al la kernaj mekanismoj listigitaj supre, Handly disponigas infrastrukturon por tekstaj bufroj kaj momentfotoj, subtenon por integriĝo kun fontkodredaktiloj (inkluzive de senfina integriĝo kun la Xtext-redaktilo), same kiel kelkajn komunajn UI-komponentojn kiuj labori kun fontkodaj redaktiloj.Maneblaj modeloj kiel skiza kadro. Por ilustri ĝiajn kapablojn, la projekto disponigas plurajn ekzemplojn, inkluzive de efektivigo de la Java modelo en Handly. (Kompare kun la plena efektivigo de la Java modelo en JDT, ĉi tiu modelo estas intencite iom simpligita por pli granda klareco. )
Kiel notite pli frue, grava fokuso dum la komenca dezajno kaj posta evoluo de Handly estis kaj daŭre estas sur skaleblo kaj fleksebleco.
Principe, tenilo-bazitaj modeloj skalas sufiĉe bone "laŭ dezajno". Ekzemple, la tenilo/korpa idiomaĵo permesas vin limigi la kvanton de memoro konsumita de modelo. Sed estas ankaŭ nuancoj. Tiel, dum testado de Handly pri skaleblo, problemo estis malkovrita en la efektivigo de la sciiga mekanismo - kiam granda nombro da elementoj estis ŝanĝitaj, konstrui deltojn prenis tro da tempo. Montriĝis, ke la sama problemo ĉeestis en la JDT Java modelo, el kiu la responda kodo iam estis adaptita. Ni riparis la cimon en Handly kaj preparis similan flikilon por JDT, kiu estis dankeme ricevita. Ĉi tio estas nur unu ekzemplo kie enkonduki Handly en ekzistantajn modelefektivigojn povus esti eble utila, ĉar ĉi-kaze tia cimo povus esti riparita en nur unu loko.
Por igi efektivigi Handly en ekzistantajn modelefektivigojn teknike realigebla, la biblioteko devas havi signifan flekseblecon. La ĉefa problemo estas konservi malantaŭan kongruon tra la API-modelo. Ĉi tiu problemo estis solvita en
Fleksebleco ankaŭ havas aliajn aspektojn. Ekzemple, Handly trudas preskaŭ neniujn restriktojn sur la strukturo de la modelo kaj povas esti uzita por modeligi kaj ĝeneraluzeblajn kaj domajn-specifajn lingvojn. Konstruante la strukturon de la fontdosiero, Handly ne preskribas ajnan apartan formon de AST-reprezento kaj, principe, eĉ ne postulas la ĉeeston de AST mem, tiel certigante kongruon kun preskaŭ ajna analiza mekanismo. Fine, Handly subtenas plenan integriĝon kun Eclipse laborspaco, sed ankaŭ povas funkcii rekte kun dosiersistemoj danke al sia integriĝo kun
Nuna versio
Kiel notite supre, unu el ĉi tiuj produktoj estas 1C:Enterprise Development Tools, kie Handly estas uzata de la komenco por modeligi elementojn de la altnivela strukturo de tiaj 1C:Enterprise-lingvoj kiel la enkonstruita programlingvo kaj demandlingvo. . Alia produkto estas malpli konata de la ĝenerala publiko. Ĉi tio
Ni esperas, ke post la liberigo de versio 1.0 kun garantio de API-stabileco kaj la projekto forlasanta la inkubacion, Handly havos novajn adoptantojn. Intertempe, la projekto daŭre testas kaj plu plibonigas la API, publikigante du "gravajn" eldonojn jare - en junio (la sama dato kiel la samtempa eldono de Eclipse) kaj decembro, provizante antaŭvideblan horaron, je kiu adoptantoj povas fidi. Ni ankaŭ povas aldoni, ke la "cimoprocento" de la projekto restas sur konstante malalta nivelo kaj Handly laboras fidinde en la produktoj de fruaj adoptantoj ekde la unuaj versioj. Por plu esplori Eclipse Handly, vi povas uzi
fonto: www.habr.com