Talán, már rég nem igényel különösebb bemutatást. Sokan ismerik az Eclipse-t az Eclipse Java fejlesztőeszközöknek köszönhetően (). A legtöbb fejlesztő ezt a népszerű nyílt forráskódú Java IDE-t asszociálja az „Eclipse” szóval. Az Eclipse azonban egyszerre bővíthető platform a fejlesztői eszközök integrálására (Eclipse Platform), valamint számos, az erre épülő IDE, köztük a JDT. Az Eclipse egyszerre az Eclipse Project, az Eclipse Platform és a JDT fejlesztését koordináló legfelső szintű projekt, valamint az Eclipse SDK, a fejlesztés eredménye. Végül, az Eclipse egy nyílt forráskódú alapítvány hatalmas projektközösséggel, amelyek nem mindegyike Java nyelven íródott vagy kapcsolódik fejlesztői eszközökhöz (például projektekhez). и ). Az Eclipse világa nagyon változatos.
Ebben a jellegét tekintve áttekintő cikkben megpróbáljuk megvizsgálni az Eclipse architektúra néhány alapját, mint integrált fejlesztői eszközök építésének platformját, és kezdeti képet adunk az Eclipse összetevőiről, amelyek a technológia alapját képezik. platform az „új Configurator” 1C: Enterprise számára. . Természetesen egy ilyen áttekintés elkerülhetetlenül felületes és meglehetősen korlátozott, többek között azért, mert nem csak az Eclipse fejlesztőire, mint célközönségére összpontosítunk. Reméljük azonban, hogy még a tapasztalt Eclipse fejlesztők is találhatnak majd érdekes információkat a cikkben. Például beszélni fogunk az Eclipse egyik titkáról, egy viszonylag új és kevéssé ismert projektről , amelyet az 1C alapított és támogatott.
Bevezetés az Eclipse architektúrába
Először nézzük meg az Eclipse architektúra néhány általános vonatkozását a példa segítségével (JDT). A JDT példakénti választása nem véletlen. Ez az első integrált fejlesztői környezet, amely megjelenik az Eclipse-ben. Más *DT Eclipse projektek, mint például az Eclipse C/C++ Development Tooling (CDT), később jöttek létre, és mind az alapvető építészeti elveket, mind az egyedi forráskódrészleteket a JDT-től kölcsönözték. A JDT-ben lefektetett architektúra alapjai a mai napig relevánsak szinte minden, az Eclipse Platformra épülő IDE esetében, beleértve az 1C:Enterprise Development Tools-t is.
Mindenekelőtt meg kell jegyezni, hogy az Eclipse-t meglehetősen világos építészeti rétegzettség jellemzi, a nyelvtől független funkcionalitás elválasztásával a specifikus programozási nyelvek támogatására tervezett funkcióktól, valamint az UI-független „mag” komponensek elválasztásával a kapcsolódó összetevőktől. támogató felhasználói felülettel.
Így az Eclipse Platform közös, nyelvfüggetlen infrastruktúrát határoz meg, a Java fejlesztőeszközök pedig egy teljes értékű Java IDE-t adnak az Eclipse-hez. Az Eclipse Platform és a JDT is több komponensből áll, amelyek mindegyike vagy egy UI-független „maghoz”, vagy egy UI réteghez tartozik (1. ábra).
Rizs. 1. Eclipse Platform és JDT
Soroljuk fel az Eclipse Platform fő összetevőit:
- Runtime — Meghatározza a beépülő modul infrastruktúráját. Az Eclipse-t a moduláris felépítés jellemzi. Lényegében az Eclipse "bővítési pontok" és "kiterjesztések" gyűjteménye.
- Munkaterület — Egy vagy több projektet kezel. A projekt mappákból és fájlokból áll, amelyek közvetlenül a fájlrendszerhez vannak hozzárendelve.
- Standard Widget Toolkit (SWT) - Az operációs rendszerbe integrált alapvető felhasználói felületelemeket biztosít.
- JFace — Számos SWT-re épített felhasználói felület-keretrendszert biztosít.
- Workbench — Meghatározza az Eclipse UI paradigmáját: szerkesztők, nézetek, perspektívák.
El kell mondanunk, hogy az Eclipse Platform számos más hasznos összetevőt is kínál az integrált fejlesztői eszközök felépítéséhez, beleértve a Debug-ot, a Compare-t, a Search-ot és a Team-et. Külön említést érdemel a JFace Text – a forráskód „intelligens szerkesztőinek” építésének alapja. Sajnos ezen komponensek, valamint az UI réteg összetevőinek felületes vizsgálata sem lehetséges e cikk keretein belül, ezért a szakasz hátralévő részében a főbb „mag” összetevők áttekintésére szorítkozunk. az Eclipse Platform és a JDT.
Core Runtime
Az Eclipse plugin infrastruktúra alapja és a projekt biztosítja . Minden Eclipse beépülő modul egy OSGi csomag. Az OSGi specifikáció különösen a verziószámítás és a függőségi feloldás mechanizmusait határozza meg. Ezen szabványos mechanizmusok mellett az Equinox bemutatja a koncepciót bővítési pontok. Mindegyik beépülő modul meghatározhatja a saját kiterjesztési pontjait, és további funkciókat („bővítményeket”) is bevezethet a rendszerbe az ugyanazon vagy más bővítmények által meghatározott kiterjesztési pontok használatával. Az OSGi és az Equinox mechanizmusok részletes leírása túlmutat e cikk hatókörén. Csak annyit jegyezzünk meg, hogy az Eclipse modularizálása teljes (bármely alrendszer, beleértve a Runtime-ot is, egy vagy több beépülő modulból áll), és az Eclipse-ben szinte minden kiterjesztés. Sőt, ezek az alapelvek már jóval az OSGi bevezetése előtt beágyazódtak az Eclipse architektúrába (akkoriban saját technológiát használtak, ami nagyon hasonlít az OSGi-hez).
Alapvető munkaterület
Szinte minden, az Eclipse Platformra épülő integrált fejlesztői környezet működik az Eclipse munkaterülettel. Általában ez a munkaterület tartalmazza az IDE-ben fejlesztett alkalmazás forráskódját. A munkaterület közvetlenül a fájlrendszerhez van leképezve, és mappákat és fájlokat tartalmazó projektekből áll. Ezeket a projekteket, mappákat és fájlokat hívják erőforrások munkaterület. Az Eclipse munkaterület-megvalósítása gyorsítótárként szolgál a fájlrendszerhez képest, amely lehetővé teszi az erőforrásfa bejárásának jelentős felgyorsítását. Ezen túlmenően a munkaterület számos további szolgáltatást kínál, beleértve и .
A Core Resources összetevő (org.eclipse.core.resources beépülő modul) felelős a munkaterület és az erőforrások támogatásáért. Ez az összetevő különösen programozott hozzáférést biztosít az űrlap munkaterületéhez erőforrás modellek. Ahhoz, hogy hatékonyan dolgozhassanak ezzel a modellel, az ügyfeleknek egyszerű módra van szükségük az erőforrásra mutató hivatkozás bemutatására. Ebben az esetben kívánatos lenne elrejteni azt az objektumot, amely közvetlenül tárolja az erőforrás állapotát a modellben a kliens hozzáférés elől. Ellenkező esetben, például egy fájl törlése esetén, a kliens továbbra is tárolhat egy olyan objektumot, amely már nem szerepel a modellben, az ebből eredő problémákkal. Az Eclipse ezt a problémát egy ún fogantyú forrás. A fogantyú kulcsként működik (csak a munkaterületen lévő erőforrás elérési útját ismeri), és teljes mértékben felügyeli a belső modellobjektumhoz való hozzáférést, amely közvetlenül tárol információkat az erőforrás állapotáról. Ez a kialakítás a minta egy változata .
Rizs. A 2. ábra a Handle/Body idiómát szemlélteti az erőforrásmodellre alkalmazva. Az IResource interfész egy erőforrás leíróját képviseli, és egy API, ellentétben az ezt az interfészt megvalósító Resource osztállyal és a törzset képviselő ResourceInfo osztállyal, amelyek nem API-k. Hangsúlyozzuk, hogy a kezelő csak az erőforrás elérési útját ismeri a munkaterület gyökeréhez viszonyítva, és nem tartalmaz hivatkozást az erőforrás információira. Az erőforrás-információs objektumok egy úgynevezett „elemfát” alkotnak. Ez az adatstruktúra teljesen materializálódik a memóriában. A leírónak megfelelő erőforrás-információs példány megkereséséhez az elemfát az adott leíróban tárolt útvonalnak megfelelően kell bejárni.
Rizs. 2. IResource és ResourceInfo
Mint később látni fogjuk, az erőforrás-modell (nevezhetjük fogantyú-alapúnak) alapkialakítását az Eclipse más modelleknél is alkalmazza. Most soroljunk fel néhány jellegzetes tulajdonságot ennek a kialakításnak:
- A fogantyú egy értékobjektum. Az értékobjektumok olyan megváltoztathatatlan objektumok, amelyek egyenlősége nem azonosságon alapul. Az ilyen objektumok biztonságosan használhatók kulcsként hashed tárolókban. A kezelő több példánya hivatkozhat ugyanarra az erőforrásra. Összehasonlításukhoz az egyenlő (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, a "kulcs", az erőforrás elérési útja).
- A fogantyú olyan erőforrásra hivatkozhat, amely nem létezik (vagy olyan erőforrásra, amelyet még nem hoztak létre, vagy olyan erőforrásra, amelyet már töröltek). Egy erőforrás megléte az IResource.exists() metódussal ellenőrizhető.
- Egyes műveletek csak magában a kezelőben tárolt információk alapján hajthatók végre (ún. csak kezelő műveletek). Ilyen például az IResource.getParent(), a getFullPath() stb. Az erőforrásnak nem kell léteznie ahhoz, hogy egy ilyen művelet sikeres legyen. Azok a műveletek, amelyek sikeréhez erőforrás szükséges, CoreExceptiont dobnak, ha az erőforrás nem létezik.
Az Eclipse hatékony mechanizmust biztosít a munkaterület-erőforrás-változások értesítésére (3. ábra). Az erőforrások az Eclipse IDE-n belül végrehajtott műveletek vagy a fájlrendszerrel való szinkronizálás eredményeként változhatnak. Az értesítésekre feliratkozó ügyfelek mindkét esetben „erőforrás-delták” formájában kapnak részletes tájékoztatást a változásokról. A delta egy munkaterület-erőforrás- (al-)fa két állapota közötti változásokat írja le, és maga is egy fa, amelynek mindegyik csomópontja egy erőforrás változását írja le, és a következő szinten lévő delta-listát tartalmazza, amely leírja az alárendelt erőforrások változásait.
Rizs. 3. IResourceChangeEvent és IResourceDelta
Az erőforrás-deltákon alapuló értesítési mechanizmus a következő jellemzőkkel rendelkezik:
- Egyetlen változtatást és sok változást ugyanazzal a struktúrával írunk le, mivel a delta a rekurzív kompozíció elve alapján épül fel. Az előfizetői ügyfelek rekurzív leereszkedéssel dolgozhatják fel az erőforrás-módosítási értesítéseket a deltafán keresztül.
- A delta teljes információt tartalmaz az erőforrás változásairól, beleértve annak mozgását és/vagy a hozzá tartozó „jelölők” változásait (például a fordítási hibákat jelölőkként ábrázoljuk).
- Mivel az erőforráshivatkozások a kezelőn keresztül történnek, a delta természetesen hivatkozhat egy távoli erőforrásra.
Amint azt hamarosan látni fogjuk, az erőforrásmodell változás értesítési mechanizmus tervezésének fő összetevői más, fogantyú alapú modelleknél is relevánsak.
JDT Core
Az Eclipse munkaterület erőforrásmodellje alapvető nyelv-agnosztikus modell. A JDT Core komponens (plugin org.eclipse.jdt.core) API-t biztosít a munkaterület szerkezetének Java szemszögből történő navigálásához és elemzéséhez, az úgynevezett „Java modell” (Java modell). Ez az API Java-elemekkel van meghatározva, szemben az alapul szolgáló erőforrásmodell API-val, amely mappák és fájlok szerint van meghatározva. A Java elemfa fő interfészeit az ábra mutatja. 4.
Rizs. 4. Java modellelemek
A Java modell ugyanazt a kezelő/törzs idiómát használja, mint az erőforrásmodell (5. ábra). Az IJavaElement a fogantyú, a JavaElementInfo pedig a törzs szerepét tölti be. Az IJavaElement interfész minden Java elemre közös protokollt határoz meg. Néhány metódusa csak kezelhető: getElementName(), getParent() stb. A JavaElementInfo objektum tárolja a megfelelő elem állapotát: annak szerkezetét és attribútumait.
Rizs. 5. IJavaElement és JavaElementInfo
A Java-modellnek van némi különbsége az alapvető fogantyú/test kialakítás megvalósításában az erőforrásmodellhez képest. Ahogy fentebb megjegyeztük, az erőforrásmodellben az elemfa, amelynek csomópontjai erőforrás-információs objektumok, teljes egészében a memóriában található. De a Java-modell lényegesen nagyobb elemszámú lehet, mint az erőforrásfa, mert a .java és .class fájlok belső szerkezetét is reprezentálja: típusokat, mezőket és metódusokat.
Annak elkerülése érdekében, hogy a teljes elemfa teljesen materializálódjon a memóriában, a Java-modell megvalósítása az eleminformációk korlátozott méretű LRU gyorsítótárát használja, ahol a kulcs a handle IJavaElement. az eleminformációs objektumok igény szerint jönnek létre az elemfa navigálása közben. Ebben az esetben a legritkábban használt elemek kikerülnek a gyorsítótárból, és a modell memóriafogyasztása a megadott gyorsítótár méretre korlátozódik. Ez a fogantyú alapú tervezés másik előnye, amely teljesen elrejti az ilyen implementációs részleteket a kliens kódja elől.
A Java elemek változásainak értesítési mechanizmusa általában hasonló a munkaterület-erőforrások változásainak nyomon követésének fentebb tárgyalt mechanizmusához. A Java-modell változásait figyelni kívánó kliens feliratkozik az értesítésekre, amelyek egy IJavaElementDeltát tartalmazó ElementChangedEvent objektumként jelennek meg (6. ábra).
Rizs. 6. ElementChangedEvent és IJavaElementDelta
A Java-modell nem tartalmaz információkat a metódustörzsekről vagy a névfeloldásról, így a Java nyelven írt kód részletes elemzéséhez a JDT Core egy további (nem kezelő alapú) modellt biztosít: (absztrakt szintaxisfa, AST). Az AST a forrásszöveg elemzésének eredményét jelenti. Az AST csomópontok megfelelnek a forrásmodul szerkezetének elemeinek (deklarációk, operátorok, kifejezések stb.), és információkat tartalmaznak a megfelelő elem koordinátáiról a forrásszövegben, valamint (opcióként) információkat a névfeloldásról a hivatkozások formája ún kötések. A kötések olyan objektumok, amelyek a fordító által ismert elnevezett entitásokat képviselnek, például típusokat, metódusokat és változókat. Ellentétben az AST csomópontokkal, amelyek egy fát alkotnak, az összerendelések támogatják a kereszthivatkozásokat, és általában grafikont alkotnak. Az ASTNode absztrakt osztály az összes AST csomópont közös alaposztálya. Az ASTNode alosztályok a Java nyelv specifikus szintaktikai konstrukcióinak felelnek meg.
Mivel a szintaktikai fák jelentős mennyiségű memóriát fogyaszthatnak, a JDT csak egy AST gyorsítótárat tárol az aktív szerkesztő számára. A Java-modelltől eltérően az AST-t jellemzően "köztes", "ideiglenes" modellnek tekintik, amelynek elemeire az ügyfelek nem hivatkozhatnak az AST létrehozásához vezető művelet kontextusán kívül.
A felsorolt három modell (Java modell, AST, kötések) együttesen képezi az alapját az „intelligens fejlesztőeszközök” JDT-ben való felépítésének, beleértve a hatékony Java szerkesztőt különféle „segítőkkel”, a forráskód feldolgozására szolgáló különféle műveleteket (beleértve az importlista rendszerezését is). nevek és formázás a testreszabott stílusnak megfelelően), keresési és átalakítási eszközök. Ebben az esetben a Java modell különleges szerepet játszik, mivel ez szolgál alapul a fejlesztés alatt álló alkalmazás szerkezetének vizuális megjelenítéséhez (például a Package Explorer, Outline, Search, Call Hierarchy, ill. Type Hierarchy).
Az 1C:Enterprise Developments Toolsban használt Eclipse összetevők
ábrán. A 7. ábra azokat az Eclipse összetevőket mutatja, amelyek az 1C:Enterprise Development Tools technológiai platformjának alapját képezik.
Rizs. 7. Az Eclipse az 1C:Enterprise Development Tools platformja
Eclipse platform alapvető infrastruktúrát biztosít. Az előző részben megvizsgáltuk ennek az infrastruktúrának néhány aspektusát.
(EMF) általános eszközt nyújt a strukturált adatok modellezésére. Az EMF integrálva van az Eclipse Platformmal, de külön-külön is használható normál Java alkalmazásokban. Az Eclipse új fejlesztői gyakran már jól ismerik az EMF-et, bár még nem értik teljesen az Eclipse Platform fortélyait. Az ilyen jól megérdemelt népszerűség egyik oka az univerzális kialakítás, amely többek között egy egységes metaszintű API-t is tartalmaz, amely lehetővé teszi bármely EMF-modellel általánosságban történő munkát. Az EMF által biztosított modellobjektumok alapvető implementációi és a metamodellre épülő modellkódot generáló alrendszer jelentősen növeli a fejlesztés sebességét és csökkenti a hibák számát. Az EMF a modellek sorozatosítására, a modell változásainak nyomon követésére és még sok másra is tartalmaz mechanizmusokat.
Mint minden igazán általános célú eszköz, az EMF is alkalmas a modellezési problémák széles körének megoldására, de egyes modellosztályok (például a fentebb tárgyalt fogantyús modellek) speciális modellező eszközöket igényelhetnek. Az EMF-ről beszélni hálátlan feladat, különösen egy cikk korlátozott keretein belül, mivel ez egy külön könyv témája, és egy meglehetősen vastag. Csak annyit jegyezzünk meg, hogy az EMF mögött meghúzódó magas színvonalú általánosítási rendszer lehetővé tette a modellezéssel foglalkozó projektek egész sorának megszületését, amelyek a felső szintű projektben szerepelnek. magával az EMF-fel együtt. Az egyik ilyen projekt az Eclipse Xtext.
"szövegmodellező" infrastruktúrát biztosít. Xtext használ a forrásszöveg és az EMF elemzéséhez az eredményül kapott ASG (absztrakt szemantikai gráf, amely lényegében az AST és a kötések kombinációja) megjelenítéséhez, amelyet „szemantikai modellnek” is neveznek. Az Xtext által modellezett nyelv nyelvtanát az Xtext saját nyelvén írja le. Ez nem csak nyelvtani leírás létrehozását teszi lehetővé az ANTLR számára, hanem egy AST szerializációs mechanizmus (azaz az Xtext elemzőt és unparsert is), környezeti tippet és számos más nyelvi összetevőt is biztosít. Másrészt az Xtextben használt nyelvtani nyelv kevésbé rugalmas, mint például az ANTLR nyelvtani nyelve. Ezért néha szükség van az implementált nyelv Xtextre való „hajlítására”, ami általában nem jelent problémát, ha a nulláról fejlesztünk nyelvet, de előfordulhat, hogy elfogadhatatlan a már kialakult szintaxisú nyelvek esetében. Ennek ellenére az Xtext jelenleg az Eclipse legkiforrottabb, leggazdagabb és legsokoldalúbb eszköze a programozási nyelvek és fejlesztőeszközök létrehozására. Különösen ideális eszköz a gyors prototípuskészítéshez (domain-specifikus nyelv, DSL). A fent említett ANTLR-en és EMF-en alapuló „nyelvi magon” kívül az Xtext számos hasznos, magasabb szintű komponenst kínál, beleértve az indexelési mechanizmusokat, a növekményes felépítést, az „okos szerkesztőt” és még sok minden mást, de kihagyja a kezelhetőséget. alapú nyelvi modellek. Az EMF-hez hasonlóan az Xtext is egy külön könyvhöz méltó téma, amelynek minden képességéről most még csak röviden is beszélhetünk.
Az 1C:Enterprise Development Tools aktívan használja magát az EMF-et és számos más Eclipse Modeling projektet is. Különösen az Xtext az egyik alapja az olyan 1C:Enterprise nyelvek fejlesztői eszközeinek, mint a beépített programozási nyelv és a lekérdezési nyelv. Ezeknek a fejlesztőeszközöknek egy másik alapja az Eclipse Handly projekt, amelyről részletesebben is szó lesz (a felsorolt Eclipse komponensek közül még mindig ez a legkevésbé ismert).
, az Eclipse Technology felső szintű projekt egyik alprojektje, amely az 1C által 2014-ben az Eclipse Foundation számára nyújtott kezdeti kóddal való hozzájárulás eredményeként jött létre. Azóta az 1C továbbra is támogatja a projekt fejlesztését: A Handly committerek a cég alkalmazottai. A projekt kicsi, de meglehetősen egyedi rést foglal el az Eclipse-ben: fő célja a fogantyús modellek fejlesztésének támogatása.
A fogantyú alapú modellek alapvető felépítési elveit, mint például a fogantyú/test idióma, fentebb tárgyaltuk az erőforrás-modell és a Java-modell példaként való felhasználásával. Azt is megjegyezte, hogy mind az erőforrás-modell, mind a Java-modell fontos alapjai az Eclipse Java fejlesztői eszközöknek (JDT). És mivel szinte minden *DT Eclipse projekt a JDT-hez hasonló architektúrával rendelkezik, nem lenne túlzás azt állítani, hogy sok, ha nem az összes Eclipse Platform tetejére épülő IDE alapja a kezelőelemekre épülő modell. Például az Eclipse C/C++ Development Tooling (CDT) rendelkezik egy fogantyú alapú C/C++ modellel, amely ugyanazt a szerepet játszik a CDT architektúrában, mint a Java modell a JDT-ben.
A Handly előtt az Eclipse nem kínált speciális könyvtárakat a fogantyú alapú nyelvi modellek készítésére. A jelenleg létező modellek főként a Java modellkód közvetlen adaptálásával jöttek létre (más néven másolás/beillesztés), azokban az esetekben, amikor megengedi Eclipse Public License (EPL). (Nyilván ez általában nem jogi probléma mondjuk magának az Eclipse-nek a projektjeinél, de a zárt forráskódú termékeknél nem.) A benne rejlő véletlenszerűségen túl ez a technika jól ismert problémákat is felvet: a hibákhoz való alkalmazkodás során bevezetett kódduplikáció, stb. A legrosszabb az, hogy az így létrejövő modellek „önmagukban lévő dolgok” maradnak, és nem használják ki az egységesítés lehetőségét. De a fogantyú alapú nyelvi modellek közös fogalmainak és protokolljainak elkülönítése a velük való munkavégzéshez újrafelhasználható komponensek létrehozásához vezethet, hasonlóan ahhoz, ami az EMF esetében történt.
Nem arról van szó, hogy az Eclipse nem értette ezeket a kérdéseket. Még 2005-ben , összefoglalva a CDT prototípus fejlesztésének tapasztalatait, a nyelvi modellek közös infrastruktúrájának létrehozásának szükségessége, beleértve a fogantyúalapú modelleket is. Ám, ahogy az gyakran megesik, a magasabb prioritású feladatok miatt ezeknek az elképzeléseknek a megvalósítása soha nem jutott el. Mindeközben a *DT-kód faktorizálása még mindig az egyik fejletlen téma az Eclipse-ben.
Bizonyos értelemben a Handly projekt megközelítőleg ugyanazokat a problémákat hivatott megoldani, mint az EMF, de kezelőelemekre épülő modellekre, és elsősorban nyelviekre (vagyis valamilyen programozási nyelv szerkezetének elemeit reprezentálva). A Handly tervezése során kitűzött fő célok az alábbiak:
- A témakör főbb absztrakcióinak azonosítása.
- Az erőfeszítések csökkentése és a fogantyú alapú nyelvi modellek megvalósításának minőségének javítása a kód újrafelhasználásával.
- Egységes metaszintű API biztosítása a kapott modellekhez, lehetővé téve olyan közös IDE komponensek létrehozását, amelyek nyelvi leíró alapú modellekkel működnek.
- Rugalmasság és méretezhetőség.
- Integráció Xtext-el (külön rétegben).
A gyakori fogalmak és protokollok kiemelése érdekében a nyelvi leíró alapú modellek meglévő implementációit elemeztük. A Handly által biztosított főbb interfészek és alapvető megvalósítások az ábrán láthatók. 8.
Rizs. 8. A Handly elemek közös felületei és alapvető megvalósításai
Az IElement interfész egy elem fogantyúját képviseli, és minden Handly-alapú modell elemében közös. Az absztrakt osztály Element az általánosított fogantyú/test mechanizmust valósítja meg (9. ábra).
Rizs. 9. IEelem és általános fogantyú/test megvalósítás
Ezenkívül a Handly egy általánosított mechanizmust biztosít a modellelemek változásainak értesítésére (10. ábra). Mint látható, nagyjából hasonló az erőforrás-modellben és a Java-modellben megvalósított értesítési mechanizmusokhoz, és az IElementDelta-t használja az elemváltozási információk egységes megjelenítésére.
Rizs. 10. A Handly értesítési mechanizmus általános felületei és alapvető megvalósításai
A fentebb tárgyalt Handly rész (9. és 10. ábra) szinte bármilyen fogantyús modell ábrázolására használható. Az alkotáshoz nyelvi modellek, a projekt további funkcionalitást kínál - különösen a forrásszöveg-struktúra elemeihez közös felületeket és alapvető megvalósításokat, az ún. forráselemek (8. ábra). Az ISourceFile felület egy forrásfájlt, az ISourceConstruct pedig a forrásfájl egy elemét képviseli. A SourceFile és SourceConstruct absztrakt osztályok általánosított mechanizmusokat valósítanak meg a forrásfájlokkal és azok elemeivel való munkavégzés támogatására, például a szöveges pufferekkel való munkavégzés, a forrásszöveg elemeinek koordinátáihoz való kötődés, a modellek egyeztetése a munkamásolat puffer aktuális tartalmával. stb. Ezeknek a mechanizmusoknak a megvalósítása általában nagy kihívást jelent, és a Handly jelentősen csökkentheti a handly-alapú nyelvi modellek fejlesztésének erőfeszítéseit, ha jó minőségű alapmegvalósításokat biztosít.
A fent felsorolt alapvető mechanizmusokon kívül a Handly infrastruktúrát biztosít szöveges pufferekhez és pillanatképekhez, támogatja a forráskód-szerkesztőkkel való integrációt (beleértve az Xtext szerkesztővel való azonnali integrációt), valamint néhány gyakori felhasználói felület-összetevőt, dolgozzon forráskód-szerkesztőkkel. Kézenfekvő modellek, mint például az outline framework. Képességeinek illusztrálására a projekt számos példát mutat be, beleértve a Java-modell Handly-ben való megvalósítását. (A Java-modell JDT-ben való teljes megvalósításához képest ezt a modellt szándékosan leegyszerűsítették a jobb áttekinthetőség érdekében.)
Amint azt korábban megjegyeztük, a Handly kezdeti tervezése és az azt követő fejlesztés során a fő hangsúly a méretezhetőségen és a rugalmasságon volt, és továbbra is az.
A fogantyús modellek elvileg meglehetősen jól méretezhetők „tervezés szerint”. Például a fogantyú/test idióma lehetővé teszi a modell által fogyasztott memória mennyiségének korlátozását. De vannak árnyalatok is. Így a Handly skálázhatósági tesztelése során problémát fedeztek fel az értesítési mechanizmus megvalósításában - amikor nagyszámú elemet megváltoztattak, a delták létrehozása túl sok időt vett igénybe. Kiderült, hogy ugyanez a probléma volt a JDT Java modellben is, amelyből egykor adaptálták a megfelelő kódot. Kijavítottuk a Handly hibáját, és elkészítettünk egy hasonló javítást a JDT-hez, amelyet köszönettel fogadtunk. Ez csak egy példa arra, hogy a Handly bevezetése a meglévő modellmegvalósításokba potenciálisan hasznos lehet, mert ebben az esetben egy ilyen hiba egyetlen helyen javítható.
Ahhoz, hogy a Handly implementálása a meglévő modellmegvalósításokba technikailag megvalósítható legyen, a könyvtárnak jelentős rugalmassággal kell rendelkeznie. A fő probléma a visszamenőleges kompatibilitás fenntartása az API-modellben. Ezt a problémát ben megoldották a fejlesztő által meghatározott és teljes mértékben vezérelt, modellspecifikus API és a könyvtár által biztosított egységes metaszintű API világos elkülönítésével. Ez nemcsak technikailag teszi lehetővé a Handly implementálását a meglévő implementációkba, hanem jelentős szabadságot ad az új modell fejlesztőjének az API tervezése során.
A rugalmasságnak más vonatkozásai is vannak. Például a Handly szinte semmilyen korlátozást nem ír elő a modell szerkezetére vonatkozóan, és használható mind az általános célú, mind a tartományspecifikus nyelvek modellezésére. A forrásfájl szerkezetének felépítése során Handly nem ír elő semmilyen konkrét AST-megjelenítési formát, és elvileg nem is követeli meg magának az AST-nek a jelenlétét, így biztosítja a kompatibilitást szinte minden elemzési mechanizmussal. Végül, a Handly támogatja a teljes integrációt az Eclipse munkaterülettel, de közvetlenül is működhet fájlrendszerekkel, köszönhetően a (EFS).
Jelenlegi verzió 2016 decemberében jelent meg. Annak ellenére, hogy a projekt jelenleg inkubációs állapotban van, és az API-t még nem sikerült véglegesen kijavítani, a Handly-t már használják két nagy kereskedelmi termékben, amelyek vállalták a kockázatot, hogy „korai alkalmazóként” lépnek fel, és meg kell mondanom, még ne bánd meg.
Mint fentebb említettük, az egyik ilyen termék az 1C:Enterprise Development Tools, ahol a Handly-t a kezdetektől fogva az ilyen 1C:Enterprise nyelvek magas szintű struktúrájának elemeinek modellezésére használják, mint a beépített programozási nyelv és a lekérdezési nyelv. . Egy másik termék kevésbé ismert a nagyközönség számára. Ez , az alkalmazás-specifikus utasításkészlet-processzor (ASIP) integrált tervezési környezete, amelyet magán a Codasip cseh vállalaton belül és ügyfelei is használnak, beleértve , , , . A Codasip 2015 óta használja a Handlyt a termelésben, a Handly 0.2-es verziójától kezdve. A Codasip Studio legújabb kiadása a 0.5-ös verziót használja, amely 2016 júniusában jelent meg. Ondřej Ilčík, aki a Codasip IDE fejlesztését vezeti, kapcsolatban áll a projekttel, és létfontosságú visszajelzést ad a „harmadik fél elfogadója” nevében. Még a projekt fejlesztésében való közvetlen részvételre is talált egy kis szabadidőt, egy UI réteget (~4000 kódsor) implementált az egyik Handly-példához, egy Java modellhez. Részletesebb, első kézből származó információk a Handly elfogadók általi használatáról a oldalon találhatók projekt.
Reméljük, hogy az API stabilitását garantáló 1.0-s verzió megjelenése és a projekt inkubációs állapotból való kilépése után a Handlynek új elfogadói lesznek. Eközben a projekt folytatja az API tesztelését és továbbfejlesztését, évente két "nagy" kiadást adnak ki – júniusban (ugyanaz a dátum, mint az egyidejű Eclipse kiadás) és decemberben, így kiszámítható ütemezést biztosítanak, amelyre az alkalmazók támaszkodhatnak. Hozzátehetjük azt is, hogy a projekt „hibaaránya” folyamatosan alacsony szinten marad, és a Handly a legelső verziók óta megbízhatóan dolgozik a korai alkalmazók termékeiben. Az Eclipse Handly további felfedezéséhez használhatja и .
Forrás: will.com