1C ویب کلائنٹ کے بارے میں

1C:Enterprise ٹیکنالوجی کی اچھی خصوصیات میں سے ایک یہ ہے کہ ایپلیکیشن سلوشن، جو مینیجڈ فارمز ٹیکنالوجی کا استعمال کرتے ہوئے تیار کیا گیا ہے، ونڈوز، لینکس، 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:Enterprise پلیٹ فارم میں جاوا اسکرپٹ میں لکھے گئے 4 پروجیکٹس ہیں:

1. WebTools - مشترکہ لائبریریاں جو دوسرے پروجیکٹس کے ذریعہ استعمال ہوتی ہیں (ہم بھی شامل ہیں۔ گوگل کلوزر لائبریری).
2. کنٹرول عنصر فارمیٹ شدہ دستاویز (جاوا اسکرپٹ میں پتلی کلائنٹ اور ویب کلائنٹ دونوں میں لاگو)
3. کنٹرول عنصر شیڈولر (جاوا اسکرپٹ میں پتلی کلائنٹ اور ویب کلائنٹ دونوں میں لاگو)
4. ویب کلائنٹ

ہر پروجیکٹ کی ساخت جاوا پروجیکٹس کی ساخت سے مشابہت رکھتی ہے (یا .NET پروجیکٹس - جو بھی قریب ہو)؛ ہمارے پاس نام کی جگہیں ہیں، اور ہر نام کی جگہ الگ فولڈر میں ہے۔ فولڈر کے اندر فائلیں اور نام کی جگہ کی کلاسیں ہیں۔ ویب کلائنٹ پروجیکٹ میں تقریباً 1000 فائلیں ہیں۔

ساختی طور پر، ویب کلائنٹ کو بڑی حد تک درج ذیل ذیلی نظاموں میں تقسیم کیا گیا ہے:

• منظم کلائنٹ ایپلیکیشن انٹرفیس
  • عام ایپلیکیشن انٹرفیس (سسٹم مینو، پینل)
  • نظم شدہ شکلوں کا انٹرفیس، بشمول دیگر چیزوں کے ساتھ، تقریباً 30 کنٹرولز (بٹن، مختلف قسم کے ان پٹ فیلڈز - متن، عددی، تاریخ/وقت، وغیرہ، میزیں، فہرستیں، گراف وغیرہ)

• کلائنٹ پر ڈویلپرز کے لیے آبجیکٹ ماڈل دستیاب ہے (مجموعی طور پر 400 سے زیادہ اقسام: منظم انٹرفیس آبجیکٹ ماڈل، ڈیٹا لے آؤٹ سیٹنگز، مشروط اسٹائلنگ، وغیرہ)
• بلٹ میں 1C زبان کا ترجمان
• براؤزر ایکسٹینشنز (جاوا اسکرپٹ میں تعاون یافتہ فعالیت کے لیے استعمال کیا جاتا ہے)
  • خفیہ نگاری کے ساتھ کام کرنا
  • فائلوں کے ساتھ کام کرنا
  • بیرونی اجزاء کی ٹیکنالوجی، انہیں پتلی اور ویب کلائنٹس دونوں میں استعمال کرنے کی اجازت دیتی ہے۔

ترقی کی خصوصیات

جاوا اسکرپٹ میں مندرجہ بالا سبھی کو لاگو کرنا آسان نہیں ہے۔ شاید 1C ویب کلائنٹ جاوا اسکرپٹ میں لکھی گئی کلائنٹ سائیڈ ایپلی کیشنز میں سے ایک ہے - تقریباً 450.000 لائنیں۔ ہم ویب کلائنٹ کوڈ میں ایک آبجیکٹ پر مبنی نقطہ نظر کو فعال طور پر استعمال کرتے ہیں، جو اتنے بڑے پروجیکٹ کے ساتھ کام کرنے کو آسان بناتا ہے۔

کلائنٹ کوڈ کے سائز کو کم کرنے کے لیے، ہم نے سب سے پہلے اپنا اوبفسکیٹر استعمال کیا، اور پلیٹ فارم ورژن 8.3.6 (اکتوبر 2014) سے شروع کرتے ہوئے ہم نے استعمال کرنا شروع کیا۔ گوگل کلوزر کمپائلر. تعداد میں استعمال کا اثر - ابہام کے بعد ویب کلائنٹ کے فریم ورک کا سائز:

• اپنا obfuscator - 1556 kb
• گوگل کلوزر کمپائلر - 1073 kb

Google Closure Compiler کے استعمال سے ویب کلائنٹ کی کارکردگی کو ہمارے اپنے obfuscator کے مقابلے میں 30% بہتر بنانے میں مدد ملی۔ اس کے علاوہ، ایپلی کیشن کے ذریعے استعمال کی گئی میموری کی مقدار میں 15-25% کی کمی واقع ہوئی ہے (براؤزر پر منحصر ہے)۔

گوگل کلوزر کمپائلر آبجیکٹ پر مبنی کوڈ کے ساتھ بہت اچھی طرح کام کرتا ہے، لہذا ویب کلائنٹ کے لیے اس کی کارکردگی زیادہ سے زیادہ ہے۔ کلوزر کمپائلر ہمارے لیے کچھ اچھی چیزیں کرتا ہے:

• پروجیکٹ کی تعمیر کے مرحلے پر جامد قسم کی جانچ پڑتال (یقینی بناتا ہے کہ ہم JSDoc تشریحات کے ساتھ کوڈ کا احاطہ کرتے ہیں)۔ نتیجہ جامد ٹائپنگ ہے، جو C++ میں ٹائپنگ کے بہت قریب ہے۔ اس سے پراجیکٹ کی تالیف کے مرحلے میں غلطیوں کی کافی بڑی فیصد کو پکڑنے میں مدد ملتی ہے۔
• مبہم کے ذریعے کوڈ کا سائز کم کرنا
• عملدرآمد شدہ کوڈ کی متعدد اصلاحیں، مثال کے طور پر، جیسے:
  • ان لائن فنکشن کے متبادل۔ جاوا اسکرپٹ میں کسی فنکشن کو کال کرنا کافی مہنگا آپریشن ہے، اور اکثر استعمال ہونے والے چھوٹے طریقوں کے ان لائن متبادل کوڈ کو نمایاں طور پر تیز کرتے ہیں۔
  • مرتب وقت میں مستقل گنتی۔ اگر ایک اظہار مستقل پر منحصر ہے، تو مستقل کی اصل قدر اس میں بدل جائے گی۔

ہم 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 کو مرکزی دھارے میں آنے سے پہلے استعمال کیا)

پیچیدہ ویب UIs کے ساتھ کام کرنے والے تمام ڈویلپرز کی طرح، ہم نے فوری طور پر محسوس کیا کہ DOM متحرک صارف انٹرفیس کے ساتھ کام کرنے کے لیے مناسب نہیں ہے۔ تقریباً فوراً، UI کے ساتھ کام کو بہتر بنانے کے لیے ورچوئل DOM کا ایک اینالاگ لاگو کیا گیا۔ ایونٹ پروسیسنگ کے دوران، تمام DOM تبدیلیاں میموری میں محفوظ کی جاتی ہیں اور، جب تمام آپریشن مکمل ہو جاتے ہیں، جمع شدہ تبدیلیاں DOM درخت پر لاگو ہوتی ہیں۔

ویب کلائنٹ کو بہتر بنانا

اپنے ویب کلائنٹ کو تیزی سے کام کرنے کے لیے، ہم براؤزر کی معیاری صلاحیتوں (CSS، وغیرہ) کو زیادہ سے زیادہ استعمال کرنے کی کوشش کرتے ہیں۔ اس طرح، فارم کمانڈ پینل (ایپلی کیشن کے تقریباً ہر فارم پر واقع ہے) کو خصوصی طور پر براؤزر ٹولز کا استعمال کرتے ہوئے، CSS پر مبنی ڈائنامک لے آؤٹ کا استعمال کرتے ہوئے پیش کیا جاتا ہے۔

ٹیسٹنگ

فنکشنل اور کارکردگی کی جانچ کے لیے، ہم ایک ملکیتی ٹول (جاوا اور C++ میں لکھا ہوا) استعمال کرتے ہیں، نیز ٹیسٹوں کا ایک مجموعہ سیلینیم.

ہمارا ٹول آفاقی ہے - یہ آپ کو تقریباً کسی بھی ونڈو والے پروگرام کی جانچ کرنے کی اجازت دیتا ہے، اور اس لیے یہ ایک پتلے کلائنٹ اور ویب کلائنٹ دونوں کی جانچ کے لیے موزوں ہے۔ یہ ٹول اس صارف کے اعمال کو ریکارڈ کرتا ہے جس نے 1C ایپلیکیشن سلوشن کو اسکرپٹ فائل میں لانچ کیا۔ ایک ہی وقت میں، اسکرین کے کام کرنے والے علاقے کی تصاویر - معیارات - ریکارڈ کی جاتی ہیں. ویب کلائنٹ کے نئے ورژن کی نگرانی کرتے وقت، اسکرپٹس کو صارف کی شرکت کے بغیر چلایا جاتا ہے۔ ایسی صورتوں میں جہاں اسکرین شاٹ کسی بھی مرحلے پر ریفرنس سے مماثل نہیں ہے، ٹیسٹ کو ناکام سمجھا جاتا ہے، جس کے بعد ایک کوالٹی ماہر اس بات کا تعین کرنے کے لیے تحقیقات کرتا ہے کہ آیا یہ غلطی ہے یا سسٹم کے رویے میں منصوبہ بند تبدیلی۔ منصوبہ بند طرز عمل کی صورت میں، معیارات خود بخود نئے سے بدل جاتے ہیں۔

یہ ٹول 25 ملی سیکنڈ تک کی درستگی کے ساتھ ایپلیکیشن کی کارکردگی کو بھی ماپتا ہے۔ کچھ معاملات میں، ہم اسکرپٹ کے حصوں کو لوپ کرتے ہیں (مثال کے طور پر، آرڈر کے اندراج کو کئی بار دہرانا) وقت کے ساتھ ساتھ عمل درآمد کے وقت کے انحطاط کا تجزیہ کرنے کے لیے۔ تمام پیمائشوں کے نتائج تجزیہ کے لیے ایک لاگ میں درج کیے جاتے ہیں۔

ہمارا ٹیسٹنگ ٹول اور ٹیسٹ کے تحت ایپلیکیشن

ہمارا ٹول اور سیلینیم ایک دوسرے کی تکمیل کرتے ہیں۔ مثال کے طور پر، اگر کسی ایک اسکرین پر موجود کچھ بٹن نے اپنا مقام تبدیل کر دیا ہے، تو ہو سکتا ہے کہ سیلینیم اسے ٹریک نہ کر سکے، لیکن ہمارا ٹول نوٹس لے گا، کیونکہ معیاری کے ساتھ اسکرین شاٹ کا پکسل بہ پکسل موازنہ کرتا ہے۔ یہ ٹول کی بورڈ یا ماؤس سے پروسیسنگ ان پٹ میں دشواریوں کو ٹریک کرنے کے قابل بھی ہے، کیونکہ یہ بالکل وہی ہے جو اسے دوبارہ تیار کرتا ہے۔

دونوں ٹولز (ہمارے اور سیلینیم) پر ٹیسٹ ہمارے ایپلیکیشن سلوشنز سے عام کام کے منظرنامے چلاتے ہیں۔ 1C:Enterprise پلیٹ فارم کی روزانہ کی تعمیر کے بعد ٹیسٹ خود بخود شروع ہو جاتے ہیں۔ اگر اسکرپٹس (پچھلی تعمیر کے مقابلے) سست ہیں، تو ہم سست روی کی وجہ کی تحقیقات کرتے ہیں اور اسے حل کرتے ہیں۔ ہمارا معیار آسان ہے - نئی تعمیر کو پچھلے سے زیادہ آہستہ کام نہیں کرنا چاہئے۔

ڈیولپرز سست روی کے واقعات کی تحقیقات کے لیے مختلف ٹولز استعمال کرتے ہیں۔ بنیادی طور پر استعمال کیا جاتا ہے Dynatrace AJAX ایڈیشن کمپنی کی پیداوار ڈائنا ٹریس. پچھلی اور نئی تعمیرات پر دشواری والے آپریشن کے عمل کے لاگز کو ریکارڈ کیا جاتا ہے، پھر لاگز کا تجزیہ کیا جاتا ہے۔ ایک ہی وقت میں، سنگل آپریشنز کے عمل کا وقت (ملی سیکنڈز میں) فیصلہ کن عنصر نہیں ہو سکتا ہے - سروس کے عمل جیسے کوڑا اٹھانا براؤزر میں وقتاً فوقتاً شروع کیا جاتا ہے، وہ فنکشنز کے عمل کے وقت کے ساتھ اوورلیپ کر سکتے ہیں اور تصویر کو مسخ کر سکتے ہیں۔ اس معاملے میں مزید متعلقہ پیرامیٹرز جاوا اسکرپٹ کی ہدایات کی تعداد، DOM پر ایٹم آپریشنز کی تعداد، وغیرہ ہوں گے۔ اگر ایک ہی اسکرپٹ میں ہدایات/کارروائیوں کی تعداد نئے ورژن میں بڑھ گئی ہے، تو اس کا مطلب کارکردگی میں کمی ہے جسے درست کرنے کی ضرورت ہے۔

اس کے علاوہ، کارکردگی میں کمی کی ایک وجہ یہ بھی ہو سکتی ہے کہ گوگل کلوزر کمپائلر کسی وجہ سے فنکشن کے ان لائن متبادل کو انجام دینے سے قاصر تھا (مثال کے طور پر، کیونکہ فنکشن تکراری یا ورچوئل ہے)۔ اس صورت میں، ہم سورس کوڈ کو دوبارہ لکھ کر صورتحال کو درست کرنے کی کوشش کرتے ہیں۔

براؤزر ایکسٹینشنز

جب کسی ایپلیکیشن سلوشن کو ایسی فعالیت کی ضرورت ہوتی ہے جو جاوا اسکرپٹ میں دستیاب نہیں ہے، تو ہم براؤزر ایکسٹینشن استعمال کرتے ہیں:

• فائلوں کے ساتھ کام کرنے کے لیے
• خفیہ نگاری کے ساتھ کام کرنے کے لیے
• ساتھ مل کر کام بیرونی اجزاء

ہماری توسیع دو حصوں پر مشتمل ہے۔ پہلا حصہ وہ ہے جسے براؤزر ایکسٹینشن کہا جاتا ہے (عام طور پر جاوا اسکرپٹ میں لکھے جانے والے کروم اور فائر فاکس کے لیے ایکسٹینشن)، جو دوسرے حصے کے ساتھ تعامل کرتے ہیں - ایک بائنری ایکسٹینشن جو ہماری ضرورت کی فعالیت کو نافذ کرتی ہے۔ یہ ذکر کرنا چاہیے کہ ہم بائنری ایکسٹینشن کے 3 ورژن لکھتے ہیں - ونڈوز، لینکس اور میک او ایس کے لیے۔ بائنری ایکسٹینشن 1C:Enterprise پلیٹ فارم کے حصے کے طور پر فراہم کی جاتی ہے اور 1C ایپلیکیشن سرور پر واقع ہے۔ جب کسی ویب کلائنٹ سے پہلی بار کال کی جاتی ہے، تو اسے کلائنٹ کمپیوٹر پر ڈاؤن لوڈ کرکے براؤزر میں انسٹال کیا جاتا ہے۔

Safari میں چلتے وقت، ہماری ایکسٹینشنز NPAPI استعمال کرتی ہیں؛ جب Internet Explorer میں چلتی ہیں، تو وہ ActiveX ٹیکنالوجی استعمال کرتی ہیں۔ مائیکروسافٹ ایج ابھی تک ایکسٹینشن کو سپورٹ نہیں کرتا ہے، اس لیے اس میں موجود ویب کلائنٹ پابندیوں کے ساتھ کام کرتا ہے۔

مزید ترقی

ویب کلائنٹ ڈویلپمنٹ ٹیم کے کاموں میں سے ایک فعالیت کی مزید ترقی ہے۔ ویب کلائنٹ کی فعالیت پتلی کلائنٹ کی فعالیت سے یکساں ہونی چاہیے؛ تمام نئی فعالیتیں پتلی اور ویب کلائنٹس دونوں میں بیک وقت لاگو ہوتی ہیں۔

دیگر کاموں میں فن تعمیر کو تیار کرنا، ری فیکٹرنگ، کارکردگی اور وشوسنییتا کو بہتر بنانا شامل ہیں۔ مثال کے طور پر، سمتوں میں سے ایک غیر مطابقت پذیر کام کے ماڈل کی طرف مزید حرکت ہے۔ ویب کلائنٹ کی کچھ فعالیت فی الحال سرور کے ساتھ تعامل کے ہم وقت ساز ماڈل پر بنائی گئی ہے۔ غیر مطابقت پذیر ماڈل اب براؤزرز میں زیادہ متعلقہ ہوتا جا رہا ہے (اور نہ صرف براؤزرز میں)، اور یہ ہمیں مطابقت پذیر کالوں کو غیر مطابقت پذیر کالوں کے ساتھ تبدیل کر کے ویب کلائنٹ کو تبدیل کرنے پر مجبور کرتا ہے (اور اس کے مطابق کوڈ کو ری فیکٹر کر رہا ہے)۔ ایک غیر مطابقت پذیر ماڈل میں بتدریج منتقلی کی وضاحت جاری کردہ حلوں اور ان کے بتدریج موافقت کی حمایت کرنے کی ضرورت سے ہوتی ہے۔

ماخذ: www.habr.com