1C वेब क्लाइन्टको बारेमा

1C: इन्टरप्राइज टेक्नोलोजीको राम्रो विशेषताहरू मध्ये एक यो हो कि व्यवस्थित फारम टेक्नोलोजी प्रयोग गरेर विकसित गरिएको अनुप्रयोग समाधान, Windows, Linux, MacOS X को लागि पातलो (कार्यान्वयनयोग्य) क्लाइन्टमा र 5 ब्राउजरहरूको लागि वेब क्लाइन्टको रूपमा सुरू गर्न सकिन्छ। क्रोम, इन्टरनेट एक्सप्लोरर, फायरफक्स, सफारी, एज, र यी सबै एप्लिकेसन स्रोत कोड परिवर्तन नगरी। यसबाहेक, बाह्य रूपमा पातलो क्लाइन्ट र ब्राउजर प्रकार्यहरूमा अनुप्रयोग र लगभग समान देखिन्छ।
10 भिन्नताहरू फेला पार्नुहोस् (कट अन्तर्गत 2 चित्रहरू):

लिनक्समा पातलो ग्राहक विन्डो:

वेब क्लाइन्टमा उही विन्डो (क्रोम ब्राउजरमा):

हामीले किन वेब क्लाइन्ट बनायौं? यसलाई अलिकति दयनीय रूपमा भन्नुपर्दा, समयले हाम्रो लागि यस्तो कार्य सेट गरेको छ। इन्टरनेटमा काम गर्नु लामो समयदेखि व्यवसायिक अनुप्रयोगहरूको लागि पूर्वशर्त भएको छ। पहिले, हामीले हाम्रो पातलो ग्राहकको लागि इन्टरनेट मार्फत काम गर्ने क्षमता थप्यौं (हाम्रा केही प्रतियोगीहरू, त्यहाँ रोकिए; अरूले, यसको विपरीत, पातलो ग्राहकलाई त्यागे र वेब क्लाइन्ट लागू गर्न आफूलाई सीमित गरे)। हामीले हाम्रा प्रयोगकर्ताहरूलाई उनीहरूलाई उपयुक्त हुने ग्राहक विकल्प छनौट गर्ने अवसर दिने निर्णय गर्यौं।

पातलो क्लाइन्टमा वेब-आधारित क्षमताहरू थप्नु क्लाइन्ट-सर्भर वास्तुकलामा पूर्ण परिवर्तनको साथ ठूलो परियोजना थियो। वेब क्लाइन्ट सिर्जना गर्नु पूर्ण रूपमा नयाँ परियोजना हो, स्क्र्याचबाट सुरु हुन्छ।

समस्याको गठन

त्यसोभए, परियोजना आवश्यकताहरू: वेब क्लाइन्टले पातलो क्लाइन्टको रूपमा गर्नु पर्छ, अर्थात्:

1. प्रयोगकर्ता इन्टरफेस प्रदर्शन गर्नुहोस्
2. 1C भाषामा लेखिएको ग्राहक कोड कार्यान्वयन गर्नुहोस्

1C मा प्रयोगकर्ता इन्टरफेस दृश्य सम्पादकमा वर्णन गरिएको छ, तर घोषणात्मक रूपमा, तत्वहरूको पिक्सेल-द्वारा-पिक्सेल व्यवस्था बिना; लगभग तीन दर्जन प्रकारका इन्टरफेस तत्वहरू प्रयोग गरिन्छ - बटनहरू, इनपुट क्षेत्रहरू (पाठ, संख्यात्मक, मिति/समय), सूचीहरू, तालिकाहरू, ग्राफहरू, आदि।

1C भाषामा क्लाइन्ट कोडले सर्भर कलहरू समावेश गर्न सक्छ, स्थानीय स्रोतहरू (फाइलहरू, आदि), मुद्रण, र धेरै धेरै काम गर्दछ।

दुबै पातलो क्लाइन्ट (वेब ​​मार्फत काम गर्दा) र वेब क्लाइन्टले 1C अनुप्रयोग सर्भरसँग सञ्चार गर्न वेब सेवाहरूको एउटै सेट प्रयोग गर्दछ। क्लाइन्ट कार्यान्वयनहरू, अवश्य पनि, फरक छन् - पातलो क्लाइन्ट C++ मा लेखिएको छ, वेब क्लाइन्ट जाभास्क्रिप्टमा लेखिएको छ।

बिटको इतिहास

वेब क्लाइन्ट परियोजना 2006 मा सुरु भयो, (औसतमा) 5 व्यक्तिहरूको टोलीसँग। परियोजनाको निश्चित चरणहरूमा, विकासकर्ताहरू विशेष कार्यक्षमता (स्प्रेडसिट कागजात, रेखाचित्र, आदि) लागू गर्न संलग्न थिए; नियमको रूपमा, यी उही विकासकर्ताहरू थिए जसले पातलो ग्राहकमा यो कार्यक्षमता गरे। ती। विकासकर्ताहरूले जाभास्क्रिप्टमा कम्पोनेन्टहरू पुन: लेखे जुन उनीहरूले पहिले C++ मा सिर्जना गरेका थिए।

सुरुदेखि नै, हामीले दुई भाषाहरू बीचको बलियो वैचारिक भिन्नताहरूको कारणले जाभास्क्रिप्ट वेब क्लाइन्टमा C++ पातलो क्लाइन्ट कोडको कुनै पनि स्वचालित (आंशिक) रूपान्तरणको विचारलाई अस्वीकार गर्यौं; वेब क्लाइन्ट स्क्र्याचबाट जाभास्क्रिप्टमा लेखिएको थियो।

परियोजनाको पहिलो पुनरावृत्तिमा, वेब क्लाइन्टले क्लाइन्ट कोडलाई निर्मित 1C भाषामा सीधा JavaScript मा रूपान्तरण गर्यो। पातलो क्लाइन्टले फरक तरिकाले कार्य गर्दछ - निर्मित 1C भाषामा कोड बाइटकोडमा कम्पाइल गरिएको छ, र त्यसपछि यो बाइटकोडलाई क्लाइन्टमा व्याख्या गरिन्छ। पछि, वेब क्लाइन्टले त्यसै गर्न थाल्यो - पहिलो, यसले प्रदर्शन लाभ दियो, र दोस्रो, यसले पातलो र वेब क्लाइन्टहरूको वास्तुकलालाई एकताबद्ध गर्न सम्भव बनायो।

1C को पहिलो संस्करण: वेब क्लाइन्ट समर्थनको साथ इन्टरप्राइज प्लेटफर्म 2009 मा जारी गरिएको थियो। वेब क्लाइन्टले त्यस समयमा 2 ब्राउजरहरूलाई समर्थन गर्यो - इन्टरनेट एक्सप्लोरर र फायरफक्स। मूल योजनाहरूमा ओपेराको लागि समर्थन समावेश थियो, तर ओपेरामा अनुप्रयोग बन्द गर्ने ह्यान्डलरहरूसँग त्यस समयमा अप्ठ्यारो समस्याहरूको कारण (एप्लिकेसन बन्द हुँदैछ भन्ने 100% निश्चितताका साथ ट्र्याक गर्न सम्भव थिएन, र त्यस क्षणबाट विच्छेदन प्रक्रिया पूरा गर्नुहोस्। 1C अनुप्रयोग सर्भर) यी योजनाहरूबाट त्याग्नुपर्ने थियो।

परियोजना संरचना

कुलमा, 1C: उद्यम प्लेटफर्ममा जाभास्क्रिप्टमा लेखिएका 4 परियोजनाहरू छन्:

1. WebTools - अन्य परियोजनाहरू द्वारा प्रयोग गरिएको साझा पुस्तकालयहरू (हामी पनि समावेश गर्दछौं गुगल क्लोजर लाइब्रेरी).
2. नियन्त्रण तत्व ढाँचा गरिएको कागजात (थिन क्लाइन्ट र वेब क्लाइन्ट दुवैमा JavaScript मा लागू गरिएको)
3. नियन्त्रण तत्व अनुसूचीकर्ता (थिन क्लाइन्ट र वेब क्लाइन्ट दुवैमा JavaScript मा लागू गरिएको)
4. वेब ग्राहक

प्रत्येक परियोजनाको संरचना जाभा परियोजनाहरूको संरचनासँग मिल्दोजुल्दो छ (वा .NET परियोजनाहरू - जुन नजिक छ); हामीसँग नेमस्पेसहरू छन्, र प्रत्येक नेमस्पेस छुट्टै फोल्डरमा छ। फोल्डर भित्र फाइलहरू र नेमस्पेस वर्गहरू छन्। वेब क्लाइन्ट परियोजनामा ​​लगभग 1000 फाइलहरू छन्।

संरचनात्मक रूपमा, वेब क्लाइन्ट धेरै हदसम्म निम्न उपप्रणालीहरूमा विभाजित छ:

• व्यवस्थित ग्राहक आवेदन इन्टरफेस
  • सामान्य अनुप्रयोग इन्टरफेस (प्रणाली मेनु, प्यानल)
  • व्यवस्थित फारमहरूको इन्टरफेस, अन्य चीजहरू बीचमा, लगभग 30 नियन्त्रणहरू (बटनहरू, विभिन्न प्रकारका इनपुट क्षेत्रहरू - पाठ, संख्यात्मक, मिति/समय, आदि, तालिकाहरू, सूचीहरू, ग्राफहरू, आदि)।

• क्लाइन्टमा विकासकर्ताहरूका लागि उपलब्ध वस्तु मोडेल (कुल 400 भन्दा बढी प्रकारहरू: व्यवस्थित इन्टरफेस वस्तु मोडेल, डेटा लेआउट सेटिङहरू, सशर्त स्टाइल, आदि)।
• निर्मित 1C भाषा को दोभाषे
• ब्राउजर विस्तारहरू (जाभास्क्रिप्टमा समर्थित छैन कार्यक्षमताका लागि प्रयोग गरिएको)
  • Cryptography मा काम गर्नुहुन्छ
  • फाइलहरूसँग काम गर्दै
  • बाह्य कम्पोनेन्टहरूको टेक्नोलोजी, तिनीहरूलाई पातलो र वेब क्लाइन्टहरूमा प्रयोग गर्न अनुमति दिँदै

विकास सुविधाहरू

जाभास्क्रिप्टमा माथिका सबै लागू गर्न सजिलो छैन। सायद 1C वेब क्लाइन्ट जाभास्क्रिप्टमा लेखिएको सबैभन्दा ठूलो क्लाइन्ट-साइड अनुप्रयोगहरू मध्ये एक हो - लगभग 450.000 लाइनहरू। हामी सक्रिय रूपमा वेब क्लाइन्ट कोडमा वस्तु-उन्मुख दृष्टिकोण प्रयोग गर्छौं, जसले यति ठूलो परियोजनाको साथ कामलाई सरल बनाउँछ।

क्लाइन्ट कोडको साइज कम गर्नको लागि, हामीले पहिले हाम्रो आफ्नै ओब्फस्केटर प्रयोग गर्यौं, र प्लेटफर्म संस्करण 8.3.6 (अक्टोबर 2014) बाट सुरु गरेर हामीले प्रयोग गर्न थाल्यौं। गुगल क्लोजर कम्पाइलर। संख्याहरूमा प्रयोगको प्रभाव - अस्पष्टता पछि वेब क्लाइन्ट फ्रेमवर्कको आकार:

• आफ्नै ओब्फस्केटर - 1556 kb
• गुगल क्लोजर कम्पाइलर - 1073 kb

गुगल क्लोजर कम्पाइलरको प्रयोगले हामीलाई वेब क्लाइन्टको कार्यसम्पादनलाई हाम्रो आफ्नै ओब्फस्केटरको तुलनामा 30% सुधार गर्न मद्दत गर्‍यो। थप रूपमा, अनुप्रयोगले खपत गरेको मेमोरीको मात्रा 15-25% (ब्राउजरमा निर्भर गर्दछ) घटेको छ।

गुगल क्लोजर कम्पाइलरले वस्तु-उन्मुख कोडसँग धेरै राम्रोसँग काम गर्दछ, त्यसैले वेब क्लाइन्टको लागि यसको दक्षता सकेसम्म उच्च छ। क्लोजर कम्पाइलरले हाम्रो लागि केहि राम्रो चीजहरू गर्दछ:

• परियोजना निर्माण चरणमा स्थिर प्रकार जाँच (हामीले 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 (){}

हामीले भर्चुअल DOM को मुख्यधारा हुनु अघि प्रयोग गर्यो)

जटिल वेब UI सँग काम गर्ने सबै विकासकर्ताहरू जस्तै, हामीले द्रुत रूपमा DOM गतिशील प्रयोगकर्ता इन्टरफेसहरूसँग काम गर्नका लागि उपयुक्त छैन भनेर महसुस गर्यौं। लगभग तुरुन्तै, UI सँग कामलाई अनुकूलन गर्न भर्चुअल DOM को एक एनालग लागू गरियो। घटना प्रशोधन गर्दा, सबै DOM परिवर्तनहरू मेमोरीमा भण्डारण गरिन्छ र, सबै कार्यहरू पूरा भएपछि मात्र, संचित परिवर्तनहरू DOM रूखमा लागू हुन्छन्।

वेब क्लाइन्ट अप्टिमाइज गर्दै

हाम्रो वेब क्लाइन्टलाई छिटो काम गर्नको लागि, हामी मानक ब्राउजर क्षमताहरू (CSS, आदि) अधिकतम प्रयोग गर्ने प्रयास गर्छौं। यसरी, फारम आदेश प्यानल (अनुप्रयोगको लगभग हरेक फारममा अवस्थित) विशेष रूपमा ब्राउजर उपकरणहरू प्रयोग गरेर, CSS मा आधारित गतिशील लेआउट प्रयोग गरी रेन्डर गरिएको छ।

परीक्षण गर्दै

कार्यात्मक र कार्यसम्पादन परीक्षणको लागि, हामी स्वामित्व उपकरण (जाभा र C++ मा लेखिएको) प्रयोग गर्दछौं, साथै परीक्षणहरूको सुइटको शीर्षमा निर्मित सेलेनियम.

हाम्रो उपकरण सार्वभौमिक छ - यसले तपाईंलाई लगभग कुनै पनि विन्डो गरिएको प्रोग्राम परीक्षण गर्न अनुमति दिन्छ, र त्यसैले पातलो ग्राहक र वेब क्लाइन्ट दुवै परीक्षणको लागि उपयुक्त छ। उपकरणले प्रयोगकर्ताका कार्यहरू रेकर्ड गर्दछ जसले 1C अनुप्रयोग समाधानलाई स्क्रिप्ट फाइलमा सुरू गर्यो। एकै समयमा, स्क्रिनको काम गर्ने क्षेत्रका छविहरू-मानकहरू रेकर्ड गरिएका छन्। वेब क्लाइन्टको नयाँ संस्करणहरू निगरानी गर्दा, लिपिहरू प्रयोगकर्ताको सहभागिता बिना प्ले गरिन्छ। स्क्रिनसटले कुनै पनि चरणमा सन्दर्भसँग मेल खाँदैन भने, परीक्षण असफल भएको मानिन्छ, त्यसपछि गुणस्तर विशेषज्ञले यो त्रुटि हो वा प्रणालीको व्यवहारमा योजनाबद्ध परिवर्तन हो भनेर निर्धारण गर्न अनुसन्धान सञ्चालन गर्दछ। नियोजित व्यवहारको मामलामा, मापदण्डहरू स्वचालित रूपमा नयाँहरूसँग बदलिन्छन्।

उपकरणले 25 मिलिसेकेन्ड सम्मको शुद्धताका साथ अनुप्रयोगको प्रदर्शनलाई पनि मापन गर्दछ। कतिपय अवस्थामा, हामी लिपिको भागहरू लुप गर्छौं (उदाहरणका लागि, अर्डर प्रविष्टि धेरै पटक दोहोर्याएर) समयसँगै कार्यान्वयन समयको गिरावटको विश्लेषण गर्न। सबै मापनका नतिजाहरू विश्लेषणको लागि लगमा रेकर्ड गरिएका छन्।

हाम्रो परीक्षण उपकरण र परीक्षण अन्तर्गत आवेदन

हाम्रो उपकरण र सेलेनियम एकअर्काको पूरक हुन्; उदाहरणका लागि, यदि कुनै स्क्रिनको कुनै बटनले यसको स्थान परिवर्तन गरेको छ भने, सेलेनियमले यसलाई ट्र्याक नगर्न सक्छ, तर हाम्रो उपकरणले नोटिस गर्नेछ, किनभने मानकसँग स्क्रिनसटको पिक्सेल-द्वारा-पिक्सेल तुलना बनाउँछ। उपकरणले किबोर्ड वा माउसबाट प्रशोधन इनपुटमा समस्याहरू ट्र्याक गर्न पनि सक्षम छ, किनकि यो वास्तवमा यसले पुन: उत्पादन गर्दछ।

दुबै उपकरणहरूमा परीक्षणहरू (हाम्रो र सेलेनियम) हाम्रो अनुप्रयोग समाधानहरूबाट विशिष्ट कार्य परिदृश्यहरू चलाउँछन्। 1C:Enterprise प्लेटफर्मको दैनिक निर्माण पछि परीक्षणहरू स्वचालित रूपमा सुरु हुन्छन्। यदि स्क्रिप्टहरू ढिलो छन् (अघिल्लो निर्माणको तुलनामा), हामी ढिलो हुनुको कारणको अनुसन्धान र समाधान गर्छौं। हाम्रो मापदण्ड सरल छ - नयाँ निर्माणले अघिल्लो भन्दा ढिलो काम गर्नु हुँदैन।

विकासकर्ताहरूले ढिलो घटनाहरूको अनुसन्धान गर्न विभिन्न उपकरणहरू प्रयोग गर्छन्; मुख्य रूपमा प्रयोग गरिन्छ Dynatrace AJAX संस्करण उत्पादन कम्पनी DynaTrace। अघिल्लो र नयाँ निर्माणहरूमा समस्याग्रस्त सञ्चालनको कार्यान्वयनको लगहरू रेकर्ड गरिएका छन्, त्यसपछि लगहरू विश्लेषण गरिन्छ। एकै समयमा, एकल अपरेसनहरूको कार्यान्वयन समय (मिलिसेकेन्डमा) निर्णायक कारक नहुन सक्छ - सेवा प्रक्रियाहरू जस्तै फोहोर सङ्कलन ब्राउजरमा आवधिक रूपमा सुरू गरिन्छ, तिनीहरू कार्यहरूको कार्यान्वयन समयसँग ओभरल्याप गर्न सक्छन् र तस्विर विकृत गर्न सक्छन्। यस मामलामा थप सान्दर्भिक प्यारामिटरहरू कार्यान्वयन गरिएका जाभास्क्रिप्ट निर्देशनहरूको संख्या, DOM मा परमाणु सञ्चालनहरूको संख्या, आदि हुनेछ। यदि एउटै स्क्रिप्टमा निर्देशन/सञ्चालनको संख्या नयाँ संस्करणमा बढेको छ भने, यसको अर्थ सँधै कार्यसम्पादनमा कमी आएको हो जुन सच्याउन आवश्यक छ।

साथै, कार्यसम्पादनमा गिरावटको एउटा कारण यो पनि हुन सक्छ कि गुगल क्लोजर कम्पाइलरले कुनै कारणले प्रकार्यको इनलाइन प्रतिस्थापन गर्न असमर्थ भएको थियो (उदाहरणका लागि, कार्य पुनरावर्ती वा भर्चुअल भएकोले)। यस अवस्थामा, हामी स्रोत कोड पुन: लेखेर स्थिति सच्याउन प्रयास गर्छौं।

ब्राउजर विस्तारहरू

जब एप्लिकेसन समाधानलाई जाभास्क्रिप्टमा उपलब्ध नभएको कार्यक्षमता चाहिन्छ, हामी ब्राउजर विस्तारहरू प्रयोग गर्छौं:

• फाइलहरु संग काम को लागी
• क्रिप्टोग्राफी संग काम को लागी
• संग काम गर्नुहोस् बाह्य अवयवहरू

हाम्रो विस्तार दुई भाग मिलेर बनेको छ। पहिलो भागलाई ब्राउजर एक्स्टेन्सन भनिन्छ (सामान्यतया जाभास्क्रिप्टमा लेखिएको क्रोम र फायरफक्सका लागि एक्सटेन्सनहरू), जसले दोस्रो भागसँग अन्तरक्रिया गर्छ - बाइनरी एक्सटेन्सन जसले हामीलाई आवश्यक कार्यक्षमता लागू गर्दछ। यो उल्लेख गर्नुपर्छ कि हामी बाइनरी एक्सटेन्सनको 3 संस्करणहरू लेख्छौं - Windows, Linux र MacOS को लागि। बाइनरी एक्सटेन्सन 1C:Enterprise प्लेटफर्मको भागको रूपमा आपूर्ति गरिएको छ र 1C अनुप्रयोग सर्भरमा अवस्थित छ। वेब क्लाइन्टबाट पहिलो पटक कल गर्दा, यो क्लाइन्ट कम्प्युटरमा डाउनलोड हुन्छ र ब्राउजरमा स्थापना हुन्छ।

Safari मा चल्दा, हाम्रा विस्तारहरूले NPAPI प्रयोग गर्छन्; Internet Explorer मा चल्दा, तिनीहरू ActiveX प्रविधि प्रयोग गर्छन्। माइक्रोसफ्ट एज अझै विस्तारहरूलाई समर्थन गर्दैन, त्यसैले यसमा रहेको वेब क्लाइन्टले प्रतिबन्धहरूसँग काम गर्दछ।

थप विकास

वेब क्लाइन्ट विकास टोलीका लागि कार्यहरू मध्ये एक कार्यक्षमताको थप विकास हो। वेब क्लाइन्टको कार्यक्षमता पातलो क्लाइन्टको कार्यक्षमतासँग मिल्दोजुल्दो हुनुपर्छ; सबै नयाँ कार्यक्षमताहरू पातलो र वेब क्लाइन्टहरू दुवैमा एकै साथ लागू गरिन्छ।

अन्य कार्यहरूमा वास्तुकलाको विकास, रिफ्याक्टरिङ, प्रदर्शन सुधार र विश्वसनीयता समावेश छ। उदाहरण को लागी, दिशाहरु मध्ये एक एक एसिन्क्रोनस कार्य मोडेल तिर थप आन्दोलन हो। वेब क्लाइन्टको केहि कार्यक्षमता हाल सर्भरसँग अन्तरक्रियाको सिंक्रोनस मोडेलमा बनाइएको छ। एसिन्क्रोनस मोडेल अब ब्राउजरहरूमा (र ब्राउजरहरूमा मात्र होइन) थप सान्दर्भिक हुँदै गइरहेको छ, र यसले हामीलाई एसिन्क्रोनस कलहरू (र तदनुसार कोड रिफ्याक्टरिंग) संग सिंक्रोनस कलहरू प्रतिस्थापन गरेर वेब क्लाइन्ट परिमार्जन गर्न बाध्य पार्छ। एक एसिन्क्रोनस मोडेलमा क्रमिक संक्रमण जारी गरिएको समाधान र तिनीहरूको क्रमिक अनुकूलनलाई समर्थन गर्ने आवश्यकताद्वारा व्याख्या गरिएको छ।

स्रोत: www.habr.com