Ajax: Interaktiviti yang boleh digunakan dengan skrip jauh

Jika penanda halaman anda mengandungi satu blog pembangunan web, anda pasti akan mengetahui bahawa skrip jauh sedang disebut -sebut sebagai "Masa Depan Web" yang baru.

walaupun saya mendapat perasaan bahawa beberapa orang mungkin sedikit terlalu teruja mengenainya, pelepasan baru-baru ini aplikasi web berprofil tinggi yang menggunakan skrip jauh telah menunjukkan bahawa terdapat kelebihan yang pasti untuk menggunakan teknik-teknik ini dalam penciptaan aplikasi web yang lancar, dan untuk menambah fungsi laman web.

Artikel ini bertujuan untuk memberi anda pengenalan kepada asas -asas skrip jauh, khususnya, protokol XMLHTTPREQUEST yang muncul. Kami kemudiannya akan melalui aplikasi contoh yang menunjukkan cara melaksanakan protokol itu, sambil mewujudkan antara muka yang boleh digunakan.

Untuk memulakan, muat turun Arkib Kod, yang mengandungi semua fail yang anda perlukan untuk membuat contoh kerja yang dibentangkan di sini.

Takeaways Key

Ajax dan skrip jarak jauh meningkatkan aplikasi web dengan membenarkan pertukaran data dengan pelayan tanpa perlu menyegarkan laman web, yang membawa kepada pengalaman pengguna yang lebih lancar dan lebih interaktif.

xmlhttprequest adalah komponen penting dalam Ajax, yang membolehkan pengambilan data dari pelayan secara asynchronously, dengan itu menghalang laman web dari pembekuan semasa pengambilan data.
Pengendalian ralat yang betul dan pertimbangan aksesibiliti adalah penting apabila melaksanakan AJAX untuk memastikan semua pengguna, termasuk mereka yang kurang upaya atau teknologi penyemak imbas yang lebih tua, boleh mengakses kandungan dengan berkesan.
• Penciptaan objek XMLHTTPREQUEST bervariasi di seluruh pelayar, yang memerlukan mekanisme sandaran untuk keserasian, terutama dengan versi Internet Explorer yang memerlukan ActiveX untuk fungsi Ajax.
• Aplikasi AJAX mesti mengendalikan data dengan selamat untuk melindungi terhadap kelemahan web yang sama seperti skrip lintas tapak (XSS) dan pemalsuan permintaan lintas tapak (CSRF), menekankan pentingnya amalan pengekodan selamat.
• Debugging Ajax boleh menjadi kompleks kerana sifatnya yang tidak segerak, tetapi alat pembangunan moden dalam pelayar dapat membantu pemantauan dan penyelesaian masalah AJAX dan respons dengan berkesan.
• apakah skrip jauh?
• Pada dasarnya, skrip jauh membolehkan JavaScript sisi klien untuk meminta data dari pelayan tanpa perlu menyegarkan halaman web. Itu sahaja. Segala -galanya yang masuk ke dalam membuat aplikasi web yang lancar menarik pada kaedah yang ditetapkan untuk memanipulasi model objek dokumen. Ini mungkin sesuatu yang semudah membuat senarai perkataan untuk dipilih, seperti yang dicadangkan oleh Google. Atau ia boleh melibatkan penciptaan keseluruhan antara muka untuk menavigasi dan mengezum imej peta, seperti itu di peta.search.ch.
Walau bagaimanapun, bersama -sama dengan keupayaan untuk mencipta pengalaman web baru, skrip jauh memberi kita keupayaan untuk membuat pengalaman web yang tidak dapat digunakan baru. Aplikasi skrip jauh dan lancar membawa mereka pelbagai masalah dari Realm Design Application Desktop, menjadikan isu -isu yang sama mungkin di web. Adalah tugas anda untuk memastikan bahawa antara muka skrip jarak jauh anda menangani isu -isu tersebut, dan memberi pengguna pengalaman terbaik yang dapat mereka dapatkan.
skrip jauh dan aksesibiliti
Seperti mana -mana aplikasi dalam talian atau laman web, kita mesti sentiasa mengambil kira keperluan pengguna. Sesetengah pengguna mungkin mempunyai penyemak imbas yang kekurangan keupayaan JavaScript, atau, walaupun mereka boleh melaksanakan JavaScript, mereka mungkin tidak mempunyai keupayaan skrip jauh.

Ini adalah amalan terbaik yang diterima umum bahawa interaksi JavaScript dan fungsi skrip jauh menambah fungsi asas kandungan berasaskan web: Kandungan masih boleh diakses dan boleh digunakan tanpa teknologi ini. Dalam kes aplikasi web yang sepenuhnya, ia boleh diterima untuk menyediakan sistem yang sama sekali berbeza bagi pengguna yang tidak mempunyai keupayaan skrip JavaScript atau jauh. Pasukan di Gmail baru-baru ini melaksanakan bukan JavaScript, antara muka alternatif ke perkhidmatan.

skrip jauh menggunakan xmlhttprequest

Walaupun xmlhttprequest adalah

tidak

standard awam, pelayar yang paling moden melaksanakannya secara konsisten, dan ia dalam perjalanan untuk menjadi standard de facto untuk pengambilan data JavaScript. Internet Explorer 5 untuk Windows, Mozilla 1.0, Safari 1.2 dan versi 8.0 Opera yang akan datang semuanya memperkenalkan XMLHTTPREQUEST sebagai objek yang tersedia. API Internet Explorer XMLHTTPREQUEST tersedia untuk dimuat turun.

anda juga boleh memuat turun dokumentasi Mozilla.

Jika anda memerlukan sokongan untuk penyemak imbas yang lebih tua daripada ini, kaedah menggunakan iframes menyediakan penyelesaian yang berdaya maju; Walau bagaimanapun, pengekodan untuk penyemak imbas ini juga akan mengehadkan keupayaan anda untuk menggunakan kaedah DOM JavaScript standard. Artikel ini akan memberi tumpuan kepada kaedah XMLHTTPREQUEST yang lebih kontemporari.

Membuat objek XMLHTTPREQUEST

Untuk mana -mana penyemak imbas, kecuali Internet Explorer, kita boleh membuat objek XMLHTTPREQUEST seperti ini:

Walau bagaimanapun, di Internet Explorer, XMLHTTPREQUEST dilaksanakan sebagai objek ActiveX. Untuk IE, objek dicipta seperti ini:

var requester = new XMLHttpRequest();

NOTA: Ini juga bermakna bahawa jika pengguna mempunyai objek ActiveX yang dilumpuhkan di Internet Explorer, mereka tidak akan dapat menggunakan XMLHTTPREQUEST walaupun JavaScript diaktifkan.

var requester = new ActiveXObject("Microsoft.XMLHTTP");

Untuk mengatasi perbezaan sintaks penciptaan objek yang digunakan oleh pelayar ini, sebaiknya menggunakan struktur percubaan/menangkap untuk memberi anda objek yang betul, atau mengembalikan ralat jika objek XMLHTTPREQUEST tidak tersedia:

var requester = new XMLHttpRequest();

Syukurlah, perbezaan antara pelaksanaan berakhir di sana, dan semua kaedah berikutnya panggilan ke objek XMLHTTPREQUEST boleh dilakukan tanpa mengira penyemak imbas skrip yang berjalan masuk.

Mengangkut data menggunakan objek XMLHTTPREQUEST

Setelah objek XMLHTTPREQUEST telah dibuat, kita mesti memanggil dua kaedah berasingan untuk mendapatkannya untuk mendapatkan data dari pelayan.

var requester = new ActiveXObject("Microsoft.XMLHTTP");

try 

{ 

  var requester = new XMLHttpRequest(); 

} 

catch (error) 

{ 

  try 

  { 

    var requester = new ActiveXObject("Microsoft.XMLHTTP"); 

  } 

  catch (error) 

  { 

    return false; 

  } 

}

URL boleh sama ada relatif atau mutlak, tetapi disebabkan oleh kebimbangan keselamatan domain, sasaran mesti berada di domain yang sama seperti halaman yang memintanya.

Kaedah Terbuka () juga mengambil argumen Boolean ketiga pilihan yang menentukan sama ada permintaan itu dibuat secara asynchronously (benar, lalai) atau serentak (palsu). Dengan permintaan segerak, penyemak imbas akan membekukan, tidak membenarkan sebarang interaksi pengguna, sehingga objek selesai. Permintaan tak segerak berlaku di latar belakang, membolehkan skrip lain berjalan dan membiarkan pengguna terus mengakses penyemak imbas mereka. Ia disyorkan bahawa anda menggunakan permintaan tak segerak; Jika tidak, kami menghadapi risiko penyemak imbas pengguna mengunci semasa mereka menunggu permintaan yang berlaku. Open () argumen pilihan keempat dan kelima adalah nama pengguna dan kata laluan untuk pengesahan apabila mengakses URL yang dilindungi kata laluan.

Setelah dibuka () telah digunakan untuk memulakan sambungan, kaedah Send () mengaktifkan sambungan dan membuat permintaan. Hantar () mengambil satu hujah, membolehkan kami menghantar data tambahan, seperti pembolehubah CGI, bersama dengan panggilan. Internet Explorer memperlakukannya sebagai pilihan, tetapi Mozilla akan mengembalikan ralat jika tiada nilai diluluskan, jadi paling selamat untuk memanggilnya menggunakan:

open() initialises the connection we wish to make, and takes two arguments, with several optionals. The first argument is the type of request we want to send; the second argument identifies the location from which we wish to request data. For instance, if we wanted to use a GET request to access feed.xml at the root of our server, we'd initialise the XMLHttpRequest object like this:

Untuk menghantar pembolehubah CGI menggunakan kaedah Get Request, kita perlu mengikat pembolehubah ke dalam URL terbuka ():

requester.open("GET", "/feed.xml");

Untuk menghantar pembolehubah CGI menggunakan kaedah permintaan pos, pembolehubah CGI boleh dihantar ke kaedah hantar () seperti:

requester.send(null);

Sebaik sahaja kami memanggil Send (), xmlhttprequest akan menghubungi pelayan dan mengambil data yang kami minta; Walau bagaimanapun, proses ini mengambil masa yang tidak pasti. Untuk mengetahui apabila objek telah selesai mengambil data, kita mesti menggunakan pendengar acara. Dalam kes objek XMLHTTPREQUEST, kita perlu mendengar perubahan dalam pembolehubah siap sedia. Pembolehubah ini menentukan status sambungan objek, dan boleh menjadi yang berikut:

0 â € "Uninitialised
1 â € "Memuatkan
2 â € "dimuatkan
3 â € "Interaktif
4 â € "selesai
Perubahan dalam pembolehubah ReadyState boleh dipantau menggunakan pendengar OnreadyStatechange khas, jadi kami perlu menyediakan fungsi untuk mengendalikan peristiwa apabila siap sedia diubah:

var requester = new XMLHttpRequest();

var requester = new ActiveXObject("Microsoft.XMLHTTP");

try 

{ 

  var requester = new XMLHttpRequest(); 

} 

catch (error) 

{ 

  try 

  { 

    var requester = new ActiveXObject("Microsoft.XMLHTTP"); 

  } 

  catch (error) 

  { 

    return false; 

  } 

}

Walaupun objek XMLHTTPREQUEST membolehkan kita memanggil kaedah terbuka () beberapa kali, setiap objek benar -benar hanya boleh digunakan untuk satu panggilan, kerana acara OnreadyStateChange tidak dikemas kini sekali lagi apabila ReadyState berubah menjadi "4" (di Mozilla). Oleh itu, kita perlu membuat objek XMLHTTPREQUEST baru setiap kali kita ingin membuat panggilan jauh.

menghuraikan data dalam objek XMLHTTPREQUEST

Jika kami telah membuat permintaan yang berjaya, dua sifat objek XMLHTTPREQUEST mungkin mengandungi data:

ResponsxML menyimpan objek berstruktur dom mana-mana data XML yang diambil oleh objek. Objek ini boleh dilayari menggunakan kaedah dan sifat akses DOM JavaScript standard, seperti getElementsByTagName (), childnodes [] dan parentnode.
ResponseText menyimpan data sebagai satu rentetan lengkap. Jika jenis kandungan data yang dibekalkan oleh pelayan adalah teks/biasa atau teks/html, maka ini adalah satu -satunya harta yang akan mengandungi data. Salinan mana -mana data teks/XML akan diratakan dan diletakkan di sini sebagai alternatif kepada responsxml.
Bergantung pada kerumitan data, mungkin lebih mudah untuk mengembalikan data semata -mata sebagai rentetan teks biasa, dengan itu menjadikan XML dalam XMLHTTPREQUEST berlebihan. Walau bagaimanapun, untuk jenis data yang lebih kompleks, anda mungkin mahu menggunakan format XML, seperti ini:


xml version = "1.0"?>

        John Smith
        john@smith.com



Kami dapat mengakses bahagian -bahagian data yang berbeza menggunakan kaedah akses DOM standard. Ingatlah bahawa data yang terkandung di antara tag dianggap mewakili nod teks kanak -kanak ibu bapa, jadi kita perlu mengambil lapisan tambahan struktur itu apabila kita mengambil data:

open() initialises the connection we wish to make, and takes two arguments, with several optionals. The first argument is the type of request we want to send; the second argument identifies the location from which we wish to request data. For instance, if we wanted to use a GET request to access feed.xml at the root of our server, we'd initialise the XMLHttpRequest object like this:

kita juga harus berhati -hati tentang ruang putih: nilai indenting dalam fail XML boleh menghasilkan ruang putih yang tidak diingini dalam nilai, atau menambah nod teks tambahan.
Sebaik sahaja kami telah menghuraikan data dari objek XMLHTTPREQUEST, kami bebas menukar, memadam dan menulisnya ke laman web kami seperti yang kami lihat!

contoh aplikasi skrip jauh

Untuk menunjukkan cara menggunakan protokol XMLHTTPREQUEST di dalam aplikasi skrip jauh, saya telah mencipta contoh satu halaman yang mudah. Ia mengandaikan bahawa JavaScript dan XMLHTTPREQUEST tersedia untuk menjadikan kod itu lebih mudah dibaca, tetapi dalam mana-mana aplikasi dunia nyata, anda harus sentiasa memeriksa bahawa XMLHTTPREQUEST tersedia dan mempunyai sandaran (iaitu penyerahan bentuk biasa) di mana ia tidak.

Aplikasi contoh akan membolehkan pengguna menghantar Ecard percuma ke alamat e -mel rakan. Untuk melakukan ini, pengguna terlebih dahulu memasuki nombor resit, yang mereka terima apabila mereka membeli barangan sebelum ini, dan sejak itu telah disimpan dalam pangkalan data contoh. Kemudian, pengguna mesti melengkapkan medan yang tinggal sebelum Ecard dihantar, memasukkan alamat e -mel penerima, mesej, dan imej grafik yang akan digunakan untuk kad:



skrip jauh digunakan untuk tiga tindakan dalam contoh ini, kepada:




meminimumkan masa menunggu untuk pengesahan nombor resit
mengautomasikan kemasukan data yang diambil ke dalam borang sebaik sahaja nombor resit telah disahkan
Tulis semula kandungan halaman apabila Ecard telah dihantar dengan jayanya
Bersama dengan tindakan ini, contohnya mengandungi JavaScript, yang mengesahkan medan bentuk lain sebelum penyerahan, dan membolehkan pengguna memilih grafik Ecard.
Contohnya telah dibuat dalam dua versi berasingan. Yang pertama dari versi ini menunjukkan pelaksanaan protokol XMLHTTPREQUEST di dalam aplikasi, tetapi ia mengandungi beberapa masalah kebolehgunaan yang kurang dapat diwujudkan. Masalah ini ditangani dalam contoh kedua, yang bertujuan untuk menyerlahkan beberapa isu yang boleh ditemui semasa anda berpindah dari model aplikasi berasaskan halaman ke arah persekitaran yang lebih dinamik dan interaktif.

Contoh 1: Melaksanakan xmlhttprequest

Dalam aplikasi pelayan/klien tradisional, keseluruhan borang ECARD perlu dikemukakan kepada pelayan, diperiksa, dan dikembalikan kepada penyemak imbas sebelum pelanggan dapat dimaklumkan sama ada nombor resit mereka sah atau tidak. Dengan model skrip jauh, kami dapat menyemak nombor resit sebaik sahaja pengguna selesai berurusan dengan medan itu. Oleh itu, apabila pengguna mengemukakan borang, penyemak imbas telah mengenal pasti sama ada data itu sah atau tidak.

Langkah pertama dalam memeriksa data dari jauh adalah untuk mengetahui apabila pengguna telah memasukkan nilai ke dalam medan nombor resit. Ini dapat dikesan menggunakan pengendali acara onchange untuk bidang. "Perubahan" pada medan teks didaftarkan apabila pengguna mengubah nilai medan teks dan kemudian "mengaburkan" dari medan itu (iaitu tab atau klik daripadanya). Ini biasanya merupakan petunjuk yang baik bahawa pengguna telah selesai mengisi medan, dan data yang terkandung di dalamnya dapat diproses. Dengan menangkap acara Onchange ini, kami dapat memberitahu skrip kami untuk mula mengesahkan kandungan medan:

var requester = new XMLHttpRequest();

var requester = new ActiveXObject("Microsoft.XMLHTTP");

Anda mungkin mengenali beberapa sintaks itu dari bahagian pertama artikel ini, iaitu struktur percubaan/tangkapan bercabang, dan kaedah terbuka () dan hantar () yang mengawal objek XMLHTTPREQUEST.

try 

{ 

  var requester = new XMLHttpRequest(); 

} 

catch (error) 

{ 

  try 

  { 

    var requester = new ActiveXObject("Microsoft.XMLHTTP"); 

  } 

  catch (error) 

  { 

    return false; 

  } 

}

yang pertama jika pernyataan memeriksa untuk melihat sama ada objek XMLHTTPREQUEST sudah ada dan sedang berjalan; Jika ya, ia membatalkan sambungan itu. Ini memastikan bahawa beberapa panggilan XMLHTTPREQUEST yang bertentangan tidak dijalankan secara serentak, yang akan menyumbat rangkaian. Fungsi ini terus berlanjutan, untuk membuat objek XMLHTTPREQUEST baru dan buka sambungan ke skrip pengesahan sisi pelayan, resit.php.

Dalam resit.php, resit pembolehubah CGI diperiksa dan, jika nilainya adalah "1234567", beberapa data XML dikembalikan; Jika tidak, rentetan teks biasa "kosong" dikembalikan, menunjukkan bahawa nombor resit tidak sah:

var requester = new XMLHttpRequest();

Nilai dan data yang dikodkan keras telah digunakan dalam contoh ini untuk memudahkan kod, tetapi di dunia nyata, skrip PHP ini akan memeriksa nombor resit terhadap pangkalan data, dan mengembalikan data yang sesuai untuk nombor itu.

Perhatikan bahawa jika nombor resit tidak sah, tajuk kandungan yang dihantar adalah "Teks/Plain". Ini memudahkan proses percetakan mesej agak, tetapi ia juga bermakna bahawa, pada sisi klien, harta responsxML objek XMLHTTPREQUEST tidak akan mengandungi apa -apa. Oleh itu, anda harus sentiasa mengetahui apa skrip sisi pelayan anda kembali, dan memerhatikan responsxml atau responsetext dengan sewajarnya.
serta memanggil skrip sisi pelayan, onChangereCeipt () juga menyerahkan OnreadyStateChangereCeipt () untuk memantau status sambungan melalui acara OnreadyStateChange, dan ia adalah fungsi yang menentukan apabila sambungan selesai dan tindakan selanjutnya harus diambil. Untuk melakukan ini, kami menggunakan keadaan siap sedia/status yang dibincangkan sebelum ini:


Fungsi OnreadyStateChangereCeipt ()
{
 / * Jika objek XMLHR telah selesai mengambil data */
 jika (requester.readystate == 4)
 {
   / * Jika data diambil dengan jayanya */
   jika (permintaan.status == 200)
   {
     writedetails ();  
   }
   / * IE mengembalikan kod status 0 pada beberapa kesempatan, jadi abaikan kes ini */
   lain jika (permintaan.Status! = 0)
   {
     Alert ("Terdapat kesilapan semasa mengambil URL:" Requester.Statustext);  
   }
 }
 
 kembali benar;  
}


Apabila kod status yang berjaya dikembalikan, writedetails () dipanggil. Ia adalah fungsi ini yang mengutip data yang dikembalikan dan menentukan apa yang perlu dilakukan ke laman web:

var requester = new XMLHttpRequest();

Fungsi ini terlebih dahulu memeriksa harta responsetext objek XMLHTTPREQUEST, untuk melihat sama ada nombor resit adalah sah atau tidak. Jika ia sah, data akan berada dalam format XML dan watak pertamanya akan menjadi pendakap bersudut pembukaan (

Pelaksanaan writedetails () menandakan berakhirnya proses skrip jauh untuk pengesahan nombor resit. Dengan harta yang sah yang dilanjutkan di lapangan, penyemak imbas tahu sama ada data itu OK, dan boleh memberi amaran kepada pengguna sebarang kesilapan apabila mereka cuba menyerahkan borang:

var requester = new ActiveXObject("Microsoft.XMLHTTP");

Jika terdapat ralat dengan borang, dialog amaran () muncul apabila butang hantar diklik, meminta pengguna untuk membetulkan ralat sebelum borang diserahkan:



try 

{ 

  var requester = new XMLHttpRequest(); 

} 

catch (error) 

{ 

  try 

  { 

    var requester = new ActiveXObject("Microsoft.XMLHTTP"); 

  } 

  catch (error) 

  { 

    return false; 

  } 

}

open() initialises the connection we wish to make, and takes two arguments, with several optionals. The first argument is the type of request we want to send; the second argument identifies the location from which we wish to request data. For instance, if we wanted to use a GET request to access feed.xml at the root of our server, we'd initialise the XMLHttpRequest object like this:

Ini menghilangkan borang awal yang dibentangkan kepada pengguna, dan memasukkan mesej status akhir:

requester.open("GET", "/feed.xml");

Walaupun aplikasi ini menulis semula hampir seluruh halaman, mudah untuk melihat bagaimana bahagian-bahagian tertentu DOM dapat diubah menggunakan skrip jauh, yang akan membolehkan bahagian berasingan antara muka aplikasi untuk mengemas kini secara bebas dari laman web itu sendiri.

Contoh 2: Buat antara muka skrip jarak jauh yang boleh digunakan
Model skrip jarak jauh agak berbeza daripada interaksi berasaskan halaman standard yang meresap kebanyakan web, dan dengan perbezaan itu terdapat perangkap kebolehgunaan baru yang terlalu mudah diperkenalkan ke dalam projek anda. Perangkap ini biasanya timbul sama ada dari manipulasi dinamik antara muka semasa pengguna mengaksesnya, atau dari keperluan untuk mengakses data yang luar ke laman web.
Contoh 1 digunakan skrip jauh untuk mengesahkan nombor resit, dan secara automatik memasukkan data yang diambil dari pangkalan data; Walau bagaimanapun, tiada maklumat ini digunakan dengan baik, dan juga tidak jelas kepada pengguna apa yang sedang berlaku. Contoh 2 bertujuan untuk membetulkan kekurangan ini dan lain -lain dalam contoh pertama, dan menjadikan pengalaman lebih cepat, lebih mudah dan lebih mudah difahami untuk pengguna. Lima petua di bawah menerangkan beberapa perubahan yang boleh digunakan untuk menjadikan pengalaman buruk menjadi yang baik.

tip #1: Beritahu pengguna mengapa mereka menunggu

skrip jauh tidak seketika. Terlepas dari kelajuan sambungan web anda, masa komunikasi dengan sumber luaran akan berbeza -beza. Jadi, semasa komunikasi dengan pelayan berlaku, sangat penting bahawa anda memberitahu pengguna mengapa mereka menunggu. (Contoh skrip PHP menggunakan panggilan tidur () untuk menyerlahkan tempoh menunggu yang boleh disebabkan oleh trafik rangkaian atau faktor lain.)

Kerana aplikasi skrip jauh tidak membuat panggilan menggunakan antara muka penyemak imbas biasa, bar status - yang biasanya memberitahu pengguna status pemindahan dan aktiviti - tidak berfungsi seperti biasa, oleh itu, kita perlu memberi maklum balas kepada pengguna sendiri.

Dalam Contoh 2, sementara nombor resit disahkan, label memaparkan di sebelah medan nombor resit untuk menjelaskan tunggu.



perubahan label untuk menunjukkan siap sekali apabila sambungan XMLHTTPREQUEST selesai.

Mesej status dimulakan sebelum sambungan XMLHTTPREQUEST, apabila acara Onchange untuk medan nombor resit dicetuskan:

Setelah operasi skrip jauh selesai, mesej dikemas kini untuk memberitahu pengguna sama ada nombor resit adalah sah atau tidak:

var requester = new XMLHttpRequest();

Mengemas kini mesej untuk menunjukkan penyelesaian adalah penting, kerana ia memberikan penutupan bagi pengguna. Jika mesej pemuatan hanya hilang, pengguna tidak pasti bahawa ia telah berjaya.

var requester = new ActiveXObject("Microsoft.XMLHTTP");

Dalam dua sampel kod di atas, fungsi mesej adalah fungsi tersuai yang secara dinamik mencipta label status untuk elemen bentuk, dan meletakkannya secara visual bersebelahan dengan elemen yang berkaitan. Ia juga menerima kelas untuk label status, yang membolehkan gaya CSS digunakan secara berbeza untuk memuatkan, kesilapan dan mesej penyelesaian:

Walaupun proses XMLHTTPREQUEST sedang berjalan, label itu menghidupkan untuk menunjukkan bahawa tindakan itu berterusan dan masih hidup. Dalam Contoh 2, ini dilakukan melalui gaya CSS dengan GIF animasi, tetapi ia juga boleh dilaksanakan menggunakan animasi JavaScript.

try 

{ 

  var requester = new XMLHttpRequest(); 

} 

catch (error) 

{ 

  try 

  { 

    var requester = new ActiveXObject("Microsoft.XMLHTTP"); 

  } 

  catch (error) 

  { 

    return false; 

  } 

}

Ciri yang sama digunakan pada butang penyerahan borang. Sekali lagi, ini memberi amaran kepada pengguna bahawa beberapa tindakan sedang dijalankan, dan juga membolehkan mereka tahu bahawa mereka telah mengklik butang, yang akan membantu menghalang pengguna daripada menekan butang lebih daripada sekali:

Untuk mencapai matlamat ini, hanya tukar nilai dan kelas CSS butang hantar:

tip #2: Jangan mengganggu interaksi pengguna

open() initialises the connection we wish to make, and takes two arguments, with several optionals. The first argument is the type of request we want to send; the second argument identifies the location from which we wish to request data. For instance, if we wanted to use a GET request to access feed.xml at the root of our server, we'd initialise the XMLHttpRequest object like this:

Pengguna menjadi kecewa dengan antara muka yang mengganggu menyelesaikan tugas mereka. Dalam Contoh 1, gangguan tersebut mungkin berlaku selepas pengguna memasuki nombor resit: Jika mereka mula mengisi nama dan alamat e -mel mereka sebelum nombor resit telah disahkan, butiran tersebut akan ditimpa apabila data pengguna mereka diterima dari pelayan.

Untuk membetulkan ini, Contoh 2 memeriksa sama ada pengguna telah menukar nilai medan teks sebelum skrip memasuki sebarang data ke dalamnya. Nilai lalai medan teks dapat dikesan apabila halaman dimuat, dan direkodkan menggunakan sifat DOM tersuai:

var requester = new XMLHttpRequest();

Nilai lalai medan kemudian boleh diperiksa terhadap kandungannya sekarang sebelum skrip cuba menulis sebarang data ke dalamnya:

var requester = new ActiveXObject("Microsoft.XMLHTTP");

Ini memastikan bahawa pengguna-yang mungkin tahu namanya sendiri lebih baik daripada yang kita lakukan-tidak mempunyai entri yang ditimpa oleh automasi yang terlalu bersemangat.
Beberapa kes gangguan umum yang harus anda elakkan termasuk memindahkan kursor ke medan sementara pengguna mengisi medan lain, dan mengunci pengguna keluar dari antara muka (itulah sebabnya XMLHTTPREQUEST harus digunakan secara asynchronously).
tip #3: menangkap kesilapan awal, tetapi tidak terlalu awal

Adalah lebih baik untuk menangkap kesilapan sebaik sahaja ia berlaku. Banyak bentuk yang kini muncul di web bergantung kepada pengguna untuk menyerahkan borang sebelum sebarang ralat borang akan ditunjukkan, sama ada menggunakan skrip sisi pelayan atau peringatan JavaScript yang tidak masuk akal (seperti contoh 1). Kaedah ini mempunyai beberapa kelemahan untuk pengguna:

Proses mengemukakan borang mengambil masa pengguna.

JavaScript Alerts tidak menandakan semua bidang yang memerlukan pembetulan.
yang menunjukkan kesilapan dengan baik setelah mereka komited memerlukan pengguna untuk mengingati mental apa yang diminta oleh medan yang salah.
Walaupun pengguna tahu yang membentuk elemen untuk membetulkan, mereka perlu menghantar semula borang untuk mengetahui sama ada unsur-unsur tersebut telah diperbetulkan dengan betul.
• Atas sebab -sebab tersebut, lebih baik untuk memaklumkan pengguna tentang kesilapan sebaik sahaja mereka membuatnya. Dalam Contoh 2, jika pengguna memasuki alamat e -mel yang tidak sah, aplikasi itu memberitahu mereka dengan segera. Pemberitahuan diletakkan betul -betul di sebelah medan e -mel, menggunakan fungsi mesej () dari Petua #1:

Walau bagaimanapun, anda tidak boleh menyemak kesahihan sebaik sahaja pengguna mula menaip, kerana ia mengganggu - belum lagi menjengkelkan - diberitahu bahawa anda telah membuat ralat sebelum anda selesai memasukkan data. Pemeriksaan medan hanya perlu dilakukan sebaik sahaja pengguna telah memuktamadkan entri, iaitu, apabila mereka berpindah dari input. Untuk medan teks, tindakan jenis ini paling baik ditangkap menggunakan acara onchange:

var requester = new XMLHttpRequest();

Fungsi yang dicetuskan oleh acara itu kemudiannya boleh menyemak medan dan memastikan bahawa data yang terkandung itu adalah sah untuk jenis data tersebut:

var requester = new ActiveXObject("Microsoft.XMLHTTP");

tip #4: Biarkan pengguna tahu bila ralat telah ditetapkan

Sebaik sahaja medan telah didapati tidak betul, dan pengguna telah dimaklumkan kepada kesilapan itu, sama pentingnya untuk memberitahu pengguna apabila dia telah mengubahnya betul, jika tidak, pengguna akan terperangkap dalam kitaran penyerahan borang sekali lagi.

Dalam keadaan ini, ia tidak cukup baik untuk menunggu acara onchange penyemak imbas untuk api, kerana biasanya berlaku hanya apabila pengguna defokus elemen bentuk. Oleh itu, lebih baik menggunakan acara OnKeyup untuk memeriksa ketepatan bidang yang diketahui tidak betul:

try 

{ 

  var requester = new XMLHttpRequest(); 

} 

catch (error) 

{ 

  try 

  { 

    var requester = new ActiveXObject("Microsoft.XMLHTTP"); 

  } 

  catch (error) 

  { 

    return false; 

  } 

}

Fungsi OnKeyUpeMail () memeriksa sama ada medan e -mel mempunyai mesej ralat yang dipaparkan bersama -sama sebelum bergerak untuk memeriksa sama ada medan itu betul. Oleh itu, sebaik sahaja pengguna membuat pembetulan yang sesuai ke medan, mesej ralat akan hilang; Walau bagaimanapun, jika pengguna menaip ke medan untuk kali pertama, tiada mesej akan muncul:

open() initialises the connection we wish to make, and takes two arguments, with several optionals. The first argument is the type of request we want to send; the second argument identifies the location from which we wish to request data. For instance, if we wanted to use a GET request to access feed.xml at the root of our server, we'd initialise the XMLHttpRequest object like this:

senario ini tidak menangkap kes di mana medan wajib telah dilangkau, jadi itu adalah idea yang baik untuk membolehkan pengguna mengemukakan borang yang tidak lengkap, kerana ini membolehkan program itu menyerlahkan dengan tepat apa yang perlu diselesaikan, bukannya mencari butiran yang belum diisi.

tip #5: Sediakan maklum balas antara muka

Mewujudkan aplikasi web yang lancar boleh membolehkan anda meneroka fungsi baru yang belum pernah dilihat dalam penyemak imbas, tetapi dengan berbuat demikian, kita masih ingat asas reka bentuk antara muka yang boleh digunakan. Salah satu asas sedemikian adalah penyediaan maklum balas antara muka: membiarkan pengguna mengetahui apa yang dapat mereka lakukan, dan apa yang telah mereka lakukan.
Dalam Contoh 1, tidak sepenuhnya jelas bahawa pengguna boleh mengklik pada gambar kecil Ecard Graphics. Ini mudah diatasi jika kita memberikan garis besar kelabu kepada imej yang mana kursor diposisikan pada bila -bila masa.

The: Hover Pseudo Class akan biasa kepada sesiapa yang telah menggunakan CSS. Ia membolehkan objek untuk menukar penampilannya apabila kursor dipindahkan ke atas objek itu. Walaupun kesan tetikus secara teorinya dapat dicapai melalui CSS sahaja, versi semasa Internet Explorer tidak membenarkan: Hover kesan pada mana -mana elemen kecuali tag utama. Oleh itu, untuk mencapai kesan hover pada elemen imej, Contoh 2 melampirkan Onmouseover dan OnMouseout Event Handlers:

Pengendali acara itu kemudiannya boleh menukar kelas setiap imej dan membolehkan kami memberikan maklum balas visual menggunakan CSS:

requester.open("GET", "/feed.xml");

Menukar kursor untuk menunjukkan "clickability" nya juga boleh membantu memberi maklum balas kepada pengguna. Ini boleh dilakukan dengan menggunakan peraturan mudah dalam CSS:

requester.send(null);

var requester = new XMLHttpRequest();

Kesimpulan

Selepas membuat semua perubahan ini kepada Contoh 1, Contoh 2 menjadi aplikasi yang lebih berguna dan boleh digunakan.



Tema umum di antara petua yang ditawarkan di sini adalah untuk membuat pengguna berasa selesa dan terkawal. Jika pengguna tidak mempunyai maklumat yang mereka perlukan untuk memahami apa yang sedang berlaku, mereka akan melihat permohonan anda dengan ketakutan, dan prestasinya akan menderita akibatnya.
Walaupun artikel ini difokuskan terutamanya pada proses skrip jauh dan kebimbangan kebolehgunaannya, terdapat juga titik kebolehcapaian yang perlu diambil kira semasa anda membuat aplikasi web yang lancar. Contoh 3 adalah versi yang lebih kompleks dari aplikasi ECARD, yang menggunakan skrip yang lebih kuat dan merendahkan diri untuk pengguna tanpa JavaScript atau tanpa XMLHTTPREQUEST. Sebaik sahaja anda menguasai teknik yang diterangkan di atas, anda mungkin ingin melihat contoh terakhir ini dan mula membuat aplikasi anda benar -benar mantap.
soalan yang sering ditanya mengenai skrip jauh dan Ajax
Apakah perbezaan utama antara Ajax dan skrip jauh? Perbezaan utama terletak pada bagaimana mereka mengendalikan data. Ajax menggunakan XML untuk menghantar dan menerima data, sementara skrip jauh boleh menggunakan sebarang format data, termasuk XML, JSON, atau teks biasa. Ajax adalah pelaksanaan spesifik skrip jauh, yang merupakan konsep yang lebih luas. Ini menghasilkan aplikasi web yang lebih cepat, lancar, dan lebih responsif, meningkatkan pengalaman pengguna keseluruhan. Walau bagaimanapun, pilihan bahasa bergantung kepada keupayaan pelanggan penyemak imbas pengguna.
Apakah implikasi keselamatan menggunakan skrip jauh? Oleh itu, penting untuk melaksanakan langkah -langkah keselamatan yang betul, seperti pengesahan input dan pengekodan output, untuk melindungi daripada ancaman ini.

Bagaimanakah penghantaran data skrip jarak jauh? Ia menghantar permintaan ke pelayan, yang memproses permintaan dan menghantar semula respons. Tanggapan ini kemudian diproses oleh skrip sisi klien untuk mengemas kini laman web tanpa tambah nilai halaman penuh. Ia membolehkan pertukaran data tak segerak, bermakna pengguna boleh terus berinteraksi dengan halaman sementara pelayan memproses permintaan. AJAX juga menyokong format data XML, yang lebih berstruktur dan lebih mudah dikendalikan daripada teks biasa.

Bolehkah skrip jauh digunakan untuk aplikasi mudah alih? Walau bagaimanapun, disebabkan oleh kuasa pemprosesan terhad dan jalur lebar rangkaian peranti mudah alih, penting untuk mengoptimumkan skrip untuk prestasi dan kecekapan. Ia juga digunakan dalam aplikasi yang perlu memuatkan sejumlah besar data tanpa menyegarkan halaman, seperti skrol tak terhingga. Walau bagaimanapun, pelayar web moden menyediakan alat pemaju yang boleh membantu. Alat ini membolehkan anda memeriksa permintaan rangkaian, melihat log konsol, dan melangkah melalui kod untuk mengenal pasti dan memperbaiki isu-isu.

Apakah amalan terbaik untuk melaksanakan skrip jauh? mengendalikan kesilapan dengan anggun; mengoptimumkan skrip untuk prestasi; melaksanakan langkah -langkah keselamatan yang betul; dan menguji skrip dalam pelbagai pelayar untuk memastikan keserasian.

Atas ialah kandungan terperinci Ajax: Interaktiviti yang boleh digunakan dengan skrip jauh. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!