Pengine, kwa muda mrefu tangu sasa hakuna utangulizi maalum. Watu wengi wanajua Eclipse shukrani kwa zana za ukuzaji za Eclipse Java () Ni IDE hii maarufu ya chanzo-wazi cha Java ambayo watengenezaji wengi huhusisha na neno "Eclipse". Walakini, Eclipse ni jukwaa linaloweza kupanuka la kuunganisha zana za ukuzaji (Eclipse Platform), na idadi ya IDE zilizojengwa kwa msingi wake, ikijumuisha JDT. Eclipse ni Mradi wa Eclipse, mradi wa ngazi ya juu ambao unaratibu uundaji wa Jukwaa la Eclipse na JDT, na SDK ya Eclipse, matokeo yaliyowasilishwa ya maendeleo hayo. Hatimaye, Eclipse ni Wakfu wa chanzo huria na jumuiya kubwa ya miradi, ambayo sio yote imeandikwa katika Java au kuhusiana na zana za maendeleo (kwa mfano, miradi. ΠΈ ) Ulimwengu wa Eclipse ni tofauti sana.
Katika nakala hii, ambayo ni muhtasari wa maumbile, tutajaribu kuangalia baadhi ya misingi ya usanifu wa Eclipse kama jukwaa la ujenzi wa zana zilizojumuishwa za maendeleo na kutoa wazo la awali la vifaa vya Eclipse ambavyo vinaunda msingi wa teknolojia. jukwaa la "Configurator mpya" 1C: Enterprise. . Bila shaka, ukaguzi kama huo bila shaka utakuwa wa juu juu na badala yake utakuwa mdogo, ikijumuisha kwa sababu hatuangai wasanidi programu wa Eclipse pekee kama hadhira yetu inayolengwa. Walakini, tunatumai kuwa hata watengenezaji wenye uzoefu wa Eclipse wataweza kupata habari ya kupendeza katika nakala hiyo. Kwa mfano, tutazungumza juu ya moja ya "siri za Eclipse", mradi mpya na usiojulikana sana. , ambayo ilianzishwa na kuungwa mkono na 1C.
Utangulizi wa Usanifu wa Eclipse
Hebu kwanza tuangalie baadhi ya vipengele vya jumla vya usanifu wa Eclipse kwa kutumia mfano (JDT). Chaguo la JDT kama mfano sio bahati mbaya. Haya ni mazingira ya kwanza ya maendeleo yaliyounganishwa kuonekana katika Eclipse. Miradi mingine ya *DT Eclipse, kama vile Zana ya Maendeleo ya Eclipse C/C++ (CDT), iliundwa baadaye na kukopa kanuni za msingi za usanifu na vipande vya msimbo wa chanzo binafsi kutoka JDT. Misingi ya usanifu uliowekwa katika JDT ni muhimu hadi leo kwa karibu IDE yoyote iliyojengwa juu ya Jukwaa la Eclipse, ikiwa ni pamoja na 1C: Zana za Maendeleo ya Biashara.
Kwanza kabisa, inapaswa kuzingatiwa kuwa Eclipse ina sifa ya uwekaji wazi wa usanifu, na mgawanyiko wa utendaji unaotegemea lugha kutoka kwa utendaji ulioundwa kusaidia lugha maalum za programu, na mgawanyiko wa sehemu za "msingi" zinazojitegemea za UI kutoka kwa vifaa vinavyohusika. na kiolesura cha mtumiaji kinachounga mkono.
Kwa hivyo, Jukwaa la Eclipse linafafanua miundombinu ya kawaida, isiyo na lugha, na zana za ukuzaji wa Java huongeza IDE kamili ya Java kwenye Eclipse. Jukwaa la Eclipse na JDT linajumuisha vipengele kadhaa, ambavyo kila kimoja ni cha "msingi" unaojitegemea wa UI au safu ya UI (Mchoro 1).
Mchele. 1. Jukwaa la Eclipse na JDT
Wacha tuorodheshe sehemu kuu za Jukwaa la Eclipse:
- Muda wa kukimbia - Inafafanua miundombinu ya programu-jalizi. Eclipse ina sifa ya usanifu wa kawaida. Kimsingi, Eclipse ni mkusanyiko wa "pointi za upanuzi" na "viendelezi".
- Sehemu ya kazi - Inasimamia mradi mmoja au zaidi. Mradi unajumuisha folda na faili ambazo zimepangwa moja kwa moja kwenye mfumo wa faili.
- Zana ya Wijeti ya Kawaida (SWT) - Hutoa vipengele vya msingi vya kiolesura vya mtumiaji vilivyounganishwa na mfumo wa uendeshaji.
- JFace - Hutoa idadi ya mifumo ya UI iliyojengwa juu ya SWT.
- Workbench - Inafafanua dhana ya UI ya Eclipse: wahariri, maoni, mitazamo.
Ni lazima kusema kwamba Jukwaa la Eclipse pia hutoa vipengele vingine vingi muhimu kwa ajili ya ujenzi wa zana zilizounganishwa za maendeleo, ikiwa ni pamoja na Utatuzi, Linganisha, Utafutaji na Timu. Inastahili kutajwa maalum kwa Maandishi ya JFace - msingi wa kuunda "wahariri mahiri" wa msimbo wa chanzo. Kwa bahati mbaya, hata uchunguzi wa haraka wa vipengele hivi, pamoja na vipengele vya safu ya UI, hauwezekani ndani ya upeo wa makala hii, kwa hiyo katika sehemu iliyobaki ya sehemu hii tutajiwekea kikomo kwa muhtasari wa sehemu kuu za "msingi" wa. Jukwaa la Eclipse na JDT.
Core Runtime
Miundombinu ya programu-jalizi ya Eclipse inategemea na zinazotolewa na mradi . Kila programu-jalizi ya Eclipse ni kifurushi cha OSGi. Uainishaji wa OSGi unafafanua, haswa, mifumo ya utayarishaji na azimio la utegemezi. Mbali na mifumo hii ya kawaida, Equinox inatanguliza dhana pointi za upanuzi. Kila programu-jalizi inaweza kufafanua viendelezi vyake, na pia kuanzisha utendakazi wa ziada ("viendelezi") kwenye mfumo kwa kutumia viendelezi vilivyobainishwa na programu-jalizi sawa au nyingine. Maelezo yoyote ya kina ya mifumo ya OSGi na Equinox ni zaidi ya upeo wa makala haya. Tukumbuke tu kwamba urekebishaji katika Eclipse ni jumla (mfumo wowote mdogo, ikijumuisha Runtime, una programu-jalizi moja au zaidi), na karibu kila kitu kwenye Eclipse ni kiendelezi. Zaidi ya hayo, kanuni hizi ziliingizwa katika usanifu wa Eclipse muda mrefu kabla ya kuanzishwa kwa OSGi (wakati huo walitumia teknolojia yao wenyewe, sawa na OSGi).
Nafasi ya Kazi ya Msingi
Takriban mazingira yoyote ya maendeleo jumuishi yaliyojengwa juu ya Jukwaa la Eclipse hufanya kazi na nafasi ya kazi ya Eclipse. Ni nafasi ya kazi ambayo kwa kawaida huwa na msimbo wa chanzo wa programu iliyotengenezwa katika IDE. Ramani za eneo la kazi moja kwa moja kwenye mfumo wa faili na lina miradi, ambayo ina folda na faili. Miradi hii, folda, na faili zinaitwa rasilimali eneo la kazi. Utekelezaji wa nafasi ya kazi katika Eclipse hutumika kama kache kuhusiana na mfumo wa faili, ambayo inafanya uwezekano wa kuharakisha kwa kiasi kikubwa kupita kwa mti wa rasilimali. Kwa kuongeza, eneo la kazi hutoa idadi ya huduma za ziada, ikiwa ni pamoja na ΠΈ .
Kipengele cha Rasilimali za Msingi ( org.eclipse.core.resources plugin ) kinawajibika kusaidia nafasi ya kazi na rasilimali zake. Hasa, sehemu hii hutoa upatikanaji wa programu kwenye nafasi ya kazi katika fomu mifano ya rasilimali. Ili kufanya kazi kwa ufanisi na mtindo huu, wateja wanahitaji njia rahisi ya kuwasilisha kiungo kwa rasilimali. Katika kesi hii, itakuwa ni kuhitajika kuficha kitu ambacho huhifadhi moja kwa moja hali ya rasilimali katika mfano kutoka kwa upatikanaji wa mteja. Vinginevyo, katika kesi ya, kwa mfano, kufuta faili, mteja anaweza kuendelea kushikilia kitu ambacho hakipo tena katika mfano, na matatizo yanayofuata. Eclipse hutatua tatizo hili kwa kutumia kitu kinachoitwa kushughulikia rasilimali. Hushughulikia hufanya kama ufunguo (inajua tu njia ya rasilimali kwenye nafasi ya kazi) na inadhibiti kabisa ufikiaji wa kitu cha ndani cha mfano, ambacho huhifadhi moja kwa moja habari kuhusu hali ya rasilimali. Kubuni hii ni tofauti ya muundo .
Mchele. Kielelezo cha 2 kinaonyesha nahau ya Kishimo/Mwili jinsi inavyotumika kwa modeli ya nyenzo. Kiolesura cha IResource kinawakilisha mpini wa rasilimali na ni API, tofauti na darasa la Rasilimali, ambalo hutekeleza kiolesura hiki, na darasa la ResourceInfo, ambalo linawakilisha shirika, ambalo si API. Tunasisitiza kwamba kipini kinajua tu njia ya rasilimali inayohusiana na mzizi wa nafasi ya kazi na haina kiungo cha maelezo ya rasilimali. Vitu vya habari vya rasilimali huunda kinachojulikana kama "mti wa kipengele". Muundo huu wa data umewekwa kabisa katika kumbukumbu. Ili kupata mfano wa maelezo ya rasilimali unaolingana na mpini, mti wa kipengele hupitiwa kulingana na njia iliyohifadhiwa kwenye mpini huo.
Mchele. 2. IResource na ResourceInfo
Kama tutakavyoona baadaye, muundo wa kimsingi wa modeli ya rasilimali (tunaweza kuiita msingi wa kushughulikia) hutumiwa katika Eclipse kwa mifano mingine pia. Kwa sasa, hebu tuorodhe baadhi ya sifa bainifu za muundo huu:
- Hushughulikia ni kitu cha thamani. Vipengee vya thamani ni vitu visivyoweza kubadilika ambavyo usawa wake hautegemei utambulisho. Vitu kama hivyo vinaweza kutumika kwa usalama kama ufunguo katika vyombo vya hashed. Matukio mengi ya kushughulikia yanaweza kurejelea rasilimali sawa. Ili kuzilinganisha, unahitaji kutumia njia ya equals(Object).
- Hushughulikia hufafanua tabia ya rasilimali, lakini haina taarifa kuhusu hali ya rasilimali (data pekee inayohifadhi ni "ufunguo", njia ya rasilimali).
- Hushughulikia inaweza kurejelea rasilimali ambayo haipo (ama rasilimali ambayo bado haijaundwa, au rasilimali ambayo tayari imefutwa). Uwepo wa rasilimali unaweza kuangaliwa kwa kutumia njia ya IResource.exists().
- Baadhi ya shughuli zinaweza kutekelezwa kulingana na maelezo yaliyohifadhiwa kwenye mpini wenyewe (kinachojulikana kama shughuli za kushughulikia pekee). Mifano ni IResource.getParent(), getFullPath(), n.k. Rasilimali haihitaji kuwepo kwa operesheni kama hiyo kufanikiwa. Uendeshaji ambao unahitaji rasilimali kuwepo ili kufanikiwa kutupa CoreException ikiwa rasilimali haipo.
Eclipse hutoa utaratibu mzuri wa kuarifu mabadiliko ya rasilimali ya nafasi ya kazi (Mchoro 3). Rasilimali zinaweza kubadilika kama matokeo ya vitendo vilivyofanywa ndani ya Eclipse IDE yenyewe au kama matokeo ya kusawazisha na mfumo wa faili. Katika matukio yote mawili, wateja wanaojiandikisha kwa arifa hutolewa maelezo ya kina kuhusu mabadiliko katika mfumo wa "deltas ya rasilimali". Delta inaelezea mabadiliko kati ya majimbo mawili ya rasilimali ya nafasi ya kazi (mdogo-) mti na yenyewe ni mti, kila nodi ambayo inaelezea mabadiliko ya rasilimali na ina orodha ya deltas katika ngazi inayofuata inayoelezea mabadiliko ya rasilimali za watoto.
Mchele. 3. IResourceChangeEvent na IResourceDelta
Utaratibu wa arifa kulingana na deltas ya rasilimali una sifa zifuatazo:
- Mabadiliko moja na mabadiliko mengi yanaelezewa kwa kutumia muundo sawa, kwani delta imejengwa kwa kutumia kanuni ya utungaji wa kujirudia. Wateja wanaojisajili wanaweza kuchakata arifa za mabadiliko ya rasilimali kwa kutumia asili ya kujirudia kupitia mti wa deltas.
- Delta ina taarifa kamili kuhusu mabadiliko ya rasilimali, ikiwa ni pamoja na harakati zake na/au mabadiliko katika "alama" zinazohusiana nayo (kwa mfano, makosa ya utungaji huwakilishwa kama vialamisho).
- Kwa kuwa marejeleo ya rasilimali hufanywa kupitia mpini, delta inaweza kurejelea rasilimali ya mbali.
Kama tutakavyoona hivi karibuni, vipengele vikuu vya muundo wa utaratibu wa arifa ya mabadiliko ya muundo wa rasilimali pia ni muhimu kwa miundo mingine inayotegemea mpini.
Msingi wa JDT
Kielelezo cha rasilimali ya nafasi ya kazi ya Eclipse ni kielelezo cha msingi cha utambuzi wa lugha. Kijenzi cha JDT Core (plugin org.eclipse.jdt.core) hutoa API ya kusogeza na kuchambua muundo wa nafasi ya kazi kutoka kwa mtazamo wa Java, kinachojulikana kama "modeli ya Java" (Mfano wa Java) API hii inafafanuliwa kulingana na vipengele vya Java, kinyume na API ya mfano ya rasilimali, ambayo inafafanuliwa kulingana na folda na faili. Miingiliano kuu ya mti wa kipengele cha Java imeonyeshwa kwenye Mtini. 4.
Mchele. 4. Vipengele vya Mfano wa Java
Muundo wa Java hutumia kishikio/ nahau sawa ya kielelezo cha rasilimali (Mchoro 5). IJavaElement ni mpini, na JavaElementInfo ina jukumu la mwili. Kiolesura cha IJavaElement kinafafanua itifaki ya kawaida kwa vipengele vyote vya Java. Baadhi ya njia zake ni za kushughulikia pekee: getElementName(), getParent(), nk. Kitu cha JavaElementInfo huhifadhi hali ya kipengele kinacholingana: muundo na sifa zake.
Mchele. 5. IJavaElement na JavaElementInfo
Muundo wa Java una tofauti fulani katika utekelezaji wa muundo wa msingi wa mpini/mwili ikilinganishwa na muundo wa rasilimali. Kama ilivyoonyeshwa hapo juu, katika mfano wa rasilimali, mti wa kipengele, ambao nodi zake ni vitu vya habari vya rasilimali, iko kwenye kumbukumbu kabisa. Lakini mfano wa Java unaweza kuwa na idadi kubwa zaidi ya vipengele kuliko mti wa rasilimali, kwa sababu pia inawakilisha muundo wa ndani wa faili za .java na .class: aina, mashamba, na mbinu.
Ili kuzuia kuweka mti mzima wa vitu kwenye kumbukumbu, utekelezaji wa mfano wa Java hutumia kashe ndogo ya LRU ya maelezo ya kipengele, ambapo ufunguo ni kushughulikia IJavaElement. vitu vya maelezo ya kipengee huundwa kwa mahitaji wakati kipengele cha mti kinavyosogezwa. Katika kesi hii, vitu vinavyotumiwa mara kwa mara huondolewa kwenye cache, na matumizi ya kumbukumbu ya mfano hubakia mdogo kwa ukubwa maalum wa cache. Hii ni faida nyingine ya kubuni-msingi ya kushughulikia, ambayo inaficha kabisa maelezo hayo ya utekelezaji kutoka kwa msimbo wa mteja.
Utaratibu wa kuarifu mabadiliko kwa vipengele vya Java kwa ujumla ni sawa na utaratibu wa kufuatilia mabadiliko kwenye rasilimali za nafasi ya kazi iliyojadiliwa hapo juu. Mteja anayetaka kufuatilia mabadiliko katika muundo wa Java anajiandikisha kupokea arifa, ambazo zinawakilishwa kama kitu cha ElementChangedEvent ambacho kina IJavaElementDelta (Mchoro 6).
Mchele. 6. ElementChangedEvent na IJavaElementDelta
Mtindo wa Java hauna habari kuhusu miili ya mbinu au azimio la jina, kwa hivyo kwa uchambuzi wa kina wa nambari iliyoandikwa katika Java, JDT Core hutoa mfano wa ziada (usio msingi wa kushughulikia): (mti wa sintaksia wa kufikirika, AST). AST inawakilisha matokeo ya kuchanganua maandishi chanzo. Nodi za AST zinalingana na vipengele vya muundo wa moduli ya chanzo (matangazo, waendeshaji, misemo, n.k.) na ina habari kuhusu kuratibu za kipengele kinacholingana katika maandishi chanzo, na pia (kama chaguo) habari kuhusu azimio la jina katika fomu ya viungo kwa kinachojulikana masharti. Vifungo ni vitu vinavyowakilisha huluki zilizopewa majina, kama vile aina, mbinu, na vigeu, vinavyojulikana kwa mkusanyaji. Tofauti na nodi za AST, ambazo huunda mti, vifungo vinaunga mkono urejeleaji mtambuka na kwa ujumla huunda grafu. Darasa la mukhtasari ASTNode ndio darasa la msingi la nodi zote za AST. Madarasa madogo ya ASTNode yanahusiana na miundo maalum ya kisintaksia ya lugha ya Java.
Kwa sababu miti ya sintaksia inaweza kutumia kiasi kikubwa cha kumbukumbu, JDT huhifadhi AST moja tu kwa kihariri kinachotumika. Tofauti na mfano wa Java, AST kawaida huzingatiwa kama mfano wa "wa kati", "wa muda", vitu ambavyo wateja hawapaswi kushikilia marejeleo ya nje ya muktadha wa operesheni iliyosababisha kuundwa kwa AST.
Mifano tatu zilizoorodheshwa (mfano wa Java, AST, vifungo) kwa pamoja huunda msingi wa kujenga "zana za maendeleo za akili" katika JDT, ikiwa ni pamoja na mhariri wa Java wenye nguvu na "wasaidizi" mbalimbali, vitendo mbalimbali vya usindikaji wa msimbo wa chanzo (ikiwa ni pamoja na kuandaa orodha ya kuagiza. majina na uumbizaji kulingana na mtindo uliobinafsishwa), utafutaji na zana za kurekebisha tena. Katika kesi hii, mfano wa Java una jukumu maalum, kwani ndio hutumika kama msingi wa uwakilishi wa kuona wa muundo wa programu inayotengenezwa (kwa mfano, katika Kifurushi cha Kifurushi, Muhtasari, Utaftaji, Utawala wa Simu, na. Aina ya Hierarkia).
Vipengele vya Eclipse vinavyotumika katika 1C:Zana za Maendeleo ya Biashara
Katika Mtini. Mchoro wa 7 unaonyesha vipengele vya Eclipse ambavyo vinaunda msingi wa jukwaa la teknolojia la 1C:Zana za Kukuza Biashara.
Mchele. 7. Eclipse kama jukwaa la 1C:Zana za Ukuzaji wa Biashara
Jukwaa la Eclipse hutoa miundombinu ya msingi. Tuliangalia baadhi ya vipengele vya miundombinu hii katika sehemu iliyopita.
(EMF) hutoa njia ya jumla ya kuunda data iliyopangwa. EMF imeunganishwa na Eclipse Platform, lakini pia inaweza kutumika kando katika programu za kawaida za Java. Mara nyingi, watengenezaji wapya wa Eclipse tayari wanaifahamu EMF, ingawa bado hawaelewi kikamilifu ugumu wa Jukwaa la Eclipse. Moja ya sababu za umaarufu huo unaostahili ni muundo wa ulimwengu wote, ambao unajumuisha, kati ya mambo mengine, API ya kiwango cha meta, ambayo inakuwezesha kufanya kazi na mfano wowote wa EMF kwa njia ya jumla. Utekelezaji wa kimsingi wa vitu vya mfano vilivyotolewa na EMF na mfumo mdogo wa kutoa nambari ya mfano kulingana na meta-modeli huongeza kwa kiasi kikubwa kasi ya maendeleo na kupunguza idadi ya makosa. EMF pia ina njia za kusawazisha miundo, kufuatilia mabadiliko ya muundo, na mengi zaidi.
Kama zana yoyote ya kusudi la jumla, EMF inafaa kusuluhisha shida nyingi za uundaji, lakini aina zingine za modeli (kwa mfano, modeli za msingi zilizojadiliwa hapo juu) zinaweza kuhitaji zana maalum zaidi za uundaji. Kuzungumza juu ya EMF ni kazi isiyo na shukrani, haswa ndani ya mipaka ndogo ya nakala moja, kwani hii ndio mada ya kitabu tofauti, na nene. Wacha tukumbuke kuwa mfumo wa hali ya juu wa jumla wa msingi wa EMF uliruhusu kuzaliwa kwa anuwai ya miradi iliyojitolea kwa modeli, ambayo imejumuishwa katika mradi wa kiwango cha juu. pamoja na EMF yenyewe. Mradi mmoja kama huo ni Eclipse Xtext.
hutoa miundombinu ya "mfano wa maandishi". Xtext hutumia kwa kuchanganua matini chanzi na EMF kwa kuwakilisha ASG inayotokana (grafu ya kisemantiki ya kufikirika, ambayo kimsingi ni mchanganyiko wa AST na vifungo), pia huitwa "muundo wa kisemantiki". Sarufi ya lugha iliyoigwa na Xtext imefafanuliwa katika lugha ya Xtext. Hii hukuruhusu sio tu kutoa maelezo ya sarufi ya ANTLR, lakini pia kupata utaratibu wa usanifu wa AST (yaani, Xtext hutoa kichanganuzi na kichanganuzi), kidokezo cha muktadha, na idadi ya vipengee vingine vya lugha. Kwa upande mwingine, lugha ya sarufi inayotumiwa katika Xtext haibadiliki kuliko, tuseme, lugha ya sarufi inayotumiwa katika ANTLR. Kwa hivyo, wakati mwingine inahitajika "kupindisha" lugha iliyotekelezwa kwa Xtext, ambayo kawaida sio shida ikiwa tunazungumza juu ya lugha inayokuzwa kutoka mwanzo, lakini inaweza kuwa haikubaliki kwa lugha zilizo na syntax tayari. Licha ya hayo, Xtext kwa sasa ndiyo zana iliyokomaa zaidi, yenye vipengele vingi, na inayoweza kutumika katika Eclipse kwa ajili ya kujenga lugha za programu na zana za maendeleo kwao. Hasa, ni chombo bora kwa prototyping haraka (lugha mahususi ya kikoa, DSL). Mbali na "msingi wa lugha" uliotajwa hapo juu kulingana na ANTLR na EMF, Xtext hutoa vipengele vingi muhimu vya ngazi ya juu, ikiwa ni pamoja na mifumo ya indexing, ujenzi wa ziada, "mhariri mwenye busara", na mengi zaidi, lakini huacha kushughulikia- mifano ya lugha ya msingi. Kama EMF, Xtext ni somo linalostahili kitabu tofauti, na hatuwezi hata kuzungumza kwa ufupi juu ya uwezo wake wote hivi sasa.
1C:Zana za Ukuzaji wa Biashara hutumia EMF yenyewe na idadi ya miradi mingine ya Kuunda Muundo wa Eclipse. Hasa, Xtext ni moja wapo ya misingi ya zana za ukuzaji kwa 1C: Lugha za Biashara kama lugha ya programu iliyojengwa ndani na lugha ya maswali. Msingi mwingine wa zana hizi za maendeleo ni mradi wa Eclipse Handly, ambao tutaujadili kwa undani zaidi (wa vipengele vya Eclipse vilivyoorodheshwa, bado haujulikani zaidi).
, mradi mdogo wa mradi wa kiwango cha juu wa Teknolojia ya Eclipse, uliibuka kama matokeo ya mchango wa awali wa msimbo kwa Wakfu wa Eclipse uliotolewa na 1C mnamo 2014. Tangu wakati huo, 1C imeendelea kusaidia maendeleo ya mradi: Wanaojitolea kwa mikono ni wafanyikazi wa kampuni. Mradi huo ni mdogo, lakini unachukua niche ya kipekee katika Eclipse: lengo lake kuu ni kusaidia maendeleo ya mifano ya kushughulikia.
Kanuni za msingi za usanifu wa miundo inayotegemea mpini, kama vile kishikio/ nahau ya mwili, zilijadiliwa hapo juu kwa kutumia muundo wa nyenzo na muundo wa Java kama mifano. Pia ilibaini kuwa muundo wa rasilimali na muundo wa Java ni misingi muhimu ya zana za ukuzaji za Eclipse Java (JDT). Na kwa kuwa karibu miradi yote ya *DT Eclipse ina usanifu unaofanana na JDT, haitakuwa ni kutia chumvi kusema kwamba mifano ya kushughulikia ina msingi wa nyingi, ikiwa sio IDE zote zilizojengwa juu ya Jukwaa la Eclipse. Kwa mfano, Zana ya Ukuzaji ya Eclipse C/C++ (CDT) ina kielelezo cha C/C++ ambacho kina jukumu sawa katika usanifu wa CDT kama vile muundo wa Java unavyofanya katika JDT.
Kabla ya Handly, Eclipse haikutoa maktaba maalum kwa miundo ya lugha inayotegemea mpini. Mifano ambazo zipo kwa sasa ziliundwa hasa kwa kurekebisha moja kwa moja msimbo wa mfano wa Java (aka copy/paste), katika hali ambapo inaruhusu Leseni ya Umma ya Eclipse (EPL). (Kwa hakika, hili kwa kawaida si suala la kisheria kwa, tuseme, miradi ya Eclipse yenyewe, lakini si kwa bidhaa zilizofungwa.) Pamoja na uzembe wake wa asili, mbinu hii inaleta matatizo yanayojulikana sana: urudufu wa msimbo unaoletwa na wakati wa kukabiliana na makosa, na kadhalika. Mbaya zaidi ni kwamba mifano inayotokana inabaki "vitu ndani yao wenyewe" na haitumii fursa ya kuunganishwa. Lakini kutenganisha dhana na itifaki za kawaida kwa miundo ya lugha inayotegemea mpini kunaweza kusababisha uundaji wa vipengee vinavyoweza kutumika tena kwa kufanya kazi navyo, sawa na kile kilichotokea katika kesi ya EMF.
Sio kwamba Eclipse hakuelewa masuala haya. Nyuma mnamo 2005 , kwa muhtasari wa uzoefu wa kutengeneza mfano wa CDT, hitaji la kuunda muundo msingi wa kawaida wa modeli za lugha, pamoja na modeli za msingi. Lakini, kama inavyotokea mara nyingi, kwa sababu ya kazi za kipaumbele cha juu, utekelezaji wa maoni haya haukuwahi kufikiwa nayo. Wakati huo huo, uainishaji wa *msimbo wa DT bado ni mojawapo ya mada ambazo hazijaendelezwa katika Eclipse.
Kwa maana fulani, mradi wa Handly umeundwa kutatua takriban matatizo sawa na EMF, lakini kwa mifano ya kushughulikia, na hasa lugha (yaani, inayowakilisha vipengele vya muundo wa baadhi ya lugha ya programu). Malengo makuu yaliyowekwa wakati wa kuunda Handly yameorodheshwa hapa chini:
- Utambulisho wa vifupisho kuu vya eneo la somo.
- Kupunguza juhudi na kuboresha ubora wa utekelezaji wa miundo ya lugha inayozingatia mpini kupitia utumiaji wa msimbo tena.
- Kutoa API ya kiwango cha meta iliyounganishwa kwa miundo inayotokana, kuwezesha kuunda vipengee vya kawaida vya IDE vinavyofanya kazi na miundo inayotegemea mpini wa lugha.
- Kubadilika na scalability.
- Kuunganishwa na Xtext (katika safu tofauti).
Ili kuangazia dhana na itifaki za kawaida, utekelezaji uliopo wa miundo inayotegemea mpini wa lugha ulichanganuliwa. Miingiliano kuu na utekelezaji wa kimsingi unaotolewa na Handly unaonyeshwa kwenye Mtini. 8.
Mchele. 8. Miingiliano ya kawaida na utekelezaji wa kimsingi wa vipengele vya Handly
Kiolesura cha IElement kinawakilisha mpini wa kipengee na ni kawaida kwa vipengele vya miundo yote yenye msingi wa Handly. Kipengele cha darasa dhahania hutekelezea utaratibu wa jumla wa kushughulikia/mwili (Mchoro 9).
Mchele. 9. IElement na generic kushughulikia/utekelezaji wa mwili
Kwa kuongeza, Handly hutoa utaratibu wa jumla wa kuarifu kuhusu mabadiliko katika vipengele vya mfano (Mchoro 10). Kama unavyoona, inafanana kwa upana na taratibu za arifa zinazotekelezwa katika modeli ya rasilimali na modeli ya Java, na hutumia IElementDelta kutoa uwakilishi mmoja wa taarifa ya mabadiliko ya kipengele.
Mchele. 10. Miingiliano ya jumla na utekelezaji wa kimsingi wa utaratibu wa arifa wa Handly
Sehemu ya Handly iliyojadiliwa hapo juu (Kielelezo 9 na 10) inaweza kutumika kuwakilisha karibu miundo yoyote inayotegemea mpini. Kwa kuunda kiisimu mifano, mradi hutoa utendaji wa ziada - haswa, miingiliano ya kawaida na utekelezaji wa kimsingi kwa vipengele vya muundo wa maandishi ya chanzo, kinachojulikana kama vipengele vya chanzo (Mchoro 8). Kiolesura cha ISourceFile kinawakilisha faili chanzo, na ISourceConstruct inawakilisha kipengele ndani ya faili chanzo. Madarasa ya muhtasari SourceFile na SourceConstruct hutekeleza mbinu za jumla ili kusaidia kufanya kazi na faili chanzo na vipengele vyake, kwa mfano, kufanya kazi na vibafa vya maandishi, kuunganisha kwa viwianishi vya kipengele katika matini chanzi, kupatanisha modeli na maudhui ya sasa ya bafa ya nakala inayofanya kazi. , na kadhalika. Utekelezaji wa mbinu hizi kwa kawaida ni changamoto, na Handly inaweza kupunguza kwa kiasi kikubwa juhudi za kuunda miundo ya lugha inayotegemea mpini kwa kutoa utekelezaji wa msingi wa ubora wa juu.
Kando na mifumo ya msingi iliyoorodheshwa hapo juu, Handly hutoa miundombinu ya vihifadhi maandishi na vijipicha, usaidizi wa kuunganishwa na wahariri wa msimbo wa chanzo (pamoja na ujumuishaji wa nje wa kisanduku na kihariri cha Xtext), na vile vile vipengee vya kawaida vya UI ambavyo fanya kazi na wahariri wa msimbo wa chanzo. Miundo ya mkono kama vile mfumo wa muhtasari. Ili kuonyesha uwezo wake, mradi hutoa mifano kadhaa, ikiwa ni pamoja na utekelezaji wa mfano wa Java katika Handly. (Ikilinganishwa na utekelezaji kamili wa modeli ya Java katika JDT, mtindo huu umerahisishwa kimakusudi kwa uwazi zaidi.)
Kama ilivyobainishwa awali, lengo kuu wakati wa usanifu wa awali wa Handly na uendelezaji uliofuata lilikuwa na linaendelea kuwa juu ya kubadilika na kubadilika.
Kimsingi, mifano ya kushughulikia-msingi inakua vizuri "kwa muundo". Kwa mfano, nahau ya mpini/mwili hukuruhusu kuweka kikomo cha kumbukumbu inayotumiwa na modeli. Lakini pia kuna nuances. Kwa hivyo, wakati wa kupima kwa Handly kwa scalability, tatizo liligunduliwa katika utekelezaji wa utaratibu wa taarifa - wakati idadi kubwa ya vipengele vilibadilishwa, kujenga deltas ilichukua muda mwingi. Ilibadilika kuwa tatizo sawa lilikuwepo katika mfano wa JDT Java, ambayo msimbo unaofanana ulibadilishwa mara moja. Tulirekebisha hitilafu kwa Handly na tukatayarisha kiraka sawa cha JDT, ambacho kilipokelewa kwa shukrani. Huu ni mfano mmoja tu ambapo kutambulisha Handly katika utekelezaji wa modeli zilizopo kunaweza kuwa muhimu, kwa sababu katika kesi hii hitilafu kama hiyo inaweza kusasishwa katika sehemu moja tu.
Ili kufanya utekelezaji wa Handly katika utekelezwaji wa modeli uliopo uwezekane kitaalam, maktaba lazima iwe na unyumbufu mkubwa. Shida kuu ni kudumisha utangamano wa nyuma katika muundo wa API. Tatizo hili lilitatuliwa katika kwa kutenganisha kwa uwazi API ya muundo mahususi, iliyofafanuliwa na kudhibitiwa kikamilifu na msanidi, kutoka kwa API iliyounganishwa ya kiwango cha meta inayotolewa na maktaba. Hii sio tu kwamba inafanya uwezekano wa kitaalam kutekeleza Handly katika utekelezaji uliopo, lakini pia inampa msanidi wa mtindo mpya uhuru muhimu wakati wa kuunda API.
Unyumbufu una vipengele vingine pia. Kwa mfano, Handly inaweka karibu vikwazo vyovyote kwenye muundo wa modeli na inaweza kutumika kuiga lugha zenye madhumuni ya jumla na kikoa mahususi. Wakati wa kuunda muundo wa faili ya chanzo, Handly haielezi aina yoyote ya uwakilishi wa AST na, kimsingi, hauhitaji hata uwepo wa AST yenyewe, na hivyo kuhakikisha utangamano na karibu utaratibu wowote wa uchanganuzi. Mwishowe, Handly inasaidia ujumuishaji kamili na nafasi ya kazi ya Eclipse, lakini pia inaweza kufanya kazi moja kwa moja na mifumo ya faili shukrani kwa ujumuishaji wake na (EFS).
Toleo la sasa ilitoka Desemba 2016. Licha ya ukweli kwamba mradi kwa sasa uko katika hali ya incubation na API bado haijarekebishwa, Handly tayari inatumika katika bidhaa mbili kubwa za kibiashara ambazo zilichukua hatari ya kufanya kama "wapokeaji wa mapema", na, lazima niseme, usijutie bado.
Kama ilivyoonyeshwa hapo juu, moja ya bidhaa hizi ni 1C:Zana za Maendeleo ya Biashara, ambapo Handly hutumiwa tangu mwanzo hadi muundo wa muundo wa hali ya juu wa 1C:Lugha za Biashara kama lugha iliyojengwa ndani ya programu na lugha ya maswali. . Bidhaa nyingine haijulikani sana kwa umma. Hii , mazingira jumuishi ya usanifu wa kichakataji-kuweka maagizo mahususi (ASIP), kinachotumika ndani ya kampuni ya Kicheki ya Codasip yenyewe na wateja wake, ikijumuisha , , , . Codasip imekuwa ikitumia Handly katika uzalishaji tangu 2015, ikianza na toleo la Handly 0.2. Toleo jipya zaidi la Codasip Studio linatumia toleo la 0.5, lililotolewa Juni 2016. OndΕej IlΔΓk, ambaye anaongoza maendeleo ya IDE katika Codasip, anawasiliana na mradi huo, akitoa maoni muhimu kwa niaba ya "mtu wa tatu anayekubali". Aliweza hata kupata muda wa bure wa kushiriki moja kwa moja katika maendeleo ya mradi, kutekeleza safu ya UI (~4000 mistari ya kanuni) kwa moja ya mifano ya Handly, mfano wa Java. Maelezo zaidi ya kina kuhusu matumizi ya Handly by adopters yanaweza kupatikana kwenye ukurasa mradi.
Tunatumahi kuwa baada ya kutolewa kwa toleo la 1.0 na hakikisho la uthabiti wa API na mradi kuondoka katika hali ya incubation, Handly itakuwa na wapitishaji wapya. Wakati huo huo, mradi unaendelea kujaribu na kuboresha zaidi API, ikitoa matoleo mawili "makuu" kwa mwaka - mnamo Juni (tarehe sawa na kutolewa kwa Eclipse kwa wakati mmoja) na Desemba, ikitoa ratiba inayotabirika ambayo wapokeaji wanaweza kutegemea. Tunaweza pia kuongeza kuwa "kiwango cha hitilafu" cha mradi kinasalia katika kiwango cha chini mara kwa mara na Handly imekuwa ikifanya kazi kwa uhakika katika bidhaa za watumiaji wa mapema tangu matoleo ya kwanza kabisa. Ili kuchunguza zaidi Eclipse Handly, unaweza kutumia ΠΈ .
Chanzo: mapenzi.com