Pa sigurisht, nuk ka nevojë për prezantim të veçantë. Shumë janë të njohur me Eclipse falë Eclipse Java development tools (). Kjo IDE popullore open-source lidh shumicën e zhvilluesve me fjalën “Eclipse”. Megjithatë, Eclipse është gjithashtu një platformë e zgjerueshme për integrimin e mjeteve të zhvillimit (Eclipse Platform), dhe një sërë IDE-sh që janë ndërtuar mbi të, përfshirë JDT. Eclipse është dhe Eclipse Project, një projekt në nivel të lartë që koordinon zhvillimin e Eclipse Platform dhe JDT, dhe Eclipse SDK – produkti i këtij zhvillimi. Për më tepër, Eclipse është një fondacion open-source me një komunitet të madh projektesh, shumë prej të cilëve nuk janë shkruar në Java ose nuk kanë lidhje me mjetet e zhvillimit (p.sh. projektet dhe ). Bota e Eclipse është shumë e larmishme.
Në këtë artikull, i cili ka karakter shqyrtues, do të përpiqemi të shqyrtojmë disa bazë të arkitekturës së Eclipse si një platformë për ndërtimin e mjeteve të integruara të zhvillimit dhe t'i japim një përshkrim fillestar komponentëve të Eclipse që formojnë fundamentin e platformës teknologjike për "konfiguruesin e ri" 1C: Enterprise, . Natyrisht, një shqyrtim i tillë do të jetë në shumicën e rasteve sipërfaqësor dhe mjaft i kufizuar, përfshirë për faktin se ne jemi duke shikuar jo vetëm tek zhvilluesit e Eclipse si audiencë të synuar. Megjithatë, shpresojmë që edhe zhvilluesit e eksperiencës me Eclipse të gjejnë informacione interesante në këtë artikull. Për shembull, do të flasim për një nga "sekretet e Eclipse", një projekt relativisht i ri dhe ende pak i njohur , i cili është themeluar dhe mbështetur nga kompania 1C.
Hyrja në arkitekturën e Eclipse
Le të shqyrtojmë fillimisht disa aspekte të përgjithshme të arkitekturës së Eclipse duke marrë si shembull (JDT). Zgjedhja e JDT si shembull nuk është e rastësishme. Kjo është ambienti i parë i integruar i zhvillimit që u shfaq në Eclipse. Projektet e tjera *DT të Eclipse, siç janë Eclipse C/C++ Development Tooling (CDT), u krijuan më vonë dhe morën si parime arkitektonike kryesore ashtu si dhe fragmente të veçanta të kodit burimor nga JDT. Bazat e arkitekturës, të vendosura në JDT, janë aktuale edhe sot për praktikisht çdo IDE që është ndërtuar mbi Eclipse Platform, përfshirë edhe 1C: Enterprise Development Tools.
Së pari duhet theksuar se Eclipse karakterizohet nga një ndarje mjaft e qartë arkitektonike, me ndarjen e funksionalitetit të pavarur nga gjuha nga funksionaliteti i destinuar për mbështetje të gjuhëve specifike të programimit, si dhe ndarjen e komponentëve "bërthamore" (core) që nuk varen nga UI nga komponentët e lidhur me mbështetje të ndërfaqes përdoruesi.
Platforma Eclipse përcakton infrastrukturën e përbashkët, të pavarur nga gjuha, ndërsa mjetet për zhvillimin e Java shtojnë në Eclipse një IDE plotësisht funksionale për Java. Si Platforma Eclipse ashtu edhe JDT përbëhen nga disa komponentë, secila prej të cilave i përket ose "bërthamës" që nuk varet nga UI, ose shtresës së UI (shih. 1).
Shih. 1. Platforma Eclipse dhe JDT
Le të rendisim komponentët kryesorë të Platformës Eclipse:
- Runtime — Përcakton infrastrukturën e plug-inëve. Eclipse karakterizohet nga një arkitekturë modulare. Në thelb, Eclipse është një koleksion i "pikave të zgjerimit" dhe "zgjerimeve".
- Workspace — Menaxhon një ose më shumë projekte. Një projekt përbëhet nga dosje dhe skedarë, të cilat shfaqen drejtpërdrejt në sistemin e skedarëve.
- Standard Widget Toolkit (SWT) — Ofron elementët bazë të ndërfaqes përdoruesi, të integruar me sistemin operative.
- JFace — Ofron një sërë kornizash UI të ndërtuara mbi SWT.
- Workbench — Përcakton paradigmat UI të Eclipse: redaktuesit, pamjet, perspektivat.
Duhet të thuhet se Platforma Eclipse ofron gjithashtu shumë componente të tjera të dobishme për ndërtimin e mjeteve të integruara të zhvillimit, ndër të cilat mund të përmendin Debug, Compare, Search dhe Team. Veçanërisht duhet përmendur JFace Text – baza për ndërtimin e "redaktuesve inteligjentë" të kodit burimor. Fatkeqësisht, edhe një shqyrtim i shpejtë i këtyre komponentëve, ashtu siç janë komponentët e shtresës UI, nuk mund të çmohet brenda këtij artikulli, kështu që në pjesën e mbetur të këtij seksioni ne do të kufizohemi në një përmbledhje të komponentëve kryesorë "bërthamore" të Platformës Eclipse dhe JDT.
Core Runtime
Infrastruktura e plug-inëve të Eclipse bazohet në dhe ofrohet nga projekti . Çdo plug-in i Eclipse është një bundle OSGi. Spefikimi OSGi përcakton, në veçanti, mekanizmat e versionimit dhe zgjidhjes së varësive. Përveç këtyre mekanizmave standarde, Equinox prezanton konceptin e pikës së zgjerimit. Çdo plugin mund të përcaktojë pikët e veta të zgjerimit, duke sjellë gjithashtu funksionalitete të tjera në sistem ('zgjerimet'), duke përdorur pikët e zgjerimit të përcaktuara nga ky ose pluginë të tjerë. Një përshkrim më i detajuar i mekanizmave OSGi dhe Equinox del jashtë kufijve të këtij artikulli. Vlen të theksohet se modularizimi në Eclipse ka karakter total (çdo nën sistem, përfshirë Runtime, përbëhet nga një ose më shumë pluginë), dhe praktikisht gjithçka në Eclipse është një zgjerim. Këto parime ishin integruar në arkitekturën e Eclipse shumë përpara zbatimit të OSGi (në atë kohë ishte përdorur një teknologji e brendshme, shumë e ngjashme me OSGi).
Workspace-i Kryesor
Praktikisht çdo mjedis i integruar i zhvillimit, i ndërtuar mbi bazën e Eclipse Platform, punon me workspace-in e Eclipse. Pikërisht workspace-i zakonisht përmban kodin burimor të aplikacionit që po zhvillohet në IDE. Workspace-i pasqyrohet drejtpërdrejt në sistemin e skedhave dhe përbëhet nga projekte, të cilat përmbajnë dosje dhe skedha. Këto projekte, dosje dhe skedha quhen burime workspace. Implementimi i workspace në Eclipse shërben si një cache në lidhje me sistemin e skedhave, duke bërë të mundur një përshpejtim të dukshëm në kalimin nëpër pemën e burimeve. Për më tepër, workspace ofron një sërë shërbimesh shtesë, duke përfshirë dhe .
Për mbështetje të workspace-it dhe burimeve të tij përgjigjet komponenti Core Resources (plugin org.eclipse.core.resources). Në veçanti, ky komponent ofron qasje programore në workspace në formën e modelit të burimeve. Për të punuar në mënyrë efikase me këtë model, klientët kanë nevojë për një mënyrë të thjeshtë për të paraqitur një lidhje me burimin. Në këtë rast, do të ishte e dëshirueshme që objekti, i cili ruan drejtpërdrejt gjendjen e burimit në model, të fshihet nga qasja e klientëve. Në të kundërt, në rastin, për shembull, të fshirjes së një skedhe, klienti mund të vazhdojë të mbajë objektin që tashmë nuk ekziston në model, duke sjellë probleme të tillë. Eclipse e zgjidh këtë problem duke përdorur atë që quhet handle i burimit. Handle funksionon si një çelës (ai di vetëm rrugën e burimit në workspace) dhe kontrollon plotësisht qasjen në objektin e brendshëm të modelit, i cili ruan drejtpërdrejt informacionin mbi gjendjen e burimit. Ky dizajn është një variacion i modelit .
Figura 2 ilustron idiomën Handle/Body në lidhje me modelin e burimeve. Interfaci IResource përfaqëson handle-in e burimit dhe është API, në të kundërt, klasa Resource që implementon këtë interfacë, si dhe klasa ResourceInfo, e cila përfaqëson body-n, që nuk janë API. Theksojmë se handle-i di vetëm rrugën për në burim në lidhje me rrënjën e workspace-it dhe nuk përmban një referencë në resource info. Objektet e resource info formojnë atë që quhet "pemë elementesh" (element tree). Kjo strukturë të dhënash është komplet e materializuar në memorie. Për të gjetur një instancë të resource info, e cila i përgjigjet një handle-i, pemës së elementeve i nënshtrohet një kalimi sipas rrugës që ruhet në këtë handle.
Figura 2. IResource dhe ResourceInfo
Siç do të shohim më tej, dizajni bazë i modelit të burimeve (që mund të quhet i bazuar në handle) përdoret në Eclipse dhe për modele të tjera. Tani, le të listojmë disa karakteristika dalluese të këtij dizajni:
- Handle-i është një objekt-me-vlerë (value object). Objektet-me-vlerë janë objekte të papërshkueshme (immutable), përputhshmëria e të cilave nuk bazohet në identitet. Këto objekte mund të përdoren sigurt në kapacitetin e çelësit në kontejnerët e heshuar. Disa instanca të handle mund të referohen në të njëjtin burim. Për t'i krahasuar ato, duhet të përdoren metoda equals(Object).
- Handle-i përcakton sjelljen e burimit, por nuk përmban informacion mbi gjendjen e burimit (të dhënat e vetme që ruan janë "çelësi", rruga për në burim).
- Handle-i mund të referohet në një burim që nuk ekziston (ose një burim që ende nuk është krijuar, ose një burim që tashmë është fshirë). Ekzistenca e burimit mund të verifikohet me metodën IResource.exists().
- Disa operacione mund të realizohen duke u bazuar ekskluzivisht në informacionin që ruhet në vetë handle-in (operacione të ashtuquajtura handle-only). Shembuj janë IResource.getParent(), getFullPath(), etj. Burimi nuk është domosdoshmërisht i nevojshëm për ekzekutimin e suksesshëm të një operacioni të tillë. Operacioneve që kërkojnë që burimi të ekzistojë për të qenë të suksesshme, u hedhin një përjashtim (CoreException) nëse burimi nuk ekziston.
Eclipse ofron një mekanizëm efektiv për njoftimin e ndryshimeve në burimet e workspace (shih. 3). Burimet mund të ndryshojnë si rezultat i veprimeve të kryera brenda vetë Eclipse IDE, ashtu edhe nga ekzekutimi i sinkronizimit me sistemin e skedarëve. Në të dy rastet, klientët që janë regjistruar për njoftime fitojnë informacion të detajuar mbi ndryshimet në formën e «delta burse» (resource delta). Delta përshkruan ndryshimet mes dy gjendjeve të (nën)strukturës së burimeve të workspace dhe vetë është një strukturë, ku çdo nyje përshkruan ndryshimin e një burimi dhe përmban një listë deltesh të nivelit të ardhshëm, duke përshkruar ndryshimet në burimet fëmijë.
Shih. 3. IResourceChangeEvent dhe IResourceDelta
Mekanizmi i njoftimit të bazuar në delta burse ka karakteristika të mëposhtme:
- Një ndryshim i vetëm dhe shumë ndryshime përshkruhen me të njëjtin strukturë, pasi delta ndërtohet mbi parimin e kompozitës rekursive. Klientët e regjistruar mund të përpunojnë njoftimet për ndryshimin e burimeve duke ecur në mënyrë rekursive përmes strukturës së deltes.
- Delta përmban informacion të plotë mbi ndryshimin e burimit, duke përfshirë lëvizjen dhe/ose ndryshimin e «markerave» të lidhura me të (siç janë gabimet e kompilimit).
- Pasi referencat për burimin bëhen përmes handle, delta mund të referohet natyrshëm në burimin e largët.
Siç do ta shohim së shpejti, përbërësit kryesorë të dizajnit të mekanizmit të njoftimit për ndryshimin e modelit të burimeve janë të rëndësishëm edhe për modele të tjera të bazuara në handle.
JDT Core
Modeli i burimeve të workspace të Eclipse është një model themelor dhe jo të varur prej gjuhës. Komponenta JDT Core (plugin org.eclipse.jdt.core) ofron API për navigimin dhe analizimin e strukturës së workspace nga këndvështrimi i Java, i njohur si «modeli Java» (Java model). Ky API është i përcaktuar në terma të elementeve Java, për dallim nga API i nëndheshëm i modelit të burimeve, i cili është i përcaktuar në terma të dosjeve dhe skedarëve. Interfacet kryesore të strukturës së elementeve të Java janë ilustruar në shih. 4.
Shih. 4. Elementet e modelit Java
Modeli Java përdor të njëjtin idiom handle/body si modeli i burimeve (fig. 5). IJavaElement është handle, ndërsa JavaElementInfo luan rolin e body. Interface IJavaElement përcakton protokollin e përbashkët për të gjitha elementet Java. Disa nga metodat e tij janë vetëm handle: getElementName(), getParent(), etj. Objekti JavaElementInfo ruan gjendjen e elementit përkatës: strukturën dhe atributet e tij.
Fig. 5. IJavaElement dhe JavaElementInfo
Modeli Java ka disa ndryshime në implementimin e dizajnit themelor handle/body në krahasim me modelin e burimeve. Siç u përmend më lart, në modelin e burimeve, pemën e elementeve, ku nyjet janë objekte resource info, e gjithë ajo ndodhet plotësisht në memorie. Por në modelin Java mund të ketë një numër ndjeshëm më të madh elementesh se në pemën e burimeve, pasi në të paraqitet, përfshirë, struktura e brendshme e skedarëve .java dhe .class: llojet, fushat dhe metodat.
Për të shmangur materializimin e plotë të gjithë pemës së elementeve në memorie, implementimi i modelit Java përdor një LRU-cache të kufizuar në madhësi për informacionin e elementeve, ku çelësi është handle IJavaElement. Objekti i informacionit të elementeve krijohet me kërkesë ndërsa ndodh navigimi në pemën e elementeve. Ndërkohë, elementet më pak të përdorura shpërngulen nga cache, dhe konsumimi i memories nga modeli mbetet i kufizuar në madhësinë e caktuar të cache-it. Ky është një tjetër avantazh i dizajnit të bazuar në handle, i cili e fsheh plotësisht njësi të tilla të implementimit nga kodi i klientit.
Mekanizmi i njoftimit për ndryshimet e elementeve Java është në përgjithësi i ngjashëm me mekanizmin e shqyrtuar më lart për ndjekjen e ndryshimeve të burimeve të workspace. Klienti, i cili dëshiron të ndjekë ndryshimet në modelin Java, regjistrohet për njoftime, të cilat paraqiten në formën e objektit ElementChangedEvent, i cili përmban IJavaElementDelta (fig. 6).
Fig. 6. ElementChangedEvent dhe IJavaElementDelta
Modeli Java nuk përmban informacion mbi trupat e metodave ose zgjidhjen e emrave, prandaj për një analizë të detajuar të kodit të shkruar në Java, JDT Core siguron një model shtesë (jo të bazuar në handle): (abstract syntax tree, AST). AST paraqet rezultatin e analizës sintaksore të tekstit origjinal. Nyjet e AST i përkasin elementeve të strukturës së modulit origjinal (deklaratave, operatorëve, shprehjeve, etj.) dhe përmbajnë informacion mbi koordinatat e elementit përkatës në tekstin origjinal, si dhe (me opsion) informacion për zgjidhjen e emrave në formën e lidhjeve në atë që quhet bindingsBindings janë objekte që përfaqësojnë entitete të emëruara, siç janë tipos, metoda dhe variablët, të njohur nga kompilatori. Ndryshe nga nyjat AST që formojnë një dru, bindings mbështesin referencat e kryqëzuara dhe zakonisht formojnë një grafik. Klasa abstrakte ASTNode është klasa themelore për të gjitha nyjat AST. Nënklasat e ASTNode korrespondojnë me konstrukcione sintaksore të caktuara të gjuhës Java.
Për shkak se drunjtë sintaksorë mund të konsumojnë një sasi të konsiderueshme këndvështrimi, JDT ruan vetëm një AST për redaktorin aktiv. Ndryshe nga modeli Java, AST zakonisht shqyrtohet si një model "ndërmjetës", "përkohshëm", në elementet e të cilit klientët nuk duhet të mbajnë referenca jashtë kontekstit të operacionit që çoi në krijimin e AST.
Të tri modelet e renditura (modeli Java, AST, bindings) së bashku përbëjnë bazën për ndërtimin e "mjeteve inteligjente të zhvillimit" në JDT, përfshirë një redaktor të fuqishëm Java me një mori "ndihmësish", si dhe veprime të ndryshme për përpunimin e kodit burimor (përfshirë organizimin e listës së importit të emrave dhe formatimin në përputhje me stilin e konfiguruar), si dhe mjete kërkimi dhe ristrukturimi. Në këtë kontekst, modeli Java luan një rol të veçantë, pasi ai përdoret si baza për paraqitjen vizuale të strukturës së aplikacionit që po zhvillohet (për shembull, në Package Explorer, Outline, Search, Call Hierarchy, dhe Type Hierarchy).
Komponentët Eclipse të përdorur në 1C:Enterprise Developments Tools
Në Fig. 7 janë shfaqur komponentët Eclipse që formojnë themelin e platformës teknologjike për 1C:Enterprise Development Tools.
Fig. 7. Eclipse si platformë për 1C:Enterprise Development Tools
Platforma Eclipse siguron infrastrukturën bazë. Ne shqyrtuam disa aspekte të kësaj infrastrukture në seksionin e mëparshëm.
(EMF) ofron mjete të përgjithshme për modelimin e të dhënave të strukturuara. EMF është i integruar me Eclipse Platform, por mund të përdoret edhe veçmas, në aplikacione Java të zakonshme. Shpesh, zhvilluesit e rinj të Eclipse janë tashmë të njohur mirë me EMF, megjithëse nuk e kuptojnë plotësisht thellësitë e Eclipse Platform. Një nga arsyet e popullaritetit të tillë të merituar është dizajni universal, i cili përfshin, përveç të tjerash, një API të unifikuar në nivel meta, që lejon të punosh me çfarëdo modeli EMF në mënyrë të përgjithshme. Realizimet themelore që EMF ofron për objektet e modelit dhe nëndega e gjenerimit të kodit të modelit nga meta-modeli rrit në mënyrë të ndjeshme shpejtësinë e zhvillimit dhe ul numrin e gabimeve. Po ashtu, EMF përmban mekanizma për serializimin e modeleve, ndjekjen e ndryshimeve në model, dhe shumë më tepër.
Si çdo mjet me të vërtetë universale, EMF është i përshtatshëm për një gamë të gjerë problemesh që lidhen me modelimin, por disa klasa modelet (për shembull, modelet që u diskutuan më sipër të bazuara në dore) mund të kenë nevojë për mjete më të specializuara modelimi. Të flasësh për EMF është një punë e vështirë, sidomos në kufijtë e një artikulli të vetëm, pasi është një temë për një libër të veçantë, dhe mjaft të trashë. Le të theksojmë vetëm se një sistem i kualitetit të tiparizimeve, që qëndron në themel të EMF, e ka lejuar lindjen e një gamë të gjerë projektesh që përfshihen në projektin e nivelit të lartë. përveç EMF vetë. Një nga këto projekte është Eclipse Xtext.
ofron infrastrukturën e ‘modelimit tekstual’. Xtext përdor për analizën sintaksore të tekstit të burimit dhe EMF për përfaqësimin e ASG-të rezultat (grafi abstrakt semantik, i cili, në thelb, është një kombinim i AST dhe lidhjeve), i njohur gjithashtu si «modeli semantik». Gramatika e gjuhës së modeluar me Xtext përshkruhet në gjuhën e saj të vetme Xtext. Kjo lejon jo vetëm gjenerimin e përshkrimit të gramatikës për ANTLR, por gjithashtu ofron një mekanizëm serializimi për AST (dmth. Xtext siguron si parser ashtu edhe unparser), sugjerim konteksti, dhe një sërë komponentësh të tjerë gjuhësorë. Nga ana tjetër, gjuha e përshkrimit të gramatikës e përdorur në Xtext është më pak fleksibël krahasuar, të themi, me gjuhën e përshkrimit të gramatikës në ANTLR. Prandaj, ndonjëherë është e nevojshme të «përshtatni» gjuhën e realizuar sipas Xtext-it, gjë që zakonisht nuk është një problem nëse kemi të bëjmë me një gjuhë që është në zhvillim të plotë, por mund të jetë e papranueshme për gjuhë me një sintaksë tashmë të vendosur. Megjithatë, Xtext është aktualisht mjeti më i pjekur, funksionalisht i plotë dhe universali në Eclipse për ndërtimin e gjuhëve të programimit dhe mjeteve për to. Njëkohësisht, ai është mjeti ideal për prototipizimin e shpejtë. (gjuhë e orientuar ndaj domenit, DSL). Përveç «në zemër» gjuhësore të përmendur më sipër që bazohet në ANTLR dhe EMF, Xtext ofron shumë komponentë të dobishëm të nivelit më të lartë, duke përfshirë mekanizmat e indeksimit, ndërtimit inkremental, «editorin e zgjuar», dhe shumë të tjera, por lë jashtë modele gjuhësore të bazuara në manekena. Ashtu si EMF, Xtext është një temë që meriton një libër të veçantë, dhe ndoshta gjithashtu nuk do të mund të përmendim të gjitha mundësitë e tij edhe për një përshkrim të shkurtër.
1C:Instrumente të Zhvillimit të Ndërmarrjeve përdorin aktivisht si EMF-në vetë, ashtu edhe një sërë projektesh të tjera Eclipse Modeling. Në veçanti, Xtext është një nga bazat e mjeteve të zhvillimit për gjuhët 1C:Ndërmarrje, si gjuha e programimit e integruar dhe gjuha e pyetjeve. Një bazë tjetër e këtyre mjeteve zhvillimi është projekti Eclipse Handly, për të cilin do të ndalemi më në detaje (nga komponentët e listuar të Eclipse, ai është për momentin më pak i njohur).
, nënprojekti i projektit kryesor Eclipse Technology, lindi si rezultat i kontributit fillestar të kodit në Eclipse Foundation, i bërë nga kompania 1C në vitin 2014. Që atëherë, kompania 1C vazhdon të mbështesë zhvillimin e projektit: komituesit e Handly janë punonjës të kompanisë. Projekti është i vogël, por zë një gjendje mjaft unike në Eclipse: qëllimi kryesor i tij është mbështetja e zhvillimit të modeleve të bazuara në handle.
Parimet arkitekturore të zakonshme të modeleve të bazuara në handle, siç është idioma handle/body, u shqyrtuan më sipër në shembullin e modelit të burimeve dhe modelit Java. Aty u theksua gjithashtu se si modeli i burimeve, ashtu dhe modeli Java janë baza të rëndësishme për mjetet e zhvillimit Eclipse Java (JDT). Dhe pasi që pothuajse të gjitha projektet *DT të Eclipse kanë një arkitekturë të ngjashme me JDT, nuk do të ishte një ekzagjerim të thuash se modelet e bazuara në handle janë në thelb të shumë, nëse jo të gjitha IDE-të, të ndërtuara mbi Platformën Eclipse. Për shembull, në Eclipse C/C++ Development Tooling (CDT) ka një model të bazuar në handle për C/C++, i cili luan në arkitekturën e CDT të njëjtin rol si modeli Java në JDT.
Para se të shfaqej Handly, Eclipse nuk ofronte biblioteka të specializuara për ndërtimin e modeleve të gjuhës të bazuara në handle. Modelet ekzistuese tani u krijuan kryesisht përmes adaptimit të drejtpërdrejtë të kodit të modelit Java (e njohur gjithashtu si kopjim/pastë). në rastet kur kjo lejohet. Licenca Publike e Eclipse (EPL). (Natyrisht, për projekte të Eclipse vetë, kjo zakonisht nuk paraqet një problem nga pikëpamja ligjore, gjë që nuk mund të thuhet për produktet me kod të mbyllur.) Përveç karakteristikave të saj të paorganizuar, një metodologji e tillë çon në probleme të njohura: dyfishimin e kodit, gabimet e sjella gjatë adaptimit, etj. Çfarë është edhe më keq, modelet e rezultuara mbeten "objekte në vetvete" dhe nuk shfrytëzojnë potencialin ekzistues për unifikim. Sepse identifikimi i koncepteve dhe protokolleve të zakonshme për modelet e bazuara në handle mund të çonte në krijimin e komponenteve të ripërdorshme për punën me to, ashtu siç ndodhi me EMF.
Nuk mund të thuhet se në Eclipse nuk kishte një kuptim të këtyre problemeve. Që në vitin 2005 , duke përmbledhur përvojën e zhvillimit të prototipit CDT, nevojën për krijimin e një infrastrukture të përbashkët për modelet gjuhësore, duke përfshirë modelet e bazuara në handle. Por, siç ndodh shpesh, për shkak të kërkesave më prioritare, këto ide nuk u realizuan kurrë. Megjithatë, faktoriza e kodit *DT-projekteve vazhdon të mbetet një nga temat e papërpunuara në Eclipse.
Në njëfarë kuptimi, projekti Handly synon të zgjidhë detyra të ngjashme me EMF, por për modelet e bazuara në handle, dhe në radhë të parë për gjuhët (pra, që përfaqësojnë elementet e strukturës së një gjuhe programuese). Më poshtë janë listuar qëllimet kryesore që ishin vendosur gjatë projektimit të Handly:
- Dallimi i abstraksioneve kryesore të domenit.
- Reduktimi i përpjekjeve dhe rritja e cilësisë së implementimit të modeleve gjuhësore të bazuara në handle përmes rizgjedhjes së kodit.
- Ofrimi i një API të unifikuar në nivelin meta për modelet e rezultuara, duke bërë të mundur krijimin e komponenteve të përbashkëta IDE që punojnë me modelet gjuhësore të bazuara në handle.
- Fleksibiliteti dhe shkallëzueshmëria.
- Integrimi me Xtext (në një nivel të veçantë).
Për të dalluar konceptet dhe protokollet e zakonshme, janë analizuar implementimet ekzistuese të modeleve gjuhësore të bazuara në handle. Interface-t kryesorë dhe implementimet bazë të ofruara nga Handly janë paraqitur në fig. 8.
Fig. 8. Interface-t e zakonshme dhe implementimet bazë të elementeve Handly
Interface-i IElement përfaqëson handle-në e një elementi dhe është i zakonshëm për elementet e të gjitha modeleve të bazuara në Handly. Klasa abstrakte Element realizon mekanizmin e përgjithësuar handle/body (fig. 9).
Fig. 9. IElement dhe implementimi i përgjithësuar handle/body
Përveç kësaj, Handly ofron një mekanizëm të përgjithësuar për njoftimin mbi ndryshimet e elementeve të modelit (fig. 10). Siç mund të shihet, në përgjithësi është analog me mekanizmat e njoftimit të implementuar në modelin e burimeve dhe modelin Java, dhe përdor IElementDelta për një paraqitje të unifikuar të informacionit mbi ndryshimin e një elementi.
Fig. 10. Interface-t e zakonshme dhe implementimet bazë të mekanizmit të njoftimit Handly
Pjesa e mësipërme e Handly (fig. 9 dhe 10) mund të përdoret për përfaqësimin e praktikisht çdo modeli të bazuar në handle. Për krijimin e modeleve gjuhësore projekti ofron funksionalitete shtesë - në veçanti, interface-t e zakonshme dhe implementimet bazë për elementet e strukturës së tekstit origjinal, të ashtuquajturat source elements (fig. 8). Interfejsi ISourceFile paraqet skedarin burimor, ndërsa ISourceConstruct është një element brenda skedarit burimor. Klasa abstrakte SourceFile dhe SourceConstruct zbatojnë mekanizmat e përgjithshme për mbështetje në punën me skedarët burimorë dhe elementët e tyre, siç janë punët me buferat tekstorë, lidhja me koordinatat e elementit në tekstin burimor, pajtimi i modelit me përmbajtjen aktuale të buferit të kopjes së punës, dhe e tjera. Zbatimi i këtyre mekanizmave zakonisht është një detyrë mjaft e ndërlikuar, dhe Handly mund të zvogëlojë ndjeshëm përpjekjet për zhvillimin e modeleve të bazuara në doreza duke ofruar implementime të cilësisë së lartë bazë.
Përveç mekanizmave kryesorë të listuar më sipër, Handly ofron infrastrukturën e buferave tekstorë dhe «snapshot»-eve, mbështetje për integrimin me editorët e kodit burimor (duke përfshirë një integrim të realizuar «në kuti» me editorin Xtext), si dhe disa komponente të zakonshme UI që punojnë me modelet e bazuara në Handly, siç është framework-u outline. Për ilustruese të mundësive të tij, projekti ofron disa shembuj, duke përfshirë dhe implementimin e modelit Java në Handly. (Krahasuar me implementimin e plotë të modelit Java në JDT, ky model është qëllimisht pak më i thjeshtë për qartësi më të madhe.)
Siç u përmend më parë, vëmendje e madhe iu kushtua dizajnimit fillestar të Handly dhe zhvillimit të mëtejshëm të tij në lidhje me shkallëzueshmërinë dhe fleksibilitetin.
Në parim, modelet e bazuara në doreza shkallëzohen mjaft mirë «vetë për dizajn». Për shembull, idioma handle/body lejon që të kufizohet sasia e memories së konsumuar nga modeli. Por ka edhe nuanca. Gjatë testeve të Handly për shkallëzueshmëri u zbulua një problem në implementimin e mekanizmit të njoftimit – gjatë ndryshimeve të një numri të madh elementesh, ndërtimi i delta merrte shumë kohë. U zbulua se e njëjta problem po ashtu ekziston edhe në modelin Java JDT, nga i cili në një kohë ishte adaptuar kodin përkatës. Ne korrigjuam gabimin në Handly dhe përgatitëm një patch të ngjashëm për JDT, i cili u pranua me falënderim. Ky është vetëm një nga shembujt e shumtë, kur implementimi i Handly në realizimet ekzistuese të modeleve mund të ishte potencialisht i dobishëm, pasi në këtë rast një gabim i tillë mund të merret parasysh vetëm në një vend.
Për të bërë implementimin e Handly në implementimet ekzistuese të modeleve teknikisht të mundshëm, biblioteka duhet të ketë një fleksibilitet të konsiderueshëm. Problemi kryesor është të ruajmë backward compatibility në API-në e modelit. Ky detyrë u zgjidh në nëpërmjet ndarjes së qartë të API-së specifike për modelin, e cila përcaktohet dhe kontrollohet plotësisht nga zhvilluesi, nga API-ja e unifikuar të nivellit meta të ofruar nga biblioteka. Kjo jo vetëm që e bën teknisht të mundur implementimin e Handly në implementimet ekzistuese, por gjithashtu i jep zhvilluesit të modelit të ri një liri të konsiderueshme në dizajnimin e API-së.
Fleksibiliteti ka aspekte të tjera. Për shembull, Handly pothuajse nuk vendos kufizime në strukturën e modelit dhe mund të përdoret si për modelimin e gjuhëve me qëllim të përgjithshëm, ashtu edhe për gjuhë specifike për fushën. Kur ndërtova strukturën e skedarit burimor, Handly nuk parashtrojnë ndonjë formë të caktuar përpara AST dhe në parim nuk kërkon as ekzistencën e AST-së, duke siguruar kështu përputhshmëri me praktikisht çfarëdo mekanizmi analize sintaksore. Së fundmi, Handly mbështet integrimin e plotë me hapësirën e punës Eclipse, por gjithashtu mund të punojë direkt me sistemet e skedarëve, falë integrimit me (EFS).
Versioni aktual doli në dhjetor 2016. Edhe pse projekti aktualisht është në fazën e inkubacionit dhe API ende nuk është përfundimisht i përcaktuar, Handly është tashmë i përdorur në dy produkte të mëdha komerciale që kanë guxuar të veprojnë si "adopterë të hershëm", dhe, duhet thënë, për momentin nuk po e pendohen për këtë.
Siç u përmend më lart, njëri nga këto produkte është 1C:Enterprise Development Tools, ku Handly përdoret që nga fillimi për modelimin e elementeve të strukturës më të lartë të gjuhëve të tilla si 1C:Enterprise, si gjuha e integruar e programimit dhe gjuha e pyetjeve. Produkti tjetër është më pak i njohur për publikun e gjerë. Ky është , një ambient i integruar për projektimin e procesorëve me qëllim të veçantë (application-specific instruction-set processor, ASIP), i përdorur si brenda vetë kompanisë çeke Codasip, ashtu edhe nga klientët e saj, mes të cilëve , , , . Codasip përdor Handly në prodhim që nga viti 2015, duke filluar nga versioni Handly 0.2. Lëshimi më i fundit i Codasip Studio aktualisht përdor versionin 0.5, i cili u publikua në qershor 2016. Ondřej Ilčík, që drejton zhvillimin e IDE në Codasip, është në kontakt me projektin, duke ofruar një feedback shumë të rëndësishëm nga një “adopter i jashtëm”. Ai arriti madje të gjejë pak kohë të lirë për t’u angazhuar drejtpërdrejt në zhvillimin e projektit, duke implementuar një nivel UI (~ 4000 rreshta kodi) për një nga shembujt e Handly, modelin Java. Informacione më të detajuara “nga burimi” mbi përdorimin e Handly nga adopterët mund të merren në faqen project.
Shpresojmë që pas lëshimit të versionit 1.0 me garancinë e stabilitetit të API dhe daljes së projektit nga fase inkubimi, Handly do të ketë adoptera të rinj. Ndërkohë, projekti vazhdon testimin dhe përmirësimin e mëtejshëm të API, duke lëshuar dy “rilisime të mëdha” në vit – në qershor (në të njëjtën datë si rilisimi i Eclipse) dhe në dhjetor, duke ofruar një program të parashikueshëm, mbi të cilin adopterët mund të mbështeten. Mund të shtojmë gjithashtu se norma e “defekteve” të projektit mbetet në një nivel të ulët të qëndrueshëm dhe Handly funksionon në mënyrë të besueshme në produktet e adopterëve të hershëm që nga versionet e para. Për njohje më të thellë me Eclipse Handly, mund të përdorni dhe .
Burimi: habr.com
