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
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish