Valószínűleg, már régóta nem szorul különösebb bemutatásra. Sokan ismerik az Eclipse-t az Eclipse Java fejlesztői eszközein keresztül (). Ez a népszerű, nyílt forráskódú Java IDE a legtöbb fejlesztő számára az "Eclipse" szóval társul. Az Eclipse azonban egy bővíthető platform is a fejlesztői eszközök integrálására (Eclipse Platform), valamint számos IDE, amely erre alapozva készült, köztük a JDT. Az Eclipse egy Eclipse Project is, amely a legfelső szintű projekt, amely koordinálja az Eclipse Platform és a JDT fejlesztését, és az Eclipse SDK – amely ennek a fejlesztésnek a kimenete. Végül az Eclipse egy nyílt forráskódú alapítvány hatalmas közösséggel, amelynek nem minden projektje íródott Java nyelven vagy kapcsolódik a fejlesztői eszközökhöz (például projektek és ). Az Eclipse világa nagyon sokszínű.
Ebben a cikkben, amely összefoglaló jellegű, megpróbáljuk áttekinteni az Eclipse architektúrájának néhány alapelvét mint platformnak az integrált fejlesztői eszközök létrehozásához, és alapvető képet adni az Eclipse komponenseiről, amelyek a 1C: Vállalat új konfigurátorához szükséges technológiai platform alapját képezik, . Természetesen ez a megfontolás elkerülhetetlenül felületes és meglehetősen korlátozott lesz, részben azért is, mert a célközönségünk nemcsak Eclipse-fejlesztők. Reméljük azonban, hogy még a tapasztalt Eclipse-fejlesztők is találhatnak az írásban érdekes információkat. Például mesélni fogunk az Eclipse egyik "titkáról", egy viszonylag új és még kevésbé ismert projektről, , amelyet a 1C cég alapított és támogat.
Bevezetés az Eclipse architektúrájába
Először nézzük meg az Eclipse architektúrájának néhány általános aspektusát a (JDT) példáján keresztül. A JDT kiválasztása mint példa nem véletlen. Ez volt az első integrált fejlesztői környezet, amely megjelent az Eclipse-ben. A többi Eclipse *DT projekt, mint például az Eclipse C/C++ Development Tooling (CDT), később készült, és átvették a fő architekturális elveket, valamint egyes forráskód-fragmentumokat a JDT-ből. A JDT-ben lefektetett architekturális alapelvek ma is érvényesek szinte minden, az Eclipse Platformra épülő IDE-re, beleértve az 1C: Vállalat Fejlesztői Eszközeit is.
Először is meg kell említenünk, hogy az Eclipse-re a viszonylag tiszta architekturális rétegződés jellemző, amely elválasztja a nyelvfüggetlen funkciókat a konkrét programozási nyelvek támogatására szolgáló funkcióktól, valamint a UI-független "mag" (core) komponenseket a felhasználói felület támogatásával kapcsolatos komponensektől.
Így az Eclipse Platform meghatározza az általános, nyelvfüggetlen infrastruktúrát, míg a Java fejlesztői eszközök teljes funkcionalitású Java IDE-t adnak az Eclipse-hez. Mind az Eclipse Platform, mind a JDT több komponensből áll, amelyek mindegyike vagy az UI-független "maghoz", vagy az UI réteghez tartozik (1. ábra).
1. ábra. Eclipse Platform és JDT
Soroljunk fel néhány alapvető komponenst az Eclipse Platformból:
- Runtime — Meghatározza a plugin-infrastruktúrát. Az Eclipse jellemzője a moduláris architektúra. Tulajdonképpen az Eclipse egy "kiterjesztési pontok" és "kiterjesztések" gyűjteménye.
- Workspace — Kezel egy vagy több projektet. A projekt mappákból és fájlokból áll, amelyek közvetlenül a fájlrendszeren jelennek meg.
- Standard Widget Toolkit (SWT) — Alapvető felhasználói felület elemeket biztosít, amelyek integrálva vannak az operációs rendszerrel.
- JFace — Számos UI keretrendszert kínál, amelyek az SWT-re épülnek.
- Workbench — Meghatározza az Eclipse UI-paradigmat: szerkesztők, nézetek, perspektívák.
Meg kell említeni, hogy az Eclipse Platform számos más hasznos komponenst is biztosít az integrált fejlesztői eszközök felépítéséhez, köztük a Debug, Compare, Search és Team megoldásokat. Külön említést érdemel a JFace Text – az "intelligens forráskód-szerkesztők" alapja. Sajnos, még a komponensek áttanulmányozása, akárcsak a UI réteg komponenseié, nem lehetséges ebben a cikk keretében, ezért a fejezet hátralévő részében az Eclipse Platform és a JDT alapvető "mag" komponenseinek áttekintésére korlátozódunk.
Core Runtime
Az Eclipse plugin infrastruktúrája az -n alapul, és az projekten keresztül biztosított. Minden Eclipse plugin OSGi-bundle. Az OSGi specifikáció különösen a verziókezelési és függőségi megoldási mechanizmusokat határozza meg. E standard mechanizmusok mellett az Equinox bevezeti a kiterjesztési pontok. Minden plugin meghatározhatja a saját kiterjesztési pontjait, és további funkcionalitást hozhat a rendszerbe („kiterjesztések”), a saját vagy más pluginok által meghatározott kiterjesztési pontok felhasználásával. Az OSGi és az Equinox mechanizmusainak részletesebb leírása már túlmutat ezen a cikken. Érdemes megjegyezni, hogy az Eclipse modularizációja totális jelleget ölt (bármely alrendszer, beleértve a Runtime-ot is, egy vagy több plugint tartalmaz), és szinte minden az Eclipse-ben kiterjesztés. Ezen elveket már jóval az OSGi bevezetése előtt beépítették az Eclipse architektúrájába (akkoriban egy saját technológiát használtak, amely nagymértékben hasonlított az OSGi-hez).
Alap Workspace
Szinte bármely integrált fejlesztési környezet, amely az Eclipse Platformra épül, az Eclipse workspace-szel működik. A workspace általában tartalmazza az IDE-ben fejlesztett alkalmazás forráskódját. A workspace közvetlenül a fájlrendszerre tér vissza, és projekteket tartalmaz, amelyek mappákból és fájlokból állnak. Ezeket a projekteket, mappákat és fájlokat erőforrásoknak hívják. Az Eclipse workspace megvalósítása tulajdonképpen egy gyorsítótárként működik a fájlrendszerrel szemben, ami jelentősen felgyorsítja az erőforrások fáját. Ezen kívül a workspace számos további szolgáltatást is nyújt, beleértve és .
A workspace és erőforrásainak támogatásáért a Core Resources komponens (org.eclipse.core.resources plugin) felelős. Különösen ez a komponens programozási hozzáférést biztosít a workspacehez a következő formában az erőforrások modelljének. E modell hatékony használatához az ügyfeleknek egyszerű módra van szükségük az erőforrásra való hivatkozás reprezentálásához. Fontos lenne, hogy az, a modellben közvetlenül tárolt erőforrás állapotát, elrejtsük az ügyféltől. Ellenkező esetben például, ha egy fájlt törölnek, az ügyfél továbbra is megtarthat egy objektumot, amely már nem létezik a modellben, ami problémákat okozhat. Az Eclipse ezt a feladatot a úgynevezett handle erőforrásaival oldja meg. A handle kulcsként működik (csak az erőforrás munkakörben elfoglalt útvonalát ismeri) és teljes mértékben ellenőrzi a hozzáférést a modell belső objektumához, amely közvetlenül tárolja az erőforrás állapotának információit. Ez a dizájn a .
A 2. ábra a Handle/Body idiomát illusztrálja az erőforrások modelljével kapcsolatban. Az IResource interfész a forráshoz tartozó handle-t képviseli, és API-nak számít, ellentétben a Resource osztállyal, amely megvalósítja ezt az interfészt, valamint a ResourceInfo osztállyal, amely a body-t reprezentálja és nem számít API-nak. Hangsúlyozni kell, hogy a handle csak az erőforráshoz vezető utat ismeri a workspace gyökere szempontjából, és nem tartalmaz hivatkozást a resource info-ra. A resource info objektumok alkotják a „tényezők fáját” (element tree). Ez az adatstruktúra teljes mértékben materializálva van a memóriában. Ahhoz, hogy megtaláljuk a resource info egy példányát, amely megfelel egy adott handle-nek, az element tree-t a handle-ben tárolt útvonal szerint járjuk be.
A 2. ábra. IResource és ResourceInfo
Ahogy azt később látni fogjuk, az erőforrásmodell alapvető tervezése (amit handle-alapúnak nevezhetünk) az Eclipse-ben és más modellekben is használt. Most felsorolunk néhány megkülönböztető jellemzőt ennek a tervezésnek:
- A handle értéktípusú objektum (value object). Az értéktípusú objektumok immutable (nem módosítható) objektumok, amelyek egyenlősége nem az identitáson alapul. Ezeket az objektumokat biztonságosan lehet használni hashelt konténerek kulcsaként. Több handle példány is hivatkozhat ugyanarra az erőforrásra. Összehasonlításukhoz az equals(Object) metódust kell használni.
- A handle meghatározza az erőforrás viselkedését, de nem tartalmaz információt az erőforrás állapotáról (az egyetlen adat, amelyet tárol, az a „kulcs”, az erőforráshoz vezető út).
- A handle hivatkozhat nemlétező erőforrásra (vagy olyan erőforrásra, amely még nem készült el, vagy már törölték). Az erőforrás létezését az IResource.exists() metódussal lehet ellenőrizni.
- Néhány művelet kizárólag a handle-ben tárolt információk alapján valósítható meg (úgynevezett handle-only műveletek). Ilyenek például az IResource.getParent(), getFullPath(), stb. Az erőforrásnak nem szükséges léteznie a művelet sikeres végrehajtásához. Azok a műveletek, amelyek sikeres végrehajtásához szükséges, hogy az erőforrás létezzen, CoreException kivételt dob, ha az erőforrás nem létezik.
Az Eclipse hatékony mechanizmust nyújt a munkaterület erőforrásainak változásairól való értesítéshez (3. ábra). Az erőforrások változhatnak úgy, hogy a folyamatban lévő műveletek a saját Eclipse IDE-jén belül történnek, vagy az fájlrendszerrel való szinkronizálás eredményeként. Mindkét esetben az értesítésekre feliratkozott ügyfelek részletes információkat kapnak a változásokról, amelyek «erőforrás-delták» (resource delta) formájában jelennek meg. A delta a két állapot közötti változásokat írja le (al-)fának, és önmaga is fa szerkezet, amelynek minden csomópontja egy bizonyos erőforrás változását írja le, és egy listát tartalmaz a következő szintű deltákról, amelyek a gyermek erőforrások változásait írják le.
3. ábra. IResourceChangeEvent és IResourceDelta
A deltaalapú értesítési mechanizmus a következő jellemzőkkel rendelkezik:
- Az egyetlen változást és a több változást ugyanazzal a struktúrával írják le, mivel a delta rekurzív kompozíció elve alapján épül fel. Az előfizető ügyfelek rekurzív mélységben kezelhetik az erőforrások változásáról szóló értesítéseket a deltafán.
- A delta teljes információt tartalmaz az erőforrás változásáról, beleértve a helyének megváltoztatását és/vagy a hozzá kapcsolódó «jelölők» (például a fordítási hibák) módosítását.
- Mivel az erőforrásokra hivatkozások a handle-en keresztül történnek, a delta természetesen utalhat távoli erőforrásokra is.
Ahogy hamarosan látni fogjuk, a változások értesítési mechanizmusának fő dizájnelemei relevánsak más handle-alapú modellekre is.
JDT Core
Az Eclipse munkaterület erőforrásmodellje egy alapvető nyelvtől független modell. A JDT Core összetevő (org.eclipse.jdt.core plugin) API-t biztosít a munkaterület struktúrájának navigálásához és elemzéséhez Java szempontból, az úgynevezett «Java modell» (Java model). Ez az API a Java elemek terminológiájában van definiálva, ellentétben az erőforrásmodell alsó szintű API-jával, amely mappák és fájlok terminológiájában van definiálva. A Java elemek fastruktúrájának fő interfészei a 4. ábrán láthatók.
4. ábra. A Java modell elemei
A Java model uses the same handle/body idiom as the resource model (see Fig. 5). IJavaElement is the handle, while JavaElementInfo serves as the body. The IJavaElement interface defines a protocol common to all Java elements. Some of its methods are handle-only: getElementName(), getParent(), etc. The JavaElementInfo object stores the state of the corresponding element: its structure and attributes.
Fig. 5. IJavaElement and JavaElementInfo
The Java model has some differences in implementing the basic handle/body design compared to the resource model. As noted above, the element tree in the resource model, whose nodes are resource info objects, is fully stored in memory. However, the Java model can have a significantly larger number of elements than the resource tree, as it also represents the internal structure of .java and .class files: types, fields, and methods.
To avoid fully materializing the entire element tree in memory, the Java model implementation uses a limited-size LRU cache for element info, where the key is the IJavaElement handle. Element info objects are created on demand as navigation through the element tree occurs. The least frequently used elements are evicted from the cache, keeping the memory consumption of the model constrained to the specified cache size. This is another advantage of the handle-based design, which completely hides such implementation details from client code.
The notification mechanism for changes in Java elements is generally similar to the previously discussed mechanism for tracking changes in the workspace resources. A client wishing to track changes in the Java model subscribes to notifications, which are represented as an ElementChangedEvent object that contains an IJavaElementDelta (see Fig. 6).
Fig. 6. ElementChangedEvent and IJavaElementDelta
The Java model does not contain information about method bodies or name resolution, so for detailed code analysis of Java-written code, JDT Core provides an additional (non-handle-based) model: (absztrakt szintaxisfa, AST). Az AST a forráskód szintaktikai elemzésének eredményét képviseli. Az AST csomópontjai megfelelnek a forrásmodul struktúrájának elemeinek (deklárációk, operátorok, kifejezések stb.), és tartalmazzák az adott elem forráskódban lévő koordinátáit, valamint (opcionálisan) a névadás feloldására vonatkozó információkat, hivatkozások formájában. kötések. A Bindings olyan objektumok, melyek névvel ellátott entitásokat képviselnek, például típusokat, metódusokat és változókat, amelyeket a fordító ismer. Az AST csomópontjaitól eltérően, amelyek fát alkotnak, a bindings keresztreferenciákat támogatnak, és általában gráfot alkotnak. Az absztrakt ASTNode osztály közös alap osztálya minden AST csomópontnak. Az ASTNode alosztályai megfelelnek a Java nyelv bizonyos szintaktikai konstrukcióinak.
Mivel a szintaktikai fák jelentős mennyiségű memóriát fogyaszthatnak, a JDT csak egy AST-t tárol a aktív szerkesztő számára. A Java modellhez képest az AST-t általában „köztes”, „ideiglenes” modellként kezelik, amelyre az ügyfeleknek nem szabad hivatkozniuk az AST létrehozásához vezető műveleten kívül.
A három felsorolt modell (Java modell, AST, bindings) együttesen alkotja az JDT-ben található „intelligens fejlesztőeszközök” alapját, köztük a Java erőteljes szerkesztőjét különféle „segédprogramokkal”, számos forráskód feldolgozási műveletet (például a névimport lista rendezése és a beállított stílusnak megfelelő formázás), keresési és refaktoráló eszközöket. A Java modell különleges szerepet játszik, mivel ez szolgál alapként a fejlesztés alatt álló alkalmazás struktúrájának vizuális ábrázolásához (például a Package Explorer, Outline, Search, Call Hierarchy és Type Hierarchy esetében).
Az Eclipse komponensei, amelyek a 1C:Enterprise Development Tools-hoz használatosak
A 7. ábrán az Eclipse komponensei láthatók, amelyek a technológiai platform alapját képezik a 1C:Enterprise Development Tools számára.
7. ábra. Az Eclipse mint platform a 1C:Enterprise Development Toolshoz
Eclipse Platform az alapinfrastruktúrát biztosítja. Néhány aspektusát ez az infrastruktúrának a korábbi szakaszban már megvizsgáltuk.
(EMF) általános eszközöket biztosít strukturált adatok modellezésére. Az EMF integrálva van az Eclipse Platformmal, de önálló Java alkalmazásokban is használható. Gyakran előfordul, hogy a kezdő Eclipse-fejlesztők jól ismerik az EMF-et, bár még nem értik teljesen az Eclipse Platform finomságait. Az egyik oka a megérdemelt népszerűségnek az egyetemes dizájn, amely többek között egy egységes meta-szintű API-t is magában foglal, lehetővé téve bármely EMF modell általános kezelését. Az EMF által biztosított alapvető megvalósítások a modellen lévő objektumokhoz és a meta-model számára történő kódgenerálási alrendszer jelentősen növeli a fejlesztési sebességet és csökkenti a hibák számát. Emellett az EMF tartalmaz modellek sorosítására, modellváltozások nyomon követésére és még sok másra vonatkozó mechanizmusokat.
Mint bármely igazi univerzális eszköz, az EMF széles spektrumú modellezési feladatok megoldására alkalmas, de egyes modellek osztálya (például a fent tárgyalt handle-alapú modellek) speciálisabb modellező eszközöket igényelhet. Az EMF-ről szólni hálátlan feladat, különösen egyetlen cikk keretein belül, mivel ez külön könyvet érdemelne, méghozzá egy elég vastagot. Megjegyezzük, hogy az EMF alapjául szolgáló minőségi általánosítási rendszer lehetővé tette egy sor projektek létrejöttét, amelyek a modellezésre összpontosítanak, és ezek a felső szintű projekt részei. az EMF mellett. Az egyik ilyen projekt az Eclipse Xtext.
infrastruktúrát biztosít a 'szöveges modellezéshez'. Az Xtext az a forrás szöveg szintaktikai elemzésére és az EMF-re, hogy előállítsa az eredményül kapott ASG-t (absztrakt szemantikai gráf, amely lényegében az AST és a kötődések kombinációja), amelyet "szemantikai modelnek" is neveznek. Az Xtext által modellezett nyelv grammatika leírása az Xtext saját nyelvén történik. Ez lehetővé teszi nemcsak a grammatikai leírás generálását az ANTLR számára, hanem az AST sorosítási mechanizmusának megszerzését is (azaz az Xtext biztosítja mind a parser-t, mind az unparser-t), a kontextus-alapú sugallatot és számos más nyelvi komponenst. Másrészt az Xtext-ben használt grammatika leírási nyelv kevésbé rugalmas az ANTLR grammatika leírási nyelvéhez képest. Ezért néha "meg kell hajlítani" a Xtext által megvalósított nyelvet, ami általában nem probléma, ha egy teljesen új nyelvről van szó, de elfogadhatatlan lehet egy már létező szintaxisú nyelvnél. Ennek ellenére az Xtext a jelenleg legérettebb, funkcionálisan teljes és univerzális eszköz az Eclipse-ben programozási nyelvek és fejlesztési eszközök létrehozásához. Különösen ideális eszköz a gyors prototípus készítéshez. (domain-specific language, DSL). Az ANTLR és az EMF alapú „nyelvi mag” mellett az Xtext számos hasznos, magasabb szintű komponenst biztosít, beleértve az indexálási mechanizmusokat, az inkrementális építést, az „intelligens szerkesztőt” és még sok mást, de figyelmen kívül hagyja a nyelvi handle-alapú modelleket. Az EMF-hez hasonlóan az Xtext is olyan téma, amely egy külön könyvet érdemel, és valószínűleg most még csak felületesen tudunk beszélni minden lehetőségéről.
1C:Enterprise Development Tools aktívan használja mind az EMF-et mint önálló projektet, mind számos más Eclipse Modeling projektet. Különösen az Xtext az alapja azoknak az eszközöknek, amelyek olyan nyelvekhez készült 1C:Enterprise, mint a beépített programozási nyelv és a lekérdező nyelv. Ezeknek a fejlesztési eszközöknek egy másik alapja az Eclipse Handly projekt, amelyre részletesebben is kitérünk (a felsorolt Eclipse komponensek közül ez eddig a legkevésbé ismert).
, az Eclipse Technology felső szintű projektjének alprojektje, amely 2014-ben a 1C cég kezdeti kódhozzájárulásával jött létre az Eclipse Foundation-nél. Azóta a 1C cég folyamatosan támogatja a projekt fejlesztését: a Handly committerei a cég munkavállalói. A projekt kicsi, de elég egyedi rést foglal el az Eclipse-ben: fő célja a handle-alapú modellek fejlesztésének támogatása.
A handle-alapú modellek fő architektúrájának elveit, mint például a handle/body idiomát, fentebb a forrásmodellek és a Java modell példáján keresztül tárgyaltuk. Ott említettük, hogy mind a forrásmodellek, mind a Java modell fontos alapot képez a Eclipse Java fejlesztői eszközök (JDT) számára. Mivel gyakorlatilag minden Eclipse *DT projekt hasonló architektúrával rendelkezik, mint a JDT, nem túlzás azt mondani, hogy a handle-alapú modellek sok, ha nem minden IDE alapját képezik, amelyeket az Eclipse Platformra építettek. Például az Eclipse C/C++ Fejlesztői Eszközkészlete (CDT) rendelkezik egy handle-alapú C/C++ modellel, amely a CDT architektúrájában ugyanezt a szerepet tölti be, mint a Java modell a JDT-ben.
A Handly megjelenése előtt az Eclipse nem kínált speciális könyvtárakat a nyelvi handle-alapú modellek létrehozásához. A jelenlegi modellek többsége főként a Java modell kódjának közvetlen adaptálásával készült (más néven másolás/beillesztés). azokban az esetekben, amikor ez lehetővé teszi az Eclipse Public License (EPL). (Egyértelmű, hogy mondjuk az Eclipse saját projektjei számára ez általában nem jogi problémát jelent, amit nem mondhatunk el a zárt forráskódú termékekről.) A módszer jellegzetes rendszertelensége mellett jól ismert problémákhoz vezet: a kód duplikálásához, a hibákhoz, amelyek az adaptáció során keletkeznek, stb. Ami még rosszabb, hogy az így létrehozott modellek „dolog marad önmagában”, és nem használják ki a már meglévő potenciált az egységesítésre. Pedig a közös fogalmak és protokollok kiemelése a nyelvi handle-alapú modellekhez újrahasználható komponensek létrehozásához vezethetett volna, hasonlóan ahhoz, ahogyan az EMF esetében történt.
Nem mondhatjuk, hogy az Eclipse nem értette ezeket a problémákat. Még 2005-ben , a CDT prototípusának fejlesztési tapasztalatát általánosítva, A közös infrastruktúra megteremtésének szükségessége a nyelvi modellek, beleértve a handle-alapú modelleket is. De, mint gyakran előfordul, a prioritást élvező feladatok miatt végül nem került sor ezen ötletek megvalósítására. Eközben a DT-projektek kódjának faktorálása továbbra is az Eclipse egyik alulfejlesztett témája marad.
Bizonyos értelemben a Handly projekt körülbelül ugyanazokat a feladatokat hivatott megoldani, mint az EMF, de a handle-alapú modellek számára, elsősorban a nyelvi modellekre (azaz a programozási nyelv bizonyos struktúráinak elemeit képviselő modellekre). Az alábbiakban felsoroljuk a Handly tervezésénél kitűzött fő célokat:
- A tárgyterület alapvető absztrakcióinak kiemelése.
- A nyelvi handle-alapú modellek megvalósításának erőfeszítéseinek csökkentése és a minőség javítása a kód újrahasználatával.
- Egy egységesített metaszintű API biztosítása az így létrejövő modellekhez, amely lehetővé teszi a nyelvi handle-alapú modellekkel dolgozó közös IDE komponensek készítését.
- Rugalmasság és skálázhatóság.
- Integráció az Xtext-tel (külön rétegen).
A közös fogalmak és protokollok kiemeléséhez a meglévő handle-alapú nyelvi modellek megvalósításait elemezték. A Handly által biztosított fő interfészek és alap megvalósítások a 8. ábrán láthatók.
8. ábra. Handly közös interfészei és alap megvalósításai
Az IElement interfész reprezentálja az elem handle-jét és közös a Handly alapú modellek összes elemével. Az Element absztrakt osztály a handle/body általános mechanizmusát valósítja meg (9. ábra).
9. ábra. IElement és a handle/body általános megvalósítása
Ezenkívül a Handly egy általánosított értesítési mechanizmust biztosít a modell elemeinek változásairól (10. ábra). Ahogy látható, alapvetően analóg a forrásmodellek és a Java-modellek által megvalósított értesítési mechanizmusokkal, és az IElementDelta-t használja az elem változásairól szóló információ egységesített megjelenítésére.
10. ábra. Handly értesítési mechanizmusának közös interfészei és alap megvalósításai
A fent tárgyalt Handly rész (9. és 10. ábra) gyakorlatilag bármilyen handle-alapú modellek reprezentálására használható. Nyelvi modellek létrehozásához a projekt további funkciókat kínál – különösen a forrás szöveg struktúrájának elemeihez, úgynevezett a nyelvi modellekhez közös interfészeket és alap megvalósításokat. source elements (ábra 8). Az ISourceFile interfész a forrásfájlt, míg az ISourceConstruct a forrásfájl egy elemét képviseli. A SourceFile és SourceConstruct absztrakt osztályok általános mechanizmusokat valósítanak meg a forrásfájlokkal és elemeikkel való munka támogatására, például szövegbufferek kezelése, az elem koordinátáinak kötése a forrás szövegben, a modell egyeztetése a munkamásolat aktuális tartalmával stb. E mechanizmusok megvalósítása általában meglehetősen bonyolult feladat, és a Handly jelentősen csökkentheti a nyelvi handle-alapú modellek fejlesztéséhez szükséges munkát a minőségi alapmegvalósítások biztosításával.
A fent említett alapmechanizmusokon kívül a Handly szövegbufferek és "pillanatképek" (snapshots) infrastruktúráját, a forráskód szerkesztőkkel való integráció támogatását (beleértve a "do-it-yourself" integrációt az Xtext szerkesztőhöz) és néhány általános UI-komponenst is kínál, amelyek Handly-alapú modellekkel működnek, például a vázlatkeretet (outline framework). Lehetőségeik illusztrálására a projekt több példát is bemutat, köztük a Handly-ra épülő Java modell megvalósítását. (Az JDT teljes Java modell megvalósítással összehasonlítva, ez a modell szándékosan valamivel leegyszerűsített a jobb áttekinthetőség érdekében.)
Ahogy korábban említettük, a Handly kezdeti tervezésénél és további fejlesztésénél komoly figyelmet fordítottunk a skálázhatóságra és a rugalmasságra.
Elvileg a handle-alapú modellek "tervezésüknél fogva" jól skálázhatóak. Például a handle/body kifejezés lehetővé teszi a modell által használt memória mennyiségének korlátozását. De vannak finomságok is. A Handly skálázhatósági tesztelésénél egy probléma merült fel a értesítési mechanizmus megvalósításával kapcsolatban – a nagy számú elem megváltoztatásakor a delta létrehozása túl sok időt vett igénybe. Kiderült, hogy ugyanaz a probléma a JDT Java modelljében is fennállt, amelyből az érintett kódot egykor adaptálták. Javítottuk a Handly hibáját, és elkészítettük a hasonló javítást a JDT számára, amelyet köszönettel fogadtak. Ez csupán egy példa arra, hogy a Handly meglévő modellmegvalósításokba való bekapcsolása potenciálisan előnyös lehet, hiszen ebben az esetben egy hibát csak egy helyen lehetne orvosolni.
A Handly integrációjának műszaki lehetőségeihez a könyvtárnak jelentős rugalmassággal kell rendelkeznie. A fő probléma az, hogy megőrizzük a modell API visszafelé kompatibilitását. Ezt a feladatot a fejlesztő által meghatározott és teljesen kontrollált, modell-specifikus API és a könyvtár által biztosított egységes meta-szintű API világos elkülönítésével oldották meg. Ez nem csak lehetővé teszi a Handly integrációját a meglévő implementációkba, hanem jelentős szabadságot is ad az új modell fejlesztőjének az API tervezésében.
A rugalmasságnak más aspektusai is vannak. Például a Handly szinte egyáltalán nem korlátozza a modell struktúráját, és használható általános célú nyelvek, valamint terület-specifikus nyelvek modellezésére is. A forrásfájl struktúrájának megalkotásakor a Handly nem ír elő semmilyen konkrét AST-megjelenítési formát, és elvileg nem is követeli meg az AST létezését, így biztosítva a kompatibilitást szinte bármilyen szintaktikai elemző mechanizmussal. Végül, a Handly teljes körű integrációt támogat az Eclipse munkaterülettel, de közvetlenül a fájlrendszerekkel is képes működni, az integrációnak köszönhetően (EFS).
A jelenlegi verzió 2016 decemberében jelent meg. Annak ellenére, hogy a projekt jelenleg inkubációs szakaszban van és az API végleg még nem rögzített, a Handly-t már használják két nagyobb kereskedelmi termékben, amelyek kockáztatták, hogy "korai elfogadókként" lépjenek fel, és azt kell mondanom, eddig nem bánják.
Mint fentebb említettem, az egyik ilyen termék a 1C:Enterprise Development Tools, ahol a Handly-t már a kezdetektől fogva a 1C vállalati nyelvek, például a beépített programozási nyelv és a lekérdezési nyelv magas szintű struktúráinak modellezésére használják. A másik termék szélesebb közönség számára kevésbé ismert. Ez a , a problémakisérésekhez tervezett processzorok (application-specific instruction-set processor, ASIP) integrált tervezői környezete, amelyet nemcsak a cseh Codasip cég, hanem annak ügyfelei is használnak, köztük , , , . A Codasip 2015 óta használja a Handlyt a gyártásban, kezdve a Handly 0.2 verziójával. A jelenlegi legfrissebb kiadás, a Codasip Studio, a 0.5 verziót használja, amely 2016 júniusában jelent meg. Ondřej Ilčík, aki a Codasip IDE fejlesztését irányítja, kapcsolatban áll a projekttel, biztosítva a „külső adapter” szempontjából kritikus fontosságú visszajelzést. Sőt, sikerült egy kis szabadidőt találnia, hogy közvetlenül részt vegyen a projekt fejlesztésében, és megvalósította a felhasználói felület rétegét (~ 4000 sor kód) az egyik Handly példához, egy Java modellt. Részletesebb információt „első kézből” a Handly használatáról az adapterek által a projekt.
Reméljük, hogy az 1.0 verzió kiadásával, amely garantálja az API stabilitását, és a projekt inkubációs állapotából való kilépésével, új adapterek csatlakoznak a Handlyhoz. Jelenleg a projekt folyamatosan tesztelés alatt áll és az API továbbfejlesztésén dolgozik, évente két „nagy” kiadást adva ki – júniusban (ugyanazon a napon, mint az Eclipse egyidejű kiadása) és decemberben, biztosítva egy kiszámítható ütemtervet, amelyre az adapterek támaszkodhatnak. Továbbá, a projekt „hiba aránya” folyamatosan alacsony szinten van, és a Handly a legelső verzióktól kezdve megbízhatóan működik a korai adapterek termékeiben. A további ismerkedéshez az Eclipse Handlyval használható és .
Forrás: habr.com
