Ola bilər,
Təbiətdə ümumi olan bu məqalədə biz inteqrasiya olunmuş inkişaf alətləri yaratmaq üçün platforma kimi Eclipse arxitekturasının bəzi əsaslarına baxmağa və texnologiyanın əsasını təşkil edən Eclipse komponentləri haqqında ilkin fikir verməyə çalışacağıq. "yeni Konfiqurator" 1C: Müəssisə üçün platforma.
Eclipse Arxitekturasına Giriş
Əvvəlcə nümunədən istifadə edərək Eclipse arxitekturasının bəzi ümumi aspektlərinə nəzər salaq
İlk növbədə qeyd etmək lazımdır ki, Eclipse kifayət qədər aydın memarlıq təbəqəsi ilə xarakterizə olunur, dildən asılı olmayan funksionallıq xüsusi proqramlaşdırma dillərini dəstəkləmək üçün nəzərdə tutulmuş funksionallıqdan ayrılır və UI-dən asılı olmayan "əsas" komponentlər əlaqəli komponentlərdən ayrılır. dəstəkləyən istifadəçi interfeysi ilə.
Beləliklə, Eclipse Platforması ümumi, dildən asılı olmayan infrastrukturu müəyyənləşdirir və Java inkişaf alətləri Eclipse-ə tam xüsusiyyətli Java IDE əlavə edir. Həm Eclipse Platforması, həm də JDT hər biri ya UI-dən asılı olmayan "nüvə" və ya UI qatına aid olan bir neçə komponentdən ibarətdir (Şəkil 1).
düyü. 1. Eclipse Platforması və JDT
Eclipse Platformasının əsas komponentlərini sadalayaq:
- İş vaxtı — Plugin infrastrukturunu müəyyən edir. Eclipse modul arxitektura ilə xarakterizə olunur. Əslində, Eclipse "uzatma nöqtələri" və "uzantılar" toplusudur.
- İş sahəsi — Bir və ya bir neçə layihəni idarə edir. Layihə birbaşa fayl sisteminə uyğunlaşdırılmış qovluq və fayllardan ibarətdir.
- Standart Vidcet Alətlər Dəsti (SWT) - Əməliyyat sistemi ilə inteqrasiya olunmuş əsas istifadəçi interfeysi elementlərini təmin edir.
- JFace — SWT üzərində qurulmuş bir sıra UI çərçivələrini təmin edir.
- Workbench — Eclipse UI paradiqmasını müəyyən edir: redaktorlar, baxışlar, perspektivlər.
Qeyd etmək lazımdır ki, Eclipse Platforması, həmçinin Sazlama, Müqayisə, Axtarış və Komanda daxil olmaqla inteqrasiya olunmuş inkişaf alətlərinin yaradılması üçün bir çox faydalı komponentlər təqdim edir. Mənbə kodunun “ağıllı redaktorlarının” qurulması üçün əsas olan JFace Text-i xüsusi qeyd etmək lazımdır. Təəssüf ki, hətta bu komponentlərin, eləcə də UI təbəqəsinin komponentlərinin kursor şəkildə araşdırılması bu məqalə çərçivəsində mümkün deyil, ona görə də bu bölmənin qalan hissəsində biz özümüzü əsas “əsas” komponentlərin icmalı ilə məhdudlaşdıracağıq. Eclipse Platforması və JDT.
Əsas iş vaxtı
Eclipse plagin infrastrukturu əsaslanır
Əsas iş sahəsi
Eclipse Platformasının üzərində qurulmuş demək olar ki, hər hansı inteqrasiya olunmuş inkişaf mühiti Eclipse iş sahəsi ilə işləyir. Adətən IDE-də hazırlanmış tətbiqin mənbə kodunu ehtiva edən iş sahəsidir. İş sahəsi birbaşa fayl sisteminə xəritə verir və qovluq və faylları ehtiva edən layihələrdən ibarətdir. Bu layihələr, qovluqlar və fayllar adlanır resurslar iş sahəsi. Eclipse-də iş sahəsinin tətbiqi fayl sistemi ilə əlaqəli bir keş kimi xidmət edir, bu da resurs ağacının keçidini əhəmiyyətli dərəcədə sürətləndirməyə imkan verir. Bundan əlavə, iş sahəsi də daxil olmaqla bir sıra əlavə xidmətlər təqdim edir
Əsas Resurslar komponenti (org.eclipse.core.resources plagini) iş sahəsini və onun resurslarını dəstəkləmək üçün məsuliyyət daşıyır. Xüsusilə, bu komponent formada iş sahəsinə proqramlı girişi təmin edir resurs modelləri. Bu modellə effektiv işləmək üçün müştərilərə resursa keçid təqdim etmək üçün sadə üsul lazımdır. Bu halda, modeldə resursun vəziyyətini birbaşa saxlayan obyekti müştəri girişindən gizlətmək arzuolunan olardı. Əks halda, məsələn, faylın silinməsi halında, müştəri daha sonra modeldə olmayan obyekti saxlamağa davam edə bilər. Eclipse adlı bir şeydən istifadə edərək bu problemi həll edir idarə resurs. Dəstək açar rolunu oynayır (yalnız iş yerində resursa gedən yolu bilir) və resursun vəziyyəti haqqında məlumatı birbaşa saxlayan daxili model obyektinə girişi tam idarə edir. Bu dizayn nümunənin bir variasiyasıdır
düyü. Şəkil 2 resurs modelinə tətbiq edilən Handle/Body idiomunu təsvir edir. IResource interfeysi bu interfeysi həyata keçirən Resurs sinifindən və API olmayan bədəni təmsil edən ResourceInfo sinfindən fərqli olaraq resursun idarəedicisini təmsil edir və API-dir. Biz vurğulayırıq ki, tutacaq yalnız iş sahəsinin kökünə nisbətən resursa gedən yolu bilir və resurs məlumatına keçidi ehtiva etmir. Resurs məlumatı obyektləri sözdə “element ağacı” təşkil edir. Bu məlumat strukturu tamamilə yaddaşda maddiləşdirilir. Dəstəyə uyğun resurs məlumatı nümunəsini tapmaq üçün element ağacı həmin tutacaqda saxlanılan yola uyğun olaraq keçilir.
düyü. 2. IResource və ResourceInfo
Daha sonra görəcəyimiz kimi, resurs modelinin əsas dizaynı (biz onu tutacaq əsaslı adlandıra bilərik) digər modellər üçün də Eclipse-də istifadə olunur. Hələlik bu dizaynın bəzi fərqli xüsusiyyətlərini sadalayaq:
- Dəstək dəyər obyektidir. Dəyər obyektləri bərabərliyi şəxsiyyətə əsaslanmayan dəyişməz obyektlərdir. Bu cür obyektlər hashed konteynerlərdə açar kimi etibarlı şəkildə istifadə edilə bilər. Dəstəyin bir neçə nümunəsi eyni mənbəyə istinad edə bilər. Onları müqayisə etmək üçün equals(Object) metodundan istifadə etməlisiniz.
- Handle resursun davranışını müəyyən edir, lakin resursun vəziyyəti haqqında məlumatı ehtiva etmir (onun saxladığı yeganə məlumat "açar", resursa gedən yoldur).
- Dəstək mövcud olmayan resursa istinad edə bilər (ya hələ yaradılmamış resurs, ya da artıq silinmiş resurs). Resursun mövcudluğu IResource.exists() metodu ilə yoxlanıla bilər.
- Bəzi əməliyyatlar yalnız sapın özündə saxlanılan məlumat əsasında həyata keçirilə bilər (sözdə yalnız tutucu əməliyyatlar). Nümunələr IResource.getParent(), getFullPath() və s. Belə bir əməliyyatın uğur qazanması üçün resursun mövcud olmasına ehtiyac yoxdur. Uğurlu olmaq üçün resursun mövcud olmasını tələb edən əməliyyatlar, əgər resurs mövcud deyilsə, istisna (CoreException) atır.
Eclipse iş sahəsinin resurs dəyişikliklərini bildirmək üçün səmərəli mexanizm təqdim edir (Şəkil 3). Resurslar ya Eclipse IDE-nin özündə həyata keçirilən hərəkətlər nəticəsində, ya da fayl sistemi ilə sinxronizasiya nəticəsində dəyişə bilər. Hər iki halda bildirişlərə abunə olan müştərilərə “resurs deltaları” şəklində dəyişikliklər haqqında ətraflı məlumat verilir. Delta iş sahəsi resursunun (alt) ağacının iki vəziyyəti arasındakı dəyişiklikləri təsvir edir və özü bir ağacdır, hər bir qovşağı resursdakı dəyişikliyi təsvir edir və uşaq resurslarında dəyişiklikləri təsvir edən növbəti səviyyədə deltaların siyahısını ehtiva edir.
düyü. 3. IResourceChangeEvent və IResourceDelta
Resurs deltalarına əsaslanan bildiriş mexanizmi aşağıdakı xüsusiyyətlərə malikdir:
- Delta rekursiv kompozisiya prinsipindən istifadə edilməklə qurulduğundan, tək dəyişiklik və bir çox dəyişikliklər eyni strukturdan istifadə etməklə təsvir olunur. Abunəçi müştərilər, deltalar ağacı vasitəsilə rekursiv enişdən istifadə edərək resurs dəyişikliyi bildirişlərini emal edə bilərlər.
- Delta resursdakı dəyişikliklər, o cümlədən onun hərəkəti və/və ya onunla əlaqəli "markerlər"dəki dəyişikliklər haqqında tam məlumatı ehtiva edir (məsələn, tərtib səhvləri markerlər kimi təqdim olunur).
- Resurs istinadları tutacaq vasitəsilə edildiyindən, delta təbii olaraq uzaq resursa istinad edə bilər.
Tezliklə görəcəyimiz kimi, resurs modelinin dəyişdirilməsi bildiriş mexanizminin dizaynının əsas komponentləri digər tutacaq əsaslı modellər üçün də aktualdır.
JDT nüvəsi
Eclipse iş sahəsi resursu modeli fundamental dil-aqnostik modeldir. JDT Core komponenti (plugin org.eclipse.jdt.core) “Java modeli” adlanan Java nöqteyi-nəzərindən iş sahəsi strukturunda naviqasiya və təhlil etmək üçün API təmin edir.Java modeli). Bu API, qovluqlar və fayllar baxımından müəyyən edilən əsas resurs modeli API-dən fərqli olaraq Java elementləri baxımından müəyyən edilir. Java element ağacının əsas interfeysləri Şəkil 4-də göstərilmişdir. XNUMX.
düyü. 4. Java Model Elementləri
Java modeli resurs modeli ilə eyni tutacaq/bədən deyimindən istifadə edir (Şəkil 5). IJavaElement tutacaq, JavaElementInfo isə bədən rolunu oynayır. IJavaElement interfeysi bütün Java elementləri üçün ümumi olan protokolu müəyyən edir. Onun bəzi üsulları yalnız idarəedicidir: getElementName(), getParent() və s. JavaElementInfo obyekti müvafiq elementin vəziyyətini saxlayır: onun strukturu və atributları.
düyü. 5. IJavaElement və JavaElementInfo
Java modeli resurs modeli ilə müqayisədə əsas tutacaq/gövdə dizaynının həyata keçirilməsində bəzi fərqlərə malikdir. Yuxarıda qeyd edildiyi kimi, resurs modelində qovşaqları resurs məlumat obyektləri olan element ağacı tamamilə yaddaşda saxlanılır. Lakin Java modeli resurs ağacından əhəmiyyətli dərəcədə daha çox elementə malik ola bilər, çünki o, həm də .java və .class fayllarının daxili strukturunu təmsil edir: növlər, sahələr və metodlar.
Yaddaşdakı bütün elementlər ağacını tamamilə həyata keçirməmək üçün Java modelinin tətbiqi element məlumatının məhdud ölçülü LRU keşindən istifadə edir, burada açar IJavaElement idarə edir. element info obyektləri element ağacı naviqasiya edildiyi üçün tələb əsasında yaradılır. Bu halda, ən az istifadə olunan elementlər keşdən çıxarılır və modelin yaddaş istehlakı müəyyən edilmiş keş ölçüsü ilə məhdudlaşır. Bu, belə icra detallarını müştəri kodundan tamamilə gizlədən tutacaq əsaslı dizaynın başqa bir üstünlüyüdür.
Java elementlərində dəyişikliklərin bildirilməsi mexanizmi ümumilikdə yuxarıda müzakirə olunan iş sahəsi resurslarında dəyişiklikləri izləmək mexanizminə bənzəyir. Java modelindəki dəyişiklikləri izləmək istəyən müştəri, IJavaElementDelta ehtiva edən ElementChangedEvent obyekti kimi təqdim olunan bildirişlərə abunə olur (Şəkil 6).
düyü. 6. ElementChangedEvent və IJavaElementDelta
Java modelində metod orqanları və ya adın həlli haqqında məlumat yoxdur, buna görə də Java-da yazılmış kodun ətraflı təhlili üçün JDT Core əlavə (qeyri-rəsmi əsaslı) model təqdim edir:
Sintaksis ağacları əhəmiyyətli miqdarda yaddaş istehlak edə bildiyinə görə, JDT aktiv redaktor üçün yalnız bir AST yaddaşını saxlayır. Java modelindən fərqli olaraq, AST adətən “aralıq”, “müvəqqəti” model kimi nəzərdən keçirilir, onun üzvləri AST-nin yaradılmasına səbəb olan əməliyyat kontekstindən kənarda müştərilər tərəfindən istinad edilməməlidir.
Sadalanan üç model (Java modeli, AST, bağlayıcılar) birlikdə JDT-də "ağıllı inkişaf alətləri" yaratmaq üçün əsas təşkil edir, o cümlədən müxtəlif "köməkçiləri" olan güclü Java redaktoru, mənbə kodunun işlənməsi üçün müxtəlif tədbirlər (idxal siyahısının təşkili daxil olmaqla). adlar və fərdiləşdirilmiş üsluba uyğun formatlaşdırma), axtarış və refaktorinq alətləri. Bu halda Java modeli xüsusi rol oynayır, çünki məhz inkişaf etdirilən proqramın strukturunun vizual təsviri üçün əsas kimi istifadə olunur (məsələn, Package Explorer, Outline, Search, Call Hierarchy və Tip iyerarxiyası).
1C: Enterprise Development Tools proqramında istifadə olunan Eclipse komponentləri
Şəkildə. Şəkil 7-də 1C: Enterprise Development Tools üçün texnoloji platformanın əsasını təşkil edən Eclipse komponentləri göstərilir.
düyü. 7. Eclipse 1C: Enterprise Development Tools üçün platforma kimi
Eclipse Platforması əsas infrastrukturu təmin edir. Biz əvvəlki bölmədə bu infrastrukturun bəzi aspektlərinə baxdıq.
Hər hansı bir həqiqi ümumi təyinatlı alət kimi, EMF geniş çeşidli modelləşdirmə problemlərinin həlli üçün uyğundur, lakin bəzi model sinifləri (məsələn, yuxarıda müzakirə olunan tutacaq əsaslı modellər) daha ixtisaslaşmış modelləşdirmə vasitələri tələb edə bilər. EMF haqqında danışmaq, xüsusən də bir məqalənin məhdud sərhədləri daxilində nankor bir işdir, çünki bu ayrıca bir kitabın mövzusudur və kifayət qədər qalındır. Yalnız qeyd edək ki, EMF-nin əsasını təşkil edən yüksək keyfiyyətli ümumiləşdirmə sistemi yüksək səviyyəli layihəyə daxil olan modelləşdirməyə həsr olunmuş bütün layihələrin yaranmasına imkan verdi.
1C: Müəssisə İnkişafı Alətləri həm EMF-nin özündən, həm də bir sıra digər Eclipse Modeling layihələrindən fəal şəkildə istifadə edir. Xüsusilə, Xtext daxili proqramlaşdırma dili və sorğu dili kimi 1C: Enterprise dilləri üçün inkişaf vasitələrinin əsaslarından biridir. Bu inkişaf alətləri üçün başqa bir əsas daha ətraflı müzakirə edəcəyimiz Eclipse Handly layihəsidir (sadalanan Eclipse komponentlərindən hələ də ən az tanınır).
Dəstək/bədən deyimi kimi tutacaq əsaslı modellərin əsas memarlıq prinsipləri yuxarıda resurs modeli və Java modelindən nümunə kimi istifadə edilərək müzakirə edilmişdir. O, həmçinin qeyd etdi ki, həm resurs modeli, həm də Java modeli Eclipse Java inkişaf alətləri (JDT) üçün mühüm təməllərdir. Demək olar ki, bütün *DT Eclipse layihələri JDT-ə bənzər bir arxitekturaya malik olduğundan, tutacaq əsaslı modellərin Eclipse Platformasının üstündə qurulmuş bütün IDE-lərin olmasa da, bir çoxunun əsasını təşkil etdiyini söyləmək böyük şişirtmə olmaz. Məsələn, Eclipse C/C++ İnkişaf Alətləri (CDT), Java modelinin JDT-də oynadığı kimi CDT arxitekturasında eyni rolu oynayan sapa əsaslanan C/C++ modelinə malikdir.
Handly-dən əvvəl Eclipse sapa əsaslanan dil modelləri yaratmaq üçün xüsusi kitabxanalar təklif etmirdi. Hazırda mövcud olan modellər əsasən Java model kodunu birbaşa uyğunlaşdırmaqla yaradılmışdır (a.k.a. copy/paste), imkan verdiyi hallarda Eclipse Public License (EPL). (Aydındır ki, bu, adətən, məsələn, Eclipse layihələrinin özü üçün hüquqi problem deyil, lakin qapalı mənbəli məhsullar üçün deyil.) Bu texnika özünəməxsus təsadüfiliyinə əlavə olaraq, məlum problemləri təqdim edir: səhvlərə uyğunlaşarkən kodun təkrarlanması, və s. Ən pisi odur ki, ortaya çıxan modellər “özlüyündə şeylər” olaraq qalır və birləşmə potensialından istifadə etmirlər. Lakin tutacaq əsaslı dil modelləri üçün ümumi konsepsiyaların və protokolların təcrid edilməsi, EMF vəziyyətində baş verənlərə bənzər, onlarla işləmək üçün təkrar istifadə edilə bilən komponentlərin yaradılmasına səbəb ola bilər.
Eclipse bu məsələləri başa düşmədi. 2005-ci ildə
Müəyyən mənada Handly layihəsi EMF ilə təxminən eyni problemləri həll etmək üçün nəzərdə tutulmuşdur, lakin tutacaq əsaslı modellər və ilk növbədə dil modelləri (yəni, bəzi proqramlaşdırma dilinin struktur elementlərini təmsil edən) üçün. Handly dizaynı zamanı qarşıya qoyulan əsas məqsədlər aşağıda verilmişdir:
- Mövzu sahəsinin əsas abstraksiyalarının müəyyən edilməsi.
- Koddan təkrar istifadə yolu ilə qulp əsaslı dil modellərinin həyata keçirilməsinin keyfiyyətinin artırılması və səylərin azaldılması.
- Yaranan modellərə vahid meta-səviyyəli API təqdim edərək, dil idarəçiliyinə əsaslanan modellərlə işləyən ümumi IDE komponentləri yaratmağa imkan verir.
- Çeviklik və miqyaslılıq.
- Xtext ilə inteqrasiya (ayrı bir təbəqədə).
Ümumi konsepsiyaları və protokolları vurğulamaq üçün dil idarəsinə əsaslanan modellərin mövcud tətbiqləri təhlil edilmişdir. Handly tərəfindən təmin edilən əsas interfeyslər və əsas tətbiqlər Şek. 8.
düyü. 8. Ümumi interfeyslər və Handly elementlərinin əsas tətbiqləri
IElement interfeysi elementin sapını təmsil edir və bütün Handly əsaslı modellərin elementləri üçün ümumidir. Abstrakt sinif Element ümumiləşdirilmiş tutacaq/gövdə mexanizmini həyata keçirir (şək. 9).
düyü. 9. IElement və ümumi tutacaq/bədənin icrası
Bundan əlavə, Handly model elementlərindəki dəyişikliklər haqqında məlumat vermək üçün ümumiləşdirilmiş mexanizm təqdim edir (şək. 10). Gördüyünüz kimi, o, resurs modelində və Java modelində həyata keçirilən bildiriş mexanizmlərinə geniş şəkildə bənzəyir və element dəyişikliyi məlumatının vahid təqdimatını təmin etmək üçün IElementDelta-dan istifadə edir.
düyü. 10. Handly bildiriş mexanizminin ümumi interfeysləri və əsas tətbiqləri
Yuxarıda müzakirə edilən Handly hissəsi (şək. 9 və 10) demək olar ki, hər hansı tutacaq əsaslı modelləri təmsil etmək üçün istifadə edilə bilər. Yaratmaq üçün Dilçilik modellər üçün layihə əlavə funksionallıq təklif edir - xüsusən də ümumi interfeyslər və mənbə mətn strukturunun elementləri üçün əsas tətbiqlər, sözdə mənbə elementləri (şək. 8). ISourceFile interfeysi mənbə faylı, ISourceConstruct isə mənbə faylı daxilindəki elementi təmsil edir. SourceFile və SourceConstruct mücərrəd sinifləri mənbə faylları və onların elementləri ilə işləməyi dəstəkləmək üçün ümumiləşdirilmiş mexanizmləri həyata keçirir, məsələn, mətn buferləri ilə işləmək, mənbə mətndəki elementin koordinatlarına bağlamaq, modelləri işləyən surət buferinin cari məzmunu ilə tutuşdurmaq. və s. Bu mexanizmlərin həyata keçirilməsi adətən olduqca çətin olur və Handly yüksək keyfiyyətli əsas tətbiqetmələri təmin etməklə tutacaq əsaslı dil modellərinin hazırlanması səylərini əhəmiyyətli dərəcədə azalda bilər.
Yuxarıda sadalanan əsas mexanizmlərə əlavə olaraq, Handly mətn buferləri və snapshotlar üçün infrastruktur, mənbə kodu redaktorları ilə inteqrasiya dəstəyi (o cümlədən Xtext redaktoru ilə qutudan kənar inteqrasiya), eləcə də bəzi ümumi UI komponentlərini təmin edir. mənbə kodu redaktorları ilə işləmək, kontur çərçivəsi kimi əllə işləyən modellər. Onun imkanlarını göstərmək üçün layihə Handly-də Java modelinin tətbiqi də daxil olmaqla bir neçə nümunə təqdim edir. (Java modelinin JDT-də tam tətbiqi ilə müqayisədə, bu model daha aydınlıq üçün qəsdən bir qədər sadələşdirilmişdir.)
Daha əvvəl qeyd edildiyi kimi, Handly-nin ilkin dizaynı və sonrakı inkişafı zamanı əsas diqqət miqyaslılıq və çeviklik idi və olmaqda davam edir.
Prinsipcə, tutacaq əsaslı modellər "dizayn baxımından" kifayət qədər yaxşı ölçülür. Məsələn, tutacaq/bədən deyimi modelin istehlak etdiyi yaddaşın miqdarını məhdudlaşdırmağa imkan verir. Ancaq nüanslar da var. Beləliklə, Handly-ni miqyaslılıq üçün sınaqdan keçirərkən, bildiriş mexanizminin tətbiqində problem aşkar edildi - çox sayda element dəyişdirildikdə, deltaların qurulması çox vaxt apardı. Məlum oldu ki, eyni problem JDT Java modelində də mövcud olub, ondan bir vaxtlar müvafiq kod uyğunlaşdırılıb. Biz Handly-də səhvi düzəltdik və JDT üçün oxşar yamaq hazırladıq, bu, minnətdarlıqla qəbul edildi. Bu, mövcud model tətbiqlərinə Handly tətbiqinin potensial olaraq faydalı ola biləcəyi bir nümunədir, çünki bu halda belə bir səhv yalnız bir yerdə düzəldilə bilər.
Handly proqramını mövcud model tətbiqlərinə texniki cəhətdən mümkün etmək üçün kitabxana əhəmiyyətli çevikliyə malik olmalıdır. Əsas problem API modeli üzrə geriyə uyğunluğu qorumaqdır. Bu problem ildə həll edildi
Çevikliyin başqa aspektləri də var. Məsələn, Handly modelin strukturuna demək olar ki, heç bir məhdudiyyət qoymur və həm ümumi təyinatlı, həm də domenə xas dilləri modelləşdirmək üçün istifadə edilə bilər. Mənbə faylının strukturunu qurarkən Handly AST təmsilinin hər hansı xüsusi formasını təyin etmir və prinsipcə, hətta AST-nin özünün olmasını tələb etmir, beləliklə, demək olar ki, hər hansı təhlil mexanizmi ilə uyğunluğu təmin edir. Nəhayət, Handly Eclipse iş sahəsi ilə tam inteqrasiyanı dəstəkləyir, eyni zamanda fayl sistemləri ilə inteqrasiyası sayəsində birbaşa işləyə bilər.
Cari versiya
Yuxarıda qeyd edildiyi kimi, bu məhsullardan biri 1C: Enterprise Development Tools-dur, burada Handly əvvəldən daxili proqramlaşdırma dili və sorğu dili kimi 1C: Enterprise dillərinin yüksək səviyyəli strukturunun elementlərini modelləşdirmək üçün istifadə olunur. . Başqa bir məhsul geniş ictimaiyyətə az məlumdur. Bu
Ümid edirik ki, API sabitliyi zəmanəti ilə 1.0 versiyasının buraxılmasından və layihənin inkubasiya vəziyyətindən çıxmasından sonra Handly-nin yeni qəbulediciləri olacaq. Bu vaxt, layihə API-ni sınaqdan keçirməyə və daha da təkmilləşdirməyə davam edir, ildə iki "əsas" buraxılış - iyunda (eyni zamanda Eclipse buraxılışı ilə eyni tarixdə) və dekabrda, qəbul edənlərin etibar edə biləcəyi proqnozlaşdırıla bilən cədvəl təqdim edir. Onu da əlavə edə bilərik ki, layihənin “səhv nisbəti” davamlı olaraq aşağı səviyyədə qalır və Handly ilk versiyalardan bəri erkən tətbiq edənlərin məhsullarında etibarlı şəkildə işləyir. Eclipse Handly-i daha çox araşdırmaq üçün istifadə edə bilərsiniz
Mənbə: www.habr.com