WebRocketX

مرحبًا بك في WebRocketX©. قم بتطوير تطبيقات الويب ذات الصفحة الواحدة (SPA) بكفاءة أكبر 10 مرات باستخدام نظام تسليم المحتوى الخفيف للغاية والسريع للغاية. يعد WebRocketX بديهيًا وفعالًا للغاية لدرجة أن أي شخص يستخدمه يتساءل على الفور عن المكان الذي كان يختبئ فيه حقن HTML طوال هذه السنوات.

ما هو ويب روكيت اكس؟

WebRocketX عبارة عن واجهة برمجة تطبيقات جافا سكريبت من جانب المتصفح والتي يتم من خلالها إجراء جميع الاستدعاءات غير المتزامنة إلى الخادم. الآلية الأساسية لتحديث الصفحة هي من خلال إدراج DOM لمقتطفات HTML باستخدام خاصية InternalHTML. من خلال وجود نقطة واحدة للتفاعل مع الخادم، يتمتع المطور بالوظائف التالية التي توفرها واجهة برمجة التطبيقات (API).

• يوفر واجهة أمامية لتطبيق صفحة واحدة (SPA) لأي تقنية توفر HTML من الواجهة الخلفية، مثل Springboot وPHP وLaravel وDjango وRails وما إلى ذلك.
• التحكم من جانب المتصفح في تفاعل المستخدم أثناء المكالمة غير المتزامنة
• معالجة الأخطاء من جانب المتصفح للاستثناءات من جانب الخادم
• التخزين المؤقت للعرض الجانبي للمتصفح ~ اجعل زر الرجوع يعمل بشكل مثالي بسهولة.
• التنقل عبر العرض الجانبي للمتصفح

للحصول على وصف أكثر تفصيلاً لفوائد استخدام WebRocketX SPA، انتقل هنا

لماذا العاشر؟

WebRocketX هو نظام هجين. إنه حل يقع في منتصف الطريق بين العالم القديم لمواقع تحديث الصفحة الكاملة وحلول JSON JSMVC الحديثة، مثل Angular.

• مثل بنية الصفحة الكاملة، يتوقع WebRocketX أن يتضمن التخطيط القادم من الخادم البيانات. يختلف هذا عن بنية JSMVC حيث يتم تسليم البيانات بشكل منفصل عن التخطيط في كائنات JSON. ومع ذلك، يدعم WebRocketX JSON عند الحاجة، ولكنه ليس نموذجًا مركزيًا لـ JSON.
• مثل بنية JSMVC، يعد WebRocketX تطبيق ويب ذو صفحة واحدة (SPA) ويعتمد على مكالمات AJAX لإرسال البيانات وجلب طرق عرض جديدة.

أشياء رائعة أخرى حول WebRocketX

مكتوب تماما في جافا سكريبت باستخدام Jquery كواجهة برمجة تطبيقات للمتصفح، سيتم تشغيله على جميع المتصفحات الرئيسية وحتى على الأجهزة المحمولة.

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

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

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

ما ليس WebRocketX

ليس حلاً من جانب الخادم ، لأن مكونات الواجهة الأمامية (المتصفح) غير مقترنة بمكونات الذاكرة الخلفية (الخادم). العلاقة الوحيدة بين ما يتم تسليمه من الخادم وإطار عمل WebRocketX هي بعض الاصطلاحات البسيطة لتسليم HTML إلى المتصفح. تتيح هذه البنية المنفصلة للمطور حرية استخدام أي إطار عمل خلفي يرغب فيه مثل Django وRuby on Rails وSpring MVC وPhp وAsp وStruts وما إلى ذلك. يتم تسليم المحتوى من الخادم بتنسيق HTML وإرساله من WebRocketX كمعلمات نموذج. الأمر بهذه البساطة.

ليس حل CSS أو التخطيط . إنها واجهة برمجة تطبيقات للتخزين المؤقت للمحتوى وتسليمها مصممة لتحويل تطبيق الويب الديناميكي الخاص بك بسهولة إلى SPA. يتمتع المطور بالحرية في تخطيط تطبيق الويب الخاص به بالطريقة التي يريدها. لا يشير شكل ومظهر موقع المعلومات هذا إلى الشكل الذي سيبدو عليه موقع الويب الخاص بك عند استخدام WRX.

غير متوافق مع تحسين محركات البحث (SEO) للمواقع الثابتة . إن استخدام WRX للمواقع الثابتة هو في المقام الأول استخدام مفاهيمي فقط ولسوء الحظ فإن محركات البحث ليست جاهزة لفهرسة مواقع SPA. لا يتوافق أي من أطر عمل الصفحة الواحدة مثل React أو Angular أو Vue مع تحسين محركات البحث، باستثناء الصفحات المقصودة الخاصة بها. من ناحية أخرى، يعد WRX مناسبًا جدًا لتطبيقات الويب الديناميكية، وخاصة المواقع التي تتطلب من المستخدم تسجيل الدخول لإدارة أي نوع من الحسابات أو الأعمال.

إذا كنت تحب WebRocketX. أعطنا نجمة هنا في جيثب. شكرًا!

تثبيت تطبيق الصفحة الواحدة الخاص بك

قم بإنشاء صفحة مقصودة/ترحيبية كما هو موضح أدناه وقم بتضمين المكتبات التالية فيها. من الأفضل عادة العثور على الصفحة المقصودة خلف صفحة تسجيل الدخول الخاصة بالنموذج. بمعنى آخر، تقوم بإعادة توجيه المستخدم إليه بعد تسجيل الدخول. كل شيء ما عدا مكتبة jquery متاح في مجلد التعليمات البرمجية المصدر لجذر WebRocketX الموجود أعلاه.

jquery[latest version].js including the draggable library from jquery UI
domUtil.js
desktopContext.js
webapi.js
webRocketXStyles.css

مثال HTML بسيط لتطبيق ويب ديناميكي ذو صفحة واحدة (SPA)

يمكن العثور على قوالب أمثلة قابلة للتشغيل لـ PHP و Django في مجلد القوالب في الكود المصدري.

الصفحة المقصودة/الترحيبية

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

 <!DOCTYPE html >

< html >
    < head >
                
        < title > Welcome </ title >

         <!-- The jquery UI library should include draggable if you want to implement draggable modals-->
        < script language =" javascript " type =" text/javascript " src =" javascripts/jquery/jquery-ui-1.11.4.custom/external/jquery/jquery-1.12.4.min.js " > </ script >
        
        < script language =" javascript " type =" text/javascript " charset =" iso-8859-1 " src =" javascripts/webRocketX/v1_10_1/domUtil.js " > </ script >
        < script language =" javascript " type =" text/javascript " charset =" iso-8859-1 " src =" javascripts/webRocketX/v1_10_1/desktopContext.js " > </ script >
        < script language =" javascript " type =" text/javascript " charset =" iso-8859-1 " src =" javascripts/webRocketX/v1_10_1/webapi.js " > </ script >
        < link rel =" stylesheet " type =" text/css " href =" javascripts/webRocketX/v1_10_1/webRocketXStyles.css " >
        
        < script type =" text/javascript " >           
            var asyncDebugMode = true ;
            var signInPageURI = "" ;
            var pageLoadTimeStamp = "" ;
            var modalTargetSpacing = 10 ;
            var staticPage = false ;
            var disableNavigation = false ;
        </ script > 

        < link rel =" stylesheet " type =" text/css " href =" styles/demo/styles.css " >
        < link rel =" stylesheet " type =" text/css " href =" styles/demo/menu.css " >
        < meta name =" viewport " content =" width=device-width " >    
    </ head >
    
    < body >             
    
        <!-- header -->        
        < table class =" bodytext " >        
            < tr >
                < td width =" 20 " > </ td >                    
                < td >
                    My Header                    
                </ td >
                < td width =" 20 " > </ td >                
            </ tr >
            
            < tr >
                < td width =" 20 " > </ td >                    
                < td class =" menuBar " >
                    < div id =" menu " > </ div >                        
                </ td >
                < td width =" 20 " > </ td >
            </ tr >
            
        </ table >
        
        < div id =" errorSpan " style =" color:red;text-align:center; " > </ div >
                
        < div id =" winMain " class =" startingTarget bodytext " >
            
            <!-- Unused or default capsule attributes do not need to be included.  They are just included here for teaching purposes. -->
            < div id =" welcome " class =" metaCapsule " capsuleType =" inline " targetId =" winMain " jsOnload ="" reloadPage =" false " saveOriginalRequest =" false " saveResponse =" false " trackPage =" true " windowTitle =" welcome " errorPage =" false " >
                Hello World
                < br /> < br />
                < a href =" # " onclick =" test1();return false; " > Test1 </ a >
            </ div >
                                                        
        </ div >
       
        <!-- footer -->     
        < table class =" bodytext " >        
            < tr >
                < td width =" 20 " > </ td >                    
                < td class =" menuBar " style =" padding: 10px 10px 10px 10px; " >
                    Powered By&nbsp;&nbsp; < a target =" _blank " href =" http://www.webrocketx.com " style =" text-decoration: none; " > < span style =" color:black;background-color:white;font-weight:bold; " > &nbsp;WebRocket </ span > < span style =" color:red;background-color:white;font-weight:bold; " > X&nbsp; </ span > </ a >                     
                </ td >
                < td width =" 20 " > </ td >                
            </ tr >                       
        </ table >
                
        < div id =" communicationErrorAlertWrapper " style =" display:none; " >
                                                               
            < div id =" communicationErrorAlert " class =" metaCapsule " capsuleType =" modal " >
                < div id =" dialogLayer " class =" BDT_Dialog_Layer " >
                    < div class =" BDT_Dialog_Center " >
                        < div class =" BDT_Dialog_Decoration " >                    
                            < table class =" expand " >
                                < tr >
                                    < td >
                                        < div id =" communicationErrorMessage " > </ div >
                                        < br /> < br />
                                        < a href =" # " onclick =" $('#communicationErrorAlertWrapper').hide(); return false; " > Ok </ a >                            
                                    </ td >
                                </ tr >                            
                            </ table >                          
                        </ div >
                    </ div >
                </ div >
            </ div >
                 
        </ div >               
        
    </ body >

</ html >

مثال للصفحة المحقونة

هذه الصفحة سوف تحل محل المحتوى الرئيسي. سنضعه في ملف يسمى test1.html. يتم تغليف المحتوى في كبسولة (علامة div) تم تكوينها باستخدام سمات XML لبيانات التعريف. البيانات الوصفية هي نوع من البرمجة التعريفية التي يستخدمها إطار العمل لتحديد ما يجب فعله بالمحتوى الخاص بك.

 < div id =" test1 " class =" metaCapsule " capsuleType =" inline " targetId =" winMain " windowTitle =" Test 1 " >
    Hello World Test 1.
</ div >

مثال على وظيفة جافا سكريبت

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

 function test1 ( ) {
    var successfulCallback = function ( innerHTMLObject ) {                        
       alert ( "this my callback" ) ;              
    }
        
    var webapi = new Webapi ( ) ;
    webapi . setSuccessCallbackReference ( successfulCallback ) ;    
    webapi . setUrl ( "test1.html" ) ;
    webapi . submitAsync ( ) ;    
}

هل يمكن أن يصبح الأمر أكثر بساطة؟

قائمة كاملة بسمات الكبسولة المتوفرة في وضع تطبيق الويب الديناميكي

تسمح بنية كبسولة WebRocketX للمطور بالتحكم في الكثير من سلوك العرض بشكل تصريحي.
تظهر أدناه جميع سمات الكبسولة الممكنة. سيعطيك هذا فكرة عن الكثير من وظائف أطر العمل، وكيف تغطي غالبية حالات استخدام تنقل المستخدم.

سيتم تعيين السمات غير المدرجة في الكبسولة على قيمها الافتراضية. يتم تمييز السمات المطلوبة بعلامة النجمة*.

• المعرف* - يُستخدم لتتبع الصفحة في إطار عمل WebRocketX. تم ترحيله من خلال معلمة CapsuleId في مثال القالب. استخدام القوالب غير مطلوب.
  
  
• class* - يجب ضبطها على القيمة "metaCapsule". يستخدمه الإطار لتحديد موقع الكبسولة div.
  
  
• نوع الكبسولة* - يمكن ضبطها على القيم الأربع التالية، والتي تحدد كيفية حقن الكبسولة وما إذا كان سيتم حقنها.
  
  
  • مضمّن - سيتم إدراج المحتوى في القسم المحدد بواسطة سمة targetId.
    
    
  • مشروط - سيتم حقن المحتوى في طبقة مشروطة عائمة.
    
    
  • البيانات - لن يتم تتبع المحتوى للتنقل بواسطة إطار العمل. يمكن للمطور أن يقرر ما إذا كان سيحدد معرف الهدف أو يضع المحتوى بنفسه، أو حتى يستخدم المحتوى دون وضعه في الصفحة. سيتم إرجاع المحتوى إلى المطور في رد الاتصال، كمعلمة أولى، في شكل كائن DOM للكبسولة ومحتوياتها المضمنة. هذا هو نوع الكبسولة المثالي الذي يمكن استخدامه للأجزاء الصغيرة القابلة للتحديث من الصفحة والتي لا يتم التنقل فيها كصفحات كاملة. على سبيل المثال، نتائج البحث، والمؤشرات، وما إلى ذلك.
    
    
  • json - ما عليك سوى عرض نص json في جانب خادم الكبسولة وسيتم تسليمه في رد الاتصال من جانب المتصفح الذي تم تحويله بالفعل إلى كائن json. يمكن إرسال معلمات json إلى الخادم عن طريق تعيين قيمة المعلمة إلى سلسلة json باستخدام كائن AsyncParametersList.
    
    
• targetId (*مطلوب إذا كان CapsuleType مضمنًا) - يحدد الموقع الذي سيتم فيه إدخال html الوارد، عندما يكون نوع الكبسولة "مضمنًا".
  
  
• jsOnload - يحدد طريقة جافا سكريبت التي سيتم استدعاؤها عند اكتمال الحقن. مفيد جدًا لتسجيل عمليات الإكمال التلقائي ومكونات واجهة المستخدم jquery وأي نوع آخر من عمليات نوع تحميل الصفحة. يتم دائمًا إرسال مؤشر الكبسولة التي تم الإعلان عن وظيفة jsOnload فيها كمعلمة واحدة إلى وظيفة js الخاصة بك.
  
  
• jsReturn - يحدد طريقة جافا سكريبت التي سيتم استدعاؤها عند إرجاع هذه الصفحة إليها ولكن لا يتم إعادة تحميلها. يمكن أن يتم تشغيل العودة إلى الصفحة باستخدام زر الرجوع أو استدعاء dtSetCapsuleById. تكون هذه الآلية مفيدة عندما يرغب المطور في تحديث جزء من العرض، أو تشغيل أي تعليمات برمجية أخرى، عند العرض إما بشكل مشروط أو غير مشروط. وبما أن التطبيق يعمل في صفحة واحدة، فيمكن نقل الشروط بين الصفحات كمتغيرات عامة. يتم دائمًا إرسال مؤشر الكبسولة التي تم الإعلان عن وظيفة jsReturn فيها كمعلمة واحدة إلى وظيفة js الخاصة بك.
  
  
• reloadPage (افتراضي: false) - عندما يكون هذا صحيحًا، سيؤدي الانتقال إلى هذه الصفحة في حزمة المتصفح إلى استرداد نسخة جديدة من هذا المحتوى من الخادم. ستتم إعادة إرسال الطلب الأصلي، بكل معلماته الأصلية، وسيتم استدعاء أسلوب رد الاتصال الأصلي.
  
  
• SkipReloadPageOnPrevious (افتراضي: false) - عندما يكون هذا صحيحًا، فإن التنقل من هذه الصفحة إلى صفحة في حزمة المتصفح التي تم وضع علامة إعادة التحميل عليها سوف يمنع تلك الصفحة الوجهة من إعادة التحميل. يعد هذا مفيدًا بشكل خاص في السماح للمطور بالتحكم فيما إذا كانت التدفقات الخلفية المختلفة إلى صفحة إعادة التحميل ستؤدي إلى إعادة التحميل أم لا. على سبيل المثال، غالبًا ما يكون من غير المرغوب فيه إعادة تحميل صفحة الخلفية هذه من أحد الوسائط عند العودة إلى صفحة الخلفية. ومع ذلك، قد يظل من المرغوب فيه إعادة تحميل صفحة الخلفية نفسها عند الانتقال إليها مرة أخرى من الصفحة التي حلت محلها.
  
  
• saveOriginalRequest (افتراضي: false) - عند التعيين على true، سيتم حفظ الطلب الأصلي حتى لو لم يكن هذا إعادة تحميل.
  
  
• saveResponse (الافتراضي: false) - عند التعيين على true، يتم تخزين كائن الاستجابة في قسم الكبسولة المحقونة. يمكن استخدام هذا لاحقًا لاستعادة المحتوى الذي تم إدخاله إلى حالته الأصلية بعد التعديلات التي أجراها المستخدم، عن طريق استدعاء RestoreAsyncResponse(id). الحالة الأكثر شيوعًا التي تكون فيها هذه الإمكانية مطلوبة هي عندما تحتوي الصفحة على زر إلغاء.
  
  
• TrackPage (افتراضي: true) - القيمة الافتراضية هي true مع تحديد أن هذه الصفحة موضوعة في المكدس الخلفي لمزيد من المرجع. هذا الإعداد غير مناسب لأنواع كبسولة البيانات وjson لأن هذه الأنواع غير قابلة للتنقل من البداية. يمكن للمطور تحديد عدم وضع هذه الصفحة في المكدس الخلفي عن طريق تعيين هذه السمة على خطأ. يعد تعيين TrackPage على false حلاً مثاليًا للصفحات التي لا تريد أن يعود المستخدم إليها ثم يعيد إرسالها، مثل صفحة "إنشاء". عندما يعود المستخدم إلى صفحة لم يتم تعقبها، فسوف يتخطاها ويهبط على الصفحة التي تم تعقبها التي تسبقها.
  
  
• windowTitle - يحدد العنوان الذي سيتم تعيينه في الجزء العلوي من المتصفح. ضروري لأننا لا نغير الصفحات مطلقًا وبالتالي لا نقوم أبدًا بتحديث علامة العنوان في رأس html.
  
  
• errorPage - يضع علامة على هذه الصفحة كاستثناء مكتوب مما سيؤدي إلى تخطي رد الاتصال الناجح الذي حدده المطور واستدعاء رد الاتصال الفاشل الذي حدده المطور.
  
  

فوائد إنشاء تطبيق Django ذو الصفحة الواحدة (SPA)

على الرغم من أن SPA تُعادل عادةً إطار عمل جافا سكريبت ثقيل من جانب العميل مقترنًا بخدمات json، إلا أنه لا يزال من الممكن جدًا الحصول على فوائد SPA مع الاستمرار في تقديم جانب خادم HTML، من خلال إطار عمل جافا سكريبت SPA الخفيف الخاص بنا.

• مزايا الطلب الصغير في صيانة حالة واجهة المستخدم - تحديث جزء فقط من الصفحة يعني أنه لا يلزم سحب الصفحة بأكملها في كل مرة. يجب فقط استرداد مقتطف html أو كائن json من الخادم. وهذا يجعل مهمة مطور واجهة المستخدم أسهل كثيرًا لأنه لا يتعين عليه القيام بأشياء مثل وضع قالب الرأس والقائمة والتذييل في كل صفحة أو القلق بشأن حالة البيانات الأخرى في أجزاء الصفحة خارج منطقة التحديث. حتى إدخالات المستخدم التي لم يتم الالتزام بها للخادم تكون آمنة طالما أنها خارج المنطقة المحدثة. يختفي الكثير من آلام تطوير واجهة المستخدم مع الطلبات الصغيرة.
  
  
• مزايا الطلبات الصغيرة في الخدمات - نظرًا لأنه يتم استرداد الأجزاء المستهدفة فقط من الصفحة، تصبح البيانات المطلوبة في هذه الأماكن أكثر تحديدًا. وهذا يقلل من منطق الأعمال المطلوب في الخدمات، مما يبسط أيضًا الاسترجاع من التطبيقات الخارجية مثل قواعد البيانات والخدمات السحابية.
  
  
• تخزين المزيد من الحالة في المتصفح - يؤدي الجمع بين طرق عرض التخزين المؤقت وتحديث أجزاء فقط من الصفحة إلى استمرار حالة أكبر بكثير في المتصفح. لذلك، لن يحتاج المطور إلى القيام بالعديد من الرحلات إلى الخادم للحصول على هذه الحالة الموجودة بالفعل. هذه فائدة عظيمة حتى في أشياء بسيطة مثل إرسال النموذج، لأنه عندما يرفض الخادم إدخال المستخدم المقدم، فإن الصفحة التي تحتوي على النموذج تستمر ببساطة في جانب العميل مع بقاء جميع مدخلات المستخدم الخاصة بها موجودة. لم نفقد الصفحة أبدًا. من ناحية أخرى، فإن النموذج المرفوض عند تحديث الصفحة بالكامل سيفقد كل مدخلات المستخدم، نظرًا لأن المتصفح بصدد عرض الصفحة التالية وستختفي صفحة النموذج. لذلك، في عملية إرسال النموذج المرفوض لتحديث الصفحة بالكامل، يجب إرسال الإدخال إلى الخادم وإعادة عرضه، وإعادة عرض النموذج بأكمله واستعادة إدخال المستخدم غير المستمر. ستتم استعادة معلمات النموذج من الطلب ولكن ليس من قاعدة البيانات لأن الإرسال كان غير صالح لذا لم تصل البيانات إلى هذا الحد. إذا كنت لا تهتم بالمستخدمين لديك، فيمكنك أن تظهر لهم رسالة خطأ وتجعلهم يكتبون كل شيء مرة أخرى، وهو ما يحدث في بعض الأحيان وغير ودي على الإطلاق. في حالة تطبيق Django ذو الصفحة الواحدة، باستخدام الطلبات الصغيرة، لم يتم ترك الصفحة مطلقًا في البداية، ولنا الحرية في إرسال رسالة خطأ كمربع حوار مشروط عائم.
  
  
• التنقل في العرض المنظم - يمكن التنقل في العروض المقدمة مسبقًا باستخدام معرفات العرض الخاصة بها. باستخدام سمات الكبسولة، يمكن تحديد طرق العرض على أنها قابلة للتخزين المؤقت أو إعادة التحميل القسري (بحيث لا تصبح قديمة).
  
  
• التحكم في تفاعل المستخدم - هل سبق لك أن واجهت مشكلات مع ضغط المستخدم على الزر مرتين؟ لن يحدث هذا النوع من المشاكل بعد الآن لأن WebRocketX يضع طبقة شفافة فوق واجهة المستخدم أثناء الرحلات ذهابًا وإيابًا إلى الخادم مما يمنع تفاعل المستخدم. يُظهر الإطار أيضًا مؤشر ساعة رملية لطيفًا لإعلام المستخدم بحدوث شيء ما.
  
  
• معالجة الأخطاء المنظمة - يمكن أن تشكل الأخطاء من جانب الخادم ومهلة الجلسة مشكلة حقيقية عندما يتوقع المطور أن يأتي التخطيط أو البيانات من رد اتصال غير متزامن. يعمل WebRocketX على توحيد معالجة الأخطاء وسلوك مهلة الجلسة بحيث لا يحدث أي شيء غير متوقع. يتم فحص جميع الاستجابات مسبقًا قبل إرسال رد الاتصال إلى رد اتصال المطور لمعالجة أي مشكلات. يتم توفير الخطافات أيضًا للسماح للمطور بتحديد السلوك المخصص لفشل رد الاتصال.
  
  

تفضّل بزيارة موقعنا الإلكتروني لمزيد من التفاصيل والوثائق

قم بزيارة ويب روكيت اكس