Wahrscheinlech, huet scho laang keng speziell Aféierung gebraucht. Vill Leit si vertraut mat Eclipse dank den Eclipse Java Entwécklungsinstrumenter (). Et ass dës populär Open-Source Java IDE déi meescht Entwéckler mam Wuert "Eclipse" associéieren. Wéi och ëmmer, Eclipse ass souwuel eng erweiterbar Plattform fir Entwécklungsinstrumenter (Eclipse Plattform) z'integréieren, an eng Zuel vun IDEs op senger Basis gebaut, dorënner JDT. Eclipse ass souwuel den Eclipse Project, den Top-Level Projet deen d'Entwécklung vun der Eclipse Plattform an der JDT koordinéiert, an den Eclipse SDK, dat geliwwert Resultat vun där Entwécklung. Schlussendlech ass Eclipse eng Open-Source Foundation mat enger riseger Gemeinschaft vu Projeten, déi net all op Java geschriwwe sinn oder mat Entwécklungsinstrumenter verbonne sinn (zum Beispill Projeten). и ). D'Welt vun Eclipse ass ganz divers.
An dësem Artikel, deen Iwwerbléck an der Natur ass, wäerte mir probéieren e puer vun de Basics vun der Eclipse Architektur als Plattform ze kucken fir integréiert Entwécklungsinstrumenter ze bauen an eng initial Iddi vun den Eclipse Komponenten ze ginn, déi d'Fundament vun der Technologie bilden Plattform fir den "neien Configurator" 1C: Enterprise. . Natierlech wäert esou eng Iwwerpréiwung zwangsleefeg gréisstendeels iwwerflächlech an zimlech limitéiert sinn, och well mir eis net nëmmen op Eclipse Entwéckler als Zilpublikum konzentréieren. Wéi och ëmmer, mir hoffen datt souguer erfuerene Eclipse Entwéckler interessant Informatioun am Artikel fannen. Zum Beispill wäerte mir iwwer ee vun de "Geheimnisser vun der Sonnendäischtert" schwätzen, e relativ neien a wéineg bekannte Projet , déi vun 1C gegrënnt an ënnerstëtzt gouf.
Aféierung an Eclipse Architektur
Loosst eis fir d'éischt e puer allgemeng Aspekter vun der Eclipse Architektur kucken mat dem Beispill (JDT). D'Wiel vum JDT als Beispill ass net zoufälleg. Dëst ass dat éischt integréiert Entwécklungsëmfeld dat an Eclipse erschéngt. Aner *DT Eclipse Projeten, wéi Eclipse C/C++ Development Tooling (CDT), goufe méi spéit erstallt a léinen souwuel grondleeënd architektonesch Prinzipien wéi individuell Quellcodefragmenter vum JDT. D'Grondlage vun der Architektur, déi am JDT festgeluegt ass, sinn relevant bis haut fir bal all IDE, déi uewen op der Eclipse Plattform gebaut ass, dorënner 1C: Enterprise Development Tools.
Als éischt sollt et bemierkt ginn datt Eclipse duerch eng zimlech kloer architektonesch Schichten charakteriséiert ass, mat der Trennung vu Sproochonofhängeger Funktionalitéit vu Funktionalitéit entwéckelt fir spezifesch Programméierungssproochen z'ënnerstëtzen, an der Trennung vun UI-onofhängege "Kär" Komponenten vu Komponenten assoziéiert. mat ënnerstëtzen User Interface.
Also definéiert d'Eclipse Plattform eng gemeinsam, sproochonofhängeg Infrastruktur, an d'Java Entwécklungsinstrumenter addéieren eng vollstänneg Java IDE zu Eclipse. Souwuel d'Eclipse Plattform wéi och d'JDT besteet aus verschiddene Komponenten, déi jidderee zu engem UI-onofhängege "Kär" oder enger UI-Schicht gehéiert (Figur 1).
Reis. 1. Sonnendäischtert Plattform an JDT
Loosst eis d'Haaptkomponente vun der Eclipse Plattform oplëschten:
- Runtime - Definéiert d'Plugininfrastruktur. Eclipse ass duerch eng modulär Architektur charakteriséiert. Wesentlech ass Eclipse eng Sammlung vun "Extensiounspunkten" an "Extensiounen".
- Aarbechtsberäich - Gestioun een oder méi Projeten. E Projet besteet aus Classeure a Dateien déi direkt op de Dateiesystem mapéiert sinn.
- Standard Widget Toolkit (SWT) - Bitt Basis User Interface Elementer integréiert mam Betribssystem.
- JFace - Bitt eng Zuel vun UI Kaderen uewen op SWT gebaut.
- Workbench - Definéiert d'Eclipse UI Paradigma: Redaktoren, Meenungen, Perspektiven.
Et muss gesot ginn datt d'Eclipse Plattform och vill aner nëtzlech Komponenten ubitt fir integréiert Entwécklungsinstrumenter ze bauen, dorënner Debug, Compare, Search, an Team. Besonnesch Ernimmung soll vun JFace Text gemaach ginn - d'Basis fir "Smart Redaktoren" vun Quellcode ze bauen. Leider ass och eng iwwerflësseg Untersuchung vun dëse Komponenten, souwéi d'UI Layer Komponenten, net méiglech am Kader vun dësem Artikel, also am Rescht vun dëser Rubrik wäerte mir eis op en Iwwerbléck vun den Haapt "Kär" Komponente limitéieren. der Eclipse Plattform an JDT.
Kär Runtime
D'Eclipse Plugin Infrastruktur baséiert op a vum Projet geliwwert . All Eclipse Plugin ass en OSGi Bündel. D'OSGi Spezifizéierung definéiert besonnesch Mechanismen fir Versiouns- an Ofhängegkeetsresolutioun. Zousätzlech zu dëse Standardmechanismus stellt Equinox d'Konzept vir Expansioun Punkten. All Plugin kann seng eegen Extensiounspunkte definéieren, an och zousätzlech Funktionalitéit ("Extensiounen") an de System aféieren andeems Extensiounspunkten definéiert sinn duerch déiselwecht oder aner Plugins. All detailléiert Beschreiwung vun den OSGi an Equinox Mechanismen ass iwwer den Ëmfang vun dësem Artikel. Loosst eis nëmmen notéieren datt d'Modulariséierung an der Eclipse total ass (all Subsystem, inklusiv Runtime, besteet aus engem oder méi Plugins), a bal alles an Eclipse ass eng Extensioun. Ausserdeem goufen dës Prinzipien an der Eclipse Architektur agebaut laang virun der Aféierung vun OSGi (zu där Zäit hunn se hir eege Technologie benotzt, vill ähnlech wéi OSGi).
Kär Aarbechtsberäich
Bal all integréiert Entwécklungsëmfeld gebaut uewen op der Eclipse Plattform funktionnéiert mat Eclipse Workspace. Et ass den Aarbechtsberäich deen normalerweis de Quellcode vun der Applikatioun enthält, déi an der IDE entwéckelt gouf. Workspace Kaarten direkt op de Dateiesystem a besteet aus Projeten déi Classeure a Dateien enthalen. Dës Projeten, Ordner an Dateie ginn genannt Ressourcen Aarbechtsberäich. D'Aarbechtsberäich Implementatioun an Eclipse déngt als Cache a Relatioun zum Dateiesystem, wat et méiglech mécht d'Traversal vum Ressourcebaum wesentlech ze beschleunegen. Zousätzlech, stellt Aarbechtsberäich eng Rei vun zousätzlech Servicer, dorënner и .
De Core Resources Komponent (org.eclipse.core.resources Plugin) ass verantwortlech fir den Aarbechtsberäich a seng Ressourcen z'ënnerstëtzen. Besonnesch dës Komponent bitt programmatesch Zougang zum Aarbechtsberäich an der Form Ressource Modeller. Fir effektiv mat dësem Modell ze schaffen, brauche Clienten en einfache Wee fir e Link op eng Ressource ze presentéieren. An dësem Fall wier et wënschenswäert, den Objet ze verstoppen, deen direkt den Zoustand vun der Ressource am Modell vum Client Zougang späichert. Soss, am Fall, zum Beispill, e Fichier ze läschen, kéint de Client weiderhin en Objet halen, deen net méi am Modell ass, mat de Problemer, déi dorop kommen. Eclipse léist dëse Problem mat eppes genannt packen Ressource. Handle handelt als Schlëssel (et weess nëmmen de Wee op d'Ressource am Aarbechtsberäich) a kontrolléiert den Zougang zum internen Modellobjekt komplett, deen direkt Informatioun iwwer den Zoustand vun der Ressource späichert. Dësen Design ass eng Variatioun vum Muster .
Reis. Figur 2 illustréiert de Handle / Body Idiom wéi op de Ressourcemodell applizéiert. D'IResource Interface representéiert de Grëff vun enger Ressource an ass eng API, am Géigesaz zu der Ressource Klass, déi dësen Interface implementéiert, an d'ResourceInfo Klass, déi de Kierper duerstellt, déi net APIen sinn. Mir betounen datt de Grëff nëmmen de Wee fir d'Ressource kennt relativ zu der Workspace Root an net e Link op d'Ressource Info enthält. Ressource Infoobjekter bilden e sougenannte "Elementbaum". Dës Datestruktur ass komplett an der Erënnerung materialiséiert. Fir d'Ressource Info Instanz ze fannen, déi zu engem Grëff entsprécht, gëtt den Elementbaum duerchgestrachent no dem Wee an deem Grëff gespäichert.
Reis. 2. IResource an ResourceInfo
Wéi mir spéider wäerte gesinn, gëtt de Basisdesign vum Ressourcemodell (mir kënnen et Handle-baséiert nennen) an Eclipse och fir aner Modeller benotzt. Loosst eis elo e puer vun den ënnerschiddlechen Eegeschafte vun dësem Design oplëschten:
- Handle ass e Wäertobjekt. Wäertobjekter sinn onverännerbar Objeten deenen hir Gläichheet net op Identitéit baséiert. Esou Objete kënne sécher als Schlëssel an hashed Container benotzt ginn. Multiple Instanzen vu Grëff kënnen déiselwecht Ressource referenzéieren. Fir se ze vergläichen, musst Dir d'selwecht (Objekt) Method benotzen.
- Handle definéiert d'Behuele vun enger Ressource, awer enthält keng Informatioun iwwer den Zoustand vun der Ressource (déi eenzeg Donnéeën déi et späichert ass de "Schlëssel", de Wee fir d'Ressource).
- Handle kann op eng Ressource bezéien déi net existéiert (entweder eng Ressource déi nach net erstallt gouf oder eng Ressource déi scho geläscht gouf). D'Existenz vun enger Ressource kann mat der Method IResource.exists () gepréift ginn.
- E puer Operatioune kënnen ëmgesat ginn nëmmen op Informatioun, déi am Grëff selwer gespäichert ass (déi sougenannte Handle-nëmmen Operatiounen). Beispiller sinn IResource.getParent(), getFullPath(), etc. D'Ressource brauch net ze existéieren fir datt esou eng Operatioun geléngt. Operatiounen déi eng Ressource erfuerderen fir ze existéieren fir Erfolleg ze werfen eng Ausnam (CoreException) wann d'Ressource net existéiert.
Eclipse bitt en effiziente Mechanismus fir d'Aarbechtsberäich Ressource Ännerungen z'informéieren (Figur 3). Ressourcen kënnen änneren entweder als Resultat vun Aktiounen, déi an der Eclipse IDE selwer gemaach ginn, oder als Resultat vun der Synchroniséierung mam Dateiesystem. A béide Fäll ginn Clienten, déi sech op Notifikatiounen abonnéieren, detailléiert Informatiounen iwwer d'Ännerungen a Form vun "Ressource Deltas" geliwwert. En Delta beschreift Ännerungen tëscht zwee Staaten vun engem Aarbechtsberäich Ressource (Ënner-) Bam an ass selwer e Bam, all Node vun deem beschreift eng Ännerung vun enger Ressource an enthält eng Lëscht vun Deltas op den nächsten Niveau datt Ännerungen Kanner Ressourcen beschreiwen.
Reis. 3. IResourceChangeEvent an IResourceDelta
Den Notifikatiounsmechanismus baséiert op Ressource Deltas huet déi folgend Charakteristiken:
- Eng eenzeg Ännerung a vill Ännerungen ginn mat der selwechter Struktur beschriwwen, well d'Delta mam Prinzip vun der rekursiver Zesummesetzung gebaut gëtt. Abonnent Clientë kënnen Ressourcenännerungsnotifikatioune veraarbecht mat rekursiven Ofstamung duerch e Bam vun Deltas.
- D'Delta enthält komplett Informatioun iwwer Ännerunge vun der Ressource, och seng Bewegung an / oder Ännerungen an den "Markéierer" déi mat him verbonne sinn (zum Beispill Kompiléierungsfehler ginn als Markéierer duergestallt).
- Zënter Ressource Referenzen duerch de Grëff gemaach ginn, kann Delta natierlech eng Remote Ressource referenzéieren.
Wéi mir geschwënn gesinn, sinn d'Haaptkomponenten vum Design vum Ressourcenmodell Ännerung Notifikatiounsmechanismus och relevant fir aner Handle-baséiert Modeller.
JDT Core
D'Eclipse Aarbechtsberäich Ressource Modell ass e fundamental Sprooch-agnostesche Modell. D'JDT Core Komponent (Plugin org.eclipse.jdt.core) bitt eng API fir d'Aarbechtsberäichstruktur aus enger Java Perspektiv ze navigéieren an ze analyséieren, de sougenannte "Java Modell" (Java Modell). Dës API ass definéiert a punkto Java Elementer, am Géigesaz zum ënnerierdesche Ressourcemodell API, deen a punkto Ordner a Dateien definéiert ass. D'Haaptschnëttplazen vum Java Elementbaum ginn an der Fig. 4.
Reis. 4. Java Model Elementer
De Java Modell benotzt dee selwechte Grëff / Kierper Idiom wéi de Ressourcemodell (Figur 5). IJavaElement ass de Grëff, an JavaElementInfo spillt d'Roll vum Kierper. D'IAvaElement Interface definéiert e Protokoll gemeinsam fir all Java Elementer. E puer vu senge Methoden sinn nëmmen handhaben: getElementName(), getParent(), etc. Den JavaElementInfo Objet späichert den Zoustand vum entspriechende Element: seng Struktur an Attributer.
Reis. 5. IJavaElement an JavaElementInfo
De Java Modell huet e puer Differenzen an der Ëmsetzung vum Basishandtak / Kierperdesign am Verglach zum Ressourcemodell. Wéi uewe bemierkt, am Ressourcemodell ass den Elementbaum, deem seng Noden Ressourceinfoobjekter sinn, ganz an der Erënnerung enthale sinn. Awer de Java Modell kann eng däitlech méi grouss Zuel vun Elementer wéi de Ressource Bam hunn, well et duerstellt och déi intern Struktur vun .java an .class Fichieren: Zorte, Felder, a Methoden.
Fir de ganze Bam vun Elementer an der Erënnerung komplett ze materialiséieren, benotzt d'Java Modellimplementatioun e limitéierten Gréisst LRU Cache vun Elementinfo, wou de Schlëssel IJavaElement ass. Element Info Objete ginn op Ufro erstallt wéi den Elementbaum navigéiert gëtt. An dësem Fall ginn déi am mannsten dacks benotzten Elementer aus dem Cache geläscht, an de Gedächtnisverbrauch vum Modell bleift op déi spezifizéiert Cachegréisst limitéiert. Dëst ass en anere Virdeel vum Handle-baséierten Design, deen esou Ëmsetzungsdetailer vum Clientcode komplett verstoppt.
De Mechanismus fir Ännerunge fir Java Elementer z'informéieren ass allgemeng ähnlech wéi de Mechanismus fir d'Verfollegung vun Ännerungen op Aarbechtsberäichressourcen, déi hei uewen diskutéiert goufen. E Client deen Ännerungen am Java Modell iwwerwaache wëllt, abonnéiert op Notifikatiounen, déi als ElementChangedEvent Objet vertruede sinn, deen en IJavaElementDelta enthält (Figur 6).
Reis. 6. ElementChangedEvent an IJavaElementDelta
De Java Modell enthält keng Informatioun iwwer Methodekierper oder Nummresolutioun, also fir eng detailléiert Analyse vum Code, deen am Java geschriwwe gëtt, gëtt JDT Core en zousätzlechen (net-handlebaséierten) Modell: (Abstrakt Syntaxbaum, AST). AST representéiert d'Resultat vum Parsing vum Quelltext. AST Wirbelen entspriechen Elementer vun der Struktur vum Quellmodul (Deklaratioune, Bedreiwer, Ausdréck, etc.) an enthalen Informatiounen iwwer d'Koordinate vum entspriechende Element am Quelltext, souwéi (als Optioun) Informatioun iwwer d'Nummresolutioun an der Form vun Linken op sougenannte Bindungen. Bindungen sinn Objeten déi benannt Entitéite representéieren, sou wéi Typen, Methoden a Variablen, bekannt vum Compiler. Am Géigesaz zu AST Wirbelen, déi e Bam bilden, ënnerstëtzen Bindungen Kräiz-Referenzéierung a bilden allgemeng eng Grafik. Déi abstrakt Klass ASTNode ass déi gemeinsam Basisklass fir all AST Noden. ASTNode Ënnerklassen entspriechen spezifesch syntaktesch Konstruktioune vun der Java Sprooch.
Well Syntaxbäume e wesentleche Betrag un Erënnerung verbrauchen, cache JDT nëmmen eng AST fir den aktive Editor. Am Géigesaz zum Java Modell gëtt den AST typesch als en "Zwëschen", "temporäre" Modell ugesinn, deem seng Memberen net solle vu Clienten ausserhalb vum Kontext vun der Operatioun referenzéiert ginn, déi zu der Schafung vun der AST gefouert hunn.
Déi opgelëscht dräi Modeller (Java Modell, AST, Bindungen) bilden zesummen d'Basis fir "intelligent Entwécklungsinstrumenter" am JDT ze bauen, dorënner e mächtege Java Editor mat verschiddenen "Helfer", verschidden Aktiounen fir d'Veraarbechtung vum Quellcode (inklusiv d'Organisatioun vun enger Lëscht vun Importer Nimm an Formatéierung no dem personaliséierte Stil), Sich- a Refactoring-Tools. An dësem Fall spillt de Java Modell eng speziell Roll, well et ass deen als Basis fir eng visuell Representatioun vun der Struktur vun der Applikatioun benotzt gëtt (zum Beispill am Package Explorer, Outline, Search, Call Hierarchy, an Typ Hierarchie).
Eclipse Komponenten déi an 1C benotzt ginn: Enterprise Developments Tools
An Fig. Figur 7 weist d'Eclipse Komponenten déi d'Fundament vun der Technologieplattform fir 1C bilden: Enterprise Development Tools.
Reis. 7. Eclipse als Plattform fir 1C: Enterprise Development Tools
Eclipse Plattform bitt Basis Infrastruktur. Mir hunn e puer Aspekter vun dëser Infrastruktur an der viregter Sektioun gekuckt.
(EMF) bitt en allgemengt Mëttel fir strukturéiert Daten ze modelléieren. EMF ass integréiert mat der Eclipse Plattform, awer kann och separat a reguläre Java Uwendungen benotzt ginn. Ganz dacks sinn nei Eclipse Entwéckler scho gutt mat EMF vertraut, obwuel se d'Intricacies vun der Eclipse Plattform nach net ganz verstinn. Ee vun de Grënn fir sou gutt-verdéngt Popularitéit ass den universellen Design, deen ënner anerem eng vereenegt Meta-Level API enthält, déi Iech erlaabt mat all EMF Modell op eng allgemeng Manéier ze schaffen. D'Basis Implementatioune fir Modellobjekter, déi vum EMF geliwwert ginn, an de Subsystem fir Modellcode ze generéieren op Basis vum Meta-Modell erhéijen d'Vitesse vun der Entwécklung wesentlech an d'Zuel vu Feeler reduzéieren. EMF enthält och Mechanismen fir Modeller ze serialiséieren, Ännerungen am Modell ze verfolgen, a vill méi.
Wéi all wierklech allgemeng Zweck Tool ass EMF gëeegent fir eng breet Palette vu Modellerprobleemer ze léisen, awer e puer Klasse vu Modeller (zum Beispill, déi uewe diskutéiert Handle-baséiert Modeller) kënne méi spezialiséiert Modellerinstrumenter erfuerderen. Iwwer EMF schwätzen ass eng dankbar Aufgab, besonnesch an de limitéierten Grenzen vun engem Artikel, well dëst Thema vun engem separaten Buch ass, an engem zimlech décke. Loosst eis nëmmen feststellen datt de qualitativ héichwäertege System vun Generalisatiounen, déi dem EMF ënnersträichen, d'Gebuert vun enger ganzer Palette vu Projete fir d'Modellering erlaabt huet, déi am Top-Level-Projet abegraff sinn. zesumme mam EMF selwer. Een esou Projet ass Eclipse Xtext.
bitt eng "Textmodelléierung" Infrastruktur. Xtext benotzt fir de Quelltext an EMF ze analyséieren fir de resultéierende ASG ze representéieren (abstrakt semantesch Grafik, wat am Wesentlechen eng Kombinatioun vun AST a Bindungen ass), och de "semanteschen Modell" genannt. D'Grammatik vun der Sprooch, déi vum Xtext modelléiert gëtt, gëtt an der eegener Sprooch vum Xtext beschriwwen. Dëst erlaabt Iech net nëmmen eng Grammatikbeschreiwung fir ANTLR ze generéieren, awer och en AST-Serialiséierungsmechanismus ze kréien (dh Xtext bitt souwuel e Parser wéi och en Unparser), e Kontext Hiweis an eng Rei vun anere Sproochkomponenten. Op der anerer Säit ass d'Grammatik Sprooch, déi am Xtext benotzt gëtt, manner flexibel wéi zum Beispill d'Grammatik Sprooch, déi an ANTLR benotzt gëtt. Dofir ass et heiansdo néideg fir d'implementéiert Sprooch op Xtext ze "béien", wat normalerweis kee Problem ass wa mir schwätzen iwwer eng Sprooch déi vun Null entwéckelt gëtt, awer vläicht inakzeptabel fir Sprooche mat enger schonn etabléierter Syntax. Trotzdem ass Xtext de Moment dat meescht reift, Feature-räich a versatile Tool an Eclipse fir Programméierungssproochen an Entwécklungsinstrumenter fir si ze bauen. Besonnesch ass et en idealt Tool fir séier Prototyping (Domain-spezifesch Sprooch, DSL). Zousätzlech zum uewe genannten "Sproochekär" baséiert op ANTLR an EMF, bitt Xtext vill nëtzlech Komponenten op héijer Niveau, dorënner Indexmechanismen, inkrementell Konstruktioun, e "Smart Editor", a vill, vill méi, awer verléisst Handle- baséiert Sprooch Modeller. Wéi EMF, Xtext ass e Sujet wiirdeg engem separat Buch, a mir kënnen elo kaum och kuerz iwwer all seng Fäegkeeten schwätzen.
1C: Enterprise Development Tools benotzen aktiv souwuel EMF selwer an eng Rei vun aneren Eclipse Modeling Projeten. Besonnesch Xtext ass ee vun de Fundamenter vun Entwécklungsinstrumenter fir sou 1C:Enterprise Sproochen wéi déi agebaute Programméierungssprooch a Query Sprooch. Eng aner Basis fir dës Entwécklungsinstrumenter ass den Eclipse Handly Projet, dee mir méi am Detail diskutéieren (vun den opgelëscht Eclipse Komponenten ass et nach ëmmer am mannsten bekannt).
, e Subprojet vum Eclipse Technology Top-Level Projet, entstanen als Resultat vun engem initialen Code Bäitrag zu der Eclipse Foundation gemaach vun 1C am 2014. Zënterhier huet 1C d'Entwécklung vum Projet weider ënnerstëtzt: Handlech Engagementer si Mataarbechter vun der Firma. De Projet ass kleng, awer et besetzt eng zimlech eenzegaarteg Nisch an der Eclipse: säin Haaptziel ass d'Entwécklung vu Handle-baséiert Modeller z'ënnerstëtzen.
D'Basis architektonesch Prinzipien vu Grëff-baséiert Modeller, wéi de Grëff / Kierper Idiom, goufen uewen diskutéiert mat de Ressource Modell an de Java Modell als Beispiller. Et huet och bemierkt datt souwuel de Ressourcemodell wéi och den Java Modell wichteg Fundamenter fir d'Eclipse Java Entwécklungsinstrumenter (JDT) sinn. A well bal all *DT Eclipse Projeten eng Architektur ähnlech wéi JDT hunn, wier et net eng grouss Iwwerdreiung ze soen datt Handle-baséiert Modeller ënnersträichen vill, wann net all IDEs uewen op der Eclipse Plattform gebaut. Zum Beispill huet d'Eclipse C / C ++ Entwécklung Tooling (CDT) e Handle-baséiert C / C ++ Modell deen déi selwecht Roll an der CDT Architektur spillt wéi de Java Modell am JDT mécht.
Virun Handly huet Eclipse keng spezialiséiert Bibliothéiken ubidden fir Handle-baséiert Sproochmodeller ze bauen. D'Modeller déi aktuell existéieren goufen haaptsächlech erstallt andeems de Java Modellcode direkt ugepasst gouf (och kopéieren / Paste), a Fäll wou et erlaabt Eclipse Public License (EPL). (Natierlech ass dëst normalerweis net e juristesche Problem fir, soen, Eclipse Projeten selwer, awer net fir zougemaach Quell Produiten.) Zousätzlech zu senger inherent haphazardness, dëser Technik stellt gutt-bekannt Problemer: Code Duplikatioun agefouert vun wann Upassung un Feeler, etc. Wat méi schlëmm ass, datt déi resultéierend Modeller "Saachen a sech selwer" bleiwen an net vum Potenzial fir d'Vereenegung profitéieren. Awer allgemeng Konzepter a Protokoller fir Handlebaséiert Sproochmodeller isoléieren kéint zu der Schafung vu wiederverwendbare Komponenten féieren fir mat hinnen ze schaffen, ähnlech wéi wat am Fall vun EMF geschitt ass.
Et ass net datt Eclipse dës Themen net verstanen huet. Zréck am Joer 2005 , d'Erfahrung vun der Entwécklung vum CDT Prototyp zesummefaassen, de Besoin fir eng gemeinsam Infrastruktur fir Sproochmodeller ze kreéieren, dorënner Handle-baséiert Modeller. Awer, wéi dacks geschitt, duerch méi héich prioritär Aufgaben, ass d'Ëmsetzung vun dësen Iddien ni erreecht. Mëttlerweil ass d'Faktoriséierung vum *DT Code nach ëmmer ee vun den ënnerentwéckelten Themen an der Eclipse.
An engem gewësse Sënn ass de Handly Projet entwéckelt fir ongeféier déiselwecht Probleemer wéi EMF ze léisen, awer fir Handle-baséiert Modeller, a virun allem Sproochen (dh Elementer vun der Struktur vun enger Programmiersprache representéieren). D'Haaptziler, déi beim Design vun Handly festgeluecht goufen, ginn hei ënnen opgezielt:
- Identifikatioun vun den Haaptabstraktiounen vum Fachberäich.
- D'Efforten reduzéieren an d'Qualitéit vun der Implementatioun vu Handle-baséiert Sproochmodeller verbesseren duerch Code Wiederverwendung.
- Eng vereenegt Meta-Niveau API un déi resultéierend Modeller ubidden, wat et méiglech mécht gemeinsam IDE Komponenten ze kreéieren déi mat Sproochhandtak-baséiert Modeller schaffen.
- Flexibilitéit a Skalierbarkeet.
- Integratioun mat Xtext (an enger separater Layer).
Fir gemeinsam Konzepter a Protokoller ze markéieren, goufen existent Implementatioune vu Sproochhandtak-baséiert Modeller analyséiert. D'Haaptschnëttplazen a Basisimplementatiounen, déi vum Handly geliwwert ginn, ginn an der Fig. 8.
Reis. 8. Gemeinsam Schnëttplazen a Basis Implementatioune vun Handly Elementer
D'IElement Interface representéiert de Grëff vun engem Element an ass gemeinsam fir Elementer vun all Hand-baséiert Modeller. D'abstrakt Klass Element implementéiert de generaliséierte Grëff / Kierpermechanismus (Fig. 9).
Reis. 9. IElement a generesch Handle / Kierper Ëmsetzung
Zousätzlech stellt Handly e generaliséierte Mechanismus fir iwwer Ännerungen an Modellelementer z'informéieren (Fig. 10). Wéi Dir gesitt, ass et breed ähnlech wéi d'Notifikatiounsmechanismen, déi am Ressourcemodell an dem Java Modell implementéiert sinn, a benotzt IElementDelta fir eng vereenegt Representatioun vun Element änneren Informatioun ze bidden.
Reis. 10. Allgemeng Schnëttplazen a Basisimplementatiounen vum Handly Notifikatiounsmechanismus
D'Handly Deel uewen diskutéiert (Fig. 9 an 10) ka benotzt ginn fir bal all Handle-baséiert Modeller ze representéieren. Fir ze kreéieren sproochlech Modeller, bitt de Projet zousätzlech Funktionalitéit - besonnesch gemeinsam Schnëttplazen a Basisimplementatiounen fir Elementer vun der Quelltextstruktur, déi sougenannt Quelle Elementer (Fig. 8). D'ISourceFile Interface representéiert eng Quelldatei, an ISourceConstruct stellt en Element an der Quelldatei duer. Déi abstrakt Klassen SourceFile a SourceConstruct implementéieren generaliséiert Mechanismen fir d'Aarbecht mat Quelldateien an hiren Elementer z'ënnerstëtzen, zum Beispill mat Textbuffer ze schaffen, un d'Koordinaten vun engem Element am Quelltext ze verbannen, Modeller mat den aktuellen Inhalter vun engem Aarbechtskopie-Puffer ze versöhnen. , etc. D'Ëmsetzung vun dëse Mechanismen ass normalerweis eng Erausfuerderung, an Handly kann den Effort wesentlech reduzéieren fir Handle-baséiert Sproochmodeller z'entwéckelen andeems se héichqualitativ Basisimplementatiounen ubidden.
Zousätzlech zu den uewe genannte Kärmechanismen, bitt Handly eng Infrastruktur fir Textbuffer a Schnappschëss, Ënnerstëtzung fir Integratioun mat Quellcode Editoren (inklusiv Out-of-the-Box Integratioun mam Xtext Editor), souwéi e puer gemeinsam UI Komponenten déi schafft mat Quellcode Editoren. Handlech Modeller wéi Outline Framework. Fir seng Fäegkeeten ze illustréieren, gëtt de Projet e puer Beispiller, dorënner eng Implementatioun vum Java Modell an Handly. (Am Verglach mat der voller Ëmsetzung vum Java Modell am JDT, ass dëse Modell bewosst e bësse vereinfacht fir méi Kloerheet.)
Wéi virdru bemierkt, e grousse Fokus wärend dem Handly säin initialen Design a spéider Entwécklung war a bleift weider op Skalierbarkeet a Flexibilitéit.
Prinzipiell sinn Handle-baséiert Modeller zimlech gutt "vum Design". Zum Beispill erlaabt de Grëff / Kierper Idiom Dir d'Quantitéit vun Erënnerung ze limitéieren vun engem Modell verbraucht. Mä et ginn och Nuancen. Also, wann Dir Handly fir Skalierbarkeet testen, gouf e Problem an der Ëmsetzung vum Notifikatiounsmechanismus entdeckt - wann eng grouss Zuel vun Elementer geännert goufen, huet d'Konstruktioun vun Deltas ze vill Zäit gedauert. Et huet sech erausgestallt datt dee selwechte Problem am JDT Java Modell präsent war, aus deem de entspriechende Code eemol ugepasst gouf. Mir hunn de Feeler an Handly fixéiert an en ähnlechen Patch fir JDT virbereet, deen dankbar krut. Dëst ass just e Beispill wou Handly an existent Modellimplementatiounen agefouert ka potenziell nëtzlech sinn, well an dësem Fall kéint esou e Feeler op nëmmen enger Plaz fixéiert ginn.
Fir d'Ëmsetzung vun Handly an existente Modellimplementatiounen technesch machbar ze maachen, muss d'Bibliothéik bedeitend Flexibilitéit hunn. Den Haaptproblem ass d'Réckkompatibilitéit iwwer den API Modell z'erhalen. Dëse Problem gouf geléist an andeems d'modellspezifesch API kloer trennt, definéiert a voll kontrolléiert vum Entwéckler, vun der vereenegt Meta-Niveau API vun der Bibliothéik. Dëst mécht et net nëmmen technesch méiglech Handly an existent Implementatiounen ëmzesetzen, mee gëtt den neie Modellentwéckler och bedeitend Fräiheet beim Design vun der API.
Flexibilitéit huet och aner Aspekter. Zum Beispill, Handly setzt bal keng Restriktiounen op d'Struktur vum Modell op a ka souwuel benotzt ginn fir allgemeng Zweck Sproochen an Domain-spezifesch Sproochen ze modelléieren. Wann Dir d'Struktur vun der Quelldatei konstruéiert, schreift Handly keng speziell Form vun AST Representatioun a verlaangt am Prinzip net emol d'Präsenz vun engem AST, sou datt d'Kompatibilitéit mat bal all Parsingmechanismus garantéiert. Schlussendlech ënnerstëtzt Handly voll Integratioun mam Eclipse Workspace, awer kann och direkt mat Dateiesystemer schaffen dank senger Integratioun mat (EFS).
Aktuell Versioun Dezember 2016 erauskomm ass. Trotz der Tatsaach datt de Projet de Moment an engem Zoustand vun der Inkubatioun ass an d'API nach net endlech fixéiert ass, gëtt Handly schonn an zwee grousse kommerziellen Produkter benotzt, déi de Risiko geholl hunn als "fréi Adoptanten" ze handelen, an ech muss soen, bedaueren et nach net.
Wéi uewen ernimmt, ass ee vun dëse Produkter 1C:Enterprise Development Tools, wou Handly vun Ufank un benotzt gëtt fir Elementer vun der héijer Struktur vun esou 1C:Enterprise Sproochen als agebauter Programméierungssprooch a Query Sprooch ze modelléieren. . En anert Produkt ass manner bekannt fir d'Allgemengheet. Dëst , en integréierten Designëmfeld fir Applikatiounsspezifesch Instruktiouns-Set-Prozessor (ASIP), souwuel an der tschechescher Firma Codasip selwer a vu senge Clienten benotzt, inklusiv , , , . Codasip huet Handly an der Produktioun zënter 2015 benotzt, ugefaange mat der Versioun Handly 0.2. Déi lescht Verëffentlechung vum Codasip Studio benotzt Versioun 0.5, verëffentlecht am Juni 2016. Den Ondřej Ilčík, deen d'IDE Entwécklung bei Codasip féiert, ass a Kontakt mam Projet, liwwert vitale Feedback am Numm vum "Drëtt Partei Adoptator". Hie konnt souguer e puer Fräizäit fannen fir direkt un der Entwécklung vum Projet deelzehuelen, eng UI Layer (~ 4000 Zeilen Code) fir ee vun de Handly Beispiller, e Java Modell, ëmzesetzen. Méi detailléiert Informatioun iwwer d'Benotzung vun Handly vun Adoptanten kann op der Säit fonnt ginn Projet.
Mir hoffen, datt no der Verëffentlechung vun der Versioun 1.0 mat enger Garantie vun der API Stabilitéit an dem Projet deen den Inkubatiounsstaat verléisst, Handly nei Adopteren hunn. An der Zwëschenzäit geet de Projet weider fir d'API ze testen a weider ze verbesseren, zwee "grouss" Verëffentlechungen pro Joer ze verëffentlechen - am Juni (dee selwechten Datum wéi déi simultan Eclipse Verëffentlechung) an Dezember, e prévisibele Zäitplang ubitt, op deen d'Adoptanten vertrauen kënnen. Mir kënnen och addéieren datt de "Bugrate" vum Projet op engem konsequent nidderegen Niveau bleift an Handly huet zënter den éischte Versiounen zouverlässeg an de Produkter vu fréien Adoptanten geschafft. Fir weider Eclipse Handly ze entdecken, kënnt Dir benotzen и .
Source: will.com