Eclipse เป็นแพลตฟอร์มเทคโนโลยีสำหรับ 1C: เครื่องมือพัฒนาองค์กร

อาจ คราส ไม่จำเป็นต้องแนะนำอะไรเป็นพิเศษมานานแล้ว หลายๆ คนคุ้นเคยกับ Eclipse ด้วยเครื่องมือพัฒนา Eclipse Java (เจ.ดี.ที). Java IDE แบบโอเพ่นซอร์สยอดนิยมนี้เองที่นักพัฒนาส่วนใหญ่เชื่อมโยงกับคำว่า "Eclipse" อย่างไรก็ตาม Eclipse เป็นทั้งแพลตฟอร์มที่ขยายได้สำหรับการบูรณาการเครื่องมือการพัฒนา (แพลตฟอร์ม Eclipse) และ IDE จำนวนหนึ่งที่สร้างขึ้นบนพื้นฐานของมัน รวมถึง JDT Eclipse เป็นทั้งโปรเจ็กต์ Eclipse ซึ่งเป็นโปรเจ็กต์ระดับบนสุดที่ประสานงานการพัฒนาแพลตฟอร์ม Eclipse และ JDT และ Eclipse SDK ซึ่งเป็นผลลัพธ์ที่ส่งมอบของการพัฒนานั้น สุดท้ายนี้ Eclipse เป็น Foundation แบบโอเพ่นซอร์สที่มีชุมชนโครงการขนาดใหญ่ ไม่ใช่ทั้งหมดที่เขียนด้วยภาษา Java หรือเกี่ยวข้องกับเครื่องมือในการพัฒนา (เช่น โครงการ อุปราคา IoT и วิทยาศาสตร์คราส). โลกของ Eclipse มีความหลากหลายมาก

ในบทความนี้ซึ่งเป็นภาพรวมโดยธรรมชาติ เราจะพยายามดูพื้นฐานบางส่วนของสถาปัตยกรรม Eclipse เพื่อเป็นแพลตฟอร์มสำหรับการสร้างเครื่องมือการพัฒนาแบบรวมและให้แนวคิดเบื้องต้นเกี่ยวกับส่วนประกอบ Eclipse ที่เป็นรากฐานของเทคโนโลยี แพลตฟอร์มสำหรับ "ตัวกำหนดค่าใหม่" 1C: Enterprise 1C: เครื่องมือพัฒนาองค์กร. แน่นอนว่า การตรวจสอบดังกล่าวจะเป็นเพียงผิวเผินเป็นส่วนใหญ่อย่างหลีกเลี่ยงไม่ได้และค่อนข้างจำกัด ซึ่งรวมถึงเนื่องจากเราไม่เพียงแต่มุ่งเน้นไปที่นักพัฒนา Eclipse ในฐานะกลุ่มเป้าหมายเท่านั้น อย่างไรก็ตาม เราหวังว่าแม้แต่นักพัฒนา Eclipse ที่มีประสบการณ์จะสามารถค้นหาข้อมูลที่น่าสนใจในบทความได้ ตัวอย่างเช่นเราจะพูดถึงหนึ่งใน "ความลับของ Eclipse" ซึ่งเป็นโครงการที่ค่อนข้างใหม่และไม่ค่อยมีใครรู้จัก คราสแฮนด์ลี่ซึ่งก่อตั้งและสนับสนุนโดย 1C

รู้เบื้องต้นเกี่ยวกับสถาปัตยกรรม Eclipse

ขั้นแรกเรามาดูลักษณะทั่วไปบางประการของสถาปัตยกรรม Eclipse โดยใช้ตัวอย่างกันก่อน เครื่องมือพัฒนา Eclipse Java (เจดีที). การเลือก JDT เป็นตัวอย่างไม่ใช่เรื่องบังเอิญ นี่เป็นสภาพแวดล้อมการพัฒนาแบบรวมแรกที่ปรากฏใน Eclipse โปรเจ็กต์ *DT Eclipse อื่นๆ เช่น Eclipse C/C++ Development Tooling (CDT) ถูกสร้างขึ้นในภายหลังและยืมทั้งหลักการสถาปัตยกรรมพื้นฐานและแฟรกเมนต์ซอร์สโค้ดแต่ละรายการจาก JDT พื้นฐานของสถาปัตยกรรมที่วางไว้ใน JDT มีความเกี่ยวข้องมาจนถึงทุกวันนี้สำหรับ IDE เกือบทุกตัวที่สร้างขึ้นบนแพลตฟอร์ม Eclipse รวมถึง 1C: เครื่องมือการพัฒนาองค์กร

ประการแรก ควรสังเกตว่า Eclipse มีลักษณะเฉพาะด้วยการแบ่งชั้นทางสถาปัตยกรรมที่ค่อนข้างชัดเจน โดยมีการแยกฟังก์ชันการทำงานที่ไม่ขึ้นอยู่กับภาษาออกจากฟังก์ชันการทำงานที่ออกแบบมาเพื่อรองรับภาษาการเขียนโปรแกรมเฉพาะ และการแยกส่วนประกอบ "หลัก" ที่ไม่ขึ้นกับ UI ออกจากส่วนประกอบที่เกี่ยวข้อง พร้อมส่วนต่อประสานผู้ใช้ที่รองรับ

ดังนั้น แพลตฟอร์ม Eclipse จึงกำหนดโครงสร้างพื้นฐานทั่วไปที่ไม่ขึ้นอยู่กับภาษา และเครื่องมือการพัฒนา Java จะเพิ่ม Java IDE ที่มีคุณลักษณะครบถ้วนลงใน Eclipse ทั้งแพลตฟอร์ม Eclipse และ JDT ประกอบด้วยองค์ประกอบหลายอย่าง ซึ่งแต่ละองค์ประกอบเป็นของ “คอร์” ที่ไม่ขึ้นกับ UI หรือเลเยอร์ UI (รูปที่ 1)

ข้าว. 1. แพลตฟอร์ม Eclipse และ JDT

เรามาแสดงรายการส่วนประกอบหลักของแพลตฟอร์ม Eclipse:

• Runtime — กำหนดโครงสร้างพื้นฐานของปลั๊กอิน Eclipse โดดเด่นด้วยสถาปัตยกรรมแบบโมดูลาร์ โดยพื้นฐานแล้ว Eclipse คือชุดของ "จุดส่วนขยาย" และ "ส่วนขยาย"
• พื้นที่ทำงาน — จัดการหนึ่งหรือหลายโครงการ โปรเจ็กต์ประกอบด้วยโฟลเดอร์และไฟล์ที่แมปกับระบบไฟล์โดยตรง
• ชุดเครื่องมือวิดเจ็ตมาตรฐาน (SWT) - จัดเตรียมองค์ประกอบส่วนต่อประสานผู้ใช้พื้นฐานที่รวมเข้ากับระบบปฏิบัติการ
• เจเฟซ — จัดเตรียมเฟรมเวิร์ก UI จำนวนหนึ่งที่สร้างขึ้นบน SWT
• ม้านั่งทำงานของช่างเครื่อง — กำหนดกระบวนทัศน์ Eclipse UI: เอดิเตอร์ มุมมอง มุมมอง

ต้องบอกว่าแพลตฟอร์ม Eclipse ยังมีส่วนประกอบที่มีประโยชน์อื่นๆ อีกมากมายสำหรับการสร้างเครื่องมือการพัฒนาแบบรวม รวมถึง Debug, เปรียบเทียบ, ค้นหา และทีม ควรกล่าวถึงเป็นพิเศษเกี่ยวกับ JFace Text ซึ่งเป็นพื้นฐานสำหรับการสร้าง "ตัวแก้ไขอัจฉริยะ" ของซอร์สโค้ด น่าเสียดายที่แม้แต่การตรวจสอบส่วนประกอบเหล่านี้อย่างคร่าว ๆ รวมถึงส่วนประกอบเลเยอร์ UI ก็ไม่สามารถทำได้ภายในขอบเขตของบทความนี้ ดังนั้นในส่วนที่เหลือของส่วนนี้ เราจะจำกัดตัวเองอยู่เพียงภาพรวมของส่วนประกอบ "หลัก" หลักของ แพลตฟอร์ม Eclipse และ JDT

รันไทม์หลัก

โครงสร้างพื้นฐานปลั๊กอิน Eclipse ขึ้นอยู่กับ โอเอสจี และจัดทำโดยโครงการ คราสอิควิน็อกซ์. ปลั๊กอิน Eclipse แต่ละตัวเป็นบันเดิล OSGi ข้อมูลจำเพาะ OSGi กำหนดกลไกสำหรับการกำหนดเวอร์ชันและการแก้ไขการพึ่งพาโดยเฉพาะ นอกเหนือจากกลไกมาตรฐานเหล่านี้ Equinox ยังแนะนำแนวคิดนี้อีกด้วย จุดขยายตัว. ปลั๊กอินแต่ละตัวสามารถกำหนดจุดส่วนขยายของตนเองได้ และยังแนะนำฟังก์ชันการทำงานเพิ่มเติม (“ส่วนขยาย”) ให้กับระบบโดยใช้จุดส่วนขยายที่กำหนดโดยปลั๊กอินเดียวกันหรือปลั๊กอินอื่น ๆ คำอธิบายโดยละเอียดของกลไก OSGi และ Equinox อยู่นอกเหนือขอบเขตของบทความนี้ ให้เราทราบเพียงว่าการทำให้เป็นโมดูลใน Eclipse นั้นเป็นทั้งหมด (ระบบย่อยใด ๆ รวมถึงรันไทม์ประกอบด้วยปลั๊กอินหนึ่งรายการขึ้นไป) และเกือบทุกอย่างใน Eclipse นั้นเป็นส่วนขยาย ยิ่งไปกว่านั้น หลักการเหล่านี้ยังฝังอยู่ในสถาปัตยกรรม Eclipse มานานก่อนที่จะมีการเปิดตัว OSGi (ในขณะนั้นพวกเขาใช้เทคโนโลยีของตัวเอง ซึ่งคล้ายกับ OSGi มาก)

พื้นที่ทำงานหลัก

สภาพแวดล้อมการพัฒนาแบบรวมเกือบทั้งหมดที่สร้างขึ้นบนแพลตฟอร์ม Eclipse ทำงานร่วมกับพื้นที่ทำงาน Eclipse เป็นพื้นที่ทำงานที่มักจะมีซอร์สโค้ดของแอปพลิเคชันที่พัฒนาใน IDE พื้นที่ทำงานแมปกับระบบไฟล์โดยตรงและประกอบด้วยโปรเจ็กต์ซึ่งมีโฟลเดอร์และไฟล์ โปรเจ็กต์ โฟลเดอร์ และไฟล์เหล่านี้ถูกเรียก ทรัพยากร พื้นที่ทำงาน การใช้งานพื้นที่ทำงานใน Eclipse ทำหน้าที่เป็นแคชที่เกี่ยวข้องกับระบบไฟล์ ซึ่งทำให้สามารถเร่งความเร็วการข้ามผ่านแผนผังทรัพยากรได้อย่างมาก นอกจากนี้ พื้นที่ทำงานยังให้บริการเพิ่มเติมอีกมากมาย ได้แก่ กลไกการแจ้งเตือนการเปลี่ยนแปลงทรัพยากร и โครงสร้างพื้นฐานของผู้สร้างที่เพิ่มขึ้น.

คอมโพเนนต์ Core Resources (ปลั๊กอิน org.eclipse.core.resources) มีหน้าที่รับผิดชอบในการสนับสนุนเวิร์กสเปซและรีซอร์ส โดยเฉพาะอย่างยิ่ง ส่วนประกอบนี้ให้การเข้าถึงพื้นที่ทำงานในรูปแบบทางโปรแกรม โมเดลทรัพยากร. เพื่อให้ทำงานกับโมเดลนี้ได้อย่างมีประสิทธิภาพ ลูกค้าจำเป็นต้องมีวิธีง่ายๆ ในการนำเสนอลิงก์ไปยังแหล่งข้อมูล ในกรณีนี้ ขอแนะนำให้ซ่อนออบเจ็กต์ที่เก็บสถานะของทรัพยากรในโมเดลโดยตรงจากการเข้าถึงของไคลเอ็นต์ มิฉะนั้น ในกรณี เช่น การลบไฟล์ ไคลเอ็นต์สามารถเก็บอ็อบเจ็กต์ที่ไม่ได้อยู่ในโมเดลต่อไปได้ โดยจะเกิดปัญหาตามมา Eclipse แก้ไขปัญหานี้โดยใช้สิ่งที่เรียกว่า จัดการ ทรัพยากร. Handle ทำหน้าที่เป็นคีย์ (รู้เส้นทางไปยังทรัพยากรในพื้นที่ทำงานเท่านั้น) และควบคุมการเข้าถึงออบเจ็กต์โมเดลภายในอย่างสมบูรณ์ ซึ่งจะจัดเก็บข้อมูลเกี่ยวกับสถานะของทรัพยากรโดยตรง การออกแบบนี้เป็นรูปแบบของรูปแบบ ที่จับ/ตัวเครื่อง.

ข้าว. รูปที่ 2 แสดงให้เห็นถึงสำนวน Handle/Body ที่ใช้กับโมเดลทรัพยากร อินเทอร์เฟซ IResource แสดงถึงหมายเลขอ้างอิงของทรัพยากรและเป็น API ซึ่งแตกต่างจากคลาส Resource ซึ่งใช้อินเทอร์เฟซนี้ และคลาส ResourceInfo ซึ่งแสดงถึงเนื้อหา ซึ่งไม่ใช่ API เราเน้นย้ำว่าตัวจัดการรู้เฉพาะเส้นทางไปยังทรัพยากรที่สัมพันธ์กับรูทของพื้นที่ทำงาน และไม่มีลิงก์ไปยังข้อมูลทรัพยากร ออบเจ็กต์ข้อมูลทรัพยากรก่อให้เกิดสิ่งที่เรียกว่า "แผนผังองค์ประกอบ" โครงสร้างข้อมูลนี้เกิดขึ้นจริงในหน่วยความจำอย่างสมบูรณ์ หากต้องการค้นหาอินสแตนซ์ข้อมูลทรัพยากรที่สอดคล้องกับหมายเลขอ้างอิง แผนผังองค์ประกอบจะถูกสำรวจตามเส้นทางที่เก็บไว้ในหมายเลขอ้างอิงนั้น

ข้าว. 2. IResource และ ResourceInfo

ดังที่เราจะเห็นในภายหลัง การออกแบบพื้นฐานของโมเดลทรัพยากร (เราอาจเรียกว่าอิงตามแฮนเดิล) จะถูกนำมาใช้ใน Eclipse สำหรับโมเดลอื่นๆ เช่นกัน ในตอนนี้ เรามาแสดงรายการคุณสมบัติพิเศษบางประการของการออกแบบนี้:

• หมายเลขอ้างอิงเป็นวัตถุที่มีค่า วัตถุค่าเป็นวัตถุที่ไม่เปลี่ยนรูปซึ่งความเท่าเทียมกันไม่ได้ขึ้นอยู่กับตัวตน อ็อบเจ็กต์ดังกล่าวสามารถใช้เป็นคีย์ในคอนเทนเนอร์ที่แฮชได้อย่างปลอดภัย หมายเลขอ้างอิงหลายอินสแตนซ์สามารถอ้างอิงทรัพยากรเดียวกันได้ หากต้องการเปรียบเทียบ คุณต้องใช้วิธีเท่ากับ (Object)
• หมายเลขอ้างอิงกำหนดพฤติกรรมของทรัพยากร แต่ไม่มีข้อมูลเกี่ยวกับสถานะของทรัพยากร (ข้อมูลเดียวที่เก็บไว้คือ "คีย์" ซึ่งเป็นเส้นทางไปยังทรัพยากร)
• หมายเลขอ้างอิงอาจหมายถึงทรัพยากรที่ไม่มีอยู่ (ทั้งทรัพยากรที่ยังไม่ได้สร้างหรือทรัพยากรที่ถูกลบไปแล้ว) สามารถตรวจสอบการมีอยู่ของทรัพยากรได้โดยใช้เมธอด IResource.exists()
• การดำเนินการบางอย่างสามารถนำไปใช้ได้โดยอาศัยข้อมูลที่จัดเก็บไว้ในตัวจัดการเท่านั้น (เรียกว่าการดำเนินการเฉพาะตัวจัดการ) ตัวอย่าง ได้แก่ IResource.getParent(), getFullPath() ฯลฯ ไม่จำเป็นต้องมีทรัพยากรเพื่อให้การดำเนินการดังกล่าวสำเร็จ การดำเนินการที่จำเป็นต้องมีทรัพยากรเพื่อให้สำเร็จจะโยน CoreException หากไม่มีทรัพยากรอยู่

Eclipse จัดเตรียมกลไกที่มีประสิทธิภาพสำหรับการแจ้งเตือนการเปลี่ยนแปลงทรัพยากรพื้นที่ทำงาน (รูปที่ 3) รีซอร์สสามารถเปลี่ยนแปลงได้เป็นผลจากการดำเนินการที่ทำภายใน Eclipse IDE เอง หรือเป็นผลจากการซิงโครไนซ์กับระบบไฟล์ ในทั้งสองกรณี ลูกค้าที่สมัครรับการแจ้งเตือนจะได้รับข้อมูลโดยละเอียดเกี่ยวกับการเปลี่ยนแปลงในรูปแบบของ "เดลต้าทรัพยากร" เดลต้าอธิบายการเปลี่ยนแปลงระหว่างสองสถานะของทรีทรัพยากรพื้นที่ทำงาน (ย่อย) และตัวมันเองเป็นทรี ซึ่งแต่ละโหนดจะอธิบายการเปลี่ยนแปลงในทรัพยากรและมีรายการเดลต้าในระดับถัดไปที่อธิบายการเปลี่ยนแปลงในทรัพยากรย่อย

ข้าว. 3. IResourceChangeEvent และ IResourceDelta

กลไกการแจ้งเตือนตามเดลต้าทรัพยากรมีลักษณะดังต่อไปนี้:

• การเปลี่ยนแปลงครั้งเดียวและการเปลี่ยนแปลงหลายอย่างอธิบายโดยใช้โครงสร้างเดียวกัน เนื่องจากเดลต้าถูกสร้างขึ้นโดยใช้หลักการขององค์ประกอบแบบเรียกซ้ำ ลูกค้าสมาชิกสามารถประมวลผลการแจ้งเตือนการเปลี่ยนแปลงทรัพยากรโดยใช้การสืบทอดแบบเรียกซ้ำผ่านแผนผังเดลตา
• เดลต้ามีข้อมูลที่ครบถ้วนเกี่ยวกับการเปลี่ยนแปลงทรัพยากร รวมถึงการเคลื่อนไหวและ/หรือการเปลี่ยนแปลงใน "เครื่องหมาย" ที่เกี่ยวข้อง (เช่น ข้อผิดพลาดในการคอมไพล์จะแสดงเป็นเครื่องหมาย)
• เนื่องจากการอ้างอิงทรัพยากรทำผ่านหมายเลขอ้างอิง เดลต้าจึงสามารถอ้างอิงทรัพยากรระยะไกลได้ตามธรรมชาติ

ดังที่เราจะได้เห็นในเร็วๆ นี้ ส่วนประกอบหลักของการออกแบบกลไกการแจ้งเตือนการเปลี่ยนแปลงแบบจำลองทรัพยากรยังเกี่ยวข้องกับแบบจำลองตามหมายเลขอ้างอิงอื่นๆ อีกด้วย

เจดีที คอร์

โมเดลรีซอร์สเวิร์กสเปซ Eclipse เป็นโมเดลที่ไม่เชื่อเรื่องภาษาพื้นฐาน คอมโพเนนต์ JDT Core (ปลั๊กอิน org.eclipse.jdt.core) จัดเตรียม API สำหรับการนำทางและวิเคราะห์โครงสร้างเวิร์กสเปซจากเปอร์สเปคทีฟ Java ซึ่งเรียกว่า "โมเดล Java" (โมเดลจาวา). API นี้ถูกกำหนดในแง่ขององค์ประกอบ Java ซึ่งตรงข้ามกับ API โมเดลทรัพยากรพื้นฐาน ซึ่งถูกกำหนดในแง่ของโฟลเดอร์และไฟล์ อินเทอร์เฟซหลักของแผนผังองค์ประกอบ 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 สมัครรับการแจ้งเตือน ซึ่งแสดงเป็นวัตถุ ElementChangedEvent ที่มี IJavaElementDelta (รูปที่ 6)

ข้าว. 6. ElementChangedEvent และ IJavaElementDelta

โมเดล Java ไม่มีข้อมูลเกี่ยวกับเนื้อความของวิธีการหรือการจำแนกชื่อ ดังนั้นสำหรับการวิเคราะห์โดยละเอียดของโค้ดที่เขียนด้วย Java นั้น JDT Core จึงมีโมเดลเพิ่มเติม (แบบไม่ใช้แฮนเดิล): ต้นไม้ไวยากรณ์นามธรรม (แผนผังไวยากรณ์นามธรรม AST) AST แสดงถึงผลลัพธ์ของการแยกวิเคราะห์ข้อความต้นฉบับ โหนด AST สอดคล้องกับองค์ประกอบของโครงสร้างของโมดูลต้นทาง (การประกาศ ตัวดำเนินการ นิพจน์ ฯลฯ) และมีข้อมูลเกี่ยวกับพิกัดขององค์ประกอบที่เกี่ยวข้องในข้อความต้นฉบับ ตลอดจนข้อมูล (เป็นตัวเลือก) เกี่ยวกับการจำแนกชื่อใน รูปแบบของการเชื่อมโยงไปยังสิ่งที่เรียกว่า ผูก. การเชื่อมโยงคืออ็อบเจ็กต์ที่แสดงถึงเอนทิตีที่มีชื่อ เช่น ประเภท วิธีการ และตัวแปร ที่คอมไพลเลอร์รู้จัก ต่างจากโหนด AST ซึ่งก่อตัวเป็นแผนผัง การผูกรองรับการอ้างอิงโยงและโดยทั่วไปจะสร้างกราฟ คลาสนามธรรม ASTNode เป็นคลาสพื้นฐานทั่วไปสำหรับโหนด AST ทั้งหมด คลาสย่อย ASTNode สอดคล้องกับโครงสร้างวากยสัมพันธ์เฉพาะของภาษา Java

เนื่องจากแผนผังไวยากรณ์สามารถใช้หน่วยความจำจำนวนมากได้ JDT จึงแคชเพียง AST เดียวสำหรับเอดิเตอร์ที่แอ็คทีฟ แตกต่างจากโมเดล Java โดยทั่วไป AST จะถูกมองว่าเป็นโมเดล "ระดับกลาง" "ชั่วคราว" ซึ่งสมาชิกไม่ควรถูกอ้างอิงโดยไคลเอนต์นอกบริบทของการดำเนินการที่นำไปสู่การสร้าง AST

โมเดลทั้งสามที่ระบุไว้ (โมเดล Java, AST, การเชื่อมโยง) รวมกันเป็นพื้นฐานสำหรับการสร้าง “เครื่องมือพัฒนาอัจฉริยะ” ใน JDT รวมถึงโปรแกรมแก้ไข Java ที่ทรงพลังพร้อม “ตัวช่วย” ต่างๆ การดำเนินการต่างๆ สำหรับการประมวลผลซอร์สโค้ด (รวมถึงการจัดระเบียบรายการนำเข้า ชื่อและการจัดรูปแบบตามสไตล์ที่กำหนดเอง) เครื่องมือค้นหาและการปรับโครงสร้างใหม่ ในกรณีนี้ โมเดล Java มีบทบาทพิเศษ เนื่องจากโมเดล Java ถูกใช้เป็นพื้นฐานสำหรับการแสดงภาพของโครงสร้างของแอปพลิเคชันที่กำลังพัฒนา (เช่น ใน Package Explorer, Outline, Search, Call Hierarchy และ ประเภทลำดับชั้น)

ส่วนประกอบ Eclipse ที่ใช้ใน 1C: เครื่องมือพัฒนาองค์กร

ในรูป รูปที่ 7 แสดงส่วนประกอบ Eclipse ที่สร้างรากฐานของแพลตฟอร์มเทคโนโลยีสำหรับ 1C: เครื่องมือพัฒนาองค์กร

ข้าว. 7. Eclipse เป็นแพลตฟอร์มสำหรับ 1C: เครื่องมือพัฒนาองค์กร

แพลตฟอร์มคราส ให้โครงสร้างพื้นฐาน เราได้ดูบางแง่มุมของโครงสร้างพื้นฐานนี้ในส่วนที่แล้ว

กรอบการสร้างแบบจำลองคราส (EMF) เป็นวิธีทั่วไปในการสร้างแบบจำลองข้อมูลที่มีโครงสร้าง EMF ถูกรวมเข้ากับแพลตฟอร์ม Eclipse แต่ยังสามารถใช้แยกกันในแอปพลิเคชัน Java ทั่วไปได้ บ่อยครั้งที่นักพัฒนา Eclipse ใหม่คุ้นเคยกับ EMF เป็นอย่างดี แม้ว่าพวกเขาจะยังไม่เข้าใจความซับซ้อนของแพลตฟอร์ม Eclipse อย่างถ่องแท้ก็ตาม สาเหตุหนึ่งที่ทำให้ความนิยมที่สมควรได้รับคือการออกแบบที่เป็นสากลซึ่งรวมถึง API ระดับเมตาแบบรวมซึ่งช่วยให้คุณทำงานกับโมเดล EMF ใด ๆ ในลักษณะทั่วไป การใช้งานพื้นฐานสำหรับอ็อบเจ็กต์โมเดลที่จัดเตรียมโดย EMF และระบบย่อยสำหรับการสร้างโค้ดโมเดลตามเมตาโมเดลจะเพิ่มความเร็วของการพัฒนาอย่างมาก และลดจำนวนข้อผิดพลาด EMF ยังมีกลไกสำหรับการทำให้โมเดลเป็นอนุกรม การติดตามการเปลี่ยนแปลงในโมเดล และอื่นๆ อีกมากมาย

เช่นเดียวกับเครื่องมืออเนกประสงค์ทั่วไป EMF เหมาะสำหรับการแก้ปัญหาการสร้างแบบจำลองที่หลากหลาย แต่คลาสของโมเดลบางคลาส (เช่น โมเดลแบบมือจับที่กล่าวถึงข้างต้น) อาจต้องใช้เครื่องมือการสร้างแบบจำลองพิเศษมากกว่า การพูดถึง EMF นั้นเป็นงานที่ไร้คุณค่า โดยเฉพาะอย่างยิ่งภายในขอบเขตที่จำกัดของบทความเดียว เนื่องจากนี่เป็นหัวข้อของหนังสือเล่มอื่นและเป็นเล่มที่ค่อนข้างหนา ให้เราทราบเพียงว่าระบบคุณภาพสูงของลักษณะทั่วไปที่เป็นรากฐานของ EMF อนุญาตให้เกิดโครงการทั้งหมดที่เกี่ยวข้องกับการสร้างแบบจำลอง ซึ่งรวมอยู่ในโครงการระดับบนสุด การสร้างแบบจำลองคราส รวมถึง EMF เองด้วย หนึ่งในโครงการดังกล่าวคือ Eclipse Xtext

คราส Xtext จัดเตรียมโครงสร้างพื้นฐาน "การสร้างแบบจำลองข้อความ" ใช้ Xtext แอนท์แอลอาร์ สำหรับการแยกวิเคราะห์ข้อความต้นฉบับและ EMF เพื่อแสดงผลลัพธ์ ASG (กราฟความหมายเชิงนามธรรม ซึ่งโดยพื้นฐานแล้วเป็นการผสมผสานระหว่าง AST และการเชื่อมโยง) หรือที่เรียกว่า "แบบจำลองความหมาย" ไวยากรณ์ของภาษาที่สร้างแบบจำลองโดย Xtext ได้รับการอธิบายในภาษาของ Xtext เอง สิ่งนี้ช่วยให้คุณไม่เพียงสร้างคำอธิบายไวยากรณ์สำหรับ ANTLR เท่านั้น แต่ยังได้รับกลไกการทำให้เป็นอนุกรม AST (เช่น Xtext มีทั้ง parser และ unparser) คำใบ้บริบท และส่วนประกอบภาษาอื่น ๆ จำนวนมาก ในทางกลับกัน ภาษาไวยากรณ์ที่ใช้ใน 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 เกิดขึ้นจากการสนับสนุนโค้ดเบื้องต้นให้กับ Eclipse Foundation ที่สร้างโดย 1C ในปี 2014 ตั้งแต่นั้นมา 1C ยังคงสนับสนุนการพัฒนาโครงการอย่างต่อเนื่อง: Handly committers คือพนักงานของบริษัท โปรเจ็กต์มีขนาดเล็ก แต่อยู่ในกลุ่มเฉพาะใน Eclipse: เป้าหมายหลักคือสนับสนุนการพัฒนาโมเดลแบบแฮนเดิล

หลักการทางสถาปัตยกรรมพื้นฐานของโมเดลแบบแฮนเดิล เช่น สำนวนแฮนเดิล/เนื้อหา ได้ถูกกล่าวถึงข้างต้นโดยใช้โมเดลทรัพยากรและโมเดล Java เป็นตัวอย่าง นอกจากนี้ยังตั้งข้อสังเกตอีกว่าทั้งโมเดลทรัพยากรและโมเดล Java เป็นรากฐานที่สำคัญสำหรับเครื่องมือการพัฒนา Eclipse Java (JDT) และเนื่องจากโปรเจ็กต์ *DT Eclipse เกือบทั้งหมดมีสถาปัตยกรรมที่คล้ายคลึงกับ JDT จึงไม่ใช่เรื่องเกินจริงที่จะกล่าวว่าโมเดลแบบแฮนเดิลรองรับหลาย ๆ ตัว หากไม่ใช่ IDE ทั้งหมดที่สร้างขึ้นบนแพลตฟอร์ม Eclipse ตัวอย่างเช่น Eclipse C/C++ Development Tooling (CDT) มีโมเดล C/C++ แบบอิงแฮนเดิลที่มีบทบาทในสถาปัตยกรรม CDT เหมือนกับที่โมเดล Java ทำใน JDT

ก่อน Handly Eclipse ไม่มีไลบรารีเฉพาะสำหรับการสร้างแบบจำลองภาษาที่ใช้แฮนเดิล โมเดลที่มีอยู่ในปัจจุบันถูกสร้างขึ้นโดยการปรับโค้ดโมเดล Java โดยตรง (หรือที่เรียกว่าการคัดลอก/วาง) ในกรณีที่อนุญาต ใบอนุญาตสาธารณะ Eclipse (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 ทั่วไปบางอย่างที่ ทำงานร่วมกับโปรแกรมแก้ไขซอร์สโค้ด โมเดลที่ใช้งานง่าย เช่น กรอบงานเค้าร่าง เพื่อแสดงให้เห็นถึงความสามารถ โปรเจ็กต์จึงมีตัวอย่างหลายตัวอย่าง รวมถึงการใช้งานโมเดล Java ใน Handly (เมื่อเปรียบเทียบกับการใช้งานโมเดล Java อย่างสมบูรณ์ใน JDT โมเดลนี้ตั้งใจทำให้ง่ายขึ้นเพื่อความชัดเจนที่มากขึ้น)

ตามที่ระบุไว้ก่อนหน้านี้ จุดสนใจหลักในระหว่างการออกแบบเบื้องต้นของ Handly และการพัฒนาที่ตามมาคือและยังคงมุ่งเน้นไปที่ความสามารถในการขยายขนาดและความยืดหยุ่น

โดยหลักการแล้ว รุ่นที่ใช้มือจับจะปรับขนาดได้ค่อนข้างดี "ตามการออกแบบ" ตัวอย่างเช่น สำนวนที่จับ/เนื้อหาช่วยให้คุณสามารถจำกัดจำนวนหน่วยความจำที่โมเดลใช้ แต่ก็มีความแตกต่างเช่นกัน ดังนั้น เมื่อทดสอบความสามารถในการปรับขนาดได้ Handly จึงพบปัญหาในการใช้กลไกการแจ้งเตือน - เมื่อองค์ประกอบจำนวนมากมีการเปลี่ยนแปลง การสร้างเดลต้าใช้เวลานานเกินไป ปรากฎว่ามีปัญหาเดียวกันนี้ในโมเดล JDT Java ซึ่งครั้งหนึ่งเคยมีการปรับเปลี่ยนโค้ดที่เกี่ยวข้อง เราได้แก้ไขข้อผิดพลาดใน Handly และเตรียมแพตช์ที่คล้ายกันสำหรับ JDT ซึ่งได้รับการตอบรับอย่างซาบซึ้งใจ นี่เป็นเพียงตัวอย่างหนึ่งที่การนำ Handly ไปใช้ในการใช้งานโมเดลที่มีอยู่อาจมีประโยชน์ เนื่องจากในกรณีนี้ข้อบกพร่องดังกล่าวสามารถแก้ไขได้ในที่เดียว

เพื่อให้การนำ Handly ไปใช้ในการใช้งานโมเดลที่มีอยู่นั้นมีความเป็นไปได้ทางเทคนิค ไลบรารีจะต้องมีความยืดหยุ่นอย่างมาก ปัญหาหลักคือการรักษาความเข้ากันได้แบบย้อนหลังในโมเดล API ปัญหานี้ได้รับการแก้ไขแล้วใน แฮนด์ลี่ 0.5 โดยการแยก API เฉพาะรุ่นที่กำหนดและควบคุมโดยนักพัฒนาออกจาก API ระดับเมตาแบบรวมที่จัดทำโดยไลบรารีอย่างชัดเจน สิ่งนี้ไม่เพียงทำให้เป็นไปได้ทางเทคนิคในการนำ Handly ไปใช้กับการใช้งานที่มีอยู่ แต่ยังให้อิสระแก่นักพัฒนาโมเดลใหม่ในการออกแบบ API อีกด้วย

ความยืดหยุ่นยังมีด้านอื่นด้วย ตัวอย่างเช่น Handly แทบไม่มีข้อจำกัดใดๆ เกี่ยวกับโครงสร้างของโมเดล และสามารถนำไปใช้ในการสร้างแบบจำลองทั้งภาษาสำหรับวัตถุประสงค์ทั่วไปและภาษาเฉพาะโดเมน เมื่อสร้างโครงสร้างของไฟล์ต้นฉบับ Handly ไม่ได้กำหนดรูปแบบเฉพาะของการแสดง AST ใดๆ และโดยหลักการแล้ว ไม่จำเป็นต้องใช้ AST ด้วยซ้ำ ดังนั้นจึงรับประกันความเข้ากันได้กับกลไกการแยกวิเคราะห์เกือบทุกชนิด สุดท้ายนี้ Handly รองรับการผสานรวมอย่างสมบูรณ์กับพื้นที่ทำงาน Eclipse แต่ยังสามารถทำงานกับระบบไฟล์ได้โดยตรงด้วยการผสานรวมกับ ระบบไฟล์คราส (อีเอฟเอส).

เวอร์ชันปัจจุบัน แฮนด์ลี่ 0.6 ออกมาในเดือนธันวาคม 2016 แม้ว่าโครงการจะอยู่ในสถานะบ่มเพาะและ API ยังไม่ได้รับการแก้ไขในที่สุด แต่ Handly ก็ถูกนำมาใช้ในผลิตภัณฑ์เชิงพาณิชย์ขนาดใหญ่สองรายการซึ่งเสี่ยงต่อการทำหน้าที่เป็น "ผู้ใช้งานกลุ่มแรก" และฉันต้องบอกว่า อย่าเพิ่งเสียใจเลย

ตามที่ระบุไว้ข้างต้น หนึ่งในผลิตภัณฑ์เหล่านี้คือ 1C:เครื่องมือพัฒนาองค์กร โดยที่ Handly ถูกใช้ตั้งแต่เริ่มต้นเพื่อสร้างแบบจำลององค์ประกอบของโครงสร้างระดับสูงของภาษา 1C:Enterprise เช่นภาษาโปรแกรมในตัวและภาษาคิวรี . สินค้าอีกชิ้นหนึ่งไม่ค่อยเป็นที่รู้จักของสาธารณชนทั่วไป นี้ โคดาซิป สตูดิโอสภาพแวดล้อมการออกแบบแบบบูรณาการสำหรับตัวประมวลผลชุดคำสั่งเฉพาะแอปพลิเคชัน (ASIP) ซึ่งใช้ทั้งภายในบริษัท Codasip ของเช็กเองและโดยลูกค้า รวมถึง เอเอ็มดี, AVG, Mobileye, การออกแบบซิกมา. Codasip ใช้ Handly ในการผลิตมาตั้งแต่ปี 2015 โดยเริ่มจากเวอร์ชัน Handly 0.2 Codasip Studio รุ่นล่าสุดใช้เวอร์ชัน 0.5 ซึ่งเปิดตัวในเดือนมิถุนายน 2016 Ondřej Ilčík ซึ่งเป็นผู้นำการพัฒนา IDE ที่ Codasip กำลังติดต่อกับโปรเจ็กต์ โดยให้ข้อเสนอแนะที่สำคัญในนามของ "ผู้รับใช้บุคคลที่สาม" เขายังสามารถหาเวลาว่างเพื่อเข้าร่วมในการพัฒนาโปรเจ็กต์โดยตรง โดยใช้เลเยอร์ UI (โค้ดประมาณ 4000 บรรทัด) สำหรับหนึ่งในตัวอย่าง Handly ซึ่งเป็นโมเดล Java ข้อมูลมือแรกโดยละเอียดเพิ่มเติมเกี่ยวกับการใช้ Handly by adopters สามารถพบได้ในหน้านี้ เรื่องราวความสำเร็จ โครงการ

เราหวังว่าหลังจากการเปิดตัวเวอร์ชัน 1.0 พร้อมการรับประกันความเสถียรของ API และโครงการออกจากสถานะบ่มเพาะ Handly จะมีผู้ใช้รายใหม่ ในระหว่างนี้ โปรเจ็กต์ยังคงทดสอบและปรับปรุง API ต่อไป โดยออกรุ่น "หลัก" สองรุ่นต่อปี ในเดือนมิถุนายน (วันเดียวกับการเปิดตัว Eclipse พร้อมกัน) และเดือนธันวาคม โดยมีกำหนดการที่คาดการณ์ได้ซึ่งผู้ใช้งานสามารถไว้วางใจได้ นอกจากนี้เรายังสามารถเพิ่มเติมได้ว่า "อัตราข้อผิดพลาด" ของโครงการยังคงอยู่ที่ระดับต่ำอย่างต่อเนื่อง และ Handly ทำงานได้อย่างน่าเชื่อถือในผลิตภัณฑ์ของผู้ใช้งานกลุ่มแรกตั้งแต่เวอร์ชันแรกสุด หากต้องการสำรวจ Eclipse Handly เพิ่มเติม คุณสามารถใช้ การเริ่มต้นใช้งานบทช่วยสอน и ภาพรวมสถาปัตยกรรม.

ที่มา: will.com