سؤال

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

إذا تم تعطيل JavaScript ، فإن كل طلب HTTP إلى الخادم سيقوم بإنشاء HTML كاستجابة. يتم تحديث المتصفح مع HTML عاد. هذا جيّد.

إذا تم تمكين JavaScript ، فسيقوم كل طلب AJAX HTTP إلى الخادم بإنشاء ... حسنًا ، JSON أو HTML.

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

إذا كان JSON ، فيجب علي تنفيذ منطق JSON-to-HTML في JavaScript مرة أخرى وهو ما يكرر تقريبًا من منطق جانب الخادم. الازدواجية شريرة. أنا حقا لا أحب ذلك. والفائدة هي أن استخدام النطاق الترددي أفضل من HTML ، والذي يجلب أداء أفضل.

إذن ، ما هو أفضل حل للتدهور الرشيق؟ Ajax طلب أفضل لإعادة JSON أو HTML؟

هل كانت مفيدة؟

المحلول

لا أعتقد أنه يمكن أن يكون هناك "حل أفضل" أي الوضع المعطى. ربما فقط ، "الحل المناسب" لحسد معين. يعتمد الأمر حقًا على ما تحاول القيام به. ما الذي يعنيه التحلل الرشيق بالنسبة لي هو:

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

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

المنظور الآخر هو أن JSON يقلل من استخدام النطاق الترددي ، لذلك يستحق الذهاب إلى ميل إضافي لتحليل بعض JSON لإنشاء بعض العلامات على العميل. أجد أنه من السهل الاختلاف مع وجهة النظر هذه ، لعدة أسباب (أنا ليس تعميم ، لا تفهموني خطأ). بادئ ذي بدء ، يتم تكوين العديد من خادمات الويب للعديد من مواقع الويب لضغط/انحراف/GZIP إخراجهم ، والعديد من المتصفحات تقبل المحتوى المضغوط. الترميز هو الى ابعد حد قابل للضغط ، لأنه يحتوي على حمولة قارب من التكرار (<strong></strong>). لذلك من المعقول أن ننظر إلى أن حجم استجابة JSON لن يكون أصغر بشكل كبير من الاستجابة مع Markup. ثانياً ، قد تعني مجموعة البيانات الكبيرة وقت تنفيذ كبير على العميل (الحلقات المتداخلة السيئة شائعة - واضحة في بعض الأسئلة التي تظهر هنا).

نصيحتي لك هي محاولة فهم الجوانب الصعود والسلبية لكل نهج ، والاستفادة من تلك المعلومات. قد ترغب في قراءة هذا:

http://www.quirksmode.org/blog/archives/2005/12/the_ajax_respon.html

نصائح أخرى

IMO ، العمل مع HTML يجلب مخاطر أمنية أكبر (حقن النصي MITM ، إلخ). في أي وقت يتم حفظه على "الازدواجية" يجب أن تنفق حقًا على التعقيم قبل الإلحاق.

يمكن تحليل JSON بأمان وعادة ما يكون أكثر إحكاما ، كما تقول ، توفير النطاق الترددي.

أعرف ما الذي سأختاره (JSON).

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

ومع ذلك ، إليك نهج قد ينجح:

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

  2. اكتب برنامج نصي من جانب الخادم يقوم ببساطة باستدعاء برنامجك ويخرج النتيجة كنص عادي أو XML.

  3. اكتب نصًا آخر من جانب الخادم يدعو البرنامج ويبني صفحة HTML منه.

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top