mungkin,
Dalam artikel ini, yang merupakan gambaran keseluruhan, kami akan cuba melihat beberapa asas seni bina Eclipse sebagai platform untuk membina alat pembangunan bersepadu dan memberi idea awal tentang komponen Eclipse yang membentuk asas teknologi. platform untuk "Konfigurator baharu" 1C: Perusahaan.
Pengenalan kepada Eclipse Architecture
Mari kita lihat beberapa aspek umum seni bina Eclipse menggunakan contoh
Pertama sekali, perlu diingatkan bahawa Eclipse dicirikan oleh lapisan seni bina yang agak jelas, dengan pemisahan fungsi bebas bahasa daripada fungsi yang direka untuk menyokong bahasa pengaturcaraan tertentu, dan pemisahan komponen "teras" bebas UI daripada komponen yang berkaitan. dengan antara muka pengguna yang menyokong.
Oleh itu, Platform Eclipse mentakrifkan infrastruktur bebas bahasa yang lazim, dan alatan pembangunan Java menambah IDE Java berciri penuh kepada Eclipse. Kedua-dua Platform Eclipse dan JDT terdiri daripada beberapa komponen, setiap satunya tergolong dalam "teras" bebas UI atau lapisan UI (Rajah 1).
nasi. 1. Platform Eclipse dan JDT
Mari kita senaraikan komponen utama Platform Eclipse:
- Runtime β Mentakrifkan infrastruktur pemalam. Eclipse dicirikan oleh seni bina modular. Pada asasnya, Eclipse ialah koleksi "titik lanjutan" dan "sambungan".
- Ruang kerja β Menguruskan satu atau lebih projek. Projek terdiri daripada folder dan fail yang dipetakan terus ke sistem fail.
- Kit Alat Widget Standard (SWT) - Menyediakan elemen antara muka pengguna asas yang disepadukan dengan sistem pengendalian.
- JFace β Menyediakan beberapa rangka kerja UI yang dibina di atas SWT.
- Workbench β Mentakrifkan paradigma UI Eclipse: editor, pandangan, perspektif.
Perlu dikatakan bahawa Platform Eclipse juga menyediakan banyak komponen berguna lain untuk membina alat pembangunan bersepadu, termasuk Nyahpepijat, Bandingkan, Cari dan Pasukan. Sebutan khusus harus dibuat tentang Teks JFace - asas untuk membina "editor pintar" kod sumber. Malangnya, walaupun pemeriksaan sepintas lalu bagi komponen ini, serta komponen lapisan UI, tidak boleh dilakukan dalam skop artikel ini, jadi dalam baki bahagian ini, kami akan mengehadkan diri kami kepada gambaran keseluruhan komponen "teras" utama Platform Eclipse dan JDT.
Masa Jalanan Teras
Infrastruktur pemalam Eclipse adalah berdasarkan
Ruang Kerja Teras
Hampir mana-mana persekitaran pembangunan bersepadu yang dibina di atas Platform Eclipse berfungsi dengan ruang kerja Eclipse. Ia adalah ruang kerja yang biasanya mengandungi kod sumber aplikasi yang dibangunkan dalam IDE. Ruang kerja memetakan terus ke sistem fail dan terdiri daripada projek yang mengandungi folder dan fail. Projek, folder dan fail ini dipanggil sumber ruang kerja. Pelaksanaan ruang kerja dalam Eclipse berfungsi sebagai cache berhubung dengan sistem fail, yang memungkinkan untuk mempercepatkan traversan pepohon sumber dengan ketara. Di samping itu, ruang kerja menyediakan beberapa perkhidmatan tambahan, termasuk
Komponen Sumber Teras (org.eclipse.core.resources plugin) bertanggungjawab untuk menyokong ruang kerja dan sumbernya. Khususnya, komponen ini menyediakan akses terprogram kepada ruang kerja dalam bentuk model sumber. Untuk bekerja dengan berkesan dengan model ini, pelanggan memerlukan cara mudah untuk membentangkan pautan ke sumber. Dalam kes ini, adalah wajar untuk menyembunyikan objek yang menyimpan secara langsung keadaan sumber dalam model daripada akses klien. Jika tidak, dalam kes, sebagai contoh, memadamkan fail, pelanggan boleh terus memegang objek yang tiada lagi dalam model, dengan masalah yang seterusnya. Eclipse menyelesaikan masalah ini menggunakan sesuatu yang dipanggil mengendalikan sumber. Handle bertindak sebagai kunci (ia hanya mengetahui laluan ke sumber dalam ruang kerja) dan mengawal sepenuhnya akses kepada objek model dalaman, yang secara langsung menyimpan maklumat tentang keadaan sumber. Reka bentuk ini adalah variasi corak
nasi. Rajah 2 menggambarkan simpulan bahasa Handle/Body seperti yang digunakan pada model sumber. Antara muka IResource mewakili pemegang sumber dan merupakan API, tidak seperti kelas Sumber, yang melaksanakan antara muka ini dan kelas ResourceInfo, yang mewakili badan, yang bukan API. Kami menekankan bahawa pemegang hanya mengetahui laluan ke sumber berbanding akar ruang kerja dan tidak mengandungi pautan ke maklumat sumber. Objek maklumat sumber membentuk apa yang dipanggil "pokok elemen". Struktur data ini terwujud sepenuhnya dalam ingatan. Untuk mencari contoh maklumat sumber yang sepadan dengan pemegang, pepohon elemen dilalui mengikut laluan yang disimpan dalam pemegang itu.
nasi. 2. IResource dan ResourceInfo
Seperti yang akan kita lihat kemudian, reka bentuk asas model sumber (kita mungkin memanggilnya berasaskan pemegang) digunakan dalam Eclipse untuk model lain juga. Buat masa ini, mari kita senaraikan beberapa ciri tersendiri reka bentuk ini:
- Pemegang ialah objek nilai. Objek nilai ialah objek tidak berubah yang persamaannya tidak berdasarkan identiti. Objek sedemikian boleh digunakan dengan selamat sebagai kunci dalam bekas cincang. Beberapa contoh pemegang boleh merujuk sumber yang sama. Untuk membandingkannya, anda perlu menggunakan kaedah equals(Object).
- Handle mentakrifkan kelakuan sumber, tetapi tidak mengandungi maklumat tentang keadaan sumber (satu-satunya data yang disimpan ialah "kunci", laluan ke sumber).
- Handle boleh merujuk kepada sumber yang tidak wujud (sama ada sumber yang belum dicipta atau sumber yang telah dipadamkan). Kewujudan sumber boleh disemak menggunakan kaedah IResource.exists().
- Sesetengah operasi boleh dilaksanakan berdasarkan maklumat yang disimpan dalam pemegang itu sendiri (yang dipanggil operasi pemegang sahaja). Contohnya ialah IResource.getParent(), getFullPath(), dsb. Sumber tidak perlu wujud untuk operasi sedemikian berjaya. Operasi yang memerlukan sumber wujud untuk berjaya membuang CoreException jika sumber itu tidak wujud.
Eclipse menyediakan mekanisme yang cekap untuk memberitahu perubahan sumber ruang kerja (Rajah 3). Sumber boleh berubah sama ada akibat tindakan yang dilakukan dalam Eclipse IDE itu sendiri atau akibat penyegerakan dengan sistem fail. Dalam kedua-dua kes, pelanggan yang melanggan pemberitahuan diberikan maklumat terperinci tentang perubahan dalam bentuk "delta sumber". Delta menerangkan perubahan antara dua keadaan pokok sumber ruang kerja (sub-) dan merupakan pokok itu sendiri, setiap nodnya menerangkan perubahan kepada sumber dan mengandungi senarai delta pada peringkat seterusnya yang menerangkan perubahan kepada sumber kanak-kanak.
nasi. 3. IResourceChangeEvent dan IResourceDelta
Mekanisme pemberitahuan berdasarkan delta sumber mempunyai ciri-ciri berikut:
- Satu perubahan dan banyak perubahan diterangkan menggunakan struktur yang sama, kerana delta dibina menggunakan prinsip komposisi rekursif. Pelanggan pelanggan boleh memproses pemberitahuan perubahan sumber menggunakan turunan rekursif melalui pokok delta.
- Delta mengandungi maklumat lengkap tentang perubahan kepada sumber, termasuk pergerakannya dan/atau perubahan dalam "penanda" yang dikaitkan dengannya (contohnya, ralat kompilasi diwakili sebagai penanda).
- Memandangkan rujukan sumber dibuat melalui pemegang, delta secara semula jadi boleh merujuk sumber jauh.
Seperti yang akan kita lihat tidak lama lagi, komponen utama reka bentuk mekanisme pemberitahuan perubahan model sumber juga relevan untuk model berasaskan pemegang yang lain.
Teras JDT
Model sumber ruang kerja Eclipse ialah model agnostik bahasa asas. Komponen Teras JDT (plugin org.eclipse.jdt.core) menyediakan API untuk menavigasi dan menganalisis struktur ruang kerja dari perspektif Java, yang dipanggil "model Java" (model Java). API ini ditakrifkan dari segi unsur Java, berbanding dengan API model sumber asas, yang ditakrifkan dari segi folder dan fail. Antara muka utama pokok elemen Java ditunjukkan dalam Rajah. 4.
nasi. 4. Elemen Model Java
Model Java menggunakan simpulan bahasa pemegang/badan yang sama seperti model sumber (Rajah 5). IJavaElement ialah pemegang, dan JavaElementInfo memainkan peranan badan. Antara muka IJavaElement mentakrifkan protokol yang biasa kepada semua elemen Java. Beberapa kaedahnya adalah pemegang sahaja: getElementName(), getParent(), dsb. Objek JavaElementInfo menyimpan keadaan elemen yang sepadan: struktur dan atributnya.
nasi. 5. IJavaElement dan JavaElementInfo
Model Java mempunyai beberapa perbezaan dalam pelaksanaan reka bentuk pemegang/badan asas berbanding dengan model sumber. Seperti yang dinyatakan di atas, dalam model sumber, pokok elemen, yang nodnya ialah objek maklumat sumber, terkandung sepenuhnya dalam ingatan. Tetapi model Java boleh mempunyai bilangan elemen yang jauh lebih besar daripada pepohon sumber, kerana ia juga mewakili struktur dalaman fail .java dan .class: jenis, medan dan kaedah.
Untuk mengelak daripada merealisasikan keseluruhan pokok elemen dalam ingatan, pelaksanaan model Java menggunakan cache LRU saiz terhad bagi maklumat elemen, di mana kuncinya adalah mengendalikan IJavaElement. objek maklumat unsur dicipta atas permintaan kerana pepohon elemen dilayari. Dalam kes ini, item yang paling kurang kerap digunakan akan dikeluarkan daripada cache, dan penggunaan memori model kekal terhad kepada saiz cache yang ditentukan. Ini adalah satu lagi kelebihan reka bentuk berasaskan pemegang, yang menyembunyikan sepenuhnya butiran pelaksanaan tersebut daripada kod klien.
Mekanisme untuk memberitahu perubahan kepada elemen Java secara umum adalah serupa dengan mekanisme untuk menjejaki perubahan kepada sumber ruang kerja yang dibincangkan di atas. Pelanggan yang ingin memantau perubahan dalam model Java melanggan pemberitahuan, yang diwakili sebagai objek ElementChangedEvent yang mengandungi IJavaElementDelta (Rajah 6).
nasi. 6. ElementChangedEvent dan IJavaElementDelta
Model Java tidak mengandungi maklumat tentang badan kaedah atau resolusi nama, jadi untuk analisis terperinci kod yang ditulis dalam Java, JDT Core menyediakan model tambahan (bukan berasaskan pemegang):
Oleh kerana pepohon sintaks boleh menggunakan sejumlah besar memori, JDT hanya menyimpan satu AST untuk editor aktif. Berbeza dengan model Java, AST biasanya dilihat sebagai model "perantaraan," "sementara" yang ahlinya tidak sepatutnya dirujuk oleh pelanggan di luar konteks operasi yang membawa kepada penciptaan AST.
Tiga model yang disenaraikan (model Java, AST, bindings) bersama-sama membentuk asas untuk membina "alat pembangunan pintar" dalam JDT, termasuk editor Java yang berkuasa dengan pelbagai "pembantu", pelbagai tindakan untuk memproses kod sumber (termasuk mengatur senarai import nama dan pemformatan mengikut gaya tersuai), alat carian dan pemfaktoran semula. Dalam kes ini, model Java memainkan peranan khas, kerana ialah yang digunakan sebagai asas untuk perwakilan visual struktur aplikasi yang sedang dibangunkan (contohnya, dalam Package Explorer, Outline, Search, Call Hierarchy, dan Hierarki Jenis).
Komponen Eclipse yang digunakan dalam 1C:Enterprise Developments Tools
Dalam Rajah. Rajah 7 menunjukkan komponen Eclipse yang membentuk asas platform teknologi untuk 1C:Enterprise Development Tools.
nasi. 7. Eclipse sebagai platform untuk 1C:Enterprise Development Tools
Platform Eclipse menyediakan infrastruktur asas. Kami melihat beberapa aspek infrastruktur ini dalam bahagian sebelumnya.
Seperti mana-mana alat yang benar-benar tujuan am, EMF sesuai untuk menyelesaikan pelbagai masalah pemodelan, tetapi sesetengah kelas model (contohnya, model berasaskan pemegang yang dibincangkan di atas) mungkin memerlukan alat pemodelan yang lebih khusus. Bercakap tentang EMF adalah tugas yang tidak berguna, terutamanya dalam had terhad satu artikel, kerana ini adalah subjek buku yang berasingan, dan yang agak tebal. Mari kita ambil perhatian bahawa sistem generalisasi berkualiti tinggi yang mendasari EMF membenarkan kelahiran pelbagai projek khusus untuk pemodelan, yang termasuk dalam projek peringkat atasan.
1C:Enterprise Development Tools secara aktif menggunakan kedua-dua EMF itu sendiri dan beberapa projek Pemodelan Eclipse yang lain. Khususnya, Xtext ialah salah satu asas alat pembangunan untuk bahasa 1C:Enterprise seperti bahasa pengaturcaraan dan bahasa pertanyaan terbina dalam. Asas lain untuk alat pembangunan ini ialah projek Eclipse Handly, yang akan kami bincangkan dengan lebih terperinci (daripada komponen Eclipse yang disenaraikan, ia masih paling kurang diketahui).
Prinsip seni bina asas model berasaskan pemegang, seperti simpulan bahasa pemegang/badan, telah dibincangkan di atas menggunakan model sumber dan model Java sebagai contoh. Ia juga menyatakan bahawa kedua-dua model sumber dan model Java adalah asas penting untuk alat pembangunan Eclipse Java (JDT). Dan memandangkan hampir semua projek *DT Eclipse mempunyai seni bina yang serupa dengan JDT, tidaklah keterlaluan untuk mengatakan bahawa model berasaskan pemegang mendasari banyak, jika tidak semua IDE yang dibina di atas Platform Eclipse. Contohnya, Eclipse C/C++ Development Tooling (CDT) mempunyai model C/C++ berasaskan pemegang yang memainkan peranan yang sama dalam seni bina CDT seperti model Java dalam JDT.
Sebelum Handly, Eclipse tidak menawarkan perpustakaan khusus untuk membina model bahasa berasaskan pemegang. Model yang wujud pada masa ini dicipta terutamanya dengan menyesuaikan kod model Java secara langsung (aka copy/paste), dalam kes di mana ia membenarkan Lesen Awam Eclipse (EPL). (Jelas sekali, ini biasanya bukan isu undang-undang untuk, katakan, Eclipse memproyeksikan sendiri, tetapi bukan untuk produk sumber tertutup.) Di samping ketidakseimbangan yang wujud, teknik ini memperkenalkan masalah yang terkenal: pertindihan kod yang diperkenalkan oleh apabila menyesuaikan diri dengan ralat, dan lain-lain. Apa yang lebih buruk ialah model yang dihasilkan kekal sebagai "perkara dalam diri mereka sendiri" dan tidak mengambil kesempatan daripada potensi untuk penyatuan. Tetapi mengasingkan konsep dan protokol biasa untuk model bahasa berasaskan pemegang boleh membawa kepada penciptaan komponen boleh guna semula untuk bekerja dengannya, sama seperti yang berlaku dalam kes EMF.
Bukannya Eclipse tidak memahami isu ini. Kembali pada tahun 2005
Dalam erti kata tertentu, projek Handly direka untuk menyelesaikan lebih kurang masalah yang sama seperti EMF, tetapi untuk model berasaskan pemegang, dan terutamanya bahasa (iaitu, mewakili elemen struktur beberapa bahasa pengaturcaraan). Matlamat utama yang ditetapkan semasa mereka bentuk Handly disenaraikan di bawah:
- Pengenalpastian abstraksi utama kawasan subjek.
- Mengurangkan usaha dan meningkatkan kualiti pelaksanaan model bahasa berasaskan pemegang melalui penggunaan semula kod.
- Menyediakan API peringkat meta bersatu kepada model yang terhasil, membolehkan anda mencipta komponen IDE biasa yang berfungsi dengan model berasaskan pemegang bahasa.
- Fleksibiliti dan skalabiliti.
- Integrasi dengan Xtext (dalam lapisan berasingan).
Untuk menyerlahkan konsep dan protokol biasa, pelaksanaan sedia ada model berasaskan pengendalian bahasa telah dianalisis. Antara muka utama dan pelaksanaan asas yang disediakan oleh Handly ditunjukkan dalam Rajah. 8.
nasi. 8. Antara muka biasa dan pelaksanaan asas elemen Handly
Antara muka IElement mewakili pemegang elemen dan biasa kepada elemen semua model berasaskan Handly. Elemen kelas abstrak melaksanakan mekanisme pemegang/badan umum (Rajah 9).
nasi. 9. Ielemen dan pelaksanaan pemegang/badan generik
Di samping itu, Handly menyediakan mekanisme umum untuk memberitahu tentang perubahan dalam elemen model (Rajah 10). Seperti yang anda lihat, ia secara amnya serupa dengan mekanisme pemberitahuan yang dilaksanakan dalam model sumber dan model Java, dan menggunakan IElementDelta untuk menyediakan perwakilan bersatu maklumat perubahan elemen.
nasi. 10. Antara muka umum dan pelaksanaan asas mekanisme pemberitahuan Handly
Bahagian Handly yang dibincangkan di atas (Rajah 9 dan 10) boleh digunakan untuk mewakili hampir semua model berasaskan pemegang. Untuk mencipta linguistik model, projek ini menawarkan fungsi tambahan - khususnya, antara muka biasa dan pelaksanaan asas untuk elemen struktur teks sumber, yang dipanggil unsur sumber (Gamb. 8). Antara muka ISourceFile mewakili fail sumber, dan ISourceConstruct mewakili elemen dalam fail sumber. Kelas abstrak SourceFile dan SourceConstruct melaksanakan mekanisme umum untuk menyokong kerja dengan fail sumber dan elemennya, contohnya, bekerja dengan penimbal teks, mengikat koordinat elemen dalam teks sumber, menyelaraskan model dengan kandungan semasa penimbal salinan yang berfungsi , dan lain-lain. Melaksanakan mekanisme ini biasanya agak mencabar, dan Handly boleh mengurangkan dengan ketara usaha membangunkan model bahasa berasaskan pemegang dengan menyediakan pelaksanaan asas berkualiti tinggi.
Sebagai tambahan kepada mekanisme teras yang disenaraikan di atas, Handly menyediakan infrastruktur untuk penimbal teks dan syot kilat, sokongan untuk penyepaduan dengan editor kod sumber (termasuk penyepaduan luar kotak dengan editor Xtext), serta beberapa komponen UI biasa yang bekerja dengan editor kod sumber. Model yang mudah digunakan seperti rangka kerja rangka kerja. Untuk menggambarkan keupayaannya, projek ini menyediakan beberapa contoh, termasuk pelaksanaan model Java dalam Handly. (Berbanding dengan pelaksanaan penuh model Java dalam JDT, model ini sengaja dipermudahkan untuk lebih jelas.)
Seperti yang dinyatakan sebelum ini, tumpuan utama semasa reka bentuk awal Handly dan pembangunan seterusnya adalah dan terus berskala dan fleksibiliti.
Pada dasarnya, model berasaskan pemegang berskala dengan baik "mengikut reka bentuk". Sebagai contoh, simpulan bahasa pemegang/badan membolehkan anda mengehadkan jumlah memori yang digunakan oleh model. Tetapi terdapat juga nuansa. Oleh itu, apabila menguji Handly untuk skalabiliti, masalah ditemui dalam pelaksanaan mekanisme pemberitahuan - apabila sejumlah besar elemen ditukar, membina delta mengambil masa terlalu lama. Ternyata masalah yang sama terdapat dalam model Java JDT, dari mana kod yang sepadan pernah disesuaikan. Kami membetulkan pepijat dalam Handly dan menyediakan tampung yang serupa untuk JDT, yang diterima dengan penuh rasa syukur. Ini hanyalah satu contoh yang memperkenalkan Handly ke dalam pelaksanaan model sedia ada berpotensi berguna, kerana dalam kes ini pepijat seperti itu boleh dibetulkan di satu tempat sahaja.
Untuk menjadikan pelaksanaan Handly ke dalam pelaksanaan model sedia ada boleh dilaksanakan secara teknikal, perpustakaan mesti mempunyai fleksibiliti yang ketara. Masalah utama adalah untuk mengekalkan keserasian ke belakang merentas model API. Masalah ini telah diselesaikan dalam
Fleksibiliti mempunyai aspek lain juga. Sebagai contoh, Handly tidak mengenakan sekatan pada struktur model dan boleh digunakan untuk memodelkan kedua-dua bahasa tujuan am dan khusus domain. Apabila membina struktur fail sumber, Handly tidak menetapkan sebarang bentuk perwakilan AST tertentu dan, pada dasarnya, tidak memerlukan kehadiran AST itu sendiri, dengan itu memastikan keserasian dengan hampir mana-mana mekanisme penghuraian. Akhir sekali, Handly menyokong penyepaduan penuh dengan ruang kerja Eclipse, tetapi juga boleh berfungsi secara langsung dengan sistem fail berkat penyepaduannya dengan
Versi terkini
Seperti yang dinyatakan di atas, salah satu daripada produk ini ialah 1C:Enterprise Development Tools, di mana Handly digunakan dari awal lagi untuk memodelkan elemen struktur peringkat tinggi seperti 1C:Enterprise bahasa sebagai bahasa pengaturcaraan dan bahasa pertanyaan terbina dalam. . Satu lagi produk kurang diketahui oleh masyarakat umum. ini
Kami berharap selepas keluaran versi 1.0 dengan jaminan kestabilan API dan projek meninggalkan keadaan pengeraman, Handly akan mempunyai pengguna baharu. Sementara itu, projek itu terus menguji dan menambah baik API, mengeluarkan dua keluaran "utama" setiap tahun - pada bulan Jun (tarikh yang sama dengan keluaran Eclipse serentak) dan Disember, menyediakan jadual yang boleh diramal yang boleh dipercayai oleh pengguna. Kami juga boleh menambah bahawa "kadar pepijat" projek kekal pada tahap rendah secara konsisten dan Handly telah bekerja dengan pasti dalam produk pengguna awal sejak versi pertama. Untuk meneroka lebih lanjut Eclipse Handly, anda boleh gunakan
Sumber: www.habr.com