1C वेब क्लायंट बद्दल

1C:एंटरप्राइझ तंत्रज्ञानाचे एक छान वैशिष्ट्य म्हणजे व्यवस्थापित फॉर्म तंत्रज्ञानाचा वापर करून विकसित केलेले ऍप्लिकेशन सोल्यूशन, Windows, Linux, MacOS X साठी पातळ (एक्झिक्युटेबल) क्लायंटमध्ये आणि 5 ब्राउझरसाठी वेब क्लायंट म्हणून लॉन्च केले जाऊ शकते - क्रोम, इंटरनेट एक्सप्लोरर, फायरफॉक्स, सफारी, एज आणि हे सर्व ऍप्लिकेशनचा सोर्स कोड न बदलता. शिवाय, बाह्यरित्या पातळ क्लायंटमध्ये आणि ब्राउझरमध्ये अनुप्रयोग कार्य करतो आणि जवळजवळ एकसारखा दिसतो.
10 फरक शोधा (कट अंतर्गत 2 चित्रे):

लिनक्सवर पातळ क्लायंट विंडो:

वेब क्लायंटमध्ये समान विंडो (क्रोम ब्राउझरमध्ये):

आम्ही वेब क्लायंट का बनवले? काहीसे दयनीयपणे सांगायचे तर, काळाने आपल्यासाठी असे कार्य निश्चित केले आहे. व्यवसाय अनुप्रयोगांसाठी इंटरनेटवर काम करणे ही पूर्वीपासून एक पूर्व शर्त आहे. प्रथम, आम्ही आमच्या पातळ क्लायंटसाठी इंटरनेटद्वारे काम करण्याची क्षमता जोडली (आमचे काही स्पर्धक, तसे, तिथेच थांबले; इतरांनी, त्याउलट, पातळ क्लायंटचा त्याग केला आणि वेब क्लायंट लागू करण्यासाठी स्वतःला मर्यादित केले). आम्ही आमच्या वापरकर्त्यांना त्यांच्यासाठी सर्वात योग्य क्लायंट पर्याय निवडण्याची संधी देण्याचा निर्णय घेतला.

क्लायंट-सर्व्हर आर्किटेक्चरमध्ये संपूर्ण बदलासह पातळ क्लायंटमध्ये वेब-आधारित क्षमता जोडणे हा एक मोठा प्रकल्प होता. वेब क्लायंट तयार करणे हा एक पूर्णपणे नवीन प्रकल्प आहे, जो सुरवातीपासून सुरू होतो.

समस्येची निर्मिती

तर, प्रकल्प आवश्यकता: वेब क्लायंटने पातळ क्लायंट प्रमाणेच केले पाहिजे, म्हणजे:

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

1C मधील वापरकर्ता इंटरफेसचे वर्णन व्हिज्युअल एडिटरमध्ये केले आहे, परंतु घटकांच्या पिक्सेल-बाय-पिक्सेल व्यवस्थेशिवाय घोषणात्मकपणे; सुमारे तीन डझन प्रकारचे इंटरफेस घटक वापरले जातात - बटणे, इनपुट फील्ड (मजकूर, अंकीय, तारीख/वेळ), सूची, सारण्या, आलेख इ.

1C भाषेतील क्लायंट कोडमध्ये सर्व्हर कॉल, स्थानिक संसाधनांसह कार्य करणे (फाईल्स इ.), मुद्रण आणि बरेच काही असू शकते.

पातळ क्लायंट (वेबद्वारे काम करताना) आणि वेब क्लायंट 1C ऍप्लिकेशन सर्व्हरशी संवाद साधण्यासाठी वेब सेवांचा समान संच वापरतात. क्लायंट अंमलबजावणी, अर्थातच, भिन्न आहेत - पातळ क्लायंट C++ मध्ये लिहिलेले आहे, वेब क्लायंट JavaScript मध्ये लिहिलेले आहे.

इतिहास एक बिट

वेब क्लायंट प्रकल्प 2006 मध्ये (सरासरी) 5 लोकांच्या टीमसह सुरू झाला. प्रकल्पाच्या काही टप्प्यांवर, विकासकांना विशिष्ट कार्यक्षमता (स्प्रेडशीट दस्तऐवज, आकृत्या इ.) लागू करण्यासाठी गुंतलेले होते; नियमानुसार, हे तेच विकसक होते ज्यांनी पातळ क्लायंटमध्ये ही कार्यक्षमता केली. त्या. डेव्हलपर्सने JavaScript मध्‍ये पुर्वी C++ मध्‍ये तयार केलेले घटक पुन्हा-लिहिले.

सुरुवातीपासूनच, दोन भाषांमधील मजबूत वैचारिक फरकांमुळे आम्ही C++ पातळ क्लायंट कोडचे JavaScript वेब क्लायंटमध्ये कोणत्याही स्वयंचलित (अगदी आंशिक) रूपांतराची कल्पना नाकारली; वेब क्लायंट सुरवातीपासून JavaScript मध्ये लिहिले होते.

प्रकल्पाच्या पहिल्या पुनरावृत्तीमध्ये, वेब क्लायंटने बिल्ट-इन 1C भाषेतील क्लायंट कोड थेट JavaScript मध्ये रूपांतरित केला. पातळ क्लायंट वेगळ्या पद्धतीने कार्य करतो - अंगभूत 1C भाषेतील कोड बायटेकोडमध्ये संकलित केला जातो आणि नंतर क्लायंटवर या बायकोडचा अर्थ लावला जातो. त्यानंतर, वेब क्लायंटने तेच करण्यास सुरुवात केली - प्रथम, त्याने कार्यप्रदर्शन वाढविले आणि दुसरे म्हणजे, पातळ आणि वेब क्लायंटचे आर्किटेक्चर एकत्र करणे शक्य केले.

1C ची पहिली आवृत्ती: वेब क्लायंट सपोर्टसह एंटरप्राइझ प्लॅटफॉर्म 2009 मध्ये रिलीज झाला. त्या वेळी वेब क्लायंटने 2 ब्राउझरला सपोर्ट केला - इंटरनेट एक्सप्लोरर आणि फायरफॉक्स. मूळ योजनांमध्ये ऑपेरासाठी समर्थन समाविष्ट होते, परंतु त्या वेळी ऑपेरामधील ऍप्लिकेशन क्लोजिंग हँडलर्ससह दुर्गम समस्यांमुळे (अॅप्लिकेशन बंद होत असल्याची 100% खात्रीने मागोवा घेणे शक्य नव्हते आणि त्या क्षणी वरून डिस्कनेक्शन प्रक्रिया पार पाडली. 1C ऍप्लिकेशन सर्व्हर) या प्लॅन्समधून सोडून द्यावे लागले.

प्रकल्प रचना

एकूण, 1C:एंटरप्राइज प्लॅटफॉर्मवर JavaScript मध्ये 4 प्रकल्प लिहिलेले आहेत:

1. वेबटूल्स – इतर प्रकल्पांद्वारे वापरल्या जाणार्‍या सामायिक लायब्ररी (आम्ही देखील समाविष्ट करतो Google क्लोजर लायब्ररी).
2. नियंत्रण घटक स्वरूपित दस्तऐवज (जावास्क्रिप्टमध्ये पातळ क्लायंट आणि वेब क्लायंटमध्ये लागू)
3. नियंत्रण घटक शेड्युलर (जावास्क्रिप्टमध्ये पातळ क्लायंट आणि वेब क्लायंटमध्ये लागू)
4. वेब क्लायंट

प्रत्येक प्रकल्पाची रचना Java प्रकल्पांच्या संरचनेसारखी असते (किंवा .NET प्रकल्प - जे जवळ असेल); आमच्याकडे नेमस्पेस आहेत आणि प्रत्येक नेमस्पेस वेगळ्या फोल्डरमध्ये आहे. फोल्डरमध्ये फाइल्स आणि नेमस्पेस वर्ग आहेत. वेब क्लायंट प्रोजेक्टमध्ये सुमारे 1000 फाईल्स आहेत.

संरचनात्मकदृष्ट्या, वेब क्लायंट मुख्यत्वे खालील उपप्रणालींमध्ये विभागलेले आहे:

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

• क्लायंटवर विकसकांसाठी ऑब्जेक्ट मॉडेल उपलब्ध आहे (एकूण 400 पेक्षा जास्त प्रकार: व्यवस्थापित इंटरफेस ऑब्जेक्ट मॉडेल, डेटा लेआउट सेटिंग्ज, सशर्त शैली इ.)
• अंगभूत 1C भाषेचा दुभाषी
• ब्राउझर विस्तार (जावास्क्रिप्टमध्ये समर्थित नसलेल्या कार्यक्षमतेसाठी वापरलेले)
  • क्रिप्टोग्राफीसह कार्य करणे
  • फाइल्ससह कार्य करणे
  • बाह्य घटकांचे तंत्रज्ञान, त्यांना पातळ आणि वेब क्लायंट दोन्हीमध्ये वापरण्याची परवानगी देते

विकास वैशिष्ट्ये

वरील सर्व गोष्टी JavaScript मध्ये लागू करणे सोपे नाही. कदाचित 1C वेब क्लायंट जावास्क्रिप्टमध्ये लिहिलेल्या सर्वात मोठ्या क्लायंट-साइड अनुप्रयोगांपैकी एक आहे - सुमारे 450.000 ओळी. आम्ही वेब क्लायंट कोडमध्ये ऑब्जेक्ट-ओरिएंटेड दृष्टिकोन सक्रियपणे वापरतो, जे अशा मोठ्या प्रकल्पासह कार्य सुलभ करते.

क्लायंट कोडचा आकार कमी करण्यासाठी, आम्ही प्रथम आमचे स्वतःचे ऑब्फस्केटर वापरले आणि प्लॅटफॉर्म आवृत्ती 8.3.6 (ऑक्टोबर 2014) पासून आम्ही वापरण्यास सुरुवात केली. Google क्लोजर कंपाइलर. संख्येच्या वापराचा परिणाम – अस्पष्टतेनंतर वेब क्लायंट फ्रेमवर्कचा आकार:

• स्वतःचे ओबफस्केटर - 1556 kb
• Google क्लोजर कंपाइलर - 1073 kb

Google Closure Compiler वापरल्याने आम्हाला वेब क्लायंटचे कार्यप्रदर्शन आमच्या स्वतःच्या obfuscator च्या तुलनेत 30% ने सुधारण्यात मदत झाली. याव्यतिरिक्त, अनुप्रयोगाद्वारे वापरल्या जाणार्‍या मेमरीचे प्रमाण 15-25% (ब्राउझरवर अवलंबून) कमी झाले आहे.

Google Closure Compiler ऑब्जेक्ट-ओरिएंटेड कोडसह खूप चांगले कार्य करते, त्यामुळे वेब क्लायंटसाठी त्याची कार्यक्षमता शक्य तितकी उच्च आहे. क्लोजर कंपाइलर आमच्यासाठी काही चांगल्या गोष्टी करतो:

• प्रोजेक्ट बिल्ड स्टेजवर स्टॅटिक प्रकार तपासणे (आम्ही JSDoc भाष्यांसह कोड कव्हर करतो याची खात्री करतो). परिणाम म्हणजे स्थिर टायपिंग, C++ मध्ये टायपिंगच्या अगदी जवळ आहे. हे प्रकल्प संकलनाच्या टप्प्यावर बर्‍यापैकी मोठ्या प्रमाणात त्रुटी पकडण्यात मदत करते.
• अस्पष्टतेद्वारे कोड आकार कमी करणे
• अंमलात आणलेल्या कोडचे अनेक ऑप्टिमायझेशन, उदाहरणार्थ, जसे की:
  • इनलाइन फंक्शन प्रतिस्थापन. JavaScript मध्‍ये फंक्‍शन कॉल करण्‍यासाठी खूप खर्चिक ऑपरेशन आहे, आणि वारंवार वापरल्या जाणार्‍या छोट्या पद्धतींचे इनलाइन बदल कोड लक्षणीयरीत्या गतीमान करतात.
  • संकलित वेळी स्थिरांक मोजणे. जर एखादी अभिव्यक्ती स्थिरांकावर अवलंबून असेल, तर स्थिरांकाचे वास्तविक मूल्य त्यामध्ये बदलले जाईल

आम्ही वेबस्टॉर्म आमच्या वेब क्लायंट डेव्हलपमेंट वातावरण म्हणून वापरतो.

कोड विश्लेषणासाठी आम्ही वापरतो सोनारक्यूब, जेथे आम्ही स्थिर कोड विश्लेषक समाकलित करतो. विश्लेषकांचा वापर करून, आम्ही 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 प्लॅटफॉर्मच्या दैनंदिन बिल्डनंतर चाचण्या स्वयंचलितपणे लाँच केल्या जातात. स्क्रिप्ट धीमे असल्यास (मागील बिल्डच्या तुलनेत), आम्ही तपास करतो आणि मंदीचे कारण शोधतो. आमचा निकष सोपा आहे - नवीन बिल्डने मागीलपेक्षा कमी काम करू नये.

मंदीच्या घटनांचा तपास करण्यासाठी विकासक विविध साधने वापरतात; प्रामुख्याने वापरले डायनाट्रेस AJAX संस्करण कंपनी उत्पादन डायनाट्रेस. मागील आणि नवीन बिल्डवर समस्याप्रधान ऑपरेशनच्या अंमलबजावणीचे लॉग रेकॉर्ड केले जातात, त्यानंतर लॉगचे विश्लेषण केले जाते. त्याच वेळी, एकल ऑपरेशन्सची अंमलबजावणी वेळ (मिलिसेकंदमध्ये) एक निर्णायक घटक असू शकत नाही - कचरा संकलनासारख्या सेवा प्रक्रिया वेळोवेळी ब्राउझरमध्ये लॉन्च केल्या जातात, ते फंक्शन्सच्या अंमलबजावणीच्या वेळेसह ओव्हरलॅप करू शकतात आणि चित्र विकृत करू शकतात. या प्रकरणात अधिक संबंधित पॅरामीटर्स अंमलात आणलेल्या JavaScript सूचनांची संख्या, DOM वर अणू ऑपरेशन्सची संख्या इ. जर नवीन आवृत्तीमध्ये समान स्क्रिप्टमधील सूचना/ऑपरेशन्सची संख्या वाढली असेल, तर याचा अर्थ जवळजवळ नेहमीच कार्यक्षमतेत घसरण होते जी दुरुस्त करणे आवश्यक आहे.

तसेच, कार्यप्रदर्शन कमी होण्याचे एक कारण हे असू शकते की Google Closure Compiler काही कारणास्तव फंक्शनचे इनलाइन प्रतिस्थापन करू शकले नाही (उदाहरणार्थ, फंक्शन रिकर्सिव किंवा व्हर्च्युअल असल्यामुळे). या प्रकरणात, आम्ही स्त्रोत कोड पुन्हा लिहून परिस्थिती सुधारण्याचा प्रयत्न करतो.

ब्राउझर विस्तार

जेव्हा ऍप्लिकेशन सोल्यूशनला JavaScript मध्ये उपलब्ध नसलेल्या कार्यक्षमतेची आवश्यकता असते, तेव्हा आम्ही ब्राउझर विस्तार वापरतो:

• फाइल्ससह काम करण्यासाठी
• क्रिप्टोग्राफीसह काम करण्यासाठी
• च्या सोबत काम करतो बाह्य घटक

आमच्या विस्तारांमध्ये दोन भाग आहेत. पहिल्या भागाला ब्राउझर एक्स्टेंशन म्हणतात (सामान्यत: जावास्क्रिप्टमध्ये लिहिलेले Chrome आणि फायरफॉक्सचे विस्तार), जे दुसऱ्या भागाशी संवाद साधतात - एक बायनरी विस्तार जो आम्हाला आवश्यक असलेली कार्यक्षमता लागू करतो. हे नमूद केले पाहिजे की आम्ही बायनरी विस्तारांच्या 3 आवृत्त्या लिहितो - Windows, Linux आणि MacOS साठी. बायनरी विस्तार 1C:एंटरप्राइज प्लॅटफॉर्मचा भाग म्हणून पुरवला जातो आणि 1C ऍप्लिकेशन सर्व्हरवर स्थित आहे. वेब क्लायंटवरून प्रथमच कॉल केल्यावर, ते क्लायंट संगणकावर डाउनलोड केले जाते आणि ब्राउझरमध्ये स्थापित केले जाते.

Safari मध्ये चालू असताना, आमचे विस्तार NPAPI वापरतात; Internet Explorer मध्ये चालत असताना, ते ActiveX तंत्रज्ञान वापरतात. मायक्रोसॉफ्ट एज अद्याप विस्तारांना समर्थन देत नाही, म्हणून त्यातील वेब क्लायंट निर्बंधांसह कार्य करते.

पुढील विकास

वेब क्लायंट डेव्हलपमेंट टीमचे एक कार्य म्हणजे कार्यक्षमतेचा पुढील विकास. वेब क्लायंटची कार्यक्षमता पातळ क्लायंटच्या कार्यक्षमतेसारखीच असावी; सर्व नवीन कार्यक्षमता एकाच वेळी पातळ आणि वेब क्लायंटमध्ये लागू केल्या जातात.

इतर कार्यांमध्ये आर्किटेक्चर विकसित करणे, रिफॅक्टरिंग, कार्यप्रदर्शन आणि विश्वासार्हता सुधारणे समाविष्ट आहे. उदाहरणार्थ, दिशानिर्देशांपैकी एक म्हणजे एसिंक्रोनस वर्क मॉडेलकडे पुढील हालचाल. वेब क्लायंटची काही कार्यक्षमता सध्या सर्व्हरशी परस्परसंवादाच्या सिंक्रोनस मॉडेलवर तयार केली आहे. अॅसिंक्रोनस मॉडेल आता ब्राउझरमध्ये (आणि केवळ ब्राउझरमध्येच नाही) अधिक प्रासंगिक होत आहे आणि हे आम्हाला सिंक्रोनस कॉल्सच्या जागी असिंक्रोनस कॉल्स (आणि त्यानुसार कोड रिफॅक्टरिंग) करून वेब क्लायंट सुधारित करण्यास भाग पाडते. अॅसिंक्रोनस मॉडेलचे क्रमिक संक्रमण हे रिलीझ केलेल्या सोल्यूशन्सला समर्थन देण्याची गरज आणि त्यांचे हळूहळू अनुकूलन करून स्पष्ट केले आहे.

स्त्रोत: www.habr.com