محفوظات AppML
في عام 1999 ، طورت Refsnes Data الإصدار الأول من AppML.
في ذلك الوقت ، كان AppML يعتمد على اتصال طلب HTTP بين عميل الويب وخادم الويب. أصبحت هذه الطريقة لاحقًا معروفة باسم AJAX.
في سبتمبر 2000 ، بدأ مشروع تطوير لعميل نرويجي كبير. كان الهدف من المشروع هو تحويل نظام معلومات ضخم (حوالي 300 تطبيق) من تطبيق سطح مكتب Windows إلى تطبيق إنترنت حديث ، باستخدام AppML فقط.
تم إطلاق النظام المستند إلى AppML في عام 2001 ، قبل عدة أشهر من الموعد المحدد ، كأول تطبيق تجاري لـ AJAX في العالم. حقق المشروع نجاحًا كبيرًا ، حيث تم تقليل وقت التطوير بنسبة 75٪ مقارنةً بتطوير الويب العادي. منذ ذلك الحين ، تمت إضافة تطبيقات جديدة ، ويغطي النظام الآن أكثر من 1000 تطبيق قيد التشغيل.
في فبراير 2015 ، أعادت W3Schools إطلاق AppML كمنتج جديد ، مفتوح للجمهور.
أهداف تصميم AppML:
- يجب تشغيل تطبيقات AppML عبر الإنترنت
- يجب أن تكون تطبيقات AppML مستقلة عن النظام الأساسي
- يجب أن تستخدم تطبيقات AppML معايير الإنترنت فقط (HTML ، CSS ، JavaScript)
- يجب أن تدعم تطبيقات AppML مجموعة متنوعة من احتياجات التطبيق
- يجب أن تكون تطبيقات AppML ذاتية الوصف
- يجب أن تكون تطبيقات AppML سهلة التطوير والصيانة والتغيير
- يجب أن تكون تطبيقات AppML إثباتًا في المستقبل
تصف الفقرات أدناه الرؤى الأصلية لـ Refsnes Data (1999) حول تطبيقات الويب المستقبلية.
سوف تموت الملفات القابلة للتنفيذ ، ستعيش JavaScript
لا يمكن تشغيل الملفات التنفيذية المجمعة (المترجمة من لغات مثل C أو Java) على أجهزة مختلفة.
العناصر القابلة للتنفيذ (ملفات EXE ، وكائنات ActiveX و COM ، وملفات DLL) هي مكونات تمنع تطوير التطبيقات التي يمكن تشغيلها عبر الإنترنت.
لن يستخدم التطبيق المستقبلي ، أو يعتمد على ، الملفات التنفيذية أو أي مكونات أخرى مثبتة على جهاز كمبيوتر العميل.
اقتراحاتنا:
اكتب تطبيقاتك المستقبلية باستخدام HTML و CSS و JavaScript فقط.
تأكد من تشغيل تطبيقاتك المستقبلية في أي متصفح ويب.
تطبيقات الويب ستكون خدمات إنترنت
التاريخ مليء بالتطبيقات الكبيرة المصممة لهذا الغرض. مات العديد من هؤلاء بسرعة كبيرة ، لأنهم لم يتمكنوا من تحمل تغييرات المتطلبات.
يجب أن تكون التطبيقات مرنة ، ومعممة ، ومتكيفة بشكل رشيق مع التغييرات ، دون أن تنهار أو تتلف.
يجب أن تكون التطبيقات قادرة على التوسع من دعم بضعة إلى ملايين الطلبات يوميًا.
يجب أن تكون التطبيقات قادرة على الانتشار من خادم إلى العديد ، أو التنقل بين الخوادم دون كسر التطبيق.
يجب أن تكون التطبيقات قادرة على التعاون مع التطبيقات الأخرى.
يجب ألا تحتوي التطبيقات على كتل كبيرة من التعليمات البرمجية.
يجب تقسيم التطبيقات إلى خدمات أصغر يسهل إنشاؤها وصيانتها.
يجب أن تكون التطبيقات عبارة عن مجموعة من خدمات الإنترنت التي يمكنها إرجاع البيانات إلى طلبات الإنترنت المقدمة.
يجب أن تطلب التطبيقات خدمات عبر بروتوكولات الإنترنت القياسية دون الحفاظ على اتصال دائم بالخادم.
اقتراحاتنا:
اكتب تطبيقاتك المستقبلية باستخدام SOA المستندة إلى الإنترنت (هندسة الخدمة الموجهة).
اجعل خدمات تطبيقك عامة ومرنة وجاهزة لخدمة أنواع مختلفة من الطلبات.
ستكون التطبيقات المستقبلية سهلة الإنشاء والتعديل
سيتبادل العملاء والخوادم البيانات بطريقة سهلة ومفهومة.
لن يتم ترميز التطبيقات ، إذا كان من الممكن تجنب ذلك.
سيتم إنشاء التطبيقات وتعديلها ، عن طريق تحرير النماذج ، وليس عن طريق تحرير التعليمات البرمجية.
ستكون أوصاف التطبيق قابلة للقراءة من قبل البشر.
وصف التطبيق سوف يصف نفسه.
سيتم كتابة الطلبات من قبل المستخدمين وليس المبرمجين.
اقتراحاتنا:
استخدم ملفات نصية يمكن للبشر قراءتها لوصف الخدمات وتقديم الخدمات من خلال تنفيذ هذه الأوصاف.
استخدم الملفات النصية (مثل ملفات JSON) لوصف التطبيقات.
استخدم الملفات النصية (مثل ملفات JSON) لتبادل البيانات.
استخدم HTML و CSS و JavaScript لتنفيذ التطبيقات.
ثلاثة من مطوري الويب الصغار ...
ذات مرة ، كان هناك ثلاثة مطوري ويب صغار يقومون بتطوير موقع ويب جديد.
1. كان أول مطور ويب يستخدم AppML.
2. كان مطور الويب الثاني يستخدم لغة برمجة الخادم المفضلة لديه.
3. والثالث هو استخدام إطار تطوير الويب الخاص بالمؤسسات المهنية.
قام مطور الويب الأول بعمل عرض توضيحي وتشغيله في غضون يومين. بعد التعاون مع المستخدمين ، أصبح النموذج الأولي جاهزًا في غضون أسبوع. وبعد أسبوعين من الاختبار ، أصبح موقع ويب ذكيًا وسريعًا وسهل الاستخدام جاهزًا للنشر.
قام مطور الويب الثاني بتجهيز موقع الويب الخاص به بعد 6 أشهر. لكن WWW غيرت متطلباتها ولم تكن راضية. لم يتمكن مطور الويب من إجراء تغييرات كبيرة على مشروعه لأنه يحتوي على الكثير من التعليمات البرمجية. لذلك بدأ تطوير الإصدار 2.
لم ينجح مطور الويب الثالث في إكمال عمله. كان من الصعب جدًا استخدام إطار تطوير الويب الاحترافي ، ومن الصعب جدًا فهمه ، ويكاد يكون من المستحيل اختباره.
ألق نظرة على كيفية قيام المطور الأول بذلك .