[تعلم اياكس في أربعة أيام] اليوم الثالث من تعلم اياكس البرنامج التعليمي والطلبات والاستجابات المتقدمة في اياكس

بالنسبة للعديد من مطوري الويب، يعد إنشاء طلبات بسيطة وتلقي استجابات بسيطة أمرًا كافيًا؛ ولكن بالنسبة للمطورين الذين يرغبون في إتقان Ajax، فمن الضروري الفهم الكامل لرموز حالة HTTP والحالات الجاهزة وكائن XMLHttpRequest. في هذه المقالة، يقدم لك بريت ماكلولين رموز الحالة المختلفة ويوضح لك كيفية تعامل المتصفحات معها، كما يلقي نظرة على بعض طلبات HTTP الأقل شيوعًا المستخدمة في Ajax.

في المقالة السابقة من هذه السلسلة، ألقينا نظرة فاحصة على كائن XMLHttpRequest، وهو محور تطبيق Ajax وهو مسؤول عن معالجة الطلبات الواردة من التطبيقات والبرامج النصية من جانب الخادم ومعالجة البيانات التي يتم إرجاعها من مكونات جانب الخادم. نظرًا لأن جميع تطبيقات Ajax تستخدم كائن XMLHttpRequest، فقد ترغب في التعرف على هذا الكائن حتى يتمكن Ajax من أداء أفضل.

في هذه المقالة، سأركز على الأجزاء الثلاثة الرئيسية لكائن الطلب هذا استنادًا إلى المقالة السابقة:

· حالة استعداد HTTP · رمز حالة HTTP · أنواع الطلبات التي يمكن إنشاؤها،

يتم إنشاء العوامل الثلاثة كلها في الاعتبار ومع ذلك، عند الطلب، لم يُكتب سوى القليل جدًا عن هذه المواضيع. ومع ذلك، إذا كنت تريد أن تتعلم أكثر من مجرد أساسيات برمجة Ajax، فسوف تحتاج إلى التعرف على محتويات الحالات الجاهزة، ورموز الحالة، والطلبات نفسها. عندما يحدث خطأ ما في تطبيقك - وهذا يحدث دائمًا - إذا فهمت حالة الاستعداد بشكل صحيح، أو كيفية إنشاء طلب HEAD، أو ما يعنيه رمز الحالة 400 بالضبط، فيمكنك تصحيح المشكلة في 5 دقائق بدلاً من 5 ساعات مستغرقة في مختلف الإحباطات والارتباكات.

دعونا نلقي نظرة أولاً على حالة استعداد HTTP.

نظرة فاحصة على حالة استعداد HTTP

ستتذكر من المقالة السابقة أن كائن XMLHttpRequest لديه خاصية تسمى ReadyState. تضمن هذه السمة أن الخادم قد أكمل الطلب، وعادةً ما يستخدم وظيفة رد الاتصال لقراءة البيانات من الخادم لتحديث محتوى نموذج الويب أو الصفحة. تعرض القائمة 1 مثالاً بسيطًا (وهو أيضًا مثال من المقالة السابقة في هذه السلسلة - راجع الموارد).

XMLHttpRequest أو XMLHttp: تغيير الاسم

يستخدم Microsoft™ وInternet Explorer كائنًا يسمى XMLHttp بدلاً من كائن XMLHttpRequest، الذي تستخدمه Mozilla وOpera وSafari ومعظم المتصفحات غير التابعة لشركة Microsoft. من أجل التبسيط، سأسمي كلا الكائنين ببساطة XMLHttpRequest. ويتوافق هذا مع ما نراه على الويب ونية Microsoft لاستخدام XMLHttpRequest ككائن الطلب في Internet Explorer 7.0. (راجع الجزء الثاني لمعرفة المزيد حول هذه المشكلة.)

القائمة 1. التعامل مع استجابة الخادم في

وظيفة رد الاتصال updatePage() {
إذا (request.readyState == 4) {
إذا (request.status == 200) {
استجابة فار = request.responseText.split("|");
document.getElementById("order").value = Response[0];
document.getElementById("address").innerHTML =
استجابة[1].replace(/n/g, "<br />");
} آخر
تنبيه ("الحالة هي" + request.status)؛
}
}

من الواضح أن هذا هو الاستخدام الأكثر شيوعًا (والأبسط) للحالة الجاهزة. كما يمكنك أن ترى من الرقم "4"، هناك العديد من الحالات الجاهزة الأخرى (لقد رأيت أيضًا هذه القائمة في المقالة السابقة - راجع الموارد):

· 0: لم تتم تهيئة الطلب (لم يتم استدعاء open() بعد) .
·1: تم إنشاء الطلب، ولكن لم يتم إرساله (لم يتم استدعاء الإرسال () بعد).
·2: تم إرسال الطلب وهو قيد المعالجة (عادةً ما يمكن الآن الحصول على رؤوس المحتوى من الرد).
·3: تتم معالجة الطلب؛ عادةً ما تكون بعض البيانات متاحة في الاستجابة، لكن الخادم لم يكتمل بعد إنشاء الاستجابة.
·4: الاستجابة كاملة، يمكنك الحصول على استجابة الخادم واستخدامها.

إذا كنت تريد أن تفهم أكثر من أساسيات برمجة Ajax، فأنت بحاجة إلى معرفة ليس فقط هذه الحالات، ولكن أيضًا متى تحدث وكيفية استخدامها. أولاً، عليك معرفة حالات الطلب التي قد تواجهها في كل حالة استعداد. لسوء الحظ، هذا ليس بديهيًا ويتضمن عدة حالات خاصة.

حالة الاستعداد المخفية

تتميز حالة الاستعداد الأولى بسمة ReadyState بأنها 0 (readyState == 0)، مما يشير إلى حالة غير مهيأة. يتم تعيين هذه الخاصية على 1 بمجرد استدعاء open() على كائن الطلب. نظرًا لأنك عادةً ما تتصل بـ open()‎ مباشرة بعد تهيئة زوج من الطلبات، نادرًا ما ترى حالة ReadyState == 0. بالإضافة إلى ذلك، فإن حالة الاستعداد غير المهيأة ليس لها أي استخدام حقيقي في التطبيقات الحقيقية.

ولكن من أجل مصلحتنا، راجع القائمة 2، التي توضح كيفية الحصول على حالة الاستعداد هذه عندما يتم ضبط ReadyState على 0.

القائمة 2. الحصول على 0 حالة الاستعداد

الدالة getSalesData() {
// أنشئ كائن طلب
createRequest();
تنبيه ("حالة الاستعداد هي:" + request.readyState)؛

// إعداد (تهيئة) الطلب
var url = "/boards/servlet/UpdateBoardSales";
request.open("GET", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}

في هذا المثال البسيط، getSalesData() هي الوظيفة التي تستدعيها صفحة الويب لبدء طلب (مثلاً عند النقر فوق زر). لاحظ أنه يجب عليك التحقق من حالة الاستعداد قبل الاتصال بـ open(). ويبين الشكل 1 نتائج تشغيل هذا التطبيق.

الشكل 1. حالة الاستعداد 0

من الواضح أن هذا لا يفيدك كثيرًا؛ هناك حالات قليلة جدًا تحتاج فيها إلى التأكد من عدم استدعاء الدالة open() بعد. في العالم الحقيقي لمعظم برمجة Ajax، الاستخدام الوحيد لحالة الاستعداد هذه هو استخدام نفس كائن XMLHttpRequest لإنشاء طلبات متعددة عبر وظائف متعددة. في هذه الحالة (غير الشائعة)، قد ترغب في التأكد من أن كائن الطلب في حالة غير مهيأة (readState == 0) قبل إنشاء طلب جديد. يضمن هذا بشكل أساسي عدم استخدام وظيفة أخرى للكائن في نفس الوقت.

عرض حالة الاستعداد للطلب الذي تتم معالجته

بالإضافة إلى حالة الاستعداد 0، يحتاج كائن الطلب أيضًا إلى المرور عبر عدة حالات جاهزة أخرى للطلبات والاستجابات النموذجية، وينتهي أخيرًا في شكل حالة الاستعداد 4. ولهذا السبب ترى السطر if (request.readyState == 4) في معظم وظائف رد الاتصال، فهو يضمن أن الخادم قد انتهى من معالجة الطلب وأصبح الآن من الآمن تحديث صفحة الويب أو تحديث الصفحة بناءً على الطلب الذي تم إرجاعه؛ من الخادم لتنفيذ العمليات.

من السهل جدًا رؤية كيفية حدوث هذه الحالة. إذا كانت حالة الاستعداد هي 4، فلن يتعين علينا فقط تشغيل التعليمات البرمجية في وظيفة رد الاتصال، ولكننا أيضًا نطبع حالة الاستعداد في كل مرة يتم فيها استدعاء وظيفة رد الاتصال. تقدم القائمة 3 مثالاً على تنفيذ هذه الوظيفة.

عندما 0 يساوي 4

، تحتاج إلى التحقق من حالة الاستعداد 0 للتأكد من أن كائن الطلب ليس قيد الاستخدام عندما تستخدم وظائف JavaScript متعددة نفس كائن الطلب. يمكن أن تسبب هذه الآلية مشاكل. نظرًا لأن ReadyState == 4 يمثل طلبًا مكتملًا، فستجد غالبًا أن كائنات الطلب في حالة الاستعداد التي لا يتم استخدامها حاليًا لا تزال مضبوطة على 4 - وذلك لأن البيانات التي تم إرجاعها من الخادم قد تم استخدامها بالفعل، ولكن لا تم إجراء التغييرات منذ أن تم ضبطها على حالة الاستعداد. توجد دالة إحباط () تعمل على إعادة تعيين كائن الطلب، لكن هذه الوظيفة لا تُستخدم حقًا لهذا الغرض. إذا كان يجب عليك استخدام وظائف متعددة، فمن الأفضل إنشاء واستخدام وظيفة واحدة لكل وظيفة بدلاً من مشاركة نفس الكائن بين وظائف متعددة.

القائمة 3. عرض

وظيفة الاستعداد updatePage() {
// إخراج حالة الاستعداد الحالية
تنبيه ("تم استدعاء updatePage () بحالة الاستعداد" + request.readyState)؛
}

إذا لم تكن متأكدًا من كيفية تشغيل هذه الوظيفة، فأنت بحاجة إلى إنشاء وظيفة، ثم استدعاء هذه الوظيفة في صفحة الويب واطلب منها إرسال طلب إلى المكون من جانب الخادم (مثل الوظيفة الموضحة في القائمة 2، أو الوظيفة في هذه السلسلة من المقالات) الأمثلة الواردة في الجزء الأول والجزء الثاني). تأكد من تعيين وظيفة رد الاتصال على updatePage() عند تقديم الطلب للقيام بذلك، وقم بتعيين خاصية onreadystatechange لكائن الطلب على updatePage().

هذا الرمز هو توضيح دقيق لمعنى onreadystatechange - في كل مرة تتغير فيها حالة الاستعداد للطلب، يتم استدعاء updatePage()، وبعد ذلك يمكننا رؤية تحذير. يوضح الشكل 2 مثالاً على استدعاء هذه الوظيفة، حيث تكون حالة الاستعداد هي 1.

الشكل 2. حالة الاستعداد 1

يمكنك محاولة تشغيل هذا الرمز بنفسك. ضعه في صفحة ويب وقم بتنشيط معالج الحدث (انقر فوق زر أو علامة تبويب بين الحقول أو استخدم أي طريقة قمت بتعيينها لتشغيل الطلب). سيتم تشغيل وظيفة رد الاتصال هذه عدة مرات - في كل مرة تتغير فيها حالة الاستعداد - ويمكنك رؤية التحذير لكل حالة استعداد. هذه هي أفضل طريقة لتتبع المراحل المختلفة التي يمر بها الطلب.

عدم تناسق المتصفح

بعد أن يكون لديك فهم أساسي للعملية، حاول الوصول إلى صفحتك من خلال عدد قليل من المتصفحات المختلفة. يجب أن تلاحظ أن المتصفحات غير متسقة في كيفية تعاملها مع هذه الحالات الجاهزة. على سبيل المثال، في Firefox 1.5، ستشاهد حالات الاستعداد التالية:

·1
·2
·3
·4

وهذا ليس مفاجئًا نظرًا لأن كل حالة طلب ممثلة هنا. ومع ذلك، إذا كنت تستخدم Safari للوصول إلى نفس التطبيق، فيجب أن ترى - أو لا - شيئًا مثيرًا للاهتمام. وإليك ما يبدو عليه في Safari 2.0.1:

·2
·3
·4

يقوم Safari بإلغاء حالة الاستعداد الأولى، ولا يوجد سبب واضح لذلك؛ ولكن هذه هي الطريقة التي يعمل بها Safari. يوضح هذا أيضًا نقطة مهمة: على الرغم من أنه من الجيد التأكد من أن حالة الطلب هي 4 قبل استخدام البيانات الموجودة على الخادم، إلا أن التعليمات البرمجية المكتوبة للاعتماد على كل حالة استعداد انتقالية ستبدو مختلفة بالفعل في نتائج المتصفحات المختلفة.

على سبيل المثال، عند استخدام Opera 8.5، تكون حالة الاستعداد المعروضة أسوأ:

·3
·

4أخيرًا، سيعرض Internet Explorer الحالة التالية:

·1
·2
·3
·4إذا

كانت لديك مشاكل مع طلباتك، فهذا هو المكان الأول الذي يجب أن تذهب إليه للتعرف على المشكلة. أفضل طريقة هي اختبار ذلك في كل من Internet Explorer وFirefox - ستشاهد جميع الحالات الأربع ويمكنك التحقق من حالة كل حالة من حالات الطلب.

بعد ذلك، دعونا نلقي نظرة على الوضع من ناحية الاستجابة.

بيانات الاستجابة تحت المجهر

بمجرد أن نفهم حالات الاستعداد المختلفة التي تحدث أثناء عملية الطلب، فقد حان الوقت للنظر إلى جانب آخر من كائن XMLHttpRequest - سمة ResponseText. تذكر ما قدمناه في المقالة السابقة، يمكنك معرفة أن هذه السمة تستخدم للحصول على البيانات من الخادم. بمجرد انتهاء الخادم من معالجة الطلب، يمكنه وضع أي بيانات مطلوبة للرد على بيانات الطلب في نص استجابة الطلب. يمكن لوظيفة رد الاتصال بعد ذلك استخدام هذه البيانات، كما هو موضح في القائمة 1 والقائمة 4.

القائمة 4. استخدام الرد الذي تم إرجاعه على الخادم

وظيفة تحديث الصفحة () {
إذا (request.readyState == 4) {
var newTotal = request.responseText;
var TotalSoldEl = document.getElementById("total-sold");
var netProfitEl = document.getElementById("net-profit");
استبدال النص (totalSoldEl, newTotal);

/* تصور صافي الربح الجديد */
var boardCostEl = document.getElementById("board-cost");
var boardCost = getText(boardCostEl);
var manCostEl = document.getElementById("man-cost");
var manCost = getText(manCostEl);
varprofitPerBoard = boardCost - manCost;
var netProfit =profitPerBoard * newTotal;

/* تحديث صافي الربح في نموذج المبيعات */
netProfit = Math.round(netProfit * 100) / 100;
استبدال النص (netProfitEl، netProfit)؛
القائمة

1 بسيطة إلى حد ما؛ القائمة 4 أكثر تعقيدًا بعض الشيء، لكن كلاهما يتحقق من حالة الاستعداد في البداية ويحصل على قيمة خاصية ResponseText.

عرض نص استجابة الطلب

كما هو الحال مع حالة الاستعداد، تتغير قيمة خاصية ResponseText أيضًا طوال فترة الطلب. لرؤية هذا التغيير، استخدم الكود الموضح في القائمة 5 لاختبار نص الاستجابة للطلب، بالإضافة إلى حالة الاستعداد.

القائمة 5. اختبار وظيفة خاصية ResponseText

updatePage() {
// إخراج حالة الاستعداد الحالية
تنبيه ("تم استدعاء updatePage () بحالة الاستعداد" + request.readyState +
"ونص الرد '" + request.responseText + "'");
}

الآن افتح تطبيق الويب في متصفحك وقم بتنشيط طلبك. لرؤية تأثير هذا الرمز بشكل أفضل، استخدم Firefox أو Internet Explorer، حيث يمكن لكلا المتصفحين الإبلاغ عن جميع حالات الاستعداد المحتملة أثناء الطلب. على سبيل المثال، في حالة الاستعداد 2، لم يتم تعريف نص الاستجابة (انظر الشكل 3)؛ إذا كانت وحدة تحكم JavaScript مفتوحة أيضًا، فسوف ترى خطأ.

الشكل 3. نص الاستجابة لحالة الاستعداد 2

ومع ذلك، في حالة الاستعداد 3، قام الخادم بوضع قيمة في خاصية ResponseText، على الأقل في هذا المثال (انظر الشكل 4).

الشكل 4. نص الاستجابة لحالة الاستعداد 3

سترى أن الاستجابة بحالة الاستعداد 3 تختلف في كل برنامج نصي وكل خادم وحتى كل متصفح. ومع ذلك، لا يزال هذا مفيدًا جدًا في تصحيح أخطاء التطبيقات.

الحصول على بيانات آمنة

تؤكد جميع المستندات والمواصفات على أنه لا يمكن استخدام البيانات بأمان إلا عندما تكون حالة الاستعداد هي 4. صدقني، عندما تكون حالة الاستعداد 3، نادرًا ما تجد موقفًا لا يمكنك فيه الحصول على البيانات من خاصية ResponseText. ومع ذلك، ليست فكرة جيدة أن تجعل المنطق الخاص بك في تطبيقك يعتمد على حالة الاستعداد 3 - بمجرد كتابة التعليمات البرمجية التي تعتمد على البيانات الكاملة في حالة الاستعداد 3، فأنت مسؤول تقريبًا عن البيانات غير المكتملة في ذلك الوقت.

الأسلوب الأفضل هو تقديم بعض الملاحظات للمستخدم أنه عندما يكون في حالة الاستعداد 3، فإن الاستجابة ستكون قريبًا. على الرغم من أن استخدام وظائف مثل التنبيه () يعد فكرة سيئة بشكل واضح - فمن الواضح أن استخدام Ajax ثم حظر المستخدم بمربع حوار تنبيه هو خطأ واضح - يمكنك تحديث الحقول في نموذج أو صفحة عندما تتغير حالة الاستعداد. على سبيل المثال، بالنسبة لحالة الاستعداد 1، قم بتعيين عرض مؤشر التقدم على 25%، بالنسبة لحالة الاستعداد 2، قم بتعيين عرض مؤشر التقدم على 50%، وبالنسبة لحالة الاستعداد 3، قم بتعيين عرض مؤشر التقدم على 25 % يتم ضبط العرض على 75%، وعندما تكون حالة الاستعداد 4، يتم ضبط عرض مؤشر التقدم على 100% (مكتمل).

بالطبع، كما رأيت بالفعل، هذه الطريقة ذكية جدًا، ولكنها تعتمد على المتصفح. في Opera، لن ترى أبدًا أول حالتين جاهزتين، وفي Safari لا توجد الحالة الأولى (1). لهذا السبب، تركت هذا الكود كتمرين ولم أدرجه في هذه المقالة.

حان الوقت الآن لإلقاء نظرة على رموز الحالة.

نظرة أعمق على رموز حالة HTTP

مع حالة الاستعداد واستجابة الخادم التي تعلمتها في تقنيات برمجة Ajax، يمكنك إضافة مستوى آخر من التعقيد إلى تطبيقات Ajax الخاصة بك - باستخدام رموز حالة HTTP. لا يوجد شيء جديد حول Ajax في هذا الكود. لقد كانوا موجودين منذ فجر الويب. ربما تكون قد شاهدت العديد من رموز الحالة في متصفحات الويب:

· 401: غير مصرح به · 403: محظور · 404: لم يتم العثور عليه

يمكنك العثور على المزيد من رموز الحالة (انظر الموارد للحصول على قائمة كاملة). لإضافة طبقة إضافية من آليات التحكم والاستجابة (والتعامل بشكل أكثر قوة مع الأخطاء) إلى تطبيقات Ajax الخاصة بك، تحتاج إلى عرض رموز الحالة بشكل صحيح في الطلبات والاستجابات.

200: كل شيء على ما يرام

في العديد من تطبيقات Ajax، سترى وظيفة رد الاتصال المسؤولة عن التحقق من حالة الاستعداد ثم الاستمرار في استخدام البيانات التي تم إرجاعها من استجابة الخادم، كما هو موضح في القائمة 6.

القائمة 6. وظيفة رد الاتصال التي تتجاهل وظيفة رمز الحالة

updatePage() {
إذا (request.readyState == 4) {
استجابة فار = request.responseText.split("|");
document.getElementById("order").value = Response[0];
document.getElementById("address").innerHTML =
استجابة[1].replace(/n/g, "<br />");
}
}

تبين أن هذا أسلوب قصير النظر وخاطئ في برمجة Ajax. إذا كان البرنامج النصي يتطلب مصادقة ولم يقدم الطلب شهادة صالحة، فسيقوم الخادم بإرجاع رمز خطأ مثل 403 أو 401. ومع ذلك، نظرًا لأن الخادم استجاب للطلب، يتم تعيين حالة الاستعداد إلى 4 (على الرغم من أن الاستجابة لم تكن كما توقعها الطلب). في النهاية، لا يحصل المستخدم على بيانات صالحة، ويمكن أن تحدث أخطاء خطيرة عندما تحاول JavaScript استخدام بيانات خادم غير موجودة.

لا يتطلب الأمر سوى أقل قدر من الجهد للتأكد من أن الخادم لا يكمل الطلب فحسب، بل يُرجع أيضًا رمز الحالة "الكل على ما يرام". هذا الرمز هو "200"، والذي يتم الإبلاغ عنه من خلال سمة الحالة لكائن XMLHttpRequest. للتأكد من أن الخادم لم يكمل الطلب فحسب، بل أبلغ أيضًا عن حالة موافق، أضف فحصًا آخر إلى وظيفة رد الاتصال الخاصة بك، كما هو موضح في القائمة 7.

القائمة 7. وظيفة التحقق من رموز الحالة الصالحة

updatePage() {
إذا (request.readyState == 4) {
إذا (request.status == 200) {
استجابة فار = request.responseText.split("|");
document.getElementById("order").value = Response[0];
document.getElementById("address").innerHTML =
استجابة[1].replace(/n/g, "<br />");
} آخر
تنبيه ("الحالة هي" + request.status)؛
}
}

من خلال إضافة هذه الأسطر القليلة من التعليمات البرمجية، يمكنك التأكد من وجود مشكلة وسيرى المستخدم رسالة خطأ مفيدة بدلاً من مجرد رؤية صفحة مكونة من بيانات مأخوذة من السياق بدون أي تفسير.

عمليات إعادة التوجيه وإعادة التوجيه

قبل أن ندخل في تفاصيل الأخطاء، من المفيد مناقشة مشكلة لا داعي للقلق بشأنها عند استخدام Ajax - عمليات إعادة التوجيه. من بين رموز حالة HTTP، هذه هي السلسلة 300 من رموز الحالة، بما في ذلك:

301: تم النقل نهائيًا 302: تم العثور عليه (تم إعادة توجيه الطلب إلى عنوان URL/URI آخر)
· 305: استخدام وكيل (يجب أن يستخدم الطلب وكيلًا للوصول إلى المورد المطلوب)

قد لا يكون مبرمجو Ajax قلقين جدًا بشأن مشكلات إعادة التوجيه، وذلك لسببين:

· أولاً، عادةً ما يتم تصميم تطبيقات Ajax خصيصًا لجانب خادم محدد البرنامج النصي أو servlet أو التطبيق. مبرمجو Ajax أقل وضوحًا بشأن المكونات التي تختفي دون أن تراها. لذا، أحيانًا تعلم أن المورد قد تم نقله (لأنك قمت بنقله، أو نقله بطريقة ما)، ثم تقوم بتعديل عنوان URL في الطلب ولن تواجه هذه النتيجة مرة أخرى أبدًا.
السبب الأكثر أهمية هو أن تطبيقات وطلبات Ajax مغلفة في وضع الحماية. وهذا يعني أن المجال الذي يخدم صفحات الويب التي تولد طلبات Ajax يجب أن يكون هو المجال الذي يستجيب لتلك الطلبات. لذلك، لا يمكن لصفحة الويب المقدمة من ebay.com تقديم طلب بنمط Ajax إلى برنامج نصي يعمل على amazon.com؛ ولا يمكن لتطبيق Ajax على ibm.com تقديم طلب إلى servlets التي تعمل على netbeans.org.
· والنتيجة هي أنه لا يمكن إعادة توجيه طلبك إلى خادم آخر دون حدوث خطأ أمني. وفي هذه الحالات، لن تحصل على رمز الحالة على الإطلاق. عادةً ما يتم إنشاء خطأ JavaScript في وحدة تحكم التصحيح. لذلك، بعد التفكير بشكل كافٍ في رموز الحالة، يمكنك تجاهل مشكلة إعادة توجيه الرموز تمامًا.

والنتيجة هي أنه لا يمكن إعادة توجيه طلبك إلى خادم آخر دون حدوث خطأ أمني. وفي هذه الحالات، لن تحصل على رمز الحالة على الإطلاق. عادةً ما يتم إنشاء خطأ JavaScript في وحدة تحكم التصحيح. لذلك، بعد التفكير بشكل كافٍ في رموز الحالة، يمكنك تجاهل مشكلة إعادة توجيه الرموز تمامًا.

الأخطاء

بمجرد أن تتلقى رمز الحالة 200 وتدرك أنه يمكنك تجاهل رموز حالة السلسلة 300 إلى حد كبير، فإن المجموعة الوحيدة من الرموز التي تحتاج إلى القلق بشأنها هي رموز السلسلة 400، والتي توضح الأنواع المختلفة من الأخطاء. انظر مرة أخرى إلى القائمة 7 ولاحظ أنه عند معالجة الأخطاء، يتم إخراج عدد قليل فقط من رسائل الخطأ الشائعة إلى المستخدم. على الرغم من أن هذه خطوة في الاتجاه الصحيح، إلا أن هذه الرسائل لا تزال غير مفيدة جدًا في إخبار المستخدمين والمبرمجين العاملين على التطبيق بالخطأ الذي يحدث بالضبط.

أولاً، سنضيف دعمًا للصفحات التي لم يتم العثور عليها. لا ينبغي أن يحدث هذا في الواقع في معظم أنظمة الإنتاج، ولكن ليس من غير المألوف عندما يتغير موقع البرنامج النصي للاختبار أو يقوم المبرمج بإدخال عنوان URL خاطئ. إذا كان بإمكانك الإبلاغ عن أخطاء 404 بشكل طبيعي، فيمكنك تقديم المزيد من المساعدة للمستخدمين والمبرمجين المحبطين. على سبيل المثال، إذا تم حذف برنامج نصي على الخادم، فيمكننا استخدام الكود الموجود في القائمة 7 بحيث يرى المستخدم خطأ غير وصفي مثل الخطأ الموضح في الشكل 5.

حالات الحافة والمواقف الصعبة

في هذه المرحلة، قد يتساءل بعض المبرمجين المبتدئين عن سبب هذا الأمر. إليك حقيقة تحتاج إلى معرفتها: أقل من 5% من طلبات Ajax تستخدم حالات الاستعداد مثل 2 و3 ورموز الحالة مثل 403 (في الواقع، ربما يكون هذا المعدل أقرب إلى 1% أو حتى أقل). هذه المواقف مهمة جدًا وتسمى حالات الحافة - فهي تحدث فقط في مواقف محددة جدًا حيث تتم مواجهة المشكلات الأكثر غرابة. على الرغم من أن هذه المواقف ليست شائعة، إلا أن حالات الحافة هذه تمثل 80% من المشكلات التي يواجهها معظم المستخدمين.

بالنسبة للمستخدم العادي، عادة ما يتم نسيان حقيقة أن التطبيق يعمل بشكل صحيح 100 مرة، ومع ذلك سيتم تذكر خطأ واحد في التطبيق بوضوح! هم. إذا كنت تستطيع التعامل مع الحالات المتطورة (أو المواقف الصعبة) بشكل جيد، فيمكنك تقديم مكافآت مرضية للمستخدمين الذين يعودون إلى موقعك.

الشكل 5. معالجة الأخطاء الشائعة

ليس لدى المستخدم أي وسيلة لمعرفة ما إذا كانت المشكلة هي مشكلة مصادقة، أو عدم العثور على برنامج نصي (كما هو الحال هنا)، أو خطأ مستخدم، أو أي شيء آخر في التعليمات البرمجية. يمكن أن تؤدي إضافة بعض التعليمات البرمجية البسيطة إلى جعل هذا الخطأ أكثر تحديدًا. يرجى الرجوع إلى القائمة 8، المسؤولة عن التعامل مع الموقف الذي لا يتم فيه العثور على البرنامج النصي أو حدوث خطأ في المصادقة، وسيتم تقديم رسائل محددة عند حدوث هذه الأخطاء.

القائمة 8. وظيفة التحقق من رموز الحالة الصالحة

updatePage() {
إذا (request.readyState == 4) {
إذا (request.status == 200) {
استجابة فار = request.responseText.split("|");
document.getElementById("order").value = Response[0];
document.getElementById("address").innerHTML =
استجابة[1].replace(/n/g, "<br />");
} وإلا إذا (request.status == 404) {
تنبيه ("لم يتم العثور على عنوان URL المطلوب.")؛
} وإلا إذا (request.status == 403) {
تنبيه ("تم رفض الوصول.")؛
} آخر
تنبيه ("الحالة هي" + request.status)؛
}
}

على الرغم من أن هذا لا يزال بسيطًا إلى حد ما، إلا أنه يوفر المزيد من المعلومات المفيدة. يوضح الشكل 6 نفس الخطأ الموجود في الشكل 5، ولكن هذه المرة يوضح رمز معالجة الأخطاء بشكل أفضل للمستخدم أو المبرمج ما حدث بالضبط.

الشكل 6. معالجة الأخطاء الخاصة

في تطبيقنا الخاص، قد نفكر في مسح اسم المستخدم وكلمة المرور وإضافة رسالة خطأ على الشاشة في حالة فشل المصادقة. يمكننا استخدام نهج مماثل للتعامل بشكل أفضل مع البرنامج النصي الذي لم يتم العثور عليه أو الأخطاء الأخرى من النوع 400 (على سبيل المثال، 405 يعني أن طريقة الطلب غير المقبولة مثل إرسال طلب HEAD غير مسموح بها، و407 يعني أن مصادقة الوكيل مطلوبة). ومع ذلك، بغض النظر عن الخيار الذي تختاره، فأنت بحاجة إلى البدء في معالجة رمز الحالة الذي تم إرجاعه من الخادم.

أنواع الطلبات الأخرى

إذا كنت تريد حقًا التحكم في كائن XMLHttpRequest، ففكر في تنفيذ هذه الوظيفة النهائية عن طريق إضافة طلب HEAD إلى التوجيه. لقد قدمنا ​​في المقالتين السابقتين كيفية إنشاء طلبات GET؛ وفي مقال قادم ستتعرف على استخدام طلبات POST لإرسال البيانات إلى الخادم. ومع ذلك، في ظل روح المعالجة المحسنة للأخطاء وجمع المعلومات، يجب أن تتعلم كيفية إنشاء طلبات HEAD.

إجراء الطلب

إجراء طلب HEAD هو في الواقع أمر بسيط جدًا؛ يمكنك استدعاء الأسلوب open() باستخدام "HEAD" (بدلاً من "GET" أو "POST") كمعلمة أولى، كما هو موضح في القائمة 9.

القائمة 9. استخدام Ajax لإنشاء

وظيفة طلب HEAD getSalesData() {
createRequest();
var url = "/boards/servlet/UpdateBoardSales";
request.open("HEAD", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}

عندما تقوم بإنشاء طلب HEAD مثل هذا، فإن الخادم لا يُرجع استجابة حقيقية كما يحدث مع طلب GET أو POST. بدلاً من ذلك، يقوم الخادم فقط بإرجاع رأس المورد، والذي يتضمن وقت آخر تعديل للمحتوى الموجود في الاستجابة، وما إذا كان المورد المطلوب موجودًا، والكثير من المعلومات المفيدة الأخرى. يمكنك استخدام هذه المعلومات للتعرف على المورد قبل معالجته وإعادته بواسطة الخادم.

إن أبسط شيء يمكنك القيام به لهذا النوع من الطلبات هو ببساطة إخراج محتويات جميع رؤوس الاستجابة. يمنحك هذا فكرة عما هو متاح عبر طلب HEAD. توفر القائمة 10 وظيفة رد اتصال بسيطة تطبع محتويات رأس الاستجابة التي تم الحصول عليها من طلب HEAD.

القائمة 10. قم بإخراج محتويات رأس الاستجابة التي تم الحصول عليها من

وظيفة طلب HEAD updatePage() {
إذا (request.readyState == 4) {
تنبيه (request.getAllResponseHeaders ())؛
}
}

انظر الشكل 7، الذي يوضح رؤوس الاستجابة التي تم إرجاعها من تطبيق Ajax بسيط يقوم بتقديم طلب HEAD إلى الخادم.

يمكنك استخدام هذه الرؤوس بشكل فردي (من نوع الخادم إلى نوع المحتوى) لتوفير معلومات أو وظائف إضافية في تطبيق Ajax الخاص بك.

التحقق من عنوان URL

لقد رأيت كيفية التحقق من أخطاء 404 عندما لا يكون عنوان URL موجودًا. إذا تبين أن هذه مشكلة شائعة - ربما يكون هناك برنامج نصي أو servlet مفقود - فقد ترغب في التحقق من عنوان URL قبل تقديم طلب GET أو POST كامل. لتنفيذ هذه الوظيفة، قم بإنشاء طلب HEAD ثم تحقق من وجود أخطاء 404 في وظيفة رد الاتصال. تعرض القائمة 11 وظيفة رد اتصال بسيطة.

القائمة 11. التحقق من وجود عنوان URL

وظيفة updatePage() {
إذا (request.readyState == 4) {
إذا (request.status == 200) {
تنبيه ("عنوان URL موجود")؛
} وإلا إذا (request.status == 404) {
تنبيه ("عنوان URL غير موجود.")؛
} آخر {
تنبيه ("الحالة هي:" + request.status)؛
}
}
}

بصراحة، قيمة هذا الرمز ليست كبيرة. يجب أن يستجيب الخادم للطلب ويقوم بإنشاء استجابة لتضمين رأس استجابة طول المحتوى، لذلك لا يتم حفظ وقت المعالجة. بالإضافة إلى ذلك، يستغرق هذا وقتًا طويلاً مثل إنشاء الطلب واستخدام طلب HEAD لمعرفة ما إذا كان عنوان URL موجودًا، نظرًا لأنه يتم إنشاء الطلب باستخدام GET أو POST بدلاً من مجرد معالجة رمز الخطأ كما هو موضح في القائمة 7. ومع ذلك، في بعض الأحيان يكون من المفيد أن تعرف بالضبط ما هو متاح حاليًا؛ فأنت لا تعرف أبدًا متى سيبدأ إبداعك أو متى ستحتاج إلى طلب HEAD!

طلبات HEAD المفيدة

أحد المجالات التي قد تجد فيها طلب HEAD مفيدًا جدًا هو معرفة طول المحتوى أو نوع المحتوى. يمكن أن يحدد هذا ما إذا كان يجب إرسال كمية كبيرة من البيانات مرة أخرى لمعالجة الطلب، وما إذا كان الخادم يحاول إرجاع البيانات الثنائية بدلاً من HTML أو النص أو XML (جميع أنواع البيانات الثلاثة أسهل في المعالجة في JavaScript من البيانات الثنائية).

في هذه الحالات، يمكنك ببساطة استخدام اسم الرأس المناسب وتمريره إلى أسلوب getResponseHeader() الخاص بكائن XMLHttpRequest. لذا، للحصول على طول الاستجابة، ما عليك سوى الاتصال بـ request.getResponseHeader("Content-Length");. للحصول على نوع المحتوى، استخدم request.getResponseHeader("Content-Type");.

في العديد من التطبيقات، لا يضيف إنشاء طلب HEAD أي وظيفة وقد يتسبب في إبطاء الطلب (من خلال إجبار طلب HEAD على الحصول على بيانات حول الاستجابة، ثم استخدام طلب GET أو POST للحصول على الاستجابة فعليًا). ومع ذلك، في المواقف التي لا تكون فيها متأكدًا من البرنامج النصي أو المكون من جانب الخادم، يمكن أن يؤدي استخدام طلب HEAD إلى الحصول على بعض البيانات الأساسية دون معالجة بيانات الاستجابة فعليًا أو الحاجة إلى قدر كبير من النطاق الترددي لإرسال الاستجابة.

الاستنتاج

بالنسبة للعديد من مبرمجي Ajax والويب، قد تبدو المواد المقدمة في هذه المقالة متقدمة جدًا. ما هي قيمة إنشاء طلب HEAD؟ متى تحتاج إلى التعامل بشكل صريح مع رموز حالة إعادة التوجيه في JavaScript؟ هذه أسئلة جيدة بالنسبة للتطبيقات البسيطة، والإجابة هي أن قيمة هذه التقنيات المتقدمة ليست كبيرة جدًا.

ومع ذلك، لم يعد الويب مكانًا تحتاج فيه فقط إلى تنفيذ تطبيقات بسيطة؛ فقد أصبح المستخدمون أكثر تقدمًا، ويتوقع العملاء استقرارًا أفضل، وتقارير أكثر تقدمًا عن الأخطاء، وإذا كان التطبيق معطلاً بنسبة 1٪ من الوقت، فقد يتمكن المدير من ذلك. يتم طرده من أجل ذلك.

لذلك، لا يمكن أن يقتصر عملك على التطبيقات البسيطة، بل يتطلب فهمًا أعمق لـ XMLHttpRequest.

·إذا كان بإمكانك التفكير في حالات الاستعداد المختلفة — وفهم كيفية اختلاف حالات الاستعداد هذه بين المتصفحات — فيمكنك تصحيح أخطاء تطبيقك بسرعة. يمكنك أيضًا تطوير بعض الوظائف الإبداعية استنادًا إلى حالة الاستعداد وإبلاغ المستخدمين والعملاء بالحالة المطلوبة.
·إذا كنت تريد التحكم في رموز الحالة، فيمكنك إعداد التطبيق الخاص بك للتعامل مع أخطاء البرنامج النصي والاستجابات غير المتوقعة وحالات الحافة. والنتيجة هي تطبيق يعمل بشكل صحيح طوال الوقت، وليس فقط عندما يكون كل شيء على ما يرام.
· أضف القدرة على إنشاء طلبات HEAD، والتحقق من وجود عنوان URL، والتأكد من تعديل الملف، وذلك لضمان حصول المستخدمين على صفحات صالحة وأن المعلومات التي يراها المستخدمون هي الأحدث (والأهم من ذلك) أن تفاجئهم مدى قوة وتنوع هذا التطبيق.
الغرض من هذه المقالة ليس جعل تطبيقك يبدو فاخرًا، ولكن مساعدتك في إزالة الأضواء الصفراء وإبراز جمال النص، أو أن يبدو أشبه بسطح المكتب. على الرغم من أن هذه كلها ميزات لأياكس (والتي سيتم تناولها في المقالات القليلة القادمة)، إلا أنها تشبه طبقة من الكريمة على الكعكة. إذا كان بإمكانك استخدام Ajax لبناء أساس متين حتى يتمكن تطبيقك من التعامل مع الأخطاء والمشكلات بشكل جيد، فسيعود المستخدمون إلى موقعك وتطبيقك. في المقالة التالية، سنضيف هذه التقنية البديهية التي ستجعل عملائك يرتعدون من الإثارة. (على محمل الجد، لا تريد أن تفوت المقالة التالية!)