Магадгүй тусгай танилцуулга хэрэггүй болоод удаж байна. Eclipse Java хөгжүүлэлтийн хэрэгслүүдийн ачаар олон хүмүүс Eclipse-ийг мэддэг.). Энэхүү алдартай нээлттэй эхийн Java IDE нь ихэнх хөгжүүлэгчид "Eclipse" гэсэн үгтэй холбоотой байдаг. Гэсэн хэдий ч Eclipse нь хөгжүүлэлтийн хэрэгслүүдийг (Eclipse платформ) нэгтгэх өргөтгөх боломжтой платформ бөгөөд үүний үндсэн дээр JDT гэх мэт олон тооны IDE-ууд байдаг. Eclipse нь Eclipse Platform болон JDT-ийн хөгжлийг зохицуулдаг дээд түвшний төсөл болох Eclipse Project, мөн Eclipse SDK нь уг хөгжүүлэлтийн үр дүн юм. Эцэст нь хэлэхэд, Eclipse бол бүгд Java хэл дээр бичигдээгүй эсвэл хөгжүүлэлтийн хэрэгслүүдтэй (жишээлбэл, төслүүд) холбогдоогүй асар том төслүүдтэй нээлттэй эхийн сан юм. и ). Eclipse-ийн ертөнц маш олон янз байдаг.
Байгалийн тоймтой энэхүү нийтлэлд бид Eclipse архитектурын зарим үндсийг цогц хөгжүүлэлтийн хэрэгслийг бий болгох платформ болгон авч үзэхийг хичээж, технологийн үндэс суурийг бүрдүүлдэг Eclipse бүрэлдэхүүн хэсгүүдийн талаархи анхны санааг өгөх болно. "шинэ тохируулагч" 1С: Аж ахуйн нэгжийн платформ. . Мэдээжийн хэрэг, бид зөвхөн Eclipse хөгжүүлэгчид төдийгүй зорилтот үзэгчид анхаарлаа хандуулж байгаа тул ийм тойм нь өнгөцхөн бөгөөд нэлээд хязгаарлагдмал байх болно. Гэсэн хэдий ч туршлагатай Eclipse хөгжүүлэгчид ч гэсэн нийтлэлээс сонирхолтой мэдээллийг олж авах боломжтой гэж найдаж байна. Жишээлбэл, бид "Хитэлтийн нууц" -ын нэг болох харьцангуй шинэ бөгөөд бага мэддэг төслийн талаар ярих болно. , 1С үүсгэн байгуулж, дэмжсэн.
Eclipse Architecture-ийн танилцуулга
Эхлээд жишээн дээр Eclipse архитектурын зарим ерөнхий талыг харцгаая (JDT). Жишээ болгон JDT сонгосон нь санамсаргүй хэрэг биш юм. Энэ нь Eclipse дээр гарч ирсэн анхны нэгдсэн хөгжүүлэлтийн орчин юм. Eclipse C/C++ Development Tooling (CDT) гэх мэт бусад *DT Eclipse төслүүд нь хожим бүтээгдсэн бөгөөд JDT-ээс архитектурын үндсэн зарчим болон бие даасан эх кодын хэсгүүдийг хоёуланг нь зээлж авсан. JDT-д тодорхойлсон архитектурын үндэс нь 1C: Enterprise Development Tools зэрэг Eclipse платформ дээр баригдсан бараг бүх IDE-д өнөөдрийг хүртэл хамааралтай.
Юуны өмнө, Eclipse нь нэлээд тодорхой архитектурын давхаргаар тодорхойлогддог гэдгийг тэмдэглэх нь зүйтэй бөгөөд хэлээс хамааралгүй функцийг тусгай програмчлалын хэлийг дэмжихэд зориулагдсан функцээс салгаж, UI-аас хамааралгүй "үндсэн" бүрэлдэхүүн хэсгүүдийг холбогдох бүрэлдэхүүн хэсгүүдээс тусгаарладаг. хэрэглэгчийн интерфэйсийг дэмждэг.
Тиймээс Eclipse платформ нь нийтлэг, хэлээс хамааралгүй дэд бүтцийг тодорхойлдог бөгөөд Java хөгжүүлэлтийн хэрэгслүүд нь Eclipse-д бүрэн хэмжээний Java IDE-г нэмж өгдөг. Eclipse Platform болон JDT хоёулаа хэд хэдэн бүрэлдэхүүн хэсгээс бүрдэх бөгөөд тус бүр нь UI-аас хамааралгүй "цөм" эсвэл UI давхаргад багтдаг (Зураг 1).
Цагаан будаа. 1. Eclipse Platform болон JDT
Eclipse платформын үндсэн бүрэлдэхүүн хэсгүүдийг жагсаая:
- Ажиллах цаг — Залгаасны дэд бүтцийг тодорхойлдог. Eclipse нь модульчлагдсан архитектураар тодорхойлогддог. Үндсэндээ Eclipse бол "өргөтгөл" болон "өргөтгөл"-ийн цуглуулга юм.
- Ажлын талбар - Нэг буюу хэд хэдэн төслийг удирддаг. Төсөл нь файлын системд шууд буулгасан хавтас, файлуудаас бүрдэнэ.
- Стандарт виджет хэрэгслийн хэрэгсэл (SWT) - Үйлдлийн системтэй нэгдсэн хэрэглэгчийн интерфейсийн үндсэн элементүүдээр хангана.
- JFace — SWT дээр суурилсан хэд хэдэн UI хүрээг хангадаг.
- Workbench — Eclipse UI парадигмыг тодорхойлдог: редакторууд, үзэл бодол, хэтийн төлөв.
Eclipse платформ нь дибаг хийх, харьцуулах, хайх, баг зэрэг цогц хөгжүүлэлтийн хэрэгслүүдийг бий болгоход хэрэгтэй бусад олон бүрэлдэхүүн хэсгүүдийг өгдөг гэдгийг хэлэх ёстой. Эх кодын "ухаалаг редактор" бүтээх үндэс болсон JFace Text-ийг онцгойлон дурдах хэрэгтэй. Харамсалтай нь, эдгээр бүрэлдэхүүн хэсгүүд, түүнчлэн UI давхаргын бүрэлдэхүүн хэсгүүдийг өнгөцхөн судалж үзэх нь энэ нийтлэлийн хүрээнд боломжгүй тул энэ хэсгийн үлдсэн хэсэгт бид "үндсэн" бүрэлдэхүүн хэсгүүдийн тоймоор хязгаарлагдах болно. Eclipse платформ ба JDT.
Үндсэн ажиллах хугацаа
Eclipse залгаасын дэд бүтэц нь дээр суурилдаг болон төслөөс олгосон . Eclipse залгаас бүр нь OSGi багц юм. OSGi-ийн тодорхойлолт нь ялангуяа хувилбар болон хамаарлыг шийдвэрлэх механизмуудыг тодорхойлдог. Эдгээр стандарт механизмуудаас гадна Equinox нь үзэл баримтлалыг танилцуулдаг өргөтгөлийн цэгүүд. Plugin бүр өөрийн өргөтгөлийн цэгүүдийг тодорхойлж, мөн ижил эсвэл бусад залгаасуудаар тодорхойлсон өргөтгөлийн цэгүүдийг ашиглан системд нэмэлт функцийг ("өргөтгөлүүд") нэвтрүүлж болно. OSGi болон Equinox механизмын нарийвчилсан тайлбар нь энэ өгүүллийн хамрах хүрээнээс гадуур юм. Eclipse дахь модульчлал нь нийт (ямар ч дэд систем, түүний дотор Runtime нь нэг буюу хэд хэдэн залгаасаас бүрддэг) бөгөөд Eclipse дээрх бараг бүх зүйл өргөтгөл гэдгийг анхаарна уу. Түүгээр ч барахгүй эдгээр зарчмуудыг OSGi-г нэвтрүүлэхээс өмнө Eclipse архитектурт суулгасан байсан (тэр үед тэд OSGi-тэй төстэй өөрсдийн технологийг ашигладаг байсан).
Үндсэн ажлын талбар
Eclipse платформ дээр баригдсан бараг бүх цогц хөгжүүлэлтийн орчин нь Eclipse ажлын талбартай ажилладаг. Энэ нь ихэвчлэн IDE-д боловсруулсан програмын эх кодыг агуулсан ажлын талбар юм. Ажлын талбар нь файлын системтэй шууд харьцдаг бөгөөд хавтас, файл агуулсан төслүүдээс бүрдэнэ. Эдгээр төсөл, хавтас, файлуудыг дууддаг нөөц ажлын талбар. Eclipse дахь ажлын талбарын хэрэгжилт нь файлын системтэй холбоотой кэш болж үйлчилдэг бөгөөд энэ нь нөөцийн мод руу шилжих үйл явцыг ихээхэн хурдасгах боломжийг олгодог. Нэмж дурдахад ажлын талбар нь хэд хэдэн нэмэлт үйлчилгээ үзүүлдэг и .
Үндсэн нөөцийн бүрэлдэхүүн хэсэг (org.eclipse.core.resources залгаас) нь ажлын талбар болон түүний нөөцийг дэмжих үүрэгтэй. Ялангуяа энэ бүрэлдэхүүн хэсэг нь маягтын ажлын талбарт програмчлагдсан хандалтыг олгодог нөөцийн загварууд. Энэ загвартай үр дүнтэй ажиллахын тулд үйлчлүүлэгчид эх сурвалжийн холбоосыг үзүүлэх энгийн арга хэрэгтэй. Энэ тохиолдолд загвар дахь нөөцийн төлөвийг шууд хадгалдаг объектыг үйлчлүүлэгчийн хандалтаас нуух нь зүйтэй юм. Үгүй бол, жишээлбэл, файлыг устгасан тохиолдолд үйлчлүүлэгч загварт байхгүй объектыг үргэлжлүүлэн барьж, улмаар асуудал үүсч болно. Eclipse гэдэг зүйл ашиглан энэ асуудлыг шийддэг зохицуулах нөөц. Бариул нь түлхүүрийн үүрэг гүйцэтгэдэг (энэ нь зөвхөн ажлын талбар дахь нөөцөд хүрэх замыг мэддэг) бөгөөд нөөцийн төлөв байдлын талаарх мэдээллийг шууд хадгалдаг дотоод загвар объект руу хандах хандалтыг бүрэн хянадаг. Энэ загвар нь хэв маягийн өөрчлөлт юм .
Цагаан будаа. Зураг 2-т нөөцийн загварт хэрэглэгдэх Handle/Body хэлцийг дүрслэн харуулав. IResource интерфэйс нь нөөцийн бариулыг төлөөлдөг бөгөөд энэ интерфейсийг хэрэгжүүлдэг Resource анги болон API биш биеийг төлөөлдөг ResourceInfo ангиас ялгаатай нь API юм. Бариул нь зөвхөн ажлын талбарын үндэстэй холбоотой нөөц рүү хүрэх замыг мэддэг бөгөөд нөөцийн мэдээллийн холбоос агуулаагүй гэдгийг бид онцолж байна. Нөөцийн мэдээллийн объектууд нь "элементийн мод" гэж нэрлэгддэг зүйлийг бүрдүүлдэг. Энэхүү өгөгдлийн бүтэц нь санах ойд бүрэн хэрэгждэг. Бариултай харгалзах нөөцийн мэдээллийн жишээг олохын тулд элементийн модыг тухайн бариулд хадгалагдсан замын дагуу дайран өнгөрнө.
Цагаан будаа. 2. IResource болон ResourceInfo
Бид дараа нь харах болно, нөөц загварын үндсэн загварыг (бид үүнийг бариул дээр суурилсан гэж нэрлэж болно) бусад загваруудад мөн Eclipse-д ашигладаг. Одоохондоо энэ дизайны онцлог шинж чанаруудыг жагсаая:
- Бариул нь утгын объект юм. Үнэт зүйлийн объектууд нь ижил төстэй байдал дээр суурилдаггүй өөрчлөгдөшгүй объектууд юм. Ийм объектыг хэш хийсэн саванд түлхүүр болгон аюулгүй ашиглаж болно. Бариулын олон тохиолдлууд нэг эх сурвалжийг лавлаж болно. Тэдгээрийг харьцуулахын тулд та тэнцүү (Object) аргыг ашиглах хэрэгтэй.
- Бариул нь нөөцийн төлөв байдлыг тодорхойлдог боловч нөөцийн төлөв байдлын талаархи мэдээллийг агуулдаггүй (түүний хадгалдаг цорын ганц өгөгдөл нь "түлхүүр", нөөцөд хүрэх зам юм).
- Бариул нь байхгүй нөөцийг (хараахан үүсгээгүй нөөц эсвэл аль хэдийн устгасан нөөцийг) хэлж болно. Нөөц байгаа эсэхийг IResource.exists() аргыг ашиглан шалгаж болно.
- Зарим үйлдлүүдийг зөвхөн бариулд хадгалагдсан мэдээлэлд үндэслэн хийж болно (зөвхөн бариултай үйлдлүүд гэж нэрлэдэг). Жишээ нь IResource.getParent(), getFullPath() гэх мэт. Ийм ажиллагааг амжилттай явуулахын тулд нөөц байх албагүй. Амжилттай ажиллахын тулд нөөц байх шаардлагатай үйлдлүүд нь нөөц байхгүй тохиолдолд CoreException-г үүсгэдэг.
Eclipse нь ажлын талбарын нөөцийн өөрчлөлтийг мэдэгдэх үр дүнтэй механизмаар хангадаг (Зураг 3). Нөөцүүд нь Eclipse IDE доторх үйлдлүүдийн үр дүнд эсвэл файлын системтэй синхрончлолын үр дүнд өөрчлөгдөж болно. Энэ хоёр тохиолдолд мэдэгдэлд бүртгүүлсэн үйлчлүүлэгчдэд "нөөцийн дельта" хэлбэрээр гарсан өөрчлөлтийн талаарх дэлгэрэнгүй мэдээллийг өгдөг. Дельта нь ажлын талбарын нөөцийн (дэд) модны хоёр төлөвийн хоорондох өөрчлөлтийг тодорхойлдог бөгөөд зангилаа бүр нь нөөцийн өөрчлөлтийг тайлбарлах ба дараагийн түвшний хүүхдийн нөөцийн өөрчлөлтийг тодорхойлсон дельтагийн жагсаалтыг агуулсан мод юм.
Цагаан будаа. 3. IResourceChangeEvent болон IResourceDelta
Нөөцийн дельта дээр суурилсан мэдэгдлийн механизм нь дараахь шинж чанартай байдаг.
- Дельта нь рекурсив найрлагын зарчмаар баригдсан тул нэг өөрчлөлт, олон өөрчлөлтийг ижил бүтцийг ашиглан дүрсэлсэн болно. Захиалагч үйлчлүүлэгчид нөөцийн өөрчлөлтийн мэдэгдлийг гурвалжин модоор дамжуулан рекурсив удмыг ашиглан боловсруулж болно.
- Дельта нь нөөцийн өөрчлөлт, түүний хөдөлгөөн ба/эсвэл үүнтэй холбоотой "тэмдэглэгээ" -ийн өөрчлөлт зэрэг бүрэн мэдээллийг агуулдаг (жишээлбэл, эмхэтгэлийн алдааг тэмдэглэгээгээр илэрхийлдэг).
- Нөөцийн лавлагааг бариулаар хийдэг тул дельта нь алсын нөөцийг лавлах боломжтой.
Бидний удахгүй харах болно, нөөцийн загварын өөрчлөлтийн мэдэгдлийн механизмын дизайны үндсэн бүрэлдэхүүн хэсгүүд нь бариул дээр суурилсан бусад загваруудад мөн хамааралтай болно.
JDT гол
Eclipse ажлын талбарын нөөцийн загвар нь үндсэн хэл-агностик загвар юм. JDT Core бүрэлдэхүүн хэсэг (plugin org.eclipse.jdt.core) нь "Java загвар" гэж нэрлэгддэг Java-ийн өнцгөөс ажлын талбарын бүтцийг удирдах, дүн шинжилгээ хийх API-г өгдөг.Java загвар). Энэ API нь хавтас, файлаар тодорхойлогддог үндсэн нөөцийн загвар API-аас ялгаатай нь Java элементүүдээр тодорхойлогддог. Java элементийн модны үндсэн интерфейсийг Зураг дээр үзүүлэв. 4.
Цагаан будаа. 4. Java загварын элементүүд
Java загвар нь нөөцийн загвартай ижил бариул/биеийн хэлцийг ашигладаг (Зураг 5). IJavaElement нь бариул бөгөөд JavaElementInfo нь биеийн үүргийг гүйцэтгэдэг. IJavaElement интерфэйс нь бүх Java элементүүдийн нийтлэг протоколыг тодорхойлдог. Түүний зарим аргууд нь зөвхөн ажиллах боломжтой: getElementName(), getParent() гэх мэт. JavaElementInfo объект нь харгалзах элементийн төлөвийг хадгалдаг: түүний бүтэц, шинж чанарууд.
Цагаан будаа. 5. IJavaElement болон JavaElementInfo
Java загвар нь нөөцийн загвартай харьцуулахад үндсэн бариул/биеийн дизайны хэрэгжилтэд зарим нэг ялгаа байдаг. Дээр дурдсанчлан нөөцийн загварт зангилаа нь нөөцийн мэдээллийн объект болох элементийн мод бүхэлдээ санах ойд агуулагддаг. Гэхдээ Java загвар нь .java болон .class файлуудын төрөл, талбар, аргуудын дотоод бүтцийг мөн илэрхийлдэг тул нөөцийн модноос хамаагүй олон тооны элементтэй байж болно.
Санах ой дахь элементүүдийн модыг бүхэлд нь бүтээхээс зайлсхийхийн тулд Java загварын хэрэгжилт нь элементийн мэдээллийн хязгаарлагдмал хэмжээтэй LRU кэшийг ашигладаг бөгөөд гол түлхүүр нь IJavaElement-ийг зохицуулдаг. Элементийн модыг чиглүүлэх үед элементийн мэдээллийн объектыг хүсэлтээр үүсгэнэ. Энэ тохиолдолд хамгийн бага ашиглагддаг зүйлсийг кэшээс зайлуулж, загварын санах ойн хэрэглээ нь заасан кэшийн хэмжээгээр хязгаарлагддаг. Энэ нь бариул дээр суурилсан дизайны бас нэг давуу тал бөгөөд ийм хэрэгжилтийн нарийн ширийнийг үйлчлүүлэгчийн кодоос бүрэн нуудаг.
Java элементүүдийн өөрчлөлтийг мэдэгдэх механизм нь дээр дурдсан ажлын талбарын нөөцийн өөрчлөлтийг хянах механизмтай ерөнхийдөө төстэй юм. Java загварын өөрчлөлтийг хянахыг хүссэн үйлчлүүлэгч IJavaElementDelta агуулсан ElementChangedEvent объект хэлбэрээр илэрхийлэгддэг мэдэгдлүүдэд бүртгүүлдэг (Зураг 6).
Цагаан будаа. 6. ElementChangedEvent болон IJavaElementDelta
Java загвар нь аргын биетүүд эсвэл нэрийн нарийвчлалын талаарх мэдээллийг агуулаагүй тул Java хэл дээр бичигдсэн кодын нарийвчилсан дүн шинжилгээ хийхийн тулд JDT Core нэмэлт (бариул дээр суурилсан бус) загварыг өгдөг. (хийсвэр синтакс мод, AST). AST нь эх текстийг задлан шинжилсний үр дүнг илэрхийлнэ. AST зангилаа нь эх модулийн бүтцийн элементүүдтэй (мэдэгдэл, оператор, илэрхийлэл гэх мэт) тохирч, эх текст дэх харгалзах элементийн координат, түүнчлэн (сонголт хэлбэрээр) нэрийн нарийвчлалын талаархи мэдээллийг агуулдаг. гэж нэрлэгддэг холбоосын хэлбэр bindings. Bindings нь хөрвүүлэгчийн мэддэг төрөл, арга, хувьсагч зэрэг нэрлэгдсэн объектуудыг төлөөлөх объектууд юм. Модыг үүсгэдэг AST зангилаанаас ялгаатай нь холбоосууд нь хөндлөн лавлагааг дэмждэг бөгөөд ерөнхийдөө график үүсгэдэг. ASTNode хийсвэр анги нь бүх AST зангилааны нийтлэг үндсэн анги юм. ASTNode дэд ангиуд нь Java хэлний тодорхой синтаксийн бүтэцтэй тохирдог.
Синтакс мод их хэмжээний санах ойг хэрэглэж чаддаг тул JDT идэвхтэй засварлагчийн хувьд зөвхөн нэг AST-г кэшлэнэ. Жава загвараас ялгаатай нь AST нь ихэвчлэн "завсрын", "түр зуурын" загвар гэж үздэг бөгөөд AST-ийг бий болгоход хүргэсэн үйл ажиллагааны хам сэдэвээс гадуур үйлчлүүлэгчид гишүүдийг нь лавлаж болохгүй.
Жагсаалтад орсон гурван загвар (Java загвар, AST, холбоосууд) нь JDT-д "ухаалаг хөгжүүлэлтийн хэрэгсэл"-ийг бий болгох үндэс суурь болж өгдөг, үүнд төрөл бүрийн "туслагч" бүхий хүчирхэг Java редактор, эх кодыг боловсруулах янз бүрийн үйлдэл (импортын жагсаалтыг зохион байгуулах гэх мэт). тохируулсан хэв маягийн дагуу нэр, формат), хайлт, дахин боловсруулах хэрэгслүүд. Энэ тохиолдолд Java загвар нь онцгой үүрэг гүйцэтгэдэг, учир нь үүнийг боловсруулж буй програмын бүтцийг дүрслэн харуулах үндэс болгон ашигладаг (жишээлбэл, Package Explorer, Outline, Search, Call Hierarchy, болон Шатлалын төрөл).
1C: Enterprise Development Tools-д ашигласан Eclipse бүрэлдэхүүн хэсгүүд
Зураг дээр. Зураг 7-д 1C: Enterprise Development Tools-ийн технологийн платформын суурийг бүрдүүлдэг Eclipse бүрэлдэхүүн хэсгүүдийг харуулав.
Цагаан будаа. 7. Eclipse нь 1C: Enterprise Development Tools-ийн платформ юм
Eclipse платформ суурь дэд бүтцээр хангадаг. Бид өмнөх хэсэгт энэ дэд бүтцийн зарим талыг авч үзсэн.
(EMF) бүтэцлэгдсэн өгөгдлийг загварчлах ерөнхий арга хэрэгслийг өгдөг. EMF нь Eclipse платформтой нэгдсэн боловч ердийн Java програмуудад тусад нь ашиглаж болно. Ихэнх тохиолдолд Eclipse-ийн шинэ хөгжүүлэгчид Eclipse платформын нарийн ширийн зүйлийг бүрэн ойлгоогүй байгаа ч EMF-ийг аль хэдийн сайн мэддэг болсон. Ийм нэр хүндтэй болсон шалтгаануудын нэг нь бусад зүйлсээс гадна аливаа EMF загвартай ажиллах боломжийг олгодог нэгдсэн мета түвшний API агуулсан бүх нийтийн загвар юм. EMF-ийн өгсөн загвар объектуудын үндсэн хэрэгжилт ба мета загварт суурилсан загвар код үүсгэх дэд систем нь хөгжлийн хурдыг ихээхэн нэмэгдүүлж, алдааны тоог бууруулдаг. EMF нь загваруудыг цуваа болгох, загварт гарсан өөрчлөлтийг хянах болон бусад олон зүйлийг агуулдаг.
Аливаа жинхэнэ ерөнхий зориулалтын хэрэгслийн нэгэн адил EMF нь загварчлалын өргөн хүрээний асуудлыг шийдвэрлэхэд тохиромжтой боловч зарим ангиллын загварууд (жишээлбэл, дээр дурдсан бариул дээр суурилсан загварууд) илүү нарийн мэргэжлийн загварчлалын хэрэгсэл шаарддаг. EMF-ийн тухай ярих нь ялангуяа нэг өгүүллийн хязгаарлагдмал хүрээнд талархалгүй ажил юм, учир нь энэ нь тусдаа номын сэдэв бөгөөд нэлээд зузаан юм. EMF-ийн үндэс суурь болсон өндөр чанарын ерөнхий үнэлгээний систем нь дээд түвшний төсөлд багтсан загварчлалд зориулагдсан бүхэл бүтэн төслүүдийг бий болгох боломжийг олгосон гэдгийг тэмдэглэх нь зүйтэй. EMF өөрөө хамт. Ийм төслүүдийн нэг нь Eclipse Xtext юм.
"текст загварчлал" дэд бүтцийг бий болгодог. Xtext ашигладаг Эх бичвэрийг задлан шинжлэхэд зориулагдсан ба үр дүнд бий болсон ASG-ийг илэрхийлэхэд зориулсан EMF (хийсвэр семантик график нь үндсэндээ AST ба холболтын хослол) бөгөөд үүнийг "семантик загвар" гэж нэрлэдэг. Xtext-ээр загварчлагдсан хэлний дүрмийг Xtext-ийн өөрийн хэлээр дүрсэлсэн байдаг. Энэ нь танд ANTLR-ийн дүрмийн тайлбарыг үүсгэхээс гадна AST цуваачлалын механизмыг (жишээ нь Xtext нь задлан шинжлэгч болон задлагчийн аль алиныг нь өгдөг), контекстийн зөвлөмж болон бусад олон тооны хэлний бүрэлдэхүүн хэсгүүдийг авах боломжийг олгодог. Нөгөөтэйгүүр, Xtext-д хэрэглэгддэг дүрмийн хэл нь ANTLR-д хэрэглэгддэг дүрмийн хэлээс бага уян хатан байдаг. Тиймээс заримдаа хэрэгжсэн хэлийг Xtext болгон "нугалах" шаардлагатай байдаг бөгөөд энэ нь эхнээс нь боловсруулж байгаа хэлний тухай ярьж байгаа бол энэ нь ихэвчлэн асуудал биш боловч аль хэдийн тогтсон синтакстай хэлнүүдийн хувьд хүлээн зөвшөөрөгдөхгүй байж магадгүй юм. Гэсэн хэдий ч Xtext нь одоогоор Eclipse-ийн програмчлалын хэл, тэдгээрийн хөгжүүлэлтийн хэрэгслийг бий болгоход зориулагдсан хамгийн боловсронгуй, онцлог шинж чанартай, олон талт хэрэгсэл юм. Ялангуяа энэ нь хурдан прототип хийхэд тохиромжтой хэрэгсэл юм (домайн тусгай хэл, DSL). Дээр дурдсан ANTLR болон EMF дээр суурилсан "хэлний цөм" -ээс гадна Xtext нь индексжүүлэх механизм, нэмэлт бүтээц, "ухаалаг засварлагч" болон бусад олон зүйлийг багтаасан дээд түвшний олон ашигтай бүрэлдэхүүн хэсгүүдийг өгдөг. үндэслэсэн хэлний загварууд. EMF-ийн нэгэн адил Xtext бол тусдаа ном болохуйц сэдэв бөгөөд бид яг одоо түүний бүх боломжуудын талаар товчхон ярих боломжгүй юм.
1C: Enterprise Development Tools нь EMF өөрөө болон бусад хэд хэдэн Eclipse Modeling төслүүдийг идэвхтэй ашигладаг. Ялангуяа Xtext нь 1C: Enterprise хэлийг програмчлалын програмчлалын хэл, асуулгын хэл зэрэг хөгжүүлэх хэрэгслүүдийн нэг юм. Эдгээр хөгжүүлэлтийн хэрэгслүүдийн өөр нэг үндэс нь Eclipse Handly төсөл бөгөөд бид үүнийг илүү дэлгэрэнгүй авч үзэх болно (жагсаалтад орсон Eclipse бүрэлдэхүүн хэсгүүдээс энэ нь хамгийн бага мэдэгддэг хэвээр байна).
, Eclipse Technology дээд түвшний төслийн дэд төсөл нь 1 онд 2014С-ээс Eclipse Foundation-д оруулсан анхны кодын хувь нэмэрийн үр дүнд бий болсон. Тэр цагаас хойш 1С нь төслийг хөгжүүлэхэд дэмжлэг үзүүлсээр ирсэн: Гар аргаар гүйцэтгэгчид бол компанийн ажилчид юм. Төсөл нь жижиг боловч Eclipse-д нэлээд өвөрмөц байр суурь эзэлдэг: түүний гол зорилго нь бариул дээр суурилсан загваруудыг хөгжүүлэхэд дэмжлэг үзүүлэх явдал юм.
Бариул/биеийн хэлц гэх мэт бариул дээр суурилсан загваруудын архитектурын үндсэн зарчмуудыг жишээ болгон нөөцийн загвар болон Java загварыг ашиглан дээр авч үзсэн. Мөн нөөцийн загвар болон Java загвар нь Eclipse Java хөгжүүлэлтийн хэрэгслүүдийн (JDT) чухал үндэс суурь болохыг мөн тэмдэглэсэн. Бараг бүх *DT Eclipse төслүүд нь JDT-тэй төстэй архитектуртай байдаг тул бариул дээр суурилсан загварууд нь Eclipse платформ дээр бүтээгдсэн бүх IDE биш юмаа гэхэд олонх нь байдаг гэж хэлэхэд хэтрүүлэг болохгүй байх. Жишээлбэл, Eclipse C/C++ Development Tooling (CDT) нь бариул дээр суурилсан C/C++ загвартай бөгөөд CDT архитектурт Java загвар JDT-д гүйцэтгэдэгтэй ижил үүрэг гүйцэтгэдэг.
Handly-ээс өмнө Eclipse нь бариул дээр суурилсан хэлний загвар бүтээх тусгай номын санг санал болгодоггүй байв. Одоо байгаа загваруудыг голчлон Java загварын кодыг (хуулбарлах / буулгах гэх мэт) шууд тохируулснаар бүтээгдсэн. зөвшөөрсөн тохиолдолд Eclipse Public License (EPL). (Мэдээжийн хэрэг, энэ нь ихэвчлэн Eclipse төслүүдийн хувьд хууль ёсны асуудал биш, харин хаалттай эхийн бүтээгдэхүүнүүдийн хувьд биш юм.) Энэ техник нь төрөлхийн санамсаргүй байдлаас гадна сайн мэддэг асуудлуудыг танилцуулдаг: алдаатай дасан зохицох үед нэвтрүүлсэн кодын давхардал, гэх мэт. Хамгийн муу зүйл бол үүссэн загварууд нь "өөрсдөө зүйл" хэвээр үлдэж, нэгдэх боломжийг ашигладаггүй явдал юм. Гэхдээ бариул дээр суурилсан хэлний загварт зориулсан нийтлэг ойлголт, протоколуудыг тусгаарлах нь EMF-ийн тохиолдолтой адил тэдэнтэй ажиллахад дахин ашиглах боломжтой бүрэлдэхүүн хэсгүүдийг бий болгоход хүргэж болзошгүй юм.
Энэ нь Eclipse эдгээр асуудлыг ойлгоогүй гэсэн үг биш юм. 2005 онд буцаж , CDT прототипийг боловсруулах туршлагыг нэгтгэн дүгнэж, бариул дээр суурилсан загвар зэрэг хэлний загваруудын нийтлэг дэд бүтцийг бий болгох хэрэгцээ. Гэхдээ ихэвчлэн тохиолддог шиг, тэргүүлэх ач холбогдол бүхий ажлуудын улмаас эдгээр санааг хэрэгжүүлэхэд хэзээ ч хүрч чадаагүй. Үүний зэрэгцээ *DT кодын хүчин зүйлчлэл нь Eclipse-ийн хөгжөөгүй сэдвүүдийн нэг хэвээр байна.
Тодорхой утгаараа Handly төсөл нь EMF-тэй ижил төстэй асуудлуудыг шийдвэрлэхэд зориулагдсан боловч бариул дээр суурилсан загварууд, үндсэндээ хэлний (жишээ нь зарим програмчлалын хэлний бүтцийн элементүүдийг төлөөлдөг) загваруудад зориулагдсан болно. Handly дизайн хийхдээ тавьсан гол зорилгыг доор жагсаав.
- Сэдвийн талбайн үндсэн хийсвэр ойлголтыг тодорхойлох.
- Кодыг дахин ашиглах замаар бариул дээр суурилсан хэлний загварыг хэрэгжүүлэх хүчин чармайлтыг бууруулж, чанарыг сайжруулах.
- Үүссэн загваруудад нэгдсэн мета түвшний API-г өгч, хэл дээр суурилсан загваруудтай ажиллах нийтлэг IDE бүрэлдэхүүн хэсгүүдийг үүсгэх боломжтой болгодог.
- Уян хатан байдал, өргөтгөх чадвар.
- Xtext-тэй нэгтгэх (тусдаа давхаргад).
Нийтлэг ойлголт, протоколуудыг тодруулахын тулд хэл дээр суурилсан загваруудын одоо байгаа хэрэгжилтэд дүн шинжилгээ хийсэн. Handly-ийн өгсөн үндсэн интерфэйсүүд болон үндсэн хэрэгжилтийг Зураг дээр үзүүлэв. 8.
Цагаан будаа. 8. Handly элементүүдийн нийтлэг интерфейс ба үндсэн хэрэгжилт
IElement интерфэйс нь элементийн бариулыг илэрхийлдэг бөгөөд Handly-д суурилсан бүх загваруудын элементүүдэд нийтлэг байдаг. Хийсвэр анги Элемент нь бариул/биеийн ерөнхий механизмыг хэрэгжүүлдэг (Зураг 9).
Цагаан будаа. 9. IElement болон ерөнхий бариул/биеийн хэрэгжилт
Нэмж дурдахад Handly загварын элементүүдийн өөрчлөлтийн талаар мэдээлэх ерөнхий механизмыг өгдөг (Зураг 10). Таны харж байгаагаар энэ нь нөөцийн загвар болон Java загварт хэрэгжсэн мэдэгдлийн механизмтай ерөнхийдөө төстэй бөгөөд элементийн өөрчлөлтийн мэдээллийн нэгдсэн дүрслэлийг хангахын тулд IElementDelta ашигладаг.
Цагаан будаа. 10. Handly мэдэгдлийн механизмын ерөнхий интерфейс ба үндсэн хэрэгжилт
Дээр дурдсан Handly хэсгийг (9 ба 10-р зураг) бариул дээр суурилсан бараг бүх загварыг төлөөлөхөд ашиглаж болно. Үүсгэхийн тулд хэл шинжлэлийн загваруудын хувьд төсөл нь нэмэлт функцуудыг санал болгодог - тухайлбал эх текстийн бүтцийн элементүүдийн нийтлэг интерфейс ба үндсэн хэрэгжилтийг санал болгодог. эх үүсвэрийн элементүүд (Зураг 8). ISourceFile интерфейс нь эх файлыг, ISourceConstruct нь эх файл доторх элементийг төлөөлдөг. SourceFile болон SourceConstruct хийсвэр ангиуд нь эх файлууд болон тэдгээрийн элементүүдтэй ажиллахад туслах ерөнхий механизмыг хэрэгжүүлдэг, жишээлбэл, текстийн буфертэй ажиллах, эх текст дэх элементийн координатыг холбох, загваруудыг ажиллаж буй хуулбар буферийн одоогийн агуулгатай нийцүүлэх. , гэх мэт. Эдгээр механизмыг хэрэгжүүлэх нь ихэвчлэн нэлээд бэрхшээлтэй байдаг бөгөөд Handly нь өндөр чанартай үндсэн хэрэгжилтийг хангаснаар бариулд суурилсан хэлний загваруудыг боловсруулах хүчин чармайлтыг эрс багасгадаг.
Дээр дурдсан үндсэн механизмуудаас гадна Handly нь текстийн буфер болон агшин зуурын агшинд зориулсан дэд бүтэц, эх кодын засварлагчтай нэгтгэх дэмжлэг (Xtext засварлагчтай бэлэн интеграцчилал гэх мэт), түүнчлэн зарим нийтлэг UI бүрэлдэхүүн хэсгүүдээр хангадаг. эх кодын засварлагчтай ажиллах. тойм хүрээ зэрэг гар аргаар загварчлах. Түүний чадавхийг харуулахын тулд төсөл нь Handly-д Java загварыг хэрэгжүүлэх зэрэг хэд хэдэн жишээг өгдөг. (Java загварыг JDT-д бүрэн хэрэгжүүлсэнтэй харьцуулахад энэ загварыг илүү ойлгомжтой болгох үүднээс зориуд бага зэрэг хялбаршуулсан болно.)
Өмнө дурьдсанчлан, Handly-ийн анхны загвар болон дараагийн хөгжүүлэлтийн явцад томоохон анхаарал хандуулсан зүйл бол өргөтгөх чадвар, уян хатан байдалд байсан бөгөөд одоо ч байсаар байна.
Зарчмын хувьд бариул дээр суурилсан загварууд нь "дизайнаар" нэлээд сайн масштабтай байдаг. Жишээлбэл, бариул/биеийн хэлц нь загварт зарцуулсан санах ойн хэмжээг хязгаарлах боломжийг олгодог. Гэхдээ бас нюансууд байдаг. Тиймээс Handly-ийг өргөтгөх чадварыг туршиж үзэхэд мэдэгдлийн механизмыг хэрэгжүүлэхэд асуудал илэрсэн - олон тооны элементүүд өөрчлөгдсөн үед дельта барихад хэтэрхий их цаг зарцуулсан. Харгалзах кодыг нэг удаа тохируулсан JDT Java загварт ижил асуудал байсан нь тогтоогдсон. Бид Handly дээрх алдааг засч, JDT-д зориулсан ижил төстэй нөхөөсийг бэлтгэсэн нь талархалтайгаар хүлээн авсан. Энэ бол одоо байгаа загварын хэрэгжилтэд Handly-г нэвтрүүлэх нь ашигтай байж болох цорын ганц жишээ юм, учир нь энэ тохиолдолд ийм алдааг зөвхөн нэг газар засах боломжтой.
Handly-г одоо байгаа загваруудын хэрэгжилтийг техникийн хувьд боломжтой болгохын тулд номын сан ихээхэн уян хатан байх ёстой. Хамгийн гол асуудал бол API загвар дээр хоцрогдсон нийцтэй байдлыг хадгалах явдал юм. Энэ асуудлыг онд шийдсэн Хөгжүүлэгчийн тодорхойлсон, бүрэн хянадаг загварт зориулсан API-г номын сангаас өгсөн нэгдсэн мета түвшний API-аас тодорхой салгаснаар. Энэ нь Handly-г одоо байгаа хэрэгжүүлэлтүүдэд техникийн хувьд нэвтрүүлэх боломжийг олгодог төдийгүй шинэ загвар хөгжүүлэгчдэд API-г зохиоход чухал эрх чөлөөг олгодог.
Уян хатан байдал нь өөр талуудтай. Жишээлбэл, Handly нь загварын бүтцэд бараг ямар ч хязгаарлалт тавьдаггүй бөгөөд ерөнхий зориулалтын болон домэйны тусгай хэлийг хоёуланг нь загварчлахад ашиглаж болно. Эх файлын бүтцийг бүтээхдээ Handly нь AST дүрслэлийн тодорхой хэлбэрийг заагаагүй бөгөөд зарчмын хувьд AST өөрөө байхыг шаарддаггүй тул бараг бүх задлан шинжлэх механизмтай нийцтэй байдлыг хангадаг. Эцэст нь Handly нь Eclipse ажлын талбартай бүрэн интеграцчлахыг дэмждэг боловч интеграцчлагдсаныхаа ачаар файлын системтэй шууд ажиллах боломжтой. (EFS).
Одоогийн хувилбар 2016 оны арванхоёрдугаар сард гарсан. Төсөл одоогоор инкубацийн төлөвт байгаа бөгөөд API нь эцэслэн тогтоогдоогүй байгаа хэдий ч Handly-ийг "эрт нэвтрүүлэгчид"-ийн үүрэг гүйцэтгэх эрсдэлтэй хоёр томоохон арилжааны бүтээгдэхүүнд аль хэдийн ашигласан бөгөөд би хэлэх ёстой. одоохондоо харамсах хэрэггүй.
Дээр дурдсанчлан эдгээр бүтээгдэхүүний нэг нь 1C: Enterprise Development Tools бөгөөд Handly нь 1C: Enterprise хэлний өндөр түвшний бүтцийн элементүүдийг анхнаасаа суулгасан програмчлалын хэл, асуулгын хэл болгон загварчлахад ашигладаг. . Өөр нэг бүтээгдэхүүнийг олон нийтэд төдийлөн мэддэггүй. Энэ , Чехийн Codasip компани болон түүний үйлчлүүлэгчдийн аль алинд нь ашигладаг программд зориулагдсан зааврын багц процессорын (ASIP) нэгдсэн дизайны орчин. , , , . Codasip-ийг Handly 2015 хувилбараас эхлэн 0.2 оноос хойш үйлдвэрлэлд ашиглаж байна. Codasip Studio-ийн хамгийн сүүлийн хувилбар нь 0.5 оны 2016-р сард гарсан 4000 хувилбарыг ашигладаг. Codasip-д IDE хөгжүүлэлтийг удирдаж буй Онджей Илчик төсөлтэй холбогдож, "гуравдагч этгээдийн хүлээн авагч"-ын өмнөөс чухал санал хүсэлтийг өгч байна. Тэрээр төслийн хөгжилд шууд оролцох чөлөөт цагаа олж, Handly жишээнүүдийн нэг болох Java загварт зориулж UI давхарга (~XNUMX мөр код) хэрэгжүүлсэн. Үрчлэгчид Handly-ийн хэрэглээний талаарх дэлгэрэнгүй мэдээллийг хуудаснаас авах боломжтой төсөл.
API тогтвортой байдлын баталгаатай 1.0 хувилбарыг гаргасны дараа төсөл инкубацийн төлөвөөс гарсны дараа Handly шинэ хэрэглэгчтэй болно гэж найдаж байна. Энэ хооронд төсөл нь API-г турших, цаашид сайжруулах ажлыг үргэлжлүүлж, жилд хоёр "гол" хувилбарыг гаргадаг - зургадугаар сард (нэгэн зэрэг Eclipse хувилбартай ижил огноо) болон XNUMX-р сард, үрчлэгч нарт найдаж болох урьдчилан таамаглах боломжтой хуваарийг гаргаж өгдөг. Төслийн "алдааны түвшин" тогтмол бага түвшинд хэвээр байгаа бөгөөд Handly нь эхний хувилбаруудаас хойш анхдагч хэрэглэгчдийн бүтээгдэхүүн дээр найдвартай ажиллаж байгааг бид нэмж хэлж болно. Eclipse Handly-г цаашид судлахын тулд та ашиглаж болно и .
Эх сурвалж: www.habr.com