डेटाबेस में AJAX संपादन करते समय, क्या मुझे नए डेटा

Question

के साथ इंटरफ़ेस तुरंत अपडेट करना चाहिए I AJAX के साथ डेटाबेस में टेक्स्ट अपडेट करने के लिए इनलाइन-एडिट का उपयोग कर रहा हूं। यह मूल रूप से प्रक्रिया है, बहुत सामान्य सामान:

• पाठ संपादन योग्य
• मैं पाठ क्लिक करें, यह संपादन योग्य
• मैं नया टेक्स्ट टाइप
• तो करने के लिए अद्यतन पाठ भेजने के लिए क्लिक करें हो जाता है नहीं है डेटाबेस
• तो गैर संपादन योग्य प्रारूप

मेरा प्रश्न जब मैं नए डेटा से इंटरफ़ेस अद्यतन करना चाहिए है के लिए पाठ वापसी? क्या मुझे AJAX कॉल से पहले इसे तुरंत अपडेट करना चाहिए, या मुझे डेटाबेस से वापस आने के लिए अद्यतन प्रतिक्रिया की प्रतीक्षा करनी चाहिए?

मेरी चिंता का विषय:

• मैं इंटरफ़ेस तुरंत अद्यतन नहीं करते हैं और डेटाबेस से प्रतिक्रिया प्राप्त करने के लिए प्रतीक्षा करने के बाद मैं अतुल्यकालिक लाभ यह है कि ajax के साथ आता है खो दिया है।
• लेकिन अगर मैं इसे तुरंत अद्यतन करता हूं, तो यदि डेटाबेस प्रतिक्रिया में कोई त्रुटि है, तो मुझे किसी भी तरह से पहले से किए गए परिवर्तन को ट्रैक करना होगा, और इसे उलट दें, जो बहुत अधिक काम है।

तो इस तरह की चीज आमतौर पर कैसे होती है?

Answer 1

मुझे लगता है कि कॉलबैक के परिणामस्वरूप प्रतिक्रिया और अद्यतन की प्रतीक्षा करना पूरी तरह से उचित है। ऐसा करने से एसिंक दृष्टिकोण से अलग नहीं होता है। यह अभी भी पूरी तरह से async है क्योंकि आप पूरे पृष्ठ को अवरुद्ध नहीं कर रहे हैं या इसे पूरी तरह से पुनः लोड कर रहे हैं।

ऐप्स में कई बार, विशेष रूप से मोबाइल में जहां बैंडविड्थ सीमित हो सकता है, मुझे एक स्पिनर दिखाई देगा जो दर्शाता है कि फ़ील्ड सबमिट हो रहा है। यह ऐप का कोई अन्य हिस्सा नहीं रखता है। जब भी मैं मोबाइल व्यू का उपयोग करता हूं तब भी स्टैक ओवरफ्लो ऐसा करता है। Async रहने के लिए कॉलबैक पर निर्भर करें और अभी भी डेटाबेस रिटर्न मानों के साथ समन्वयित हो।

Answer 2

पाठ्यक्रम के नेटवर्क मुद्दों को छोड़कर AJAX कॉल बहुत तेज़ हैं। व्यक्तिगत रूप से, मुझे नहीं लगता कि आप डेटाबेस से प्रतिक्रिया की प्रतीक्षा करके AJAX का लाभ खो देंगे। यही है, जब तक कि आप सर्वर-साइड प्रोसेसिंग आदि के कारण धीमे होने की योजना बनाते हैं ...

अब यदि आप टेक्स्टफील्ड को एक गैर-संपादन योग्य स्थिति में सेट करना चाहते हैं, तो उपयोगकर्ता सोच सकता है कि उसका परिवर्तन स्वीकार कर लिया गया है और जब सर्वर एक त्रुटि देता है और मूल्य को मूल स्थिति में वापस कर दिया जाता है तो भ्रमित हो जाएगा। मैं सर्वर लौटने तक फ़ील्ड संपादन योग्य छोड़ दूंगा।

Answer 3

यदि आप jQuery का उपयोग कर रहे हैं तो यह बहुत आसान है, लेकिन यदि आप अपने होमब्री AJAX कॉल स्क्रिप्ट का उपयोग कर रहे हैं तो आपको यह देखने के लिए कुछ तंत्र जोड़ना होगा कि सब कुछ अच्छा या बुरा हो गया है या नहीं।

$.ajax({ 
url: '/ajax/doSomething.php', 
type: 'POST', 
dataType: 'json', 
data: { 
    'q': $("#editableText").val() 
}, 
success: function(json) { 
    $("#editableText").html(json.value); 
}, 
error: { 
    alert('something went wrong!'); 
} 
}) 

तो जब आपका doSomething.php सत्य या गलत लौटाता है, तो हमारे AJAX कॉल इसके अनुसार कुछ करते हैं।

हाँ AJAX कॉल बहुत तेज़ हैं, लेकिन पृष्ठ पर प्रदर्शित डेटा को बदलने से पहले मुझे लगता है कि आपको यह सुनिश्चित करना होगा कि सब कुछ ठीक हो गया है, अन्यथा उपयोगकर्ता यह जाने बिना पृष्ठ छोड़ सकता है कि उन्होंने संपादन किया है या नहीं।

Answer 4

आपके द्वारा वर्णित मामला एक आशावादी यूआई अपडेट है। इस मामले में आप मान रहे हैं (implictly) कि अद्यतन बिना किसी त्रुटि के सर्वर पर किया जाएगा।

इस दृष्टिकोण को नुकसान एक इस परिदृश्य पर

1. उपयोगकर्ता को भी संपादित पाठ पर क्लिक करता है के साथ होगा
2. पाठ नए पाठ में संपादन योग्य
3. उपयोगकर्ता प्रकार हो जाता है
4. उपयोगकर्ता क्लिक करता है
भेज
5. यूआई नए पाठ में बदलता है और इसे अयोग्य बनाता है
6. उपयोगकर्ता ब्राउज़र विंडो को बंद करता है (या दूर से नेविगेट करता है पृष्ठ) उत्तर देने से पहले कभी वापस आता है (माना जाता है कि परिवर्तन किया गया था)
7. अगली बार जब उपयोगकर्ता लॉग इन करता है (या पृष्ठ पर वापस आता है) तो वे उलझन में हैं कि परिवर्तन क्यों लागू नहीं हुआ!

हालांकि आप भी ajax के अतुल्यकालिक प्रकृति का उपयोग करें और सुनिश्चित करें कि उपयोगकर्ता अब भी अपने ऐप (या शेष पृष्ठ) के साथ बातचीत कर सकते हैं के रूप में इस परिवर्तन का प्रदर्शन किया जा रहा है बनाना चाहते हैं।

जिस तरह से हम है कि (मेरे काम की जगह पर) आम तौर पर किया जाएगा

1. उपयोगकर्ता को भी संपादित पाठ
2. पाठ संपादन योग्य
हो जाता है साथ सूचना का आदान (लंबी मतदान या http धक्का उपयोग करते हुए) करना नया पाठ में
3. उपयोगकर्ता प्रकार
4. उपयोगकर्ता क्लिक के पाठ को अद्यतन करने के बजाय
5. भेज आशावादी हम स्पिनर (केवल पाठ पर) किसी तरह का पता चलता है कि उपयोगकर्ता है कि हम फिर से किसी तरह का इंतज़ार कर रहे हैं करने के लिए इंगित करता है सर्वर से sponse। ध्यान दें कि चूंकि हम केवल पृष्ठ के उस हिस्से को अक्षम कर रहे हैं जो इस पाठ को दिखाता है, उपयोगकर्ता को शेष पृष्ठ के साथ बातचीत करने के लिए AJAX कॉल को वापस लौटने की प्रतीक्षा नहीं करनी पड़ती है। (वास्तव में हमारे पास कई मामले हैं जो समानांतर में पृष्ठ के कई हिस्सों को अपडेट करने का समर्थन करते हैं)। जीमेल के बारे में सोचें जहां आप ब्राउज़र विंडो में किसी के साथ चैट कर रहे हों और साथ ही आपको एक ईमेल प्राप्त हो। चैट चालू हो सकती है और ईमेल काउंटर भी बढ़ता जा रहा है। वे दोनों एक ही पृष्ठ पर हैं लेकिन एक-दूसरे पर निर्भर नहीं हैं (या किसी अन्य तरीके से एक दूसरे के लिए प्रतीक्षा करें)
6. जब अद्यतन पूरा हो जाता है तो हम स्पिनर को ले जाते हैं (जिसे आमतौर पर सीएसएस - टॉगल क्लास का उपयोग करके दिखाया जाता है) और तत्व के मान को नए टेक्स्ट से प्रतिस्थापित करें।

आखिरकार यदि आप ऐसा कुछ कर रहे हैं तो सुनिश्चित करें कि आपके सर्वर को टेक्स्ट फ़ील्ड में लंबित कक्षा जोड़ने के लिए भी समर्थन है (जिससे स्पिनर दिखाई देगा)। यह निम्न कारणों से

1. उपयोगकर्ता अपडेट पाठ के लिए किया जाता है और प्रस्तुत
2. उपयोगकर्ता तुरंत एक भिन्न पृष्ठ पर जाने है
3. उपयोगकर्ता उसके बाद फिर से मूल पृष्ठ पर वापस आ जाता है (और हमें लगता है कि अद्यतन नहीं है चलो अभी तक पूरा)
4. चूंकि आपका सर्वर जानता है कि फ़ील्ड अपडेट किया जा रहा है और लेबल/डिस्प्ले फ़ील्ड में लंबित सीएसएस क्लास जोड़ सकता है, पृष्ठ एक स्पिनर के साथ लोड हो जाता है।
5. अंत में जब लंबे poller संदेश सर्वर से वापस आता है स्पिनर से हटा लिया जाता है और वर्तमान मूल्य