1C ويب ڪلائنٽ بابت

1C:Enterprise ٽيڪنالاجي جي سٺي خاصيتن مان هڪ اها آهي ته ايپليڪيشن حل، منظم فارم ٽيڪنالاجي استعمال ڪندي ترقي ڪئي، ٻنهي کي ٿلهي (ايگزيڪيوٽيبل) ڪلائنٽ ۾ ونڊوز، لينڪس، MacOS X، ۽ 5 برائوزرن لاءِ ويب ڪلائنٽ طور لانچ ڪري سگهجي ٿو. ڪروم، انٽرنيٽ ايڪسپلورر، فائر فاکس، سفاري، ايج، ۽ هي سڀ بغير ايپليڪيشن جي سورس ڪوڊ کي تبديل ڪرڻ جي. ان کان علاوه، ٻاهرئين طور تي پتلي ڪلائنٽ ۾ ايپليڪيشن ۽ برائوزر ۾ ڪم ڪندو آهي ۽ لڳ ڀڳ هڪجهڙائي ڏسڻ ۾ اچي ٿو.
10 فرق ڳوليو (ڪٽ هيٺان 2 تصويرون):

لينڪس تي پتلي ڪلائنٽ ونڊو:

ساڳي ونڊو ويب ڪلائنٽ ۾ (ڪروم برائوزر ۾):

اسان ويب ڪلائنٽ ڇو ٺاهيو؟ ان کي ڪنهن حد تائين افسوسناڪ انداز ۾ رکڻ لاءِ، وقت اسان لاءِ اهڙو ڪم مقرر ڪيو آهي. انٽرنيٽ تي ڪم ڪرڻ ڊگهي عرصي کان ڪاروباري ايپليڪيشنن لاءِ هڪ لازمي شرط آهي. پهرين، اسان پنهنجي پتلي ڪلائنٽ لاءِ انٽرنيٽ ذريعي ڪم ڪرڻ جي صلاحيت شامل ڪئي (اسان جا ڪجهه حريف، رستي ۾، اتي بند ٿي ويا؛ ٻيا، ان جي ابتڙ، پتلي ڪلائنٽ کي ڇڏي ڏنو ۽ پاڻ کي ويب ڪلائنٽ لاڳو ڪرڻ تائين محدود ڪيو). اسان فيصلو ڪيو ته اسان جي صارفين کي ڪلائنٽ اختيار چونڊڻ جو موقعو ڏيو جيڪو انهن لاء بهترين آهي.

پتلي ڪلائنٽ ۾ ويب تي ٻڌل صلاحيتون شامل ڪرڻ هڪ وڏو منصوبو هو ڪلائنٽ-سرور فن تعمير ۾ مڪمل تبديلي سان. ويب ڪلائنٽ ٺاهڻ هڪ مڪمل طور تي نئون منصوبو آهي، شروع کان شروع ٿئي ٿو.

مسئلو جي ترتيب

تنهن ڪري، منصوبي جي گهرج: ويب ڪلائنٽ کي پتلي ڪلائنٽ وانگر ساڳيو ڪم ڪرڻ گهرجي، يعني:

1. يوزر انٽرفيس ڏيکاريو
2. 1C ٻولي ۾ لکيل ڪلائنٽ ڪوڊ تي عمل ڪريو

1C ۾ يوزر انٽرفيس هڪ بصري ايڊيٽر ۾ بيان ڪيو ويو آهي، پر واضح طور تي، عناصر جي پکسل-جي-پڪسل ترتيب جي بغير؛ اٽڪل ٽي درجن قسم جا انٽرفيس عناصر استعمال ڪيا ويا آهن - بٽڻ، ان پٽ فيلڊ (ٽيڪسٽ، عددي، تاريخ/وقت)، فهرستون، ٽيبل، گراف، وغيره.

1C ٻولي ۾ ڪلائنٽ ڪوڊ سرور ڪالن تي مشتمل ٿي سگھي ٿو، مقامي وسيلن سان ڪم ڪرڻ (فائل، وغيره)، ڇپائي، ۽ گهڻو ڪجهه.

ٻئي پتلي ڪلائنٽ (جڏهن ويب ذريعي ڪم ڪري رهيا آهن) ۽ ويب ڪلائنٽ 1C ايپليڪيشن سرور سان رابطو ڪرڻ لاءِ ويب سروسز جو ساڳيو سيٽ استعمال ڪندا آهن. ڪلائنٽ لاڳو ڪرڻ، يقينا، مختلف آهن - پتلي ڪلائنٽ C++ ۾ لکيل آهي، ويب ڪلائنٽ جاوا اسڪرپٽ ۾ لکيل آهي.

تاريخ جو هڪ سا

ويب ڪلائنٽ پروجيڪٽ 2006 ۾ شروع ٿيو، (اوسط طور تي) 5 ماڻهن جي ٽيم سان. پروجيڪٽ جي ڪجهه مرحلن تي، ڊولپرز مخصوص ڪارڪردگي کي لاڳو ڪرڻ ۾ شامل هئا (اسپريڊ شيٽ دستاويز، ڊراگرام، وغيره)؛ ضابطي جي طور تي، اهي ساڳيا ڊولپر هئا جن هن ڪارڪردگي کي پتلي ڪلائنٽ ۾ ڪيو. اهي. ڊولپرز جاوا اسڪرپٽ ۾ اجزاء ٻيهر لکيا جيڪي انهن اڳ ۾ C++ ۾ ٺاهيا هئا.

شروع کان ئي، اسان ٻن ٻولين جي وچ ۾ مضبوط تصوراتي اختلافن جي ڪري C++ پتلي ڪلائنٽ ڪوڊ جي جاوا اسڪرپٽ ويب ڪلائنٽ ۾ ڪنهن به خودڪار (جيتوڻيڪ جزوي) تبديلي جي خيال کي رد ڪيو؛ ويب ڪلائنٽ شروع کان JavaScript ۾ لکيو ويو.

منصوبي جي پهرين ورهاڱي ۾، ويب ڪلائنٽ ڪلائنٽ ڪوڊ کي بلٽ ان 1C ٻولي ۾ سڌو سنئون JavaScript ۾ تبديل ڪيو. پتلي ڪلائنٽ مختلف طريقي سان ڪم ڪري ٿو - ڪوڊ ۾ ٺهيل 1C ٻولي ۾ بائيٽ ڪوڊ ۾ مرتب ڪيو ويو آهي، ۽ پوء هي بائيٽ ڪوڊ ڪلائنٽ تي تفسير ڪيو ويو آهي. تنهن کان پوء، ويب ڪلائنٽ ساڳيو ڪم ڪرڻ شروع ڪيو - پهرين، اهو هڪ ڪارڪردگي حاصل ڪيو، ۽ ٻيو، اهو ممڪن ڪيو ته پتلي ۽ ويب ڪلائنٽ جي فن تعمير کي متحد ڪرڻ.

1C جو پهريون نسخو: ويب ڪلائنٽ سپورٽ سان انٽرنيشنل پليٽ فارم 2009 ۾ جاري ڪيو ويو. ويب ڪلائنٽ ان وقت 2 برائوزرن کي سپورٽ ڪيو - انٽرنيٽ ايڪسپلورر ۽ فائر فاکس. اصل منصوبن ۾ اوپيرا لاءِ سپورٽ شامل هئي، پر ان وقت اوپيرا ۾ ايپليڪيشن بند ڪرڻ واري هينڊلر سان ناقابل برداشت مسئلن جي ڪري (اهو 100٪ يقين سان ٽريڪ ڪرڻ ممڪن نه هو ته ايپليڪيشن بند ٿي رهي هئي، ۽ ان وقت کان ڌار ٿيڻ واري عمل کي انجام ڏيو. انهن منصوبن مان 1C ايپليڪيشن سرور) کي ڇڏڻو پوندو.

منصوبي جي جوڙجڪ

مجموعي طور تي، 1C: انٽرپرائز پليٽ فارم جاوا اسڪرپٽ ۾ لکيل 4 منصوبا آهن:

1. WebTools - ٻين منصوبن پاران استعمال ڪيل گڏيل لائبريريون (اسان پڻ شامل ڪريون ٿا گوگل بند لائبريري).
2. ڪنٽرول عنصر فارميٽ ٿيل دستاويز (جاوا اسڪرپٽ ۾ ٻنهي پتلي ڪلائنٽ ۽ ويب ڪلائنٽ ۾ لاڳو ٿيل)
3. ڪنٽرول عنصر شيڊيولر (جاوا اسڪرپٽ ۾ ٻنهي پتلي ڪلائنٽ ۽ ويب ڪلائنٽ ۾ لاڳو ٿيل)
4. ويب ڪلائنٽ

هر پروجيڪٽ جي ساخت جاوا پروجيڪٽس جي ڍانچي وانگر آهي (يا .NET پروجيڪٽ - جيڪو به ويجهو هجي)؛ اسان وٽ نالا اسپيس آهن، ۽ هر نالي جي جڳهه هڪ الڳ فولڊر ۾ آهي. فولڊر جي اندر فائلون ۽ نالا اسپيس ڪلاس آهن. ويب ڪلائنٽ پروجيڪٽ ۾ اٽڪل 1000 فائلون آهن.

ساخت جي لحاظ کان، ويب ڪلائنٽ گهڻو ڪري هيٺين سب سسٽم ۾ ورهايل آهي:

• منظم ڪيل ڪلائنٽ ايپليڪيشن انٽرفيس
  • عام ايپليڪيشن انٽرفيس (سسٽم مينيو، پينل)
  • منظم ٿيل فارمن جو انٽرفيس، بشمول، ٻين شين جي وچ ۾، اٽڪل 30 ڪنٽرول (بٽن، مختلف قسم جا ان پٽ فيلڊز - ٽيڪسٽ، عددي، تاريخ/وقت، وغيره.، ٽيبل، فهرستون، گراف، وغيره)

• ڪلائنٽ تي ڊولپرز لاءِ موجود آبجیکٹ ماڊل (مجموعي طور تي 400 کان وڌيڪ قسمون: منظم انٽرفيس آبجیکٹ ماڊل، ڊيٽا لي آئوٽ سيٽنگون، مشروط اسٽائل، وغيره)
• تعمير ٿيل 1C ٻولي جو مترجم
• برائوزر ايڪسٽينشن (ڪارڪردگي لاءِ استعمال ٿيل جاوا اسڪرپٽ ۾ سپورٽ نه آهي)
  • cryptography سان ڪم ڪرڻ
  • فائلن سان ڪم
  • ٻاهرين حصن جي ٽيڪنالاجي، انهن کي پتلي ۽ ويب ڪلائنٽ ٻنهي ۾ استعمال ڪرڻ جي اجازت ڏئي ٿي

ترقي جون خاصيتون

جاوا اسڪرپٽ ۾ مٿين سڀني کي لاڳو ڪرڻ آسان ناهي. شايد 1C ويب ڪلائنٽ جاوا اسڪرپٽ ۾ لکيل سڀ کان وڏي ڪلائنٽ سائڊ ايپليڪيشنن مان هڪ آهي - اٽڪل 450.000 لائينون. اسان فعال طور تي ويب ڪلائنٽ ڪوڊ ۾ اعتراض تي مبني طريقي سان استعمال ڪندا آهيون، جيڪو اهڙي وڏي منصوبي سان ڪم ڪرڻ آسان بڻائي ٿو.

ڪلائنٽ ڪوڊ جي سائيز کي گھٽائڻ لاءِ، اسان پھريون ڀيرو پنھنجو استعمال ڪيو اوبفسڪيٽر، ۽ پليٽ فارم ورزن 8.3.6 (آڪٽوبر 2014) سان شروع ڪندي اسان استعمال ڪرڻ شروع ڪيو. گوگل بند ڪرڻ وارو ڪمپلر. انگن ۾ استعمال جو اثر - ويب ڪلائنٽ جي فريم ورڪ جي ماپ کان پوء obfuscation:

• پنهنجو اوبفسڪيٽر - 1556 kb
• گوگل بند ڪرڻ وارو ڪمپلر - 1073 kb

Google Closure Compiler استعمال ڪرڻ اسان جي مدد ڪئي ويب ڪلائنٽ جي ڪارڪردگيءَ کي 30% بهتر ڪرڻ ۾ اسان جي پنهنجي obfuscator جي مقابلي ۾. ان کان سواء، ايپليڪيشن پاران استعمال ڪيل ياداشت جي مقدار ۾ 15-25٪ (براؤزر تي منحصر) گھٽجي وئي آهي.

Google Closure Compiler تمام سٺو ڪم ڪري ٿو اعتراض تي مبني ڪوڊ سان، تنهن ڪري ويب ڪلائنٽ لاءِ ان جي ڪارڪردگي ممڪن حد تائين وڌيڪ آهي. بند ڪرڻ وارو ڪمپلر اسان لاءِ ڪجھ سٺيون شيون ڪري ٿو:

• پراجيڪٽ جي تعمير واري مرحلي تي جامد قسم جي چڪاس (يقين ڪري ٿي ته اسان ڪوڊ کي JSDoc تشريح سان ڍڪيندا آهيون). نتيجو جامد ٽائپنگ آهي، سي ++ ۾ ٽائپنگ جي سطح ۾ تمام ويجهو. هي پروجيڪٽ جي تاليف واري مرحلي ۾ غلطين جو هڪ وڏو سيڪڙو پڪڙڻ ۾ مدد ڪري ٿو.
• ضابطي جي ذريعي ڪوڊ جي سائيز کي گھٽائڻ
• عمل ٿيل ڪوڊ جي اصلاحن جو تعداد، مثال طور، جھڙوڪ:
  • ان لائن فنڪشن متبادل. JavaScript ۾ هڪ فنڪشن کي ڪال ڪرڻ هڪ تمام مهانگو آپريشن آهي، ۽ اڪثر استعمال ٿيل ننڍڙن طريقن جي ان لائن متبادل ڪوڊ کي تيز ڪري ٿو.
  • مرتب وقت تي مستقل ڳڻڻ. جيڪڏهن هڪ اظهار هڪ مستقل تي منحصر آهي، مستقل جي حقيقي قيمت ان ۾ تبديل ٿي ويندي

اسان استعمال ڪندا آهيون WebStorm اسان جي ويب ڪلائنٽ ڊولپمينٽ ماحول جي طور تي.

ڪوڊ تجزيي لاءِ اسان استعمال ڪريون ٿا سونارو ڪيوب، جتي اسان جامد ڪوڊ تجزيي ڪندڙن کي ضم ڪريون ٿا. تجزيو ڪندڙ استعمال ڪندي، اسان جاوا اسڪرپٽ جي سورس ڪوڊ جي معيار جي خرابي جي نگراني ڪندا آهيون ۽ ان کي روڪڻ جي ڪوشش ڪندا آهيون.

اسان ڪهڙا مسئلا حل ڪري رهيا آهيون؟

منصوبي تي عمل ڪرڻ دوران، اسان کي ڪيترن ئي دلچسپ مسئلن جو سامنا ڪيو ويو آهي ته اسان کي حل ڪرڻو پوندو.

سرور سان ۽ ونڊوز جي وچ ۾ ڊيٽا مٽايو

اهڙا حالتون آهن جتي ماخذ ڪوڊ جي ڀڃڪڙي سسٽم جي آپريشن سان مداخلت ڪري سگهي ٿي. ڪوڊ ٻاهران ويب ڪلائنٽ جي ايگزيڪيوٽيبل ڪوڊ لاءِ، مبهم ٿيڻ جي ڪري، ٿي سگھي ٿو فنڪشن ۽ پيٽرول جا نالا جيڪي انهن کان مختلف هجن جيڪي اسان جي قابل عمل ڪوڊ جي توقع رکي ٿو. اسان لاءِ خارجي ڪوڊ آهي:

• ڪوڊ ڊيٽا جي جوڙجڪ جي صورت ۾ سرور کان اچي رهيو آهي
• ٻي ايپليڪيشن ونڊو لاءِ ڪوڊ

سرور سان لهه وچڙ ۾ رڪاوٽ کان بچڻ لاءِ، اسان استعمال ڪريون ٿا @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 (){}

اسان ورچوئل ڊوم استعمال ڪيو ان کان اڳ جو مکيه وهڪرو بڻجي ويو)

سڀني ڊولپرز وانگر پيچيده ويب UIs سان ڊيل ڪندي، اسان جلدي محسوس ڪيو ته DOM متحرڪ يوزر انٽرفيس سان ڪم ڪرڻ لاءِ ناقص موزون آهي. تقريبن فوري طور تي، ورچوئل ڊوم جو هڪ اينالاگ لاڳو ڪيو ويو UI سان ڪم کي بهتر ڪرڻ لاءِ. ايونٽ پروسيسنگ دوران، DOM جون سڀئي تبديليون ميموري ۾ محفوظ ڪيون وينديون آهن ۽، صرف جڏهن سڀ عمل مڪمل ٿي ويندا آهن، جمع ٿيل تبديليون DOM وڻ تي لاڳو ٿينديون آهن.

ويب ڪلائنٽ کي بهتر ڪرڻ

اسان جي ويب ڪلائنٽ کي تيزيءَ سان ڪم ڪرڻ لاءِ، اسان ڪوشش ڪريون ٿا معياري برائوزر صلاحيتن (CSS، وغيره) کي وڌ ۾ وڌ استعمال ڪرڻ جي. اهڙيءَ طرح، فارم ڪمانڊ پينل (لڳ ڀڳ هر ايپليڪيشن جي فارم تي واقع آهي) خاص طور تي برائوزر اوزار استعمال ڪندي، سي ايس ايس جي بنياد تي متحرڪ ترتيب استعمال ڪندي.

جاچ

فنڪشنل ۽ ڪارڪردگي جي جاچ لاءِ، اسان استعمال ڪندا آهيون هڪ مالڪي وارو اوزار (لکيل جاوا ۽ C++ ۾)، انهي سان گڏ مٿي تي ٺهيل ٽيسٽ جو هڪ سوٽ سلينيم.

اسان جو اوزار آفاقي آهي - اهو توهان کي تقريبن ڪنهن به ونڊو ٿيل پروگرام کي جانچڻ جي اجازت ڏئي ٿو، ۽ تنهن ڪري ٻنهي پتلي ڪلائنٽ ۽ ويب ڪلائنٽ جي جاچ لاءِ موزون آهي. اوزار استعمال ڪندڙ جي عملن کي رڪارڊ ڪري ٿو جيڪو 1C ايپليڪيشن حل کي اسڪرپٽ فائل ۾ شروع ڪيو. ساڳئي وقت، اسڪرين جي ڪم ڪندڙ علائقي جون تصويرون - معيار - رڪارڊ ٿيل آهن. جڏهن ويب ڪلائنٽ جي نئين نسخن جي نگراني ڪندي، اسڪرپٽ کي ادا ڪيو ويندو آهي بغير صارف جي شموليت جي. ڪيسن ۾ جتي اسڪرين شاٽ ڪنهن به قدم تي ريفرنس سان نه ملندو آهي، ٽيسٽ کي ناڪام سمجهيو ويندو آهي، جنهن کان پوء هڪ معيار جو ماهر هڪ تحقيق ڪري ٿو اهو طئي ڪرڻ لاء ته ڇا اهو غلطي آهي يا سسٽم جي رويي ۾ هڪ رٿيل تبديلي. منصوبابندي ڪيل رويي جي صورت ۾، معيار خودڪار طريقي سان نئين سان تبديل ٿي ويا آهن.

اوزار پڻ 25 ملي سيڪنڊن جي درستگي سان ايپليڪيشن ڪارڪردگي کي ماپ ڪري ٿو. ڪجهه حالتن ۾، اسين اسڪرپٽ جي حصن کي لوپ ڪريون ٿا (مثال طور، آرڊر جي داخلا کي ڪيترائي ڀيرا ورجائي) وقت سان گڏ عمل جي وقت جي گھٽتائي جو تجزيو ڪرڻ لاءِ. سڀني ماپن جا نتيجا تجزيو لاءِ لاگ ۾ رڪارڊ ٿيل آهن.

اسان جي جاچ وارو اوزار ۽ ايپليڪيشن ٽيسٽ تحت

اسان جو اوزار ۽ Selenium هڪ ٻئي کي پورو. مثال طور، جيڪڏهن اسڪرين مان هڪ تي ڪجهه بٽڻ ان جي جڳهه کي تبديل ڪري ڇڏيو آهي، سيلينيم شايد ان کي ٽريڪ نه ڪري سگهي، پر اسان جو اوزار نوٽيس ڪندو، ڇاڪاڻ ته معياري سان اسڪرين شاٽ جو پکسل-جي-پڪسل مقابلو ڪري ٿو. اوزار پڻ ڪيبورڊ يا مائوس مان پروسيسنگ ان پٽ جي مسئلن کي ٽريڪ ڪرڻ جي قابل آهي، ڇاڪاڻ ته اهو ئي آهي جيڪو اهو ٻيهر پيدا ڪري ٿو.

ٻنهي اوزارن تي ٽيسٽ (اسان جو ۽ سيلينيم) اسان جي ايپليڪيشن حلن مان عام ڪم جي منظرنامي کي هلائي ٿو. ٽيسٽ خود بخود شروع ٿينديون آهن روزاني تعمير کان پوءِ 1C:انٽرپرائز پليٽ فارم. جيڪڏهن اسڪرپٽ سست آهن (اڳئين تعمير جي مقابلي ۾)، اسان تحقيق ڪريون ٿا ۽ سست ٿيڻ جي سبب کي حل ڪريو. اسان جو معيار سادو آهي - نئين تعمير کي اڳئين کان وڌيڪ سست ڪم نه ڪرڻ گهرجي.

ڊولپرز سستي واقعن جي تحقيق ڪرڻ لاءِ مختلف اوزار استعمال ڪن ٿا؛ خاص طور تي استعمال ڪيو Dynatrace AJAX ايڊيشن پيداوار ڪمپني ڊينا ٽريس. اڳوڻي ۽ نئين تعميرات تي مشڪلاتي آپريشن جي عمل جي لاگز کي رڪارڊ ڪيو ويو آهي، پوء لاگ ان جو تجزيو ڪيو ويندو. ساڳئي وقت، ھڪڙي عملن جي عمل جو وقت (ملي سيڪنڊن ۾) ھڪڙو فيصلو ڪندڙ عنصر نه ٿي سگھي ٿو - خدمت جي عملن جھڙوڪ ڪچرو گڏ ڪرڻ وقتي طور تي برائوزر ۾ شروع ڪيو ويندو آھي، اھي عملن جي عمل جي وقت سان اوورليپ ڪري سگھن ٿا ۽ تصوير کي خراب ڪري سگھن ٿا. هن معاملي ۾ وڌيڪ لاڳاپيل پيٽرولر جاوا اسڪرپٽ جي هدايتن جو تعداد، DOM تي ايٽمي عملن جو تعداد، وغيره. جيڪڏهن ساڳئي اسڪرپٽ ۾ هدايتون/عملن جو تعداد نئين ورزن ۾ وڌي ويو آهي، ته ان جو مطلب هميشه ڪارڪردگيءَ ۾ گهٽتائي آهي جنهن کي درست ڪرڻ جي ضرورت آهي.

انهي سان گڏ، ڪارڪردگي ۾ گهٽتائي جو هڪ سبب اهو ٿي سگهي ٿو ته گوگل بند ڪرڻ وارو ڪمپلر ڪجهه سببن لاء فنڪشن جي ان لائن متبادل کي انجام ڏيڻ جي قابل نه هو (مثال طور، ڇاڪاڻ ته فنڪشن ريٽيڪل يا ورچوئل آهي). انهي حالت ۾، اسان سورس ڪوڊ کي ٻيهر لکڻ سان صورتحال کي درست ڪرڻ جي ڪوشش ڪندا آهيون.

برائوزر ايڪسٽينشن

جڏهن هڪ ايپليڪيشن حل کي ڪارڪردگي جي ضرورت آهي جيڪا جاوا اسڪرپٽ ۾ موجود ناهي، اسان برائوزر ايڪسٽينشن استعمال ڪندا آهيون:

• فائلن سان ڪم ڪرڻ لاء
• cryptography سان ڪم ڪرڻ لاء
• سان ڪم ڪرڻ خارجي اجزاء

اسان جون واڌايون ٻن حصن تي مشتمل آهن. پھريون حصو اھو آھي جنھن کي برائوزر ايڪسٽينشن چئبو آھي (عام طور تي جاوا اسڪرپٽ ۾ لکيل Chrome ۽ Firefox لاءِ ايڪسٽينشن)، جيڪو ٻئي حصي سان لاڳاپو رکي ٿو - ھڪڙو بائنري ايڪسٽينشن جيڪو اسان جي گهربل ڪارڪردگي کي لاڳو ڪري ٿو. اهو ذڪر ڪرڻ گهرجي ته اسان بائنري ايڪسٽينشن جا 3 ورجن لکون ٿا - ونڊوز، لينڪس ۽ ميڪوس لاءِ. بائنري توسيع 1C جي حصي طور فراهم ڪئي وئي آهي: انٽرپرائز پليٽ فارم ۽ 1C ايپليڪيشن سرور تي واقع آهي. جڏهن ويب ڪلائنٽ کان پهريون ڀيرو سڏيو ويندو آهي، اهو ڪلائنٽ ڪمپيوٽر تي ڊائون لوڊ ڪيو ويندو آهي ۽ برائوزر ۾ نصب ڪيو ويندو آهي.

جڏهن سفاري ۾ هلندا آهن، اسان جون واڌايون استعمال ڪندا آهن NPAPI؛ جڏهن انٽرنيٽ ايڪسپلورر ۾ هلندا آهن، اهي ActiveX ٽيڪنالاجي استعمال ڪندا آهن. Microsoft ايج اڃا تائين واڌارن کي سپورٽ نٿو ڪري، تنهنڪري ان ۾ ويب ڪلائنٽ پابندين سان ڪم ڪري ٿو.

وڌيڪ ترقي

ويب ڪلائنٽ ڊولپمينٽ ٽيم لاءِ ڪمن مان ھڪڙو آھي ڪارڪردگي جي وڌيڪ ترقي. ويب ڪلائنٽ جي ڪارڪردگي پتلي ڪلائنٽ جي ڪارڪردگي سان هڪجهڙائي هجڻ گهرجي؛ تمام نئين ڪارڪردگي هڪ ئي وقت پتلي ۽ ويب ڪلائنٽ ٻنهي ۾ لاڳو ٿينديون آهن.

ٻين ڪمن ۾ شامل آهن فن تعمير کي ترقي ڪرڻ، ريفيڪٽرنگ، ڪارڪردگي بهتر ڪرڻ ۽ اعتبار. مثال طور، ھڪڙي ھدايتن مان ھڪڙو وڌيڪ حرڪت آھي ھڪڙي غير مطابقت واري ڪم جي ماڊل ڏانھن. ويب ڪلائنٽ جي ڪجهه ڪارڪردگي هن وقت سرور سان رابطي جي هڪ هم وقت سازي ماڊل تي ٺهيل آهي. هم وقت سازي ماڊل هاڻي برائوزرن ۾ وڌيڪ لاڳاپيل ٿي رهيو آهي (۽ نه صرف برائوزرن ۾)، ۽ هي اسان کي مجبور ڪري ٿو ته ويب ڪلائنٽ کي تبديل ڪرڻ سان هم وقت ساز ڪالن کي تبديل ڪرڻ سان (۽ ان مطابق ڪوڊ کي ريفيڪٽر ڪرڻ). بتدريج منتقلي هڪ غير مطابقت واري ماڊل ڏانهن جاري ڪيل حل ۽ انهن جي تدريجي موافقت جي حمايت ڪرڻ جي ضرورت جي وضاحت ڪئي وئي آهي.

جو ذريعو: www.habr.com