Ehtimol,
Tabiatda umumiy ko'rinishga ega bo'lgan ushbu maqolada biz Eclipse arxitekturasining ba'zi asoslarini integratsiyalashgan ishlab chiqish vositalarini yaratish platformasi sifatida ko'rib chiqishga harakat qilamiz va texnologiyaning asosini tashkil etuvchi Eclipse komponentlari haqida dastlabki tasavvurni beramiz. "yangi konfigurator" 1C: Enterprise platformasi.
Eclipse arxitekturasiga kirish
Keling, avval misol yordamida Eclipse arxitekturasining ba'zi umumiy jihatlarini ko'rib chiqaylik
Avvalo shuni ta'kidlash kerakki, Eclipse juda aniq arxitektura qatlamlari bilan ajralib turadi, bunda tilga bog'liq bo'lmagan funksionallikni muayyan dasturlash tillarini qo'llab-quvvatlash uchun mo'ljallangan funksionallikdan ajratish va UI-mustaqil "yadro" komponentlarini bog'langan komponentlardan ajratish. qo'llab-quvvatlovchi foydalanuvchi interfeysi bilan.
Shunday qilib, Eclipse Platformasi umumiy, tildan mustaqil infratuzilmani belgilaydi va Java ishlab chiqish vositalari Eclipse-ga to'liq xususiyatli Java IDE qo'shadi. Eclipse Platformasi ham, JDT ham bir nechta komponentlardan iborat bo'lib, ularning har biri UI-dan mustaqil "yadro" yoki UI qatlamiga tegishli (1-rasm).
Guruch. 1. Eclipse platformasi va JDT
Keling, Eclipse platformasining asosiy komponentlarini sanab o'tamiz:
- Ish vaqti — Plagin infratuzilmasini belgilaydi. Eclipse modulli arxitektura bilan tavsiflanadi. Aslida, Eclipse "kengaytma nuqtalari" va "kengaytmalar" to'plamidir.
- Ish maydoni — Bir yoki bir nechta loyihani boshqaradi. Loyiha to'g'ridan-to'g'ri fayl tizimiga joylashtirilgan papkalar va fayllardan iborat.
- Standart vidjet asboblar to‘plami (SWT) - Operatsion tizim bilan integratsiyalashgan foydalanuvchi interfeysining asosiy elementlarini taqdim etadi.
- JFace — SWT ustiga qurilgan bir qator UI ramkalarini taqdim etadi.
- Workbench — Eclipse UI paradigmasini belgilaydi: muharrirlar, qarashlar, istiqbollar.
Aytish kerakki, Eclipse Platformasi integratsiyalashgan ishlab chiqish vositalarini yaratish uchun boshqa ko'plab foydali komponentlarni, jumladan, disk raskadrovka, solishtirish, qidirish va jamoani ham taqdim etadi. JFace Text-ni alohida ta'kidlash kerak - manba kodining "aqlli muharrirlarini" yaratish uchun asos. Afsuski, ushbu tarkibiy qismlarni, shuningdek, UI qatlamining tarkibiy qismlarini kursoriy tekshirish ham ushbu maqola doirasida mumkin emas, shuning uchun ushbu bo'limning qolgan qismida biz o'zimizni asosiy "asosiy" komponentlarning umumiy ko'rinishi bilan cheklaymiz. Eclipse platformasi va JDT.
Asosiy ish vaqti
Eclipse plaginlari infratuzilmasi asoslanadi
Asosiy ish maydoni
Eclipse platformasi ustida qurilgan deyarli har qanday integratsiyalashgan ishlab chiqish muhiti Eclipse ish maydoni bilan ishlaydi. Bu odatda IDE da ishlab chiqilgan dasturning manba kodini o'z ichiga olgan ish maydoni. Ish maydoni to'g'ridan-to'g'ri fayl tizimiga mos keladi va papkalar va fayllarni o'z ichiga olgan loyihalardan iborat. Ushbu loyihalar, papkalar va fayllar deyiladi resurslar ish maydoni. Eclipse-da ish maydonini amalga oshirish fayl tizimiga nisbatan kesh bo'lib xizmat qiladi, bu esa resurs daraxti bo'ylab harakatlanishni sezilarli darajada tezlashtirishga imkon beradi. Bundan tashqari, ish maydoni bir qator qo'shimcha xizmatlarni taqdim etadi, jumladan
Core Resources komponenti (org.eclipse.core.resources plagini) ish maydoni va uning resurslarini qo'llab-quvvatlash uchun javobgardir. Xususan, ushbu komponent shakldagi ish maydoniga dasturiy kirishni ta'minlaydi resurs modellari. Ushbu model bilan samarali ishlash uchun mijozlarga manbaga havolani taqdim etishning oddiy usuli kerak. Bunday holda, modeldagi resurs holatini bevosita saqlaydigan ob'ektni mijoz kirishidan yashirish maqsadga muvofiqdir. Aks holda, masalan, faylni o'chirib tashlagan taqdirda, mijoz modelda bo'lmagan ob'ektni keyingi muammolar bilan ushlab turishni davom ettirishi mumkin. Eclipse bu muammoni deb nomlangan narsa yordamida hal qiladi Ushlab turing manba. Tutqich kalit vazifasini bajaradi (u faqat ish maydonidagi resursga yo'lni biladi) va resurs holati haqidagi ma'lumotlarni bevosita saqlaydigan ichki model ob'ektiga kirishni to'liq nazorat qiladi. Ushbu dizayn naqshning o'zgarishi
Guruch. 2-rasmda resurs modeliga qo'llaniladigan tutqich/tana idiomasi tasvirlangan. IResource interfeysi resurs tutqichini ifodalaydi va bu interfeysni amalga oshiradigan Resurs sinfi va API bo'lmagan tanani ifodalovchi ResourceInfo sinfidan farqli o'laroq API hisoblanadi. Biz ta'kidlaymizki, tutqich faqat ish maydoni ildiziga nisbatan resursga yo'lni biladi va manba ma'lumotlariga havolani o'z ichiga olmaydi. Resurs ma'lumotlari ob'ektlari "element daraxti" deb ataladigan narsalarni tashkil qiladi. Ushbu ma'lumotlar strukturasi xotirada to'liq moddiylashtirilgan. Tutqichga mos keladigan manba ma'lumotlari misolini topish uchun element daraxti ushbu tutqichda saqlangan yo'lga ko'ra o'tadi.
Guruch. 2. IResource va ResourceInfo
Keyinchalik ko'rib chiqamiz, resurs modelining asosiy dizayni (biz uni dastakka asoslangan deb atashimiz mumkin) Eclipse-da boshqa modellar uchun ham qo'llaniladi. Hozircha ushbu dizaynning o'ziga xos xususiyatlarini sanab o'tamiz:
- Tutqich qiymat ob'ektidir. Qiymat ob'ektlari tengligi identifikatsiyaga asoslanmagan o'zgarmas ob'ektlardir. Bunday ob'ektlardan xeshlangan konteynerlarda kalit sifatida xavfsiz foydalanish mumkin. Tutqichning bir nechta nusxalari bir xil manbaga murojaat qilishi mumkin. Ularni solishtirish uchun teng (Object) usulidan foydalanish kerak.
- Tutqich resursning harakatini belgilaydi, lekin resurs holati haqida ma'lumotni o'z ichiga olmaydi (u saqlaydigan yagona ma'lumot "kalit", resursga yo'l).
- Tutqich mavjud bo'lmagan manbaga murojaat qilishi mumkin (hali yaratilmagan resurs yoki allaqachon o'chirilgan resurs). Resurs mavjudligini IResource.exists() usuli yordamida tekshirish mumkin.
- Ba'zi operatsiyalar faqat tutqichning o'zida saqlangan ma'lumotlarga asoslangan holda amalga oshirilishi mumkin (faqat ishlov berish operatsiyalari deb ataladi). Misollar IResource.getParent(), getFullPath() va boshqalar. Bunday operatsiya muvaffaqiyatli bo'lishi uchun resurs mavjud bo'lishi shart emas. Muvaffaqiyatli bo'lish uchun resurs mavjudligini talab qiladigan operatsiyalar, agar resurs mavjud bo'lmasa, CoreException ni chiqaradi.
Eclipse ish maydoni resurslarining o'zgarishi haqida xabar berishning samarali mexanizmini taqdim etadi (3-rasm). Resurslar Eclipse IDE-ning o'zida bajarilgan harakatlar natijasida yoki fayl tizimi bilan sinxronizatsiya natijasida o'zgarishi mumkin. Ikkala holatda ham bildirishnomalarga obuna bo'lgan mijozlarga "resurs deltalari" ko'rinishidagi o'zgarishlar haqida batafsil ma'lumot beriladi. Delta ish maydoni resursi (sub-) daraxtining ikki holati o'rtasidagi o'zgarishlarni tavsiflaydi va o'zi daraxt bo'lib, har bir tugun resursdagi o'zgarishlarni tavsiflaydi va keyingi darajadagi deltalar ro'yxatini o'z ichiga oladi, ular bolalar resurslariga kiritilgan o'zgarishlarni tavsiflaydi.
Guruch. 3. IResourceChangeEvent va IResourceDelta
Resurs deltalariga asoslangan bildirishnoma mexanizmi quyidagi xususiyatlarga ega:
- Bitta o'zgarish va ko'plab o'zgarishlar bir xil tuzilma yordamida tasvirlangan, chunki delta rekursiv kompozitsiya printsipi yordamida qurilgan. Abonent mijozlari deltalar daraxti orqali rekursiv tushish yordamida resurs o'zgarishi haqidagi bildirishnomalarni qayta ishlashlari mumkin.
- Delta resursdagi o'zgarishlar, shu jumladan uning harakati va/yoki u bilan bog'liq "markerlar"dagi o'zgarishlar haqida to'liq ma'lumotni o'z ichiga oladi (masalan, kompilyatsiya xatolar markerlar sifatida taqdim etiladi).
- Resurs havolalari tutqich orqali amalga oshirilganligi sababli, delta tabiiy ravishda masofaviy manbaga murojaat qilishi mumkin.
Tez orada ko'rib turganimizdek, resurs modeli o'zgarishi to'g'risida bildirishnoma mexanizmini loyihalashning asosiy komponentlari boshqa tutqichga asoslangan modellar uchun ham tegishli.
JDT yadrosi
Eclipse ish maydoni resurs modeli asosiy til-agnostik modeldir. JDT Core komponenti (plugin org.eclipse.jdt.core) "Java modeli" deb ataladigan Java nuqtai nazaridan ish maydoni tuzilishini navigatsiya qilish va tahlil qilish uchun API taqdim etadi (Java modeli). Ushbu API papkalar va fayllar nuqtai nazaridan aniqlangan asosiy resurs modeli API dan farqli ravishda Java elementlari nuqtai nazaridan aniqlanadi. Java elementlar daraxtining asosiy interfeyslari rasmda ko'rsatilgan. 4.
Guruch. 4. Java modeli elementlari
Java modeli resurs modeli bilan bir xil tutqich/tana idiomasidan foydalanadi (5-rasm). IJavaElement tutqich, JavaElementInfo esa tana rolini o'ynaydi. IJavaElement interfeysi barcha Java elementlari uchun umumiy protokolni belgilaydi. Uning ba'zi usullari faqat ishlov berish uchun mo'ljallangan: getElementName(), getParent() va boshqalar. JavaElementInfo obyekti tegishli elementning holatini saqlaydi: uning tuzilishi va atributlari.
Guruch. 5. IJavaElement va JavaElementInfo
Java modeli resurs modeliga nisbatan asosiy tutqich/tana dizaynini amalga oshirishda ba'zi farqlarga ega. Yuqorida ta'kidlab o'tilganidek, resurs modelida tugunlari resurs ma'lumotlari ob'ekti bo'lgan element daraxti to'liq xotirada joylashgan. Lekin Java modeli resurs daraxtiga qaraganda sezilarli darajada ko'p elementlarga ega bo'lishi mumkin, chunki u .java va .class fayllarining ichki tuzilishini ham ifodalaydi: turlari, maydonlari va usullari.
Xotiradagi elementlarning butun daraxtini to'liq amalga oshirishga yo'l qo'ymaslik uchun Java modelini amalga oshirish element ma'lumotlarining cheklangan o'lchamdagi LRU keshidan foydalanadi, bu erda kalit IJavaElement dastagidir. element ma'lumoti ob'ektlari element daraxti navigatsiya qilinganda talab bo'yicha yaratiladi. Bunday holda, eng kam ishlatiladigan elementlar keshdan chiqariladi va modelning xotira iste'moli belgilangan kesh hajmi bilan cheklangan bo'lib qoladi. Bu tutqichga asoslangan dizaynning yana bir afzalligi bo'lib, u bunday amalga oshirish tafsilotlarini mijoz kodidan butunlay yashiradi.
Java elementlariga o'zgartirishlar haqida xabar berish mexanizmi, odatda, yuqorida muhokama qilingan ish maydoni resurslaridagi o'zgarishlarni kuzatish mexanizmiga o'xshaydi. Java modelidagi o'zgarishlarni kuzatmoqchi bo'lgan mijoz IJavaElementDelta ni o'z ichiga olgan ElementChangedEvent obyekti sifatida taqdim etilgan bildirishnomalarga obuna bo'ladi (6-rasm).
Guruch. 6. ElementChangedEvent va IJavaElementDelta
Java modelida usul tanasi yoki nom rezolyutsiyasi haqida ma'lumot mavjud emas, shuning uchun Java-da yozilgan kodni batafsil tahlil qilish uchun JDT Core qo'shimcha (tutqichga asoslangan bo'lmagan) modelni taqdim etadi:
Sintaksis daraxtlari katta hajmdagi xotirani iste'mol qilishi mumkinligi sababli, JDT faol muharrir uchun faqat bitta ASTni keshlaydi. Java modelidan farqli o'laroq, AST odatda "oraliq", "vaqtinchalik" model sifatida qaraladi, uning a'zolari ASTni yaratishga olib kelgan operatsiya kontekstidan tashqarida mijozlar tomonidan havola qilinmasligi kerak.
Ro'yxatda keltirilgan uchta model (Java modeli, AST, bog'lashlar) birgalikda JDTda "aqlli ishlab chiqish vositalari" ni yaratish uchun asos bo'lib xizmat qiladi, shu jumladan turli xil "yordamchilar" ga ega kuchli Java muharriri, manba kodini qayta ishlash uchun turli xil harakatlar (shu jumladan import ro'yxatini tashkil qilish). moslashtirilgan uslubga muvofiq nomlar va formatlash), qidiruv va refaktoring vositalari. Bunday holda, Java modeli alohida rol o'ynaydi, chunki u ishlab chiqilayotgan dastur tuzilishini vizual ko'rsatish uchun asos sifatida ishlatiladi (masalan, Package Explorer, Outline, Search, Call ierarxiyasi va Ierarxiya turi).
1C: Enterprise Development Tools da ishlatiladigan Eclipse komponentlari
Shaklda. 7-rasmda 1C: Enterprise Development Tools uchun texnologik platformaning asosini tashkil etuvchi Eclipse komponentlari ko'rsatilgan.
Guruch. 7. Eclipse 1C: Enterprise Development Tools platformasi sifatida
Eclipse platformasi asosiy infratuzilmani ta'minlaydi. Biz oldingi bo'limda ushbu infratuzilmaning ba'zi jihatlarini ko'rib chiqdik.
Har qanday haqiqiy umumiy maqsadli vosita singari, EMF keng ko'lamli modellashtirish muammolarini hal qilish uchun javob beradi, ammo ba'zi modellar sinflari (masalan, yuqorida muhokama qilingan dastakka asoslangan modellar) ko'proq ixtisoslashgan modellashtirish vositalarini talab qilishi mumkin. EMF haqida gapirish, ayniqsa, bitta maqolaning cheklangan doirasidagi noshukur ishdir, chunki bu alohida kitobning mavzusi va juda qalin. Shuni ta'kidlash kerakki, EMF asosidagi yuqori sifatli umumlashtirish tizimi yuqori darajadagi loyihaga kiritilgan modellashtirishga bag'ishlangan bir qator loyihalarni yaratishga imkon berdi.
1C: Enterprise Development Tools EMFning o'zi va boshqa bir qator Eclipse Modeling loyihalaridan faol foydalanadi. Xususan, Xtext o'rnatilgan dasturlash tili va so'rovlar tili kabi 1C: Enterprise tillarini ishlab chiqish vositalarining asoslaridan biridir. Ushbu ishlab chiqish vositalarining yana bir asosi Eclipse Handly loyihasi bo'lib, biz uni batafsilroq ko'rib chiqamiz (Ro'yxatda keltirilgan Eclipse komponentlaridan u hali ham eng kam ma'lum).
Tutqichga asoslangan modellarning asosiy me'moriy tamoyillari, masalan, tutqich/tana idiomasi, misol sifatida manba modeli va Java modelidan foydalangan holda yuqorida muhokama qilindi. Shuningdek, resurs modeli ham, Java modeli ham Eclipse Java ishlab chiqish vositalari (JDT) uchun muhim asoslar ekanligini taʼkidladi. Deyarli barcha *DT Eclipse loyihalari JDTga o'xshash arxitekturaga ega bo'lganligi sababli, Eclipse Platformasi tepasida qurilgan barcha IDElar bo'lmasa ham, dastakka asoslangan modellar ko'pchilikning asosini tashkil qiladi, desak mubolag'a bo'lmaydi. Masalan, Eclipse C/C++ Development Tooling (CDT) dastakka asoslangan C/C++ modeliga ega bo'lib, CDT arxitekturasida Java modeli JDTda qanday rol o'ynaydi.
Handlydan oldin Eclipse dastakka asoslangan til modellarini yaratish uchun maxsus kutubxonalarni taklif qilmagan. Hozirda mavjud bo'lgan modellar asosan Java model kodini to'g'ridan-to'g'ri moslashtirish orqali yaratilgan (aka nusxa ko'chirish/joylashtirish), ruxsat bergan hollarda Eclipse Public License (EPL). (Shubhasiz, bu, masalan, Eclipse loyihalarining o‘zi uchun huquqiy muammo emas, lekin yopiq manbali mahsulotlar uchun emas.) Bu usul o‘ziga xos tasodifiylikdan tashqari, taniqli muammolarni ham keltirib chiqaradi: xatolarga moslashishda kodning takrorlanishi, va boshqalar. Eng yomoni, natijada paydo bo'lgan modellar "o'z-o'zidan narsalar" bo'lib qoladi va birlashish potentsialidan foydalanmaydi. Ammo dastakka asoslangan til modellari uchun umumiy tushunchalar va protokollarni izolyatsiya qilish, EMF holatida bo'lgani kabi, ular bilan ishlash uchun qayta foydalanish mumkin bo'lgan komponentlarni yaratishga olib kelishi mumkin.
Eclipse bu muammolarni tushunmagani emas. 2005 yilda
Muayyan ma'noda Handly loyihasi EMF bilan bir xil muammolarni hal qilish uchun mo'ljallangan, lekin dastakka asoslangan modellar va birinchi navbatda til uchun (ya'ni, ba'zi dasturlash tilining strukturasi elementlarini ifodalovchi) uchun. Handly-ni loyihalashda qo'yilgan asosiy maqsadlar quyida keltirilgan:
- Mavzu sohasining asosiy abstraksiyalarini aniqlash.
- Kodni qayta ishlatish orqali dastakka asoslangan til modellarini amalga oshirish sifatini oshirish va harakatlarni kamaytirish.
- Olingan modellarga yagona meta-darajali API taqdim etish, til boshqaruviga asoslangan modellar bilan ishlaydigan umumiy IDE komponentlarini yaratish imkonini beradi.
- Moslashuvchanlik va miqyoslilik.
- Xtext bilan integratsiya (alohida qatlamda).
Umumiy tushunchalar va protokollarni ta'kidlash uchun til boshqaruviga asoslangan modellarning mavjud ilovalari tahlil qilindi. Handly tomonidan taqdim etilgan asosiy interfeyslar va asosiy ilovalar rasmda ko'rsatilgan. 8.
Guruch. 8. Handly elementlarining umumiy interfeyslari va asosiy ilovalari
IElement interfeysi elementning dastagini ifodalaydi va Handly-asosidagi barcha modellarning elementlari uchun umumiydir. Mavhum sinf Element umumlashtirilgan tutqich/tana mexanizmini amalga oshiradi (9-rasm).
Guruch. 9. IElement va umumiy tutqich/tanani amalga oshirish
Bundan tashqari, Handly model elementlaridagi o'zgarishlar haqida xabar berishning umumlashtirilgan mexanizmini taqdim etadi (10-rasm). Ko'rib turganingizdek, u resurs modelida va Java modelida amalga oshirilgan bildirishnoma mexanizmlariga keng o'xshaydi va elementlarni o'zgartirish haqidagi ma'lumotni birlashtirilgan taqdim etish uchun IElementDelta'dan foydalanadi.
Guruch. 10. Handly bildirishnoma mexanizmining umumiy interfeyslari va asosiy ilovalari
Yuqorida muhokama qilingan Handly qismi (9 va 10-rasm) deyarli har qanday tutqichga asoslangan modellarni ifodalash uchun ishlatilishi mumkin. Yaratish uchun lingvistik modellar uchun loyiha qo'shimcha funktsiyalarni taklif qiladi - xususan, umumiy interfeyslar va manba matn tuzilishi elementlari uchun asosiy ilovalar, manba elementlari (8-rasm). ISourceFile interfeysi manba faylni, ISourceConstruct esa manba fayl ichidagi elementni ifodalaydi. SourceFile va SourceConstruct mavhum sinflari manba fayllari va ularning elementlari bilan ishlashni qo'llab-quvvatlash uchun umumlashtirilgan mexanizmlarni amalga oshiradi, masalan, matn buferlari bilan ishlash, manba matnidagi elementning koordinatalari bilan bog'lanish, modellarni ishchi nusxa buferining joriy mazmuni bilan moslashtirish. , va boshqalar. Ushbu mexanizmlarni amalga oshirish odatda juda qiyin va Handly yuqori sifatli bazaviy ilovalarni taqdim etish orqali dastakka asoslangan til modellarini ishlab chiqish harakatlarini sezilarli darajada kamaytirishi mumkin.
Yuqorida sanab o'tilgan asosiy mexanizmlarga qo'shimcha ravishda, Handly matn buferlari va oniy tasvirlar uchun infratuzilmani, manba kodi muharrirlari bilan integratsiyani qo'llab-quvvatlashni (jumladan, Xtext muharriri bilan to'liq integratsiyani), shuningdek, ba'zi umumiy UI komponentlarini taqdim etadi. manba kodi muharrirlari bilan ishlash, kontur ramkasi kabi qulay modellar. Uning imkoniyatlarini ko'rsatish uchun loyiha bir nechta misollarni, jumladan, Handly-da Java modelini amalga oshirishni taqdim etadi. (Java modelining JDT-da to'liq amalga oshirilishi bilan solishtirganda, bu model aniqroq bo'lishi uchun ataylab biroz soddalashtirilgan.)
Yuqorida ta'kidlab o'tilganidek, Handlyning dastlabki dizayni va keyingi rivojlanishida asosiy e'tibor miqyoslilik va moslashuvchanlikka qaratilgan edi va shunday bo'ladi.
Aslida, tutqichga asoslangan modellar "dizayn bo'yicha" juda yaxshi o'lchaydi. Misol uchun, tutqich/tana idiomasi model tomonidan iste'mol qilinadigan xotira miqdorini cheklash imkonini beradi. Ammo nuanslar ham bor. Shunday qilib, Handly-ni miqyosda sinab ko'rishda bildirishnoma mexanizmini amalga oshirishda muammo aniqlandi - ko'p sonli elementlar o'zgartirilganda, deltalarni qurish juda ko'p vaqtni oldi. Ma'lum bo'lishicha, xuddi shu muammo JDT Java modelida mavjud bo'lib, undan tegishli kod bir vaqtlar moslashtirilgan. Biz Handly-dagi xatoni tuzatdik va JDT uchun shunga o'xshash yamoq tayyorladik, u minnatdorchilik bilan qabul qilindi. Bu mavjud model ilovalariga Handly ni kiritish potentsial foydali bo'lishi mumkin bo'lgan bir misol, chunki bu holda bunday xatolik faqat bitta joyda tuzatilishi mumkin.
Handly-ni mavjud modellarni amalga oshirishni texnik jihatdan amalga oshirish uchun kutubxona sezilarli moslashuvchanlikka ega bo'lishi kerak. Asosiy muammo API modeli bo'ylab orqaga qarab muvofiqlikni saqlab qolishdir. Bu muammo yilda hal qilindi
Moslashuvchanlikning boshqa jihatlari ham bor. Misol uchun, Handly model tuzilishiga deyarli hech qanday cheklovlar qo'ymaydi va umumiy maqsadli va domenga xos tillarni modellashtirish uchun ishlatilishi mumkin. Manba faylining strukturasini yaratishda Handly AST ko'rsatishning biron bir shaklini belgilamaydi va, qoida tariqasida, ASTning o'zi mavjudligini ham talab qilmaydi, shuning uchun deyarli har qanday tahlil qilish mexanizmi bilan muvofiqlikni ta'minlaydi. Va nihoyat, Handly Eclipse ish maydoni bilan to'liq integratsiyani qo'llab-quvvatlaydi, lekin u bilan integratsiyalashgani tufayli fayl tizimlari bilan bevosita ishlashi mumkin.
Joriy versiya
Yuqorida ta'kidlab o'tilganidek, ushbu mahsulotlardan biri 1C: Enterprise Development Tools bo'lib, u erda Handly boshidanoq o'rnatilgan dasturlash tili va so'rovlar tili sifatida 1C: Enterprise tillarining yuqori darajadagi tuzilmasi elementlarini modellashtirish uchun ishlatiladi. . Boshqa mahsulot keng jamoatchilikka kamroq ma'lum. Bu
Umid qilamizki, API barqarorligi kafolati va loyiha inkubatsiya holatidan chiqqan 1.0 versiyasi chiqarilgandan so'ng Handly yangi qabul qiluvchilarga ega bo'ladi. Shu bilan birga, loyiha API-ni sinovdan o'tkazish va yanada takomillashtirishni davom ettirmoqda, yiliga ikkita "asosiy" relizlarni chiqaradi - iyunda (bir vaqtning o'zida Eclipse nashri bilan bir xil sana) va dekabrda, qabul qiluvchilar ishonishi mumkin bo'lgan taxminiy jadvalni taqdim etadi. Bundan tashqari, loyihaning "xatolik darajasi" doimiy ravishda past darajada qolayotganini qo'shishimiz mumkin va Handly birinchi versiyalardan boshlab erta qabul qiluvchilarning mahsulotlarida ishonchli ishlamoqda. Eclipse Handly-ni batafsil o'rganish uchun siz foydalanishingiz mumkin
Manba: www.habr.com