เกี่ยวกับเว็บไคลเอ็นต์ 1C

หนึ่งในคุณสมบัติที่ดีของเทคโนโลยี 1C: Enterprise คือโซลูชันแอปพลิเคชันที่พัฒนาโดยใช้เทคโนโลยีฟอร์มที่มีการจัดการสามารถเปิดใช้ได้ทั้งในไคลเอนต์แบบบาง (เรียกใช้งานได้) ภายใต้ Windows, Linux, MacOS X และเป็นเว็บไคลเอนต์สำหรับ 5 เบราว์เซอร์ - Chrome, Internet Explorer, Firefox, Safari, Edge และทั้งหมดนี้โดยไม่ต้องเปลี่ยนซอร์สโค้ดของแอปพลิเคชัน ยิ่งไปกว่านั้น ภายนอก แอปพลิเคชันในไคลเอนต์แบบบางและในเบราว์เซอร์ทำงานและดูเกือบจะเหมือนกัน
ค้นหา 10 ความแตกต่าง (ภายใต้การตัด 2 ภาพ):

หน้าต่างไคลเอนต์แบบบางบน Linux:

หน้าต่างเดียวกันในเว็บไคลเอ็นต์ (ในเบราว์เซอร์ Chrome):

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

การเพิ่มความสามารถของเว็บให้กับธินไคลเอ็นต์ถือเป็นการดำเนินการครั้งใหญ่ด้วยการเปลี่ยนแปลงสถาปัตยกรรมไคลเอ็นต์/เซิร์ฟเวอร์ทั้งหมด การสร้างเว็บไคลเอนต์เป็นโครงการใหม่ที่เริ่มต้นจากศูนย์

คำแถลงปัญหา

ดังนั้น ข้อกำหนดสำหรับโครงการ: เว็บไคลเอ็นต์ต้องทำเช่นเดียวกับไคลเอนต์แบบบาง กล่าวคือ:

1. แสดงส่วนติดต่อผู้ใช้
2. รันโค้ดไคลเอนต์ที่เขียนด้วยภาษา 1C

ส่วนต่อประสานผู้ใช้ใน 1C นั้นอธิบายไว้ในโปรแกรมแก้ไขภาพ แต่เป็นการเปิดเผยโดยไม่มีการจัดเรียงองค์ประกอบแบบพิกเซลต่อพิกเซล มีการใช้องค์ประกอบอินเทอร์เฟซประมาณสามโหล - ปุ่ม, ช่องป้อนข้อมูล (ข้อความ, ดิจิตอล, วันที่ / เวลา), รายการ, ตาราง, กราฟ ฯลฯ

รหัสไคลเอนต์ในภาษา 1C สามารถมีการเรียกเซิร์ฟเวอร์ ทำงานกับทรัพยากรในเครื่อง (ไฟล์ ฯลฯ) การพิมพ์ และอื่นๆ อีกมากมาย

ทั้งไคลเอ็นต์แบบบาง (เมื่อทำงานผ่านเว็บ) และเว็บไคลเอ็นต์ใช้บริการเว็บชุดเดียวกันเพื่อสื่อสารกับแอปพลิเคชันเซิร์ฟเวอร์ 1C แน่นอนว่าการใช้งานไคลเอนต์นั้นแตกต่างกัน - ไคลเอนต์แบบบางเขียนด้วย C ++ เว็บไคลเอ็นต์เขียนด้วย JavaScript

บิตของประวัติศาสตร์

โครงการเว็บไคลเอนต์เริ่มต้นในปี 2006 โดยมีทีมงาน (โดยเฉลี่ย) 5 คน ในบางขั้นตอนของโครงการ นักพัฒนามีส่วนร่วมในการใช้ฟังก์ชันเฉพาะ (เอกสารสเปรดชีต ไดอะแกรม ฯลฯ) ตามกฎแล้ว คนเหล่านี้คือนักพัฒนาคนเดียวกันที่สร้างฟังก์ชันนี้ในไคลเอนต์แบบบาง เหล่านั้น. นักพัฒนาเขียนส่วนประกอบใน JavaScript ที่พวกเขาสร้างไว้ก่อนหน้านี้ใน C ++

จากจุดเริ่มต้น เราปฏิเสธแนวคิดของการแปลงโค้ด C++ ไคลเอนต์แบบบางโดยอัตโนมัติ (อย่างน้อยบางส่วน) เป็นเว็บไคลเอ็นต์ JavaScript เนื่องจากความแตกต่างทางแนวคิดอย่างมากระหว่างสองภาษา เว็บไคลเอนต์เขียนด้วย JavaScript ตั้งแต่เริ่มต้น

ในการทำซ้ำครั้งแรกของโครงการ เว็บไคลเอนต์แปลงรหัสไคลเอนต์ในภาษา 1C ในตัวเป็น JavaScript โดยตรง ธินไคลเอ็นต์ทำหน้าที่แตกต่างออกไป โค้ดในภาษา 1C ในตัวจะถูกคอมไพล์เป็นไบต์โค้ด จากนั้นจึงตีความโค้ดไบต์นี้บนไคลเอ็นต์ ต่อจากนั้น เว็บไคลเอ็นต์ก็เริ่มทำแบบเดียวกัน ประการแรก ทำให้ประสิทธิภาพเพิ่มขึ้น และประการที่สอง ทำให้สามารถรวมสถาปัตยกรรมของธินและเว็บไคลเอนต์เข้าด้วยกันได้

เวอร์ชันแรกของแพลตฟอร์ม 1C: Enterprise พร้อมการสนับสนุนเว็บไคลเอ็นต์เปิดตัวในปี 2009 เว็บไคลเอนต์ในเวลานั้นรองรับ 2 เบราว์เซอร์ - Internet Explorer และ Firefox แผนเดิมคือการสนับสนุน Opera แต่เนื่องจากปัญหาที่ผ่านไม่ได้กับตัวจัดการการปิดแอปพลิเคชันใน Opera ในขณะนั้น (ไม่สามารถติดตามได้อย่างแน่นอน 100% ว่าแอปพลิเคชันกำลังปิด และในขณะนั้นเพื่อดำเนินการขั้นตอนการตัดการเชื่อมต่อจากเซิร์ฟเวอร์แอปพลิเคชัน 1C) แผนเหล่านี้จึงต้องล้มเลิกไป

โครงสร้างโครงการ

โดยรวมแล้ว แพลตฟอร์ม 1C:Enterprise มี 4 โครงการที่เขียนด้วย JavaScript:

1. WebTools - ไลบรารีที่ใช้ร่วมกันซึ่งใช้โดยโครงการอื่น (ในที่นี้รวมถึง Google ปิดห้องสมุด).
2. องค์ประกอบการควบคุม เอกสารที่จัดรูปแบบ (ใช้งานใน JavaScript ทั้งในไคลเอ็นต์แบบบางและในเว็บไคลเอ็นต์)
3. องค์ประกอบการควบคุม กำหนดการ (ใช้งานใน JavaScript ทั้งในไคลเอ็นต์แบบบางและในเว็บไคลเอ็นต์)
4. เว็บไคลเอนต์

โครงสร้างของแต่ละโปรเจ็กต์คล้ายกับโครงสร้างของโปรเจ็กต์ Java (หรือโปรเจ็กต์ .NET - แล้วแต่จำนวนใดจะใกล้เคียงกับคุณ) เรามีเนมสเปซ และแต่ละเนมสเปซอยู่ในโฟลเดอร์แยกต่างหาก ภายในโฟลเดอร์มีไฟล์และคลาสเนมสเปซ มีไฟล์ประมาณ 1000 ไฟล์ในโครงการเว็บไคลเอ็นต์

โครงสร้างเว็บไคลเอ็นต์แบ่งออกเป็นระบบย่อยดังต่อไปนี้:

• อินเทอร์เฟซแอปพลิเคชันไคลเอ็นต์ที่มีการจัดการ
  • อินเทอร์เฟซแอปพลิเคชันทั่วไป (เมนูระบบ แผงควบคุม)
  • อินเทอร์เฟซแบบฟอร์มที่มีการจัดการซึ่งประกอบด้วยตัวควบคุมประมาณ 30 รายการ (ปุ่ม ช่องป้อนข้อมูลประเภทต่างๆ - ข้อความ ดิจิทัล วันที่/เวลา ฯลฯ ตาราง รายการ กราฟ ฯลฯ)

• โมเดลออบเจกต์พร้อมใช้งานสำหรับนักพัฒนาบนไคลเอ็นต์ (รวมแล้วมากกว่า 400 ประเภท: โมเดลอ็อบเจ็กต์อินเทอร์เฟซที่มีการจัดการ การตั้งค่าองค์ประกอบข้อมูล การจัดรูปแบบตามเงื่อนไข ฯลฯ)
• ตัวแปลภาษาในตัว 1C
• ส่วนขยายของเบราว์เซอร์ (ใช้สำหรับการทำงานที่ไม่รองรับใน JavaScript)
  • ทำงานกับการเข้ารหัส
  • ทำงานกับไฟล์
  • เทคโนโลยีส่วนประกอบภายนอกที่อนุญาตให้ใช้ในไคลเอนต์แบบบางและแบบเว็บ

คุณสมบัติการพัฒนา

การนำทั้งหมดข้างต้นไปใช้ใน JavaScript นั้นไม่ใช่เรื่องง่าย บางทีเว็บไคลเอ็นต์ 1C อาจเป็นหนึ่งในแอปพลิเคชันฝั่งไคลเอ็นต์ที่ใหญ่ที่สุดที่เขียนด้วย JavaScript - ประมาณ 450.000 บรรทัด เราใช้วิธีการเชิงวัตถุอย่างจริงจังในรหัสเว็บไคลเอ็นต์ ซึ่งช่วยลดความยุ่งยากในการทำงานกับโครงการขนาดใหญ่เช่นนี้

เพื่อลดขนาดของรหัสไคลเอนต์ อันดับแรกเราใช้ตัวสร้างความสับสนของเราเอง และเริ่มใช้ตั้งแต่แพลตฟอร์มเวอร์ชัน 8.3.6 (ตุลาคม 2014) คอมไพเลอร์ปิด Google. ผลของการใช้ตัวเลขคือขนาดของเว็บไคลเอ็นต์เฟรมเวิร์กหลังจากการทำให้งงงวย:

• obfuscator ของตัวเอง - 1556 kb
• คอมไพเลอร์ปิด Google - 1073 kb

การใช้ Google Closure Compiler ช่วยให้เราปรับปรุงประสิทธิภาพของเว็บไคลเอ็นต์ได้ 30% เมื่อเทียบกับเครื่องมือสร้างความสับสนของเราเอง นอกจากนี้ จำนวนหน่วยความจำที่แอปพลิเคชันใช้ลดลง 15-25% (ขึ้นอยู่กับเบราว์เซอร์)

Google Closure Compiler ทำงานได้ดีกับโค้ดเชิงวัตถุ ดังนั้นประสิทธิภาพจึงสูงสุดสำหรับเว็บไคลเอ็นต์ Closure Compiler ทำสิ่งดีๆ ให้เรา:

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

เราใช้ WebStorm เป็นสภาพแวดล้อมการพัฒนาเว็บไคลเอ็นต์ของเรา

สำหรับการวิเคราะห์รหัสเราใช้ โซนาร์คิวบ์ซึ่งเราผสานรวมเครื่องมือวิเคราะห์โค้ดแบบสแตติก ด้วยความช่วยเหลือของตัววิเคราะห์ เราตรวจสอบการลดคุณภาพของซอร์สโค้ด JavaScript และพยายามป้องกัน

เรากำลังแก้ไขงานอะไรอยู่

ในระหว่างการดำเนินโครงการ เราเผชิญกับงานที่น่าสนใจหลายอย่างที่เราต้องแก้ไข

การแลกเปลี่ยนข้อมูลกับเซิร์ฟเวอร์และระหว่างหน้าต่าง

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

• รหัสที่มาจากเซิร์ฟเวอร์เป็นโครงสร้างข้อมูล
• รหัสสำหรับหน้าต่างแอปพลิเคชันอื่น

เพื่อหลีกเลี่ยงความสับสนเมื่อโต้ตอบกับเซิร์ฟเวอร์ เราใช้แท็ก @expose:

/**
 * @constructor
 * @extends {Base.SrvObject}
 */
Srv.Core.GenericException = function ()
{
    /**
     * @type {string}
     * @expose
     */
    this.descr;

    /**
     * @type {Srv.Core.GenericException}
     * @expose
     */
    this.inner;

    /**
     * @type {string}
     * @expose
     */
    this.clsid;

    /**
     * @type {boolean}
     * @expose
     */
    this.encoded;
}

และเพื่อหลีกเลี่ยงความสับสนเมื่อโต้ตอบกับหน้าต่างอื่น เราใช้อินเทอร์เฟซที่ส่งออกที่เรียกว่า (อินเทอร์เฟซที่ส่งออกเมธอดทั้งหมด)

/**
 * Экспортируемый интерфейс контрола DropDownWindow
 *
 * @interface
 * @struct
 */
WebUI.IDropDownWindowExp = function(){}

/**
 * Перемещает выделение на 1 вперед или назад
 *
 * @param {boolean} isForward
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOnly){}

/**
 * Перемещает выделение в начало или конец
 *
 * @param {boolean} isFirst
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly){}

/**
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.selectValue = function (){}

เราใช้ Virtual DOM ก่อนที่มันจะกลายเป็นกระแสหลัก)

เช่นเดียวกับนักพัฒนาทั้งหมดที่เกี่ยวข้องกับ Web UI ที่ซับซ้อน เราตระหนักได้อย่างรวดเร็วว่า DOM ไม่เหมาะกับอินเทอร์เฟซผู้ใช้แบบไดนามิก เกือบจะในทันที มีการใช้อะนาล็อกของ Virtual DOM เพื่อเพิ่มประสิทธิภาพการทำงานกับ UI ระหว่างการประมวลผลเหตุการณ์ การเปลี่ยนแปลง DOM ทั้งหมดจะถูกจัดเก็บไว้ในหน่วยความจำ และเมื่อดำเนินการทั้งหมดเสร็จสิ้นแล้ว การเปลี่ยนแปลงที่สะสมจะถูกนำไปใช้กับแผนผัง DOM

การเพิ่มประสิทธิภาพเว็บไคลเอ็นต์

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

การทดสอบ

สำหรับการทดสอบการทำงานและประสิทธิภาพ เราใช้เครื่องมือของเราเอง (เขียนด้วย Java และ C++) รวมถึงชุดการทดสอบที่สร้างขึ้นบนพื้นฐานของ ซีลีเนียม.

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

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

เครื่องมือทดสอบและแอปพลิเคชันของเราอยู่ระหว่างการทดสอบ

เครื่องมือของเราและซีลีเนียมเสริมซึ่งกันและกัน ตัวอย่างเช่น หากปุ่มใดปุ่มหนึ่งบนหน้าจอใดหน้าจอหนึ่งเปลี่ยนตำแหน่ง - ซีลีเนียมอาจไม่สามารถติดตามได้ แต่เครื่องมือของเราจะสังเกตเห็น เนื่องจาก ทำการเปรียบเทียบพิกเซลต่อพิกเซลของภาพหน้าจอกับมาตรฐาน นอกจากนี้ เครื่องมือยังสามารถติดตามปัญหาเกี่ยวกับการประมวลผลอินพุตจากแป้นพิมพ์หรือเมาส์ เนื่องจากนั่นคือสิ่งที่สร้างขึ้นใหม่

การทดสอบเครื่องมือทั้งสอง (ของเราและซีลีเนียม) รันสถานการณ์การทำงานทั่วไปจากโซลูชันแอปพลิเคชันของเรา การทดสอบจะเปิดขึ้นโดยอัตโนมัติหลังจากสร้างแพลตฟอร์ม 1C: Enterprise รายวัน หากสคริปต์ทำงานช้าลง (เทียบกับรุ่นก่อนหน้า) เราจะตรวจสอบและแก้ไขสาเหตุของการชะลอตัว เกณฑ์ของเรานั้นง่าย - ชุดประกอบใหม่ไม่ควรทำงานช้ากว่าชุดก่อนหน้า

นักพัฒนาใช้เครื่องมือต่าง ๆ เพื่อตรวจสอบเหตุการณ์การชะลอตัว ใช้เป็นหลัก Dynatrace รุ่น AJAX บริษัทผลิต ไดน่าเทรซ. บันทึกของการดำเนินการของการดำเนินการที่มีปัญหาในชุดก่อนหน้าและชุดใหม่จะถูกบันทึก จากนั้นบันทึกจะถูกวิเคราะห์ ในขณะเดียวกัน เวลาดำเนินการของการดำเนินการเดี่ยว (หน่วยเป็นมิลลิวินาที) อาจไม่ใช่ปัจจัยชี้ขาด - กระบวนการบริการ เช่น การรวบรวมขยะ จะถูกเรียกใช้เป็นระยะในเบราว์เซอร์ ซึ่งอาจทับซ้อนกับเวลาดำเนินการของฟังก์ชันและทำให้ภาพบิดเบี้ยว พารามิเตอร์ที่เกี่ยวข้องในกรณีนี้คือจำนวนของคำสั่ง JavaScript ที่ดำเนินการ จำนวนของการดำเนินการปรมาณูใน DOM และอื่นๆ หากจำนวนคำสั่ง/การดำเนินการในสคริปต์เดียวกันในเวอร์ชันใหม่เพิ่มขึ้น แสดงว่าประสิทธิภาพลดลงซึ่งจำเป็นต้องแก้ไขเกือบทุกครั้ง

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

ส่วนขยายของเบราว์เซอร์

ในกรณีที่โซลูชันที่ใช้ต้องการฟังก์ชันที่ไม่ได้อยู่ใน JavaScript เราจะใช้ส่วนขยายของเบราว์เซอร์:

• เพื่อทำงานกับไฟล์
• เพื่อทำงานกับการเข้ารหัส
• ทำงานกับ ส่วนประกอบภายนอก

ส่วนขยายของเราประกอบด้วยสองส่วน ส่วนแรกคือสิ่งที่เรียกว่าส่วนขยายของเบราว์เซอร์ (โดยปกติคือส่วนขยาย JavaScript สำหรับ Chrome และ Firefox) ที่โต้ตอบกับส่วนที่สอง ซึ่งเป็นส่วนขยายแบบไบนารีที่ใช้ฟังก์ชันการทำงานที่เราต้องการ ควรสังเกตว่าเราเขียนส่วนขยายไบนารี 3 เวอร์ชัน - สำหรับ Windows, Linux และ MacOS ส่วนขยายไบนารีมีให้โดยเป็นส่วนหนึ่งของแพลตฟอร์ม 1C: Enterprise และอยู่บนเซิร์ฟเวอร์แอปพลิเคชัน 1C ครั้งแรกที่เรียกจากเว็บไคลเอ็นต์ ระบบจะดาวน์โหลดไปยังคอมพิวเตอร์ไคลเอ็นต์และติดตั้งในเบราว์เซอร์

เมื่อทำงานใน Safari ส่วนขยายของเราจะใช้ NPAPI เมื่อทำงานใน Internet Explorer ส่วนขยายของเราจะใช้เทคโนโลยี ActiveX Microsoft Edge ยังไม่รองรับส่วนขยาย ดังนั้นเว็บไคลเอ็นต์จึงทำงานได้อย่างจำกัด

การพัฒนาต่อไป

หนึ่งในกลุ่มงานสำหรับทีมพัฒนาเว็บไคลเอ็นต์คือการพัฒนาเพิ่มเติมของฟังก์ชัน ฟังก์ชันการทำงานของเว็บไคลเอ็นต์ควรเหมือนกันกับฟังก์ชันของไคลเอ็นต์แบบบาง ฟังก์ชันการทำงานใหม่ทั้งหมดจะถูกนำไปใช้พร้อมกันทั้งในไคลเอ็นต์แบบบางและเว็บไคลเอ็นต์

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

ที่มา: will.com