بررسی سیر تحولات Javascript ، ظهور JQuery ، هماهنگی مثال زدنی JQuery با MVC و حمایت از AJAX - قسمت دوم

    تا اینجا شاید این سوال مطرح شده باشد که با وجود JQuery (که بوضوح عملیات مشابه در مقایسه با JavaScript از کیفیت ، سرعت و دقت بالاتری برخوردار است) طرح برخی جزییات در مورد JavaScript غیر ضروری و بی اهمیت باشد . اما باید توجه داشت که علیرغم اینکه JQuery مخصوصا در زمینه سازگاری با مرورگرهای مختلف و انجام عملیاتی که انتظار داریم از Syntax و روشهای بسیار ساده تری استفاده می کند ، به همان میزان برنامه نویس از بسیاری از جزییات دور نگاه داشته می شود که به نظر می رسد مخصوصا با شرایطی که امروز وجود دارد، حداقل درک بسیاری از این جزییات برای برنامه نویسانی که از تکنولوژی های ASP .NET MVC و WEB API استفاده می کنند ، ضروری است . حداقل درک عمیقی از مفاهیم Request و Response ، Synchronous و Asynchronous ، وجه تمایز بین Verb های HTTP، ساختار URL و نقش AJAX قطعا برنامه نویس را در اتخاذ روش های مناسب و کارآمد یاری داده و امکان انتخاب رویکرد صحیح را در شرایط متنوع میسر می سازد . 
مخصوصا در AJAX موضوع در Javascript کاملا با دقت و تمرکز بیشتری بررسی شده و پس از آن روشهای بسیار ساده تری که در JQuery برای انجام همین عملیات تدارک دیده شده اند معرفی خواهند شد .

در ساده ترین حالت، همه Message ها یا پیام های HTTP در دو گروه عمده Request و Response قابل تقسیم بندی هستند . واضح است که چنانچه از نام آنها نیز مشخص می باشد Request عبارت است از یک درخواست که اطلاعات دقیق تر این درخواست در قالب یک پکیج اطلاعاتی شامل Request Header و Request Body جهت دریافت محتوای اطلاعاتی خاص (Contents) یا انجام عملیات خاص (Actions) به یک سرویس دهنده ارسال می شود . آدرس یا مشخصه یکتایی (Unique) سرویس دهنده در URL و به طور دقیق تر در Request Header قرار می گیرد . 
همچنین اطلاعات ارسال شده در این پکیج شامل یک مشخصه خاص به نام Method یا Verb می باشد. بر اساس اطلاعات ارائه شده پروتکل HTML 1.1 در RFC 2616 ، از مهمترین انواع Method ها می توان به GET و POST اشاره کرد . بر اساس استاندارد مطرح شده توسط W3C تعداد Method ها در واقع بیش از این دو می باشد که در حال حاضر ذکر آنها ضروری نیست . برای اطلاعات دقیقتر می توانید به مستندات W3C و بخشهای مربوط به تقسیم بندی این متدها در RFC 2616 در زیر:

 

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

 

مراجعه نمایید.
امروزه همه مرورگرهای مدرن از هر دو متد GET و POST پشتیبانی می کنند و در مورد سایر متدها اختلاف هایی وجود دارد که جزییات آن در مستندات هر مرورگر وجود دارد . 
قبل از توصیف مختصری در مورد این دو متد و تفاوتهای آنها لازم است توجه داشته باشیم که تایپ URL یا آدرس در Address Bar مرورگر یا کلیک بر روی یک لینک، در حقیقت نمونه های بارز و رایجی از آغاز یک در خواست با متد GET می باشند که از این به بعد آن را Get Request می نامیم . در خواست POST معمولا در مرور گر توسط ارسال (Submit) پکیج اطلاعات یک فرم قابل انجام می باشد که از این به بعد آن را POST Request می نامیم . در اینجا فرض بر این است که خواننده این سطور کاملا با مفهوم Form در HTML و استفاده از Attribute های Action و Method آشنا می باشد . به طور دقیق تر Attribute مشخص شده با نام Method در داخل تگ FORM مشخص کننده نوع متد مورد نظر جهت ارسال پکیج اطلاعات Form به URL یا آدرسی است که در Action ذکر شده است .

نکته:

نظر به اهمیت استفاده از همه ظرفیت های پروتکل HTTP در WEB API ، موضوع توجه و تمایز بین Verb های مستند شده در HTTP 1.0 بسیار اهمیت دارد . حتی در ASP .NET MVC نیز در مقایسه با ASP .NET Web Form موضوع توجه به ویژگیها و موارد استفاده از Verb ها بسیار پر رنگ تر از گذشته مورد توجه برنامه نویسان می باشد . اما در WEB API درک دقیق Verb ها و چنانچه اشاره شد استفاده کامل از حداکثر ظرفیتهای HTTP از اولویت بسیار بالایی برخوردار است . به عبارت دیگر معماری REST حساسیت بسیار ویژه ای نسبت به Verb های متنوع پروتکل HTTP مخصوصا Get ، Post ، Put و Delete داشته و حتی یک مراجعه سطحی به مستندات Web API بوضوح نشان می دهد که اساسا سرویسهای RESTFull بر همین مبنا پایه گذاری شده اند . به طور دقیق Verb های HTML تر در WEB API از یک دیدگاه بسیار خاص )نسبت به نوع عملکرد آنها) طبقه بندی شده اند و در این میان، عامل اصلی تعیین کننده نوع Verb، ساختار ظاهری URL می باشد که بر اساس ساختار اطلاعاتی هدف (اینکه یک آیتم یا یک لیست یا مجموعه باشد) مشخص می گردد. با این توضیحات و با در نظر گرفتن چهار Verb ذکر شده ، می توان به سادگی دریافت که هشت عملیات مختلف و متنوع ، توسط کنترلر های Web API قابل انجام است . مجددا تکرار می کنم که این موضوع کاملا وابسته به ساختار URL می باشد . تقسیم بندی خاصی که پیشتر به آن اشاره شد مفهوم ویژه ای به نام Idempotency را مطرح می سازد که اشاره به این واقعیت مهم است که تکرار عملیات (به عنوان مثال عملیات ناشی از صدور فرمان Refresh یا کلید F5) در Verb های Get و Put و Delete منجر به انجام عملیات یکسانی می گردد و تکرار آن به هیچ وجه مضر یا مخرب نیست . در یک مثال ساده با هربار تکرار URL و آدرس فرضی

http://Nowhere.com/Customers /12345

زیر (که بوضوح می تواند به عنوان یک Get Request به منظور دریافت جزییات اطلاعات مربوط به مشتری (Customer) خاصی با ID و شناسه 12345 تلقی شود) ، آنچه هر بار تکرار خواهد شد تکرار ارائه جزییات اطلاعات یک مشتری با مشخصه CustomerID=12345 خواهد بود . از این جهت این Verb (ها) اصطلاحا Idempotent نامیده می شوند . 
در یک مورد مشابه دیگر اگر URL مثال قبلی را این بار از نوع Put Request در نظر بگیریم (که می تواند به صورت ایجاد یک Instance یا نمونه جدید از یک مشتری با مشخصه CustomerID=12345 تلقی شود) مجددا تکرار این عملیات در نهایت منجر به ایجاد یک نمونه از اطلاعات مشتری خواهد شد که مجددا از همین رو Put یک Verb از نوع Idempotent در نظر گرفته می شود .در مورد Delete هم دقیقا همین وضعیت وجود دارد و از ذکر مثال خودداری شده است. در مجموع این اصطلاح به تعبیری اشاره به Safe بودن یا ایمن بودن ذاتی نوع عملیاتی است که توسط Get و Put و Delete انجام می شود . در مقابل POST هیچگاه به عنوان یک Verb از نوع Idempotent در نظر گرفته نمی شود . چنانچه مطلع هستید استفاده از Post به صورت رایجی در مواقعی است که نیاز به ایجاد یک نمونه جدید از یک Object خاص وجود دارد که بر خلاف وضعیت تشریح شده در Put انتظار داریم سیستم خود یک ID معتبر تولید کرده و (بر اساس سایر اطلاعات تکمیلی که Post شده است) اقدام به ایجاد نمونه جدید بنماید . بدیهی است که تکرار این عملیات مخرب و با هر بار اجرا یک نمونه جدید (بر خلاف مثال های قبل) ایجاد خواهد شد . 
 

ذکر این جزییات فقط تاکید بر این نکته بسیار مهم است که به نظر می رسد باید یک تغییر یا تجدید نظر کلی در نگرش به Verb ها و نوع استفاده از آنها برای برنامه نویسانی که قصد استفاده موثر از Asp .NET MVC و WEB API را دارند ، ایجاد شود . 
در مورد جزییات تمایز بین Verb ها در MVC در ادامه مثالهایی ارائه خوهد شد و ملاحظه خواهیم کرد که بر خلاف ASP .NET Web Form که اجبار به استفاده از یک Form و تشریک مساعی مکانیسم Page Rendering/Server Controls از سوی سیستم تحمیل میشد، در MVC امکان استفاده از چندین Form با Verb های متنوع و حتی استفاده از Asynchronous Request بواسطه استفاده از تکنولوژی AJAX ، شاهد افزایش چشمیگری در کیفیت خواهیم بود.
 

ملاحظاتی در باره Get و Post

در ساده ترین شکل می توان چنین گفت که استفاده از Get Request در مجموع باید صرفا به منظور دریافت (get) اطلاعات (در فرمت های متنوع HTML ، XML ، JSON و ...) از web Server تدارک دیده شود . در مقابل یک Post Request به طور معمول انحصارا برای تغییر (Modify) در اطلاعات (اشاره به Insert و Update و Delete) مورد استفاده قرار می گیرد .
تنها و تنها برنامه نویس مسئول انتخاب استراتژی و انتخاب Verb مناسب ، بعد از تشخیص کامل Idempotent بودن یا Safe بودن یا غیر مخرب بودن عملیات است . عملیاتی نظیر جسجتو در Database یا دریافت گزارش از واضح ترین مصادیق استفاده صحیح از Get Request می باشند . در هنگام انتخاب Get Request موارد زیر باید همیشه مورد توجه باشند :

1- امکان Cache شدن نوع درخواست Get (بر خلاف Post) وجود دارد.
2- در شرایط طبیعی، همواره سابقه درخواست های Get در Browser History ثبت می شوند .
3- امکان نشانه گذاری و Bookmark درخواست های Get وجود دارد .
4- در صورت تمایل به سادگی امکان به اشتراک گذاری (Sharing) در خواست های نوع Get وجود دارند .
5 درخواستهای نوع Get به سادگی قابل دستکاری ، سو استفاده و واضح تر عرض کنم Hack شدن می باشند . بنابراین در هنگام طراحی سیستم پردازش درخواست های Get باید از مکانیسم های مناسب جهت کنترل این ویژگی استفاده کنید که متاسفانه اینجا مجال پرداختن به آنها نیست .
6- مکانیسم درخواست های Get به ترتیبی است که اطلاعات تکمیلی مورد نیاز برای پردازش (در صورت نیاز) در خود URL و توسط مجموعه QueryString به سمت Server هدایت می شود . بدیهیست که معنای دقیقتر آن این است که این مکانیسم به هیچ وجه نباید در ارسال اطلاعات حساسی مثل کلمه عبور ، مشخصات کارتهای اعتباری و ... مورد استفاده قرار بگیرد .

نکته:

بر خلاف یک نظریه غلط که Post Request را روش ایمنی برای موارد مذکور تلقی می کنند ، باید توجه داشت که اصولا موضوع امنیت اساسا هیچ ارتباطی با انتخاب Verb نداشته و باید در نظر گرفت که در Post Request اطلاعات صرفا در بدنه Request قرار می گیرند که تقریبا به همان سهولت روش Get می تواند توسط افراد سوجو مورد سواستفاده قرار بگیرد . 

7- با عنایت به مطلب اشاره شده در آیتم ششم، هر چند هیچ محدودیتی در پروتکل Http جهت تعیین حداکثر اندازه یا تعداد کاراکترهای Query String تعیین نشده اما محدودیت ویژه ای از طرف خود مرورگرها برای این ویژگی وجود دارد . در IE این مقدار حداکثر 2048 (با احتساب سایر مولفه ای موجود در URL) کاراکتر می باشد .
8- در صورت استفاده از Javascript یا ترجیحا JQuery امکان ارسال Asynchronous Get Request با استفاده از تکنولوژی AJAX وجود دارد که مثالهایی از آن در ادامه ارائه خواهد شد . در JQuery متدهای get و getJSON و getScript و load به همین منظور تدارک دیده شده اند .

خلاصه ای از مواردی که در Post Request باید به آن توجه شود به قرار زیر است :

1- در صورتیکه حجم اطلاعاتی نیاز دارید به Server ارسال کنید زیاد باشد بهتر است که روش Post را انتخاب کنید .
2- در صورت نیاز به ارسال اطلاعات حساسی مثل Password و مشخصات کارت های اعتباری و اطلاعات حسابهای بانکی از روش Post (به همراه اطمنیان از سایر مولفه های امنیتی مثل SSL و پروتکل Https ) استفاده نمایید .
3- در شرایط معمولی یک Post Request معمولا با استفاده از ساختار و تگ Form با ذکر Method=Post در HTML میسر می باشد. اما این لزوما به این معنی نیست که تگ Form صرفا برای آغاز یک Post Request کاربرد دارد . بدیهی است که با تغییر در Method امکان تغییر به Get نیز وجود خواهد داشت . چنانچه در ادامه شاهد خواهیم بود با استفاده از AJAX تقریبا امکان استفاده از همه انواع Verb ها وجود دارد .
4- در JQuery متد post برای ایجاد یک Asynchronous Post Request با استفاده از AJAX تدارک دیده شده است .

بررسی سیر تحولات Javascript ، ظهور JQuery ، هماهنگی مثال زدنی JQuery با MVC و حمایت از AJAX - قسمت اول

بعد از گذشت زمان نسبتا طولانی از نوشتن آخرین مطالبی که هر از گاهی در وبلاگ یا فیسبوک نوشته میشد ، مدتها بود موضوع روند تکامل Form ها در HTML از زمان به کار گیری Javascript به عنوان ابزاری برای کنترل "صحت مقدار یا فرمت مقادیر" ، تا زمان حاضر که شاهد یک همکاری و هارمونی بسیار شگفت انگیز بین JQuery و MVC هستیم ، بخشی از ذهن مرا به خود مشغول ساخته بود.
مخصوصا دغدغه مرور مختصری بر مفهوم و کاربرد FORM در MVC و ارتباط آن با مفاهیم بسیار مهم تری به نام AJAX و Partial View ابعاد این موضوع را تا حد نسبتا غیر قابل کنترلی (حداقل از دیدگاه من) افزایش می داد .
به عبارت ساده تر به نظرم رسید حتی یک معرفی سطحی و اجمالی بر موضوعات مذکور ممکن است بسیار فراتر از مجال محدودی باشد که در اختیار من قرار دارد. مجموعه عناوین و مفاهیمی که ذکر شد بسیار گسترده ولی انصافا بسیار مهم و ظریف بوده و حاوی نکاتی هستند که یقین دارم تحقیق در مورد آنها ابعاد تازه و جالب تری را به این مجموعه اضافه خواهد نمود . 
اگر به روزهای ابتدایی HTML و در واقع زمان معرفی اولین Browser یا مرورگر مخصوص وب با نام Mozaic در سال 1993 برگردیم ، بنا بر مستندات مستدل موجود این مرور گر که در واقع جد همه مرورگرهای مدرن امروزی محسوب میشود ، قابلیت برقراری یک ارتباط محاوره ای با User را با استفاده از تگ Form برای کاربر فراهم می کرده است . 
در واقع یک سال بعد یعنی در سال 1994 وب که حالا تقریبا 4 ساله شده بود توجه بسیاری از بازیگران عصر طلایی صنعت IT را به خود جلب کرد و در سپتامبر همان سال Internet Engineering Task Force با نام اختصاری IETF که متولی ، ناشر و حامی غیر انتفاعی استانداردهای اینترنت بود، کار گروه ویژه ای را برای تدوین و انتشار استانداردهای HTML منسوب کرد. از اعضای مهم این گروه می توان به Tim Berners-Lee (مخترع وب) ، Don Connelly و Mark Anderson اشاره کرد که حاصل این اقدام انتشار استاندارد HTML 2 و تهیه Document Type Definition مربوط به این استاندارد بود .
جالب است بدانیم که Netscape Navigator که به عنوان اولین مرورگر تجاری موفق در سیلیکون ولی تدوین و منتشر شد حاصل کار گروهی Mark Anderson و Jim Clark بود. همانطور که قبلا هم اشاره شد، از همان ابتدا عنصر Form یکی از اصلی ترین و پر کاربرد ترین عناصر و یا Element های HTML محسوب میشد و با توجه به محدودیت های پهنای باند و بنا بر ویژگیها و محدودیت هایی که پروتکل HTTP بر وب تحمیل می کرد ، تا قبل از 1995 موضوع بررسی یا کنترل صحت مقادیر و اطلاعات Form که به نام Form Validation شناخته می شود منحصرا صرفا با یک Round Trip (اشاره به Post Back و Initiate و آغاز Request از سوی مرورگر ، پردازش Request در Server و ایجاد Response ) میسر بود . به عبارت ساده تر ، امکان انجام این کنترل صرفا در Server و با استفاده از زبانهایی مثل PERL وجود داشت که با توجه به سرعت مودم های 28.8 kbps ، نیاز به زمان قابل توجهی داشت . اولین بار Brenden Eich که از مهندسین ارشد Netscape بود به فکر انجام این کنترل، تمام با استفاده از یک زبان اسکریپت افتاد و این انگیزه سبب طراحی زبان اسکریپتی گردید که ابتدا Mocha و در فاصله کوتاهی LiveScript نامیده شد. قبل از تولید نسخه تجاری Netscape Navigator 2 در سال 1995 بازیگر مطرحی در عرصه تکنولوژی مثل Sun Microsystem در تکمیل طراحی LiveScript پا به عرصه وجود گذاشت و نتیجه این همکاری تولد زبان JavaScript بود که با یک تاخیر زمانی کوتاه به Netscape Navigator 3 ملحق شد و از آن موقع تا زمان حاضر چنانچه همه ما مطلع هستیم، به عنوان یکی از ملزومات اصلی مروگرها شناخته می شود. 
اما در این میان همه چیز آن چنان که انتظار میرفت پیش نرفت . چرا که Microsoft به سرعت شروع به تدوین مرورگر اختصاصی و معلوم الحال خود نمود که علاوه بر داغ تر کردن تنور رقابت بازار مروگرها، به دلیل پرهیز از مشکلات ناشی از ثبت انحصاری Javascript نسخه انحصاری خود از زبان اسکریپتی اختصاصی خود به نام Jscript را ضمیمه مرورگر خود کرد و روانه بازار نمود . این موضوع در واقع مبدأ آشفته بازاری بود که انگیزه نیاز به یک استاندارد جامع در زبانهای اسکریپت را تقویت نمود و در نهایت منجر به تدوین ECMAScript ( به صورت رایجی ، اکما - اسکریپت تلفظ می شود) به عنوان استاندارد پایه و مبنای زبانهای اسکریپت شد . 
نکته مهم:
از آنجاییکه JQuery و نقش آن در DOM Processing و Form Validation و Form Submission و نهایتا AJAX بسیار حائز اهمیت است، لاجرم لازم می دانم که که در این مقاله ، هر چند به اجمال، این مباحث بیشتر بررسی شده تا احیانا برخی از ابهامات موجود در این زمینه برطرف گردد .

با در نظر گرفتن مطالبی که عنوان شد از اینجا به بعد در واقع Javascript بر خلاف یک تلقی اشتباه (که برخی آن را مترادف با ECMAScript قلمداد می کنند) یک پیاده سازی از استاندارد از ECMAScript است و در حقیقت شامل اجزای زیر می باشد :
1- هسته و Core مربوط به ECMAScript .
2- Document Object Model یا به اختصار DOM
3- پشتیبانی از Browser Object Model یا به اختصار BOM

به منظور درک عمیقتر ECMAScript اولا باید آن را مستقل از Web در نظر گرفت. در واقع مرورگرهای وب یک میزبان برای هسته اصلی ECMAScript می باشند که امکان پیاده سازی سطوح بالاتر ، بر مبنای امکانات پایه ای که فراهم می کند را ، میسر می سازند . مواردی نظیر نحو یا Syntax ، امکان تعریف Type ، کلید واژه ها، اپراتور ها ، مفهوم Object و ... در JavaScript همه به لطف پیاده سازی سطوح پایین تر در ECMAScript ایجاد و بنا بر نیاز موجود تقویت و بهینه شده اند . با مراجعه به منابع معتبر می توان بوضوح مشاهده کرد که ECMAScript در طول حیات خود و با گذشت زمان و قطعا متناسب با نیازهای موجود ، دارای هسته ای به مراتب مجهز تر شده است که به نظرم در اینجا مجال پرداختن به جزییات آن وجود ندارد و علاقمندان می توانند با مراجعه به منابع معتبر جزییات دقیق تر این تکامل تدریجی ECMAScript را مطالعه کرده و در جریان کامل آن قرار بگیرند . در این زمینه، پشتیبانی از دستورات try catch ، پشتیبانی دقیق تر از کلاسها و مفهوم Inheritance و وراثت ، پشتیبانی و پیاده سازی JSON به عنوان فرمتی برای تبادل Object ها و اطلاعات و .... از مهمترین مواردی بودند که به تدریج در چرخه تکامل ECMAScript نقش آفرینی کرده اند .
مفهوم Document Object Model یا DOM
این مفهوم در اصل عبارت است از یک API خاص منظوره برای کار با فرمت XML که بعدها به منظور کار با HTML تقویت ، ویرایش و یا گسترش یافته است . 
در مقطعی از زمان مرورگرهای اختصاصی Netscape و Microsoft هر یک روایت اختصاصی خود از DHTML را که لزوما با یکدیگر سازگار نبوده و حتی تضادهایی هم داشت، ارائه نموده و این موضوع یکی از عوامل اصلی نیاز به یک استاندارد فراگیر را مطرح کرد که موجب شد World Wide Web Consortium یا W3C تدوین استانداردهای DOM را در دستور کار خود قرار دهد .
از دیدگاه DOM یک سند XML یا HTML (در واقع HTML یک زیر مجموعه از XML محسوب می شود) صرفا دارای مجموعه ای از اجزا یا المانها یا Node هایی است که به صورت سلسله مراتبی (Hierarchical) ، به ترتیبی قرار دارند که اولا همه اجزا (یا همان المانها و Node ها) منشعب از یک Node ویژه به عنوان Root و ریشه بوده و ثانیا هر Node می تواند از نظر محتوا شامل یک یا چند Node فرزند (یا هیچ) بوده و از نظر نوع می تواند شامل انواع متفاوتی از اطلاعات یا Data باشد .
اتخاذ این استراتژی، API را قادر می سازد تا عملیاتی نظیر پیمایش (Traverse) ، افزودن (Add) ، حذف (Remove) ، الحاق (Append) و ... را به صورت بسیار موثر و کارآمدی را انجام دهد . 
اصطلاحات DOM Level 1 ، DOM Level 2 و DOM Level 3 اشاره به روایت های متعددی است که از سال 1998 تا امروز استانداردهای DOM را بر حسب شرایط روز تدوین و منتشر نموده است . در حقیقت مواردی مثل حمایت از Device هایی همچون Mouse ، الحاق و پشتیبانی Css و در ادامه تجهیز و گسترش Event ها و الحاق استاندارد XPath همه و همه از مواردی بودند که به مرور زمان در DOM ایجاد شده و منتشر شدند . 
در حال حاضر به لطف Library های مشهور و کاربردی و در صدر آنها JQuery حمایت و قابلیت کار با DOM تا بالاترین سطح خود در مرورگرها گسترش پیدا کرده و در ادامه و مخصوصا در مباحث مربوط به AJAX مثالهای کاربردی تری از آن را ملاحظه خواهیم کرد .
در واقع به نظرم تا اینجا خواننده این سطور باید به این نکته مهم توجه داشته باشد که JavaScript و JQuery (به عنوان یک کتابخانه کاربردی بنا شده بر اساس Javascript) چگونه در طول زمان بر اساس نیازهای موجود از یک ابزار اسکریپت نویسی ساده به منظور کنترل Form Validation و Dom Traversal (اشاره به قابلیت های آن در ارتباط با پیمایش ، حذف، الحاق و ... Node ها در ساختار سلسله مراتبی DOM) به یک جزء لاینفک از Platform های وب مخصوصا ASP .NET MVC تبدیل شد .
مفهوم Browser Object Model یا BOM
چنانچه پیشتر نیز اشاره شد، اولین و مهمترین ویژگی Javascript پشتیبانی کامل از ECMAScript و DOM و BOM می باشد . به طور دقیق تر مفهوم BOM اشاره به مجموعه ای از امکاناتی بود که همزمان با Netscape Navigator 3 و Internet Explorer 3 در این دو مرورگر ایجاد شد که امکان کار با Window یا پنجره میزبان مرورگر و همچنین استفاده از Dialog های Modalو Modeless را فراهم نمودند . به طور مشخص تمرکز BOM در کار با خود Object پنجره میزبان (Window) و Frame های این پنجره قرار داشت و به طور کلی شامل امکاناتی برای کار با سایر پنجره های Popup ، امکان قابلیت حرکت، تغییر اندازه و بستن پنجره ها و امکان کار با Object های کاربردی navigatorو location و Screen و از همه مهمتر (و در بحث ما با تمرکز بیشتر) تولد XMLHttpRequest به عنوان محور اصلی ظهور تکنولوژی AJAX و گسترش آن بود .