Eclipse د 1C لپاره د ټیکنالوژۍ پلیټ فارم په توګه: د سوداګرۍ پراختیا وسیلې

شاید، کسوف د اوږدې مودې راهیسې کوم ځانګړي تعارف ته اړتیا نشته. ډیری خلک د Eclipse سره آشنا دي د Eclipse جاوا پرمختیایی وسیلو څخه مننه (JDT). دا د خلاصې سرچینې جاوا IDE مشهور دی چې ډیری پراختیا کونکي د "Eclipse" کلمې سره تړاو لري. په هرصورت، Eclipse دواړه د پراختیایي وسیلو (Eclipse پلیټ فارم) ادغام لپاره د توزیع وړ پلیټ فارم دی، او یو شمیر IDEs د هغې پر بنسټ جوړ شوي، په شمول د JDT. Eclipse دواړه د Eclipse پروژه ده، د لوړې کچې پروژه چې د Eclipse پلیټ فارم او JDT پراختیا همغږي کوي، او د Eclipse SDK، د دې پراختیا وړاندې شوې پایله. په نهایت کې ، Eclipse د خلاصې سرچینې بنسټ دی چې د پروژو لویه ټولنه لري ، چې ټول یې په جاوا کې ندي لیکل شوي یا د پراختیا وسیلو پورې اړه لري (د مثال په توګه ، پروژې Eclipse IoT и د Eclipse ساینس). د Eclipse نړۍ خورا متنوع ده.

پدې مقاله کې ، کوم چې په طبیعت کې عمومي کتنه ده ، موږ به هڅه وکړو چې د یولپس جوړښت ځینې اساسات د مدغم پرمختیایی وسیلو رامینځته کولو لپاره د پلیټ فارم په توګه وګورو او د Eclipse اجزاوو لومړني نظر ورکړو چې د ټیکنالوژۍ بنسټ جوړوي. د "نوي ترتیب کونکي" 1C لپاره پلیټ فارم: شرکت. 1C: د تشبث پراختیا وسیلې. البته، دا ډول بیاکتنه به حتما په لویه کچه سطحي او محدود وي، پشمول ځکه چې موږ نه یوازې د Eclipse پراختیا کونکو باندې د هدف لیدونکو په توګه تمرکز کوو. په هرصورت، موږ امید لرو چې حتی تجربه لرونکي Eclipse پراختیا کونکي به وکوالی شي په مقاله کې په زړه پوري معلومات ومومي. د مثال په توګه، موږ به د یو د "Eclipse رازونو" په اړه وغږیږو، یوه نسبتا نوې او لږ پیژندل شوې پروژه Eclipse په لاسي ډول، کوم چې د 1C لخوا تاسیس شوی او ملاتړ شوی.

د Eclipse معمارۍ پیژندنه

راځئ چې لومړی د مثال په کارولو سره د Eclipse معمارۍ ځینې عمومي اړخونه وګورو Eclipse جاوا پرمختیا وسیلې (JDT). د مثال په توګه د JDT انتخاب ناڅاپي ندی. دا لومړی مدغم شوی پرمختیایی چاپیریال دی چې په Eclipse کې څرګندیږي. نورې *DT Eclipse پروژې، لکه Eclipse C/C++ Development Tooling (CDT)، وروسته رامنځته شوې او دواړه بنسټیز معماري اصول او د انفرادي سرچینې کوډ ټوټې د JDT څخه پور اخلي. د معمارۍ اساسات چې په JDT کې ایښودل شوي د دې ورځې پورې اړوند دي د نږدې هر IDE لپاره چې د Eclipse پلیټ فارم په سر کې جوړ شوي ، په شمول د 1C: د سوداګرۍ پراختیا وسیلې.

تر ټولو لومړی، دا باید په پام کې ونیول شي چې Eclipse د کافي روښانه معماري پرت لخوا ځانګړتیا لري، د ژبې څخه خپلواک فعالیت جلا کول د فعالیت څخه د ځانګړي پروګرامینګ ژبو مالتړ لپاره ډیزاین شوي، او د اړوندو اجزاوو څخه د UI - خپلواک "اصلي" اجزاو جلا کول. د ملاتړ کونکي انٹرفیس سره.

په دې توګه، د Eclipse پلیټ فارم یو عام، د ژبې خپلواک زیربنا تعریفوي، او د جاوا پراختیا وسیلې په Eclipse کې د بشپړ مشخص جاوا IDE اضافه کوي. د Eclipse پلیټ فارم او JDT دواړه د څو برخو څخه جوړ دي، چې هر یو یې د UI- خپلواک "کور" یا د UI پرت پورې اړه لري (شکل 1).

وريجې. 1. Eclipse پلیټ فارم او JDT

راځئ چې د Eclipse پلیټ فارم اصلي برخې لیست کړو:

• ځغاسته - د پلگ ان زیربنا تعریفوي. Eclipse د ماډلر جوړښت لخوا مشخص شوی. په لازمي ډول، Eclipse د "توسیع ټکي" او "توسیع" ټولګه ده.
• کاري ځای - یو یا څو پروژې اداره کوي. یوه پروژه د فولډرو او فایلونو څخه جوړه ده چې مستقیم د فایل سیسټم ته نقشه شوي.
• د معیاري ویجټ اوزار کټ (SWT) - د عملیاتي سیسټم سره مدغم شوي لومړني کارونکي انٹرفیس عناصر چمتو کوي.
• JFace - د SWT په سر کې جوړ شوي یو شمیر UI چوکاټونه چمتو کوي.
• کاربینچ - د Eclipse UI تمثیل تعریفوي: مدیران، لیدونه، لید.

باید وویل شي چې د Eclipse پلیټ فارم د مدغم پرمختیایی وسیلو جوړولو لپاره ډیری نورې ګټورې برخې هم چمتو کوي ، پشمول د ډیبګ ، پرتله کول ، لټون او ټیم. د JFace متن ځانګړې یادونه باید وشي - د سرچینې کوډ "سمارټ ایډیټرانو" جوړولو اساس. له بده مرغه، حتی د دې اجزاوو سرسري ازموینه، او همدارنګه د UI پرت اجزاوو، د دې مقالې په ساحه کې ممکنه نه ده، نو د دې برخې په پاتې برخه کې به موږ ځان د اصلي "اصلي" اجزاوو عمومي کتنې ته محدود کړو. د Eclipse پلیټ فارم او JDT.

د چلولو اصلي وخت

د Eclipse پلگ ان زیربنا پر بنسټ والړ دی OSGi او د پروژې لخوا چمتو شوي Eclipse Equinox. هر Eclipse پلگ ان د OSGi بنډل دی. د OSGi مشخصات په ځانګړي توګه د نسخې او انحصاري حل میکانیزمونه تعریفوي. د دې معیاري میکانیزمونو سربیره، Equinox مفهوم معرفي کوي د پراختیا ټکي. هر پلگ ان کولی شي خپل د تمدید ټکي تعریف کړي، او سیسټم ته اضافي فعالیت ("توسیع") هم د ورته یا نورو پلگ انونو لخوا تعریف شوي د تمدید نقطو په کارولو سره معرفي کړي. د OSGi او Equinox میکانیزمونو هر ډول توضیحي توضیحات د دې مقالې له دائرې څخه بهر دي. راځئ چې یوازې یادونه وکړو چې په Eclipse کې ماډلرائزیشن ټول دی (هر فرعي سیسټم، په شمول د Runtime، یو یا څو پلگ انونه لري)، او په Eclipse کې نږدې هرڅه یو توسیع دی. سربیره پردې ، دا اصول د OSGi معرفي کیدو دمخه د Eclipse جوړښت کې ځای په ځای شوي وو (په هغه وخت کې دوی خپله ټیکنالوژي کارولې ، د OSGi سره ورته ورته).

اصلي کاري ځای

د Eclipse پلیټ فارم په سر کې جوړ شوی نږدې هر مدغم پرمختیایی چاپیریال د Eclipse کاري ځای سره کار کوي. دا هغه کاري ځای دی چې معمولا په IDE کې رامینځته شوي غوښتنلیک سرچینه کوډ لري. کاري ځای په مستقیم ډول د فایل سیسټم ته نقشه کوي او د پروژو څخه جوړه ده چې فولډر او فایلونه لري. دا پروژې، فولډر، او فایلونه ویل کیږي سرچینې کاري ځای په Eclipse کې د کاري ځای پلي کول د فایل سیسټم سره په تړاو کې د کیچ په توګه کار کوي، کوم چې دا ممکنه کوي چې د سرچینې ونې ته د پام وړ سرعت ګړندی کړي. سربیره پردې ، کاري ځای یو شمیر اضافي خدمات چمتو کوي ، پشمول د سرچینو د بدلون لپاره د خبرتیا میکانیزم и زیاتیدونکي جوړونکي زیربنا.

د اصلي سرچینو برخه (org.eclipse.core.resources پلگ ان) د کاري ځای او د دې سرچینو مالتړ لپاره مسؤل دی. په ځانګړې توګه، دا برخه په فورمه کې د کار ځای ته پروګراماتي لاسرسی چمتو کوي د سرچینو ماډلونه. د دې ماډل سره په اغیزمنه توګه کار کولو لپاره، پیرودونکي د یوې سرچینې لپاره د لینک وړاندې کولو لپاره ساده لار ته اړتیا لري. په دې حالت کې، دا به د پام وړ وي چې هغه شی پټ کړئ چې په مستقیم ډول په ماډل کې د سرچینې حالت د پیرودونکي لاسرسي څخه ذخیره کوي. که نه نو، د بیلګې په توګه، د فایل حذف کولو په صورت کې، پیرودونکی کولی شي یو داسې اعتراض وساتي چې نور په موډل کې نه وي، د راتلونکو ستونزو سره. Eclipse دا ستونزه د یو څه په کارولو سره حل کوي سمبال کړئ سرچینه هینډل د کیلي په توګه کار کوي (دا یوازې په کاري ځای کې سرچینې ته لاره پیژني) او په بشپړ ډول د داخلي ماډل څیز ته لاسرسی کنټرولوي ، کوم چې مستقیم د سرچینې حالت په اړه معلومات ذخیره کوي. دا ډیزاین د نمونې توپیر دی لاس / بدن.

وريجې. شکل 2 د هینډل / باډي محاورې په ګوته کوي لکه څنګه چې د سرچینې ماډل کې پلي کیږي. د IRResource انٹرفیس د سرچینې د لاسوند استازیتوب کوي او یو API دی، د سرچینې ټولګي برعکس، کوم چې دا انٹرفیس پلي کوي، او د ResourceInfo ټولګي، چې د بدن استازیتوب کوي، کوم چې APIs نه دي. موږ ټینګار کوو چې هینډل یوازې د کاري ځای ریښې پورې اړوند سرچینې ته لاره پیژني او د سرچینې معلوماتو لپاره لینک نلري. د سرچینې معلوماتو توکي د "عنصر ونې" په نوم یادیږي. د دې معلوماتو جوړښت په بشپړ ډول په حافظه کې مادي شوی. د سرچینې معلوماتو مثال موندلو لپاره چې د هینډل سره مطابقت لري، د عنصر ونه په هغه لاسي کې ذخیره شوي لارې سره سم تیریږي.

وريجې. 2. IRResource او ResourceInfo

لکه څنګه چې موږ به وروسته وګورو، د سرچینې ماډل بنسټیز ډیزاین (موږ ممکن دا د هینډل پر بنسټ ووایو) په Eclipse کې د نورو ماډلونو لپاره هم کارول کیږي. د اوس لپاره، راځئ چې د دې ډیزاین ځینې ځانګړتیاوې لیست کړو:

• لاسي یو ارزښت لرونکی څیز دی. ارزښت لرونکي توکي د بدلون وړ توکي دي چې مساوات د هویت پر بنسټ ندي. دا ډول توکي په خوندي ډول په هش شوي کانټینرونو کې د کیلي په توګه کارول کیدی شي. د هینډل ډیری مثالونه ورته سرچینې حواله کولی شي. د دوی پرتله کولو لپاره، تاسو اړتیا لرئ د مساوي (آبجیکٹ) میتود وکاروئ.
• هینډل د سرچینې چلند تعریفوي، مګر د سرچینې حالت په اړه معلومات نلري (یوازې هغه معلومات چې دا یې ذخیره کوي "کیلي" ده، سرچینې ته لاره).
• لاسوند ممکن یوې سرچینې ته مراجعه وکړي چې شتون نلري (یا هغه سرچینه چې لاهم نه ده رامینځته شوې ، یا هغه سرچینه چې دمخه حذف شوې وي). د سرچینې شتون د IResource.exists() میتود په کارولو سره چیک کیدی شي.
• ځینې ​​​​عملیات یوازې په هینډل کې ذخیره شوي معلوماتو پراساس پلي کیدی شي (په نوم یوازې د هینډل عملیات). مثالونه د IResource.getParent()، getFullPath()، او داسې نور دي. د داسې عملیاتو د بریالیتوب لپاره سرچینې شتون ته اړتیا نلري. هغه عملیات چې د بریالیتوب لپاره سرچینې شتون ته اړتیا لري د CoreException غورځوي که چیرې سرچینه شتون ونلري.

Eclipse د کاري ځای سرچینې بدلونونو خبرتیا لپاره یو اغیزمن میکانیزم چمتو کوي (شکل 3). سرچینې کولی شي یا پخپله د Eclipse IDE دننه ترسره شوي عملونو په پایله کې یا د فایل سیسټم سره همغږي کولو پایله کې بدل شي. په دواړو حالتونو کې، هغه پیرودونکي چې د خبرتیاو ګډون کوي ​​د "سرچینې ډیلټا" په بڼه د بدلونونو په اړه مفصل معلومات چمتو کوي. ډیلټا د کاري ځای سرچینې (فرعي) ونې د دوه حالتونو ترمینځ بدلونونه بیانوي او پخپله یوه ونه ده ، چې هر نوډ یې سرچینې ته بدلون تشریح کوي او په راتلونکي کچه د ډیلټا لیست لري چې د ماشومانو سرچینو کې بدلونونه بیانوي.

وريجې. 3. IResourceChangeEvent او IResourceDelta

د سرچینو د ډیلټا پر بنسټ د خبرتیا میکانیزم لاندې ځانګړتیاوې لري:

• یو واحد بدلون او ډیری بدلونونه د ورته جوړښت په کارولو سره تشریح شوي، ځکه چې ډیلټا د تکراري ترکیب له اصولو څخه جوړ شوی. پیرودونکي پیرودونکي کولی شي د ډیلټا د ونې له لارې د تکراري نزول په کارولو سره د سرچینو بدلون خبرتیاوې پروسس کړي.
• ډیلټا د سرچینې د بدلونونو په اړه بشپړ معلومات لري، پشمول د هغې حرکت او/یا د هغې سره تړلي "مارکرونو" کې بدلونونه (د مثال په توګه، د تالیف کولو تېروتنې د مارکر په توګه ښودل شوي).
• څرنګه چې د سرچینې حوالې د لاسوند له لارې رامینځته کیږي، ډیلټا کولی شي په طبیعي توګه لیرې سرچینې حواله کړي.

لکه څنګه چې موږ به ډیر ژر وګورو، د سرچینې ماډل بدلون د خبرتیا میکانیزم ډیزاین اصلي برخې د نورو لاسي ماډلونو لپاره هم اړین دي.

د JDT کور

د Eclipse کاري ځای سرچینې ماډل د ژبې - اګنوسټیک بنسټیز ماډل دی. د JDT کور اجزا (پلگ ان org.eclipse.jdt.core) د جاوا له لید څخه د کار ځای جوړښت نیویګینګ او تحلیل لپاره API چمتو کوي ، د "جاوا ماډل" په نوم یادیږي (جاوا ماډل). دا API د جاوا عناصرو په شرایطو کې تعریف شوی، لکه څنګه چې د اصلي سرچینې ماډل API سره مخالف دی، کوم چې د فولډرو او فایلونو په شرایطو کې تعریف شوی. د جاوا عنصر ونې اصلي انٹرفیسونه په انځور کې ښودل شوي. 4.

وريجې. 4. د جاوا ماډل عناصر

د جاوا ماډل د سرچینې ماډل (شکل 5) په څیر ورته لاستی/باډي محاورې کاروي. IJavaElement لاستی دی، او JavaElementInfo د بدن رول لوبوي. د IJavaElement انٹرفیس د جاوا ټولو عناصرو لپاره یو عام پروتوکول تعریفوي. د دې ځینې میتودونه یوازې لاس ته راوړل دي: getElementName()، getParent()، او داسې نور. د JavaElementInfo څیز د اړونده عنصر حالت ذخیره کوي: جوړښت او ځانګړتیاوې.

وريجې. 5. IJavaElement او JavaElementInfo

د جاوا ماډل د سرچینې ماډل په پرتله د بنسټیز هینډل / باډي ډیزاین پلي کولو کې ځینې توپیرونه لري. لکه څنګه چې پورته یادونه وشوه، د سرچینې ماډل کې، د عنصر ونې، چې نوډونه یې د سرچینې معلوماتو توکي دي، په بشپړه توګه په حافظه کې شتون لري. مګر د جاوا ماډل کولی شي د سرچینې ونې په پرتله د پام وړ لوی شمیر عناصر ولري، ځکه چې دا د جاوا او کلاس فایلونو داخلي جوړښت هم څرګندوي: ډولونه، ساحې، او میتودونه.

د دې لپاره چې په حافظه کې د عناصرو ټولې ونې په بشپړ ډول مادي کولو څخه مخنیوی وشي ، د جاوا ماډل پلي کول د عنصر معلوماتو محدود اندازې LRU کیچ کاروي ، چیرې چې کیلي د IJavaElement اداره کوي. د عنصر معلوماتو توکي د غوښتنې سره سم رامینځته کیږي ځکه چې د عنصر ونې نیویګیټ کیږي. په دې حالت کې، لږترلږه کارول شوي توکي د کیچ څخه ایستل کیږي، او د ماډل حافظې مصرف د ټاکل شوي کیچ اندازې پورې محدود پاتې کیږي. دا د هینډل پراساس ډیزاین بله ګټه ده ، کوم چې د پیرودونکي کوډ څخه دا ډول پلي کولو توضیحات په بشپړ ډول پټوي.

د جاوا عناصرو ته د بدلونونو خبرولو میکانیزم په عمومي ډول د کاري ځای سرچینو کې د بدلونونو تعقیب کولو میکانیزم ته ورته دی چې پورته یې بحث شوی. یو پیرودونکی چې غواړي د جاوا ماډل کې بدلونونه وڅاري نو خبرتیاو ته ګډون کوي، کوم چې د ElementChangedEvent څیز په توګه ښودل شوي چې IJavaElementDelta لري (شکل 6).

وريجې. 6. ElementChangedEvent او IJavaElementDelta

د جاوا ماډل د میتود باډي یا نوم حل په اړه معلومات نلري ، نو په جاوا کې د لیکل شوي کوډ تفصيلي تحلیل لپاره ، JDT کور اضافي (غیر لاسي پراساس) ماډل چمتو کوي: د نحو لنډیز ونه (خلاصه نحو ونه، AST). AST د سرچینې متن پارس کولو پایله څرګندوي. د AST نوډونه د سرچینې ماډل جوړښت عناصرو سره مطابقت لري (اعلانات، چلونکي، څرګندونې، او نور) او د سرچینې متن کې د اړونده عنصر د همغږۍ په اړه معلومات لري، او همدارنګه (د اختیار په توګه) د نوم حل کولو په اړه معلومات. د تش په نامه لینکونو بڼه بندونه. بانډنګونه هغه توکي دي چې د نومول شوي ادارو استازیتوب کوي، لکه ډولونه، میتودونه، او متغیرات، چې کمپیلر ته پیژندل شوي. د AST نوډونو برعکس، کوم چې یوه ونه جوړوي، بانډونه د کراس حواله کولو ملاتړ کوي او عموما ګراف جوړوي. د خلاصې ټولګي ASTNode د ټولو AST نوډونو لپاره عام بیس کلاس دی. د ASTNode فرعي ټولګي د جاوا ژبې ځانګړي ترکیبي جوړښتونو سره مطابقت لري.

ځکه چې د ترکیب ونې کولی شي د پام وړ حافظه مصرف کړي ، JDT د فعال مدیر لپاره یوازې یو AST کیچ کوي. د جاوا ماډل برعکس، AST عموما د "منځنۍ"، "موقتي" ماډل په توګه لیدل کیږي چې غړي یې باید د مراجعینو لخوا د عملیاتو شرایطو څخه بهر نه وي چې د AST رامینځته کولو المل شوي.

لست شوي درې ماډلونه (جاوا ماډل، AST، بانډونه) په ګډه په JDT کې د "ذهني پراختیا وسیلو" جوړولو لپاره اساس جوړوي، په شمول د مختلف "مرستندویانو" سره د ځواکمن جاوا مدیر، د سرچینې کوډ پروسس کولو لپاره مختلف عملونه (د وارداتو لیست تنظیم کولو په شمول. نومونه او د دودیز سټایل سره سم فارمیټ کول) ، د لټون او بیاکتنې وسیلې. په دې حالت کې، د جاوا ماډل یو ځانګړی رول لوبوي، ځکه چې دا د غوښتنلیک د جوړښت د بصری استازیتوب لپاره د بنسټ په توګه کارول کیږي (د بیلګې په توګه، په پیکج اکسپلورر، خاکه، لټون، د کال درجه بندي، او ډوله درجه بندي).

د Eclipse اجزا چې په 1C کې کارول کیږي: د سوداګرۍ پراختیا وسیلې

په انځور کې. شکل 7 د Eclipse برخې ښیي چې د 1C لپاره د ټیکنالوژۍ پلیټ فارم بنسټ جوړوي: د تصدۍ پراختیا وسیلې.

وريجې. 7. Eclipse د 1C لپاره د پلیټ فارم په توګه: د سوداګرۍ پراختیا وسیلې

د Eclipse پلیټ فارم بنسټیز زیربنا چمتو کوي. موږ په تیره برخه کې د دې زیربنا ځینې اړخونه وڅیړل.

د Eclipse ماډلینګ چوکاټ (EMF) د جوړښت شوي ډاټا ماډل کولو عمومي وسیله چمتو کوي. EMF د Eclipse پلیټ فارم سره مدغم شوی ، مګر په منظم جاوا غوښتنلیکونو کې هم په جلا توګه کارول کیدی شي. ډیری وختونه ، د Eclipse نوي پراختیا کونکي دمخه د EMF سره ښه آشنا دي ، که څه هم دوی لاهم د Eclipse پلیټ فارم پیچلتیاوې په بشپړ ډول نه پوهیږي. د داسې ښه وړ شهرت یو دلیل نړیوال ډیزاین دی، کوم چې د نورو شیانو په منځ کې، یو متحد میټا لیول API، چې تاسو ته اجازه درکوي په عمومي ډول د هر EMF ماډل سره کار وکړئ. د ماډل شیانو لپاره لومړني پلي کول د EMF لخوا چمتو شوي او د میټا ماډل پراساس د ماډل کوډ رامینځته کولو لپاره فرعي سیسټم د پام وړ د پراختیا سرعت زیاتوي او د غلطیو شمیر کموي. EMF د ماډلونو سیریل کولو لپاره میکانیزمونه هم لري، په ماډل کې بدلونونه تعقیبوي، او نور ډیر څه.

د هر ریښتیني عمومي هدف وسیلې په څیر ، EMF د ماډلینګ ستونزو پراخه لړۍ حل کولو لپاره مناسب دی ، مګر د ماډلونو ځینې ټولګي (د مثال په توګه ، د لاسي پراساس ماډلونه چې پورته یې بحث شوی) ممکن د ماډلینګ نورو ځانګړو وسیلو ته اړتیا ولري. د EMF په اړه خبرې کول یو بې شکره کار دی، په ځانګړې توګه د یوې مقالې په محدودو محدودیتونو کې، ځکه چې دا د جلا کتاب موضوع ده، او یو ډیر موټی دی. اجازه راکړئ یوازې یادونه وکړو چې د EMF لاندې د عمومي کولو لوړ کیفیت سیسټم د ماډلینګ لپاره وقف شوي پروژې بشپړ لړۍ رامینځته کولو ته اجازه ورکړه ، کوم چې د لوړې کچې پروژې کې شامل دي. Eclipse ماډلینګ پخپله د EMF سره. یوه ورته پروژه Eclipse Xtext ده.

Eclipse Xtext د "متن ماډلینګ" زیربنا چمتو کوي. Xtext کاروي ANTLR د سرچینې متن او EMF تحلیل کولو لپاره چې پایله یې د ASG نمایندګي کوي (د خلاصې سیمانټیک ګراف چې په اصل کې د AST او بانډونو ترکیب دی) ، چې د "سیمنټیک ماډل" په نوم هم یادیږي. د Xtext لخوا ماډل شوې ژبې ګرامر د Xtext په خپله ژبه کې بیان شوی. دا تاسو ته اجازه درکوي نه یوازې د ANTLR لپاره د ګرامر توضیحات رامینځته کړئ ، بلکه د AST سیریل کولو میکانیزم هم ترلاسه کړئ (د مثال په توګه Xtext دواړه پارسر او غیر پارسر چمتو کوي) ، د شرایطو اشاره ، او یو شمیر نورې ژبې برخې. له بلې خوا، په Xtext کې کارول شوي ګرامر ژبه د ANTLR کې کارول شوي ګرامر ژبې په پرتله لږ انعطاف وړ ده. له همدې امله ، ځینې وختونه اړین دي چې پلي شوې ژبه Xtext ته "غوږ" کړئ ، کوم چې معمولا ستونزه نده که موږ د یوې ژبې په اړه خبرې کوو چې له سکریچ څخه رامینځته کیږي ، مګر ممکن د دمخه رامینځته شوي ترکیب سره د ژبو لپاره د منلو وړ نه وي. سره له دې، Xtext اوس مهال په Eclipse کې ترټولو بالغ، بډایه، او هر اړخیزه وسیله ده چې د پروګرام کولو ژبو جوړولو او د دوی لپاره د پراختیا وسیلو لپاره. په ځانګړې توګه، دا د چټک پروټوټایپ کولو لپاره یو مثالی وسیله ده د ډومین ځانګړي ژبې (د ډومین ځانګړې ژبه، DSL). د ANTLR او EMF پر بنسټ د پورته ذکر شوي "ژبې اصلي" سربیره، Xtext ډیری ګټورې لوړې کچې برخې چمتو کوي، پشمول د شاخص کولو میکانیزمونه، زیاتیدونکي جوړښت، یو "سمارټ مدیر"، او نور ډیر څه، مګر اداره پریږدي- د ژبې پر بنسټ ماډلونه. د EMF په څیر، Xtext د یو جلا کتاب وړ موضوع ده، او موږ کولی شو حتی په لنډه توګه د دې ټولو وړتیاوو په اړه خبرې وکړو.

1C: د تشبث پراختیا وسیلې په فعاله توګه پخپله EMF او یو شمیر نورو Eclipse ماډلینګ پروژې کاروي. په ځانګړې توګه، Xtext د داسې 1C لپاره د پراختیا وسیلو یو بنسټ دی: د تشبث ژبې د جوړ شوي پروګرامینګ ژبې او پوښتنو ژبې په توګه. د دې پراختیایی وسیلو بل اساس د Eclipse Handly پروژه ده، کوم چې موږ به په ډیر تفصیل سره بحث وکړو (د Eclipse اجزاوو لیست شوي، دا لاهم لږ پیژندل شوي).

Eclipse په لاسي ډول، د Eclipse ټیکنالوژۍ د لوړې کچې پروژې یوه فرعي پروژه ، په 1 کې د 2014C لخوا رامینځته شوي د Eclipse بنسټ سره د لومړني کوډ مرستې په پایله کې راپورته شوه. له هغه وخت راهیسې، 1C د پروژې پراختیا ته دوام ورکړی: لاسي ژمنونکي د شرکت کارمندان دي. پروژه کوچنۍ ده ، مګر دا په Eclipse کې یو ځانګړی ځای نیسي: د دې اصلي هدف د لاسي ماډلونو پراختیا ملاتړ کول دي.

د دستګاه پر بنسټ د ماډلونو بنسټیز جوړښت اصول، لکه د هینډل / باډي محاورې، د مثال په توګه د سرچینې ماډل او جاوا ماډل په کارولو سره پورته بحث شوی. دا هم یادونه وشوه چې د سرچینې ماډل او جاوا ماډل دواړه د Eclipse Java پراختیایی وسیلو (JDT) لپاره مهم بنسټونه دي. او له هغه ځایه چې نږدې ټولې *DT Eclipse پروژې JDT ته ورته جوړښت لري ، نو دا به لوی مبالغه نه وي چې ووایو چې د هینډل پراساس ماډلونه ډیری لاندې لري ، که نه ټول IDEs د Eclipse پلیټ فارم په سر کې جوړ شوي. د مثال په توګه، د Eclipse C/C++ پرمختیایي وسیله (CDT) د لاسي پر بنسټ C/C++ ماډل لري چې د CDT په جوړښت کې ورته رول لوبوي لکه څنګه چې جاوا ماډل په JDT کې کوي.

د Handly څخه مخکې، Eclipse د لاسي پر بنسټ د ژبې ماډلونو جوړولو لپاره ځانګړي کتابتونونه وړاندې نه کړل. هغه موډلونه چې اوس مهال شتون لري په عمده توګه د جاوا ماډل کوډ (کاپي/پیسټ) په مستقیم ډول د تطبیق له لارې رامینځته شوي. په هغه حالتونو کې چې اجازه ورکوي د Eclipse عامه جواز (EPL). (په ښکاره ډول، دا معمولا د Eclipse پروژو لپاره قانوني مسله نده، مګر د تړلو سرچینو محصولاتو لپاره نه.) د دې اصلي ګډوډۍ سربیره، دا تخنیک ښه پیژندل شوي ستونزې معرفي کوي: د کوډ نقل کول د غلطیو سره د تطبیق په وخت کې معرفي شوي، etc څه بدتر دی چې پایله شوي ماډلونه "په خپل ځان کې شیان" پاتې کیږي او د یووالي احتمالي ګټه نه اخلي. مګر د لاسوند پر بنسټ د ژبې ماډلونو لپاره د عام مفهومونو او پروتوکولونو جلا کول کولی شي د دوی سره د کار کولو لپاره د بیا کارونې وړ اجزاو رامینځته کولو لامل شي ، د EMF په قضیه کې ورته ورته.

داسې نه ده چې Eclipse په دې مسلو نه پوهیږي. بیرته په 2005 کې مارتین ایسچلیمن، د CDT پروټوټایپ رامینځته کولو تجربې لنډیز کول ، استدلال وکړ د ژبې د ماډلونو لپاره د یوې ګډې زیربنا رامینځته کولو اړتیا، په شمول د لاسي ماډلونو په شمول. مګر، لکه څنګه چې ډیری وختونه پیښیږي، د لوړو لومړیتوبونو دندو له امله، د دې نظرونو پلي کول هیڅکله هم د هغې په شاوخوا کې ندي. په ورته وخت کې ، د *DT کوډ فکتور کول لاهم په Eclipse کې یو له پرمختللو موضوعاتو څخه دی.

په یو مشخص معنی کې، د لاسي پروژه د EMF په څیر نږدې ورته ستونزې حل کولو لپاره ډیزاین شوې، مګر د لاسي ماډلونو لپاره، او په ابتدايي توګه د ژبې لپاره (د بیلګې په توګه، د ځینې پروګرام کولو ژبې جوړښت عناصر استازیتوب کوي). د لاسي ډیزاین کولو په وخت کې ټاکل شوي اصلي اهداف په لاندې ډول لیست شوي دي:

• د موضوع ساحې د اصلي خلاصون پیژندنه.
• د هڅو کمول او د کوډ بیا کارولو له لارې د لاسي ژبې ماډلونو پلي کولو کیفیت ښه کول.
• پایلې لرونکي ماډلونو ته د یو متحد میټا لیول API چمتو کول ، د دې امکان رامینځته کوي چې د عام IDE اجزا رامینځته کړي چې د ژبې هینډل پراساس ماډلونو سره کار کوي.
• انعطاف او توزیع وړتیا.
• د Xtext سره یوځای کول (په جلا پرت کې).

د عامو مفاهیمو او پروتوکولونو د روښانه کولو لپاره، د ژبې د سمبالولو پر بنسټ د ماډلونو موجود تطبیقونه تحلیل شوي. د لاسي لخوا چمتو شوي اصلي انٹرفیسونه او اساسي پلي کول په انځور کې ښودل شوي. ۸.

وريجې. 8. عام انٹرفیسونه او د لاسي عناصرو بنسټیز تطبیق

د IElement انٹرفیس د عنصر هینډل استازیتوب کوي او د ټولو لاسي ماډلونو عناصرو لپاره عام دی. د خلاصې ټولګي عنصر د عمومي لاسوند/بډي میکانیزم پلي کوي (9 شکل).

وريجې. 9. IE عنصر او عمومي لاسوند/د بدن تطبیق

برسېره پردې، لاسي د ماډل عناصرو کې د بدلونونو په اړه د خبرتیا لپاره عمومي میکانیزم چمتو کوي (انځور 10). لکه څنګه چې تاسو لیدلی شئ، دا په پراخه توګه د سرچینې ماډل او جاوا ماډل کې پلي شوي د خبرتیا میکانیزمونو سره ورته دی، او د عنصر بدلون معلوماتو متحد استازیتوب چمتو کولو لپاره IElementDelta کاروي.

وريجې. 10. عمومي انٹرفیسونه او د لاسي خبرتیا میکانیزم بنسټیز تطبیق

لاسي برخه چې پورته بحث شوی (9 او 10 شکل) د هر ډول لاسي ماډلونو نمایندګۍ لپاره کارول کیدی شي. د جوړولو لپاره ژبپوهنه ماډلونه، پروژه اضافي فعالیت وړاندې کوي - په ځانګړې توګه، عام انٹرفیسونه او د سرچینې متن جوړښت عناصرو لپاره بنسټیز تطبیق، چې په نوم یادیږي سرچینې عناصر (انځور 8). د ISourceFile انٹرفیس د سرچینې فایل استازیتوب کوي، او ISourceConstruct د سرچینې فایل کې یو عنصر استازیتوب کوي. د خلاصې ټولګي SourceFile او SourceConstruct د سرچینې فایلونو او د دوی عناصرو سره د کار کولو ملاتړ لپاره عمومي میکانیزمونه پلي کوي ، د مثال په توګه ، د متن بفرونو سره کار کول ، د سرچینې متن کې د عنصر همغږي کولو پابند کول ، د کاري کاپي بفر اوسني مینځپانګې سره موډلونه پخلا کول , etc. د دې میکانیزمونو پلي کول معمولا یوه ننګونه ده، او په لاسي ډول کولی شي د لوړ کیفیت بنسټیز تطبیق چمتو کولو سره د لاسي ژبې د ماډلونو د پراختیا هڅې د پام وړ کم کړي.

د پورته لیست شوي اصلي میکانیزمونو سربیره ، په لاسي ډول د متن بفرونو او سنیپ شاټونو لپاره زیربنا چمتو کوي ، د سرچینې کوډ ایډیټرونو سره ادغام لپاره ملاتړ (د Xtext ایډیټر سره د بکس څخه بهر ادغام په شمول) ، او همدارنګه ځینې عام UI برخې چې د سرچینې کوډ ایډیټرانو سره کار وکړئ په لاسي ماډلونه لکه د خاکه چوکاټ. د دې وړتیاو روښانه کولو لپاره، پروژه په لاسي کې د جاوا ماډل پلي کولو په ګډون ډیری مثالونه وړاندې کوي. (په JDT کې د جاوا ماډل بشپړ پلي کولو په پرتله، دا ماډل په قصدي توګه د ډیر وضاحت لپاره یو څه ساده شوی.)

لکه څنګه چې مخکې یادونه وشوه، د هینډلي د لومړني ډیزاین او وروسته پراختیا په جریان کې لوی تمرکز د توزیع او انعطاف وړ و او دوام لري.

په اصولو کې، د هینډل پر بنسټ ماډلونه د "ډیزاین په واسطه" خورا ښه اندازه کوي. د مثال په توګه، هینډل/باډي محاوره تاسو ته اجازه درکوي د ماډل لخوا مصرف شوي حافظې مقدار محدود کړئ. خو nuances هم شتون لري. په دې توګه، کله چې د توزیع کولو لپاره په لاسي ډول ازموینه وشوه، د خبرتیا میکانیزم پلي کولو کې ستونزه وموندل شوه - کله چې ډیری عناصر بدل شول، د ډیلټا جوړول ډیر وخت نیسي. دا معلومه شوه چې ورته ستونزه د JDT جاوا ماډل کې شتون درلود، له کوم څخه چې ورته کوډ یوځل تطبیق شوی و. موږ بګ په لاسي کې حل کړ او د JDT لپاره ورته پیچ چمتو کړ، کوم چې په مننه سره ترلاسه شو. دا یوازې یوه بیلګه ده چیرې چې د موجوده ماډل پلي کولو کې د لاسي معرفي کول ممکن احتمالي ګټور وي ، ځکه چې پدې حالت کې دا ډول بګ یوازې په یو ځای کې حل کیدی شي.

د دې لپاره چې په لاسي ډول د موجوده ماډل پلي کول په تخنیکي توګه ممکن وي، کتابتون باید د پام وړ انعطاف ولري. اصلي ستونزه د API ماډل په اوږدو کې د شاته مطابقت ساتل دي. دا ستونزه په کې حل شوه په لاسي توګه 0.5 د ماډل ځانګړي API په روښانه ډول جلا کولو سره، د پراختیا کونکي لخوا تعریف شوی او په بشپړ ډول کنټرول شوی، د کتابتون لخوا چمتو شوي متحد میټا لیول API څخه. دا نه یوازې د تخنیکي پلوه دا ممکنه کوي چې په موجوده تطبیقونو کې په لاسي ډول پلي کړي، بلکې د نوي ماډل پراختیا کونکي ته د API ډیزاین کولو په وخت کې د پام وړ ازادي ورکوي.

انعطاف نور اړخونه هم لري. د مثال په توګه، په لاسي ډول د ماډل په جوړښت باندې تقریبا هیڅ محدودیت نه لګوي او د عمومي هدف او ډومین ځانګړي ژبې دواړه ماډل کولو لپاره کارول کیدی شي. کله چې د سرچینې فایل جوړښت رامینځته کول ، په لاسي ډول د AST نمایندګۍ کومه ځانګړې بڼه نه وړاندیز کوي او په اصولو کې حتی پخپله د AST شتون ته اړتیا نلري ، پدې توګه د نږدې هرډول تحلیل میکانیزم سره مطابقت تضمینوي. په نهایت کې ، په لاسي ډول د Eclipse کاري ځای سره د بشپړ ادغام ملاتړ کوي ، مګر کولی شي مستقیم د فایل سیسټمونو سره کار وکړي د دې ادغام څخه مننه د Eclipse فایل سیسټم (EFS).

اوسنۍ نسخه په لاسي توګه 0.6 په دسمبر 2016 کې خپور شو. د دې حقیقت سره سره چې پروژه اوس مهال د انکیوبیشن په حالت کې ده او API لا تر اوسه په پای کې نه دی ټاکل شوی، لاسي لا دمخه په دوه لوی سوداګریزو محصولاتو کې کارول کیږي چې د "لومړني اختیار کونکو" په توګه د عمل کولو خطر یې اخیستی، او زه باید ووایم، تر اوسه مه پښیمانه کیږئ.

لکه څنګه چې پورته یادونه وشوه، د دغو محصولاتو څخه یو دی 1C: د تشبث پراختیا وسیلې، چیرې چې لاسي له پیل څخه د 1C د لوړې کچې جوړښت عناصرو ماډل کولو لپاره کارول کیږي: د تشبث ژبې د جوړ شوي پروګرامینګ ژبې او پوښتنو ژبې په توګه . بل محصول د عامو خلکو لپاره لږ پیژندل شوی. دا کوډاسپ سټوډیو، د غوښتنلیک ځانګړي لارښوونې-سیټ پروسیسر (ASIP) لپاره یو مدغم ډیزاین چاپیریال ، چې دواړه پخپله د چک شرکت Codasip او د دې پیرودونکو لخوا کارول کیږي ، پشمول لښګرګاه, AVG, موبایل, سیګما ډیزاینونه. کوډاسپ له 2015 راهیسې په لاسي تولید کې کار کوي ، د Handly 0.2 نسخه سره پیل کیږي. د کوډاسپ سټوډیو وروستی خپرونه د 0.5 نسخه کاروي، د جون په 2016 کې خپور شوی. Ondřej Ilčík، چې په Codasip کې د IDE پراختیا مشري کوي، د پروژې سره په تماس کې دی، د "دریم اړخ اختیار کونکي" په استازیتوب حیاتي نظر وړاندې کوي. هغه حتی د دې توان درلود چې د پروژې په پراختیا کې مستقیم برخه اخیستو لپاره یو څه وړیا وخت ومومي ، د یو لاسي مثال لپاره د UI پرت (~ 4000 لاین کوډ) پلي کول ، د جاوا ماډل. د ‏‎Handly by adopters‎‏ پاڼې اړوند نور معلومات په فسبوک کې اوګورئ بریالیتوب کیسې پروژه

موږ امید لرو چې د 1.0 نسخه خوشې کیدو وروسته د API ثبات تضمین سره او پروژه د انکیوبیشن حالت پریښودو سره ، په لاس کې به نوي اختیار کونکي ولري. په ورته وخت کې، پروژه د API ازموینې او لا ښه کولو ته دوام ورکوي، په کال کې دوه "لوی" ریلیزونه خپروي - د جون په میاشت کې (په ورته وخت کې د Eclipse خوشې کولو نیټه) او دسمبر، د وړاندوینې وړ مهالویش چمتو کوي چې پلي کونکي یې تکیه کولی شي. موږ دا هم اضافه کولی شو چې د پروژې "بګ کچه" په دوامداره توګه ټیټه کچه پاتې ده او په لاسي ډول د لومړي نسخو راهیسې د لومړني اختیار کونکو محصولاتو کې د باور وړ کار کوي. د لاسي Eclipse نور سپړلو لپاره، تاسو کولی شئ وکاروئ د زده کړې پیل کول и د ارکیټیکچرل عمومي کتنه.

سرچینه: www.habr.com