Ringkasan: Penjelasan terperinci untuk penggunaan kontrol web ASP+ verifikasi.
Daftar isi
Pendahuluan singkat
Memulai
Kapan itu terjadi?
Urutan verifikasi di sisi server
Verifikasi Klien
Aturan yang efektif dan informasi kesalahan yang berguna
Fungsi yang diaktifkan, terlihat, dan menampilkan properti
Kontrol CustomValidator
Kontrol mana yang dapat diverifikasi?
Akhir
-------------------------------------------------- -------------------------------------------------- ------------------------
Pendahuluan singkat
Artikel ini menjelaskan metode kerja kontrol verifikasi ASP+ secara rinci. Jika Anda ingin menghasilkan halaman kompleks yang berisi kontrol verifikasi, atau untuk memperluas kerangka kerja verifikasi, disarankan agar Anda membaca artikel ini. Jika Anda ingin belajar menggunakan kontrol verifikasi atau memutuskan apakah akan menggunakan kontrol verifikasi, lihat "ASP+ pengguna masukkan verifikasi (bahasa Inggris)".
Memulai
Kita tahu bahwa penting untuk memahami verifikasi selama seluruh proses pengembangan ASP+. Lihatlah sebagian besar situs web komersial saat ini, Anda akan menemukan bahwa ada banyak bentuk di situs -situs ini, yang jelas dieksekusi dengan mengeksekusi sejumlah besar kode tulisan tangan. Menulis kode verifikasi bukanlah pekerjaan yang menarik. Jika Anda menulis kode untuk menampilkan tabel data atau secara dinamis menghasilkan grafik, itu mungkin sangat menarik, tetapi tidak ada yang dapat mengkonfirmasi dengan rekan -rekannya bahwa metode "keren" ini dapat melarang nilai kosong di bidang nama.
Karena alasan lain, verifikasi aplikasi web juga sangat merepotkan. HTML 3.2 memiliki banyak batasan pada konten yang dapat Anda kendalikan atau umpan balik yang dapat Anda dapatkan dari pengguna, sehingga tidak dapat diterapkan pada teknik yang dapat digunakan pada klien yang lebih memuaskan, seperti melarang pengguna memasukkan karakter tertentu atau membuat suara. Menggunakan skrip browser dapat menghasilkan verifikasi yang lebih kuat. Namun, metode ini sulit untuk dikonfirmasi, karena browser pelanggan tidak harus skrip, dan pengguna jahat dapat memotongnya. Oleh karena itu, untuk memastikan keamanan situs, perlu melakukan inspeksi server yang sama.
Saat mengembangkan ASP+, niat asli kami adalah menggunakan hanya satu kontrol untuk memproses verifikasi. Tetapi ketika itu dirancang, saya menemukan bahwa keinginan ini tidak dapat dicapai. Kami telah meneliti sejumlah besar formulir input data untuk menemukan solusi yang dapat diterapkan pada sebanyak mungkin bentuk. Kami menemukan bahwa tabel input data memiliki banyak fitur menarik:
Meskipun informasi atau ikon kesalahan sering berdekatan dengan elemen input, mereka hampir selalu terletak di sel yang berbeda dari tabel.
Seringkali ada area di halaman untuk meringkas semua kesalahan.
Banyak situs termasuk skrip klien untuk memberikan umpan balik yang lebih cepat sambil mencegah perjalanan antara server dengan sia -sia.
Banyak situs yang berisi skrip klien menampilkan kotak informasi saat ada kesalahan.
Tidak hanya input teks akan diverifikasi, tetapi juga daftar drop -down dan tombol single -selection akan diverifikasi.
Jika bidang kosong, situs biasanya menunjukkan informasi atau ikon yang berbeda ketika entri tidak valid.
Banyak pemeriksaan yang efektif dapat digantikan dengan baik oleh ekspresi yang umum digunakan.
Verifikasi biasanya didasarkan pada hasil perbandingan antara dua input.
90% atau lebih dari 90% dari tugas verifikasi adalah beberapa operasi umum, seperti memeriksa nama atau kode pos. Sebagian besar situs tampaknya masih mengulangi tugas -tugas ini.
Karena perbedaan antar situs biasanya terlalu besar, solusi sempurna tidak dapat diperoleh untuk menangani semua tugas verifikasi dari setiap situs.
Mempertimbangkan semua situasi di atas, solusi akhir mencakup lima kontrol perangkat verifikasi, kontrol validasi, dan integrasi dengan objek halaman. Pada saat yang sama, jelas bahwa solusi perlu diperluas, dan API diperlukan untuk bekerja sama pada klien dan server.
Kami menemukan bahwa kami tampaknya membutuhkan kotak alat yang lebih besar selama berbagai verifikasi penelitian. Di sebagian besar lingkungan komponen, seperti Microsoft & Reg; ActiveX & Reg;, kami mungkin telah mencoba mengintegrasikan fungsi semua kontrol verifikasi ke dalam kontrol untuk memproses atribut yang berbeda dalam mode yang berbeda. Untungnya, ada warisan magis di Microsoft & Reg;
Sebagian besar kontrol ini diimplementasikan dalam basevalidator tingkat induk publik mereka. Anda juga dapat menyelesaikan berbagai tugas dari Basevalidator atau kontrol lainnya. Bahkan, bahkan jika Basevalidator terlalu malas untuk mencapai atribut teksnya sendiri, ia diwarisi dari atribut label.
Kapan itu terjadi?
Sangat efektif untuk memahami urutan peristiwa saat memproses halaman yang berisi halaman kontrol web. Jika kondisi verifikasi adalah opsional, Anda perlu memahami secara akurat ketika klien dan server diverifikasi. Jika Anda ingin menulis rutinitas verifikasi sendiri, mungkin sudah sangat membuat waktu atau efek samping. Pada saat yang sama, penting juga untuk memahami waktu panggilan verifikasi rutin.
Pertama, mari kita lihat server.
Urutan verifikasi di sisi server
Penting untuk memahami periode validitas halaman. Jika Anda terbiasa memproses formulir dalam Visual Basic atau alat klien fungsional yang serupa, Anda perlu menghabiskan waktu tertentu untuk memahami. Semua objek pada halaman dan halaman tidak efektif saat berinteraksi dengan pengguna, meskipun terkadang ini sama.
Berikut ini adalah urutan acara yang disederhanakan saat mengunjungi halaman untuk pertama kalinya:
Buat halaman dan kontrolnya berdasarkan file ASPX.
Memicu acara page_load.
Halaman dan atribut kontrol disimpan di bidang tersembunyi.
Halaman dan kontrol dikonversi menjadi HTML.
Buang semuanya.
Sekarang, ketika pengguna mengklik tombol atau kontrol yang serupa, itu akan kembali ke server dan kemudian menjalankan urutan acara yang serupa. Urutan ini disebut urutan pengembalian:
Buat halaman dan kontrolnya berdasarkan file ASPX.
Kembalikan halaman dan kontrol atribut dari bidang tersembunyi.
Masukkan Kontrol Halaman Pembaruan sesuai dengan pengguna.
Memicu acara page_load.
Memicu perubahan acara pemberitahuan.
Halaman dan atribut kontrol disimpan di bidang tersembunyi.
Halaman dan kontrol dikonversi menjadi HTML.
Buang semuanya lagi.
Mengapa kita tidak menyimpan semua objek dalam memori? Karena situs web yang ditetapkan dengan ASP+ tidak dapat menangani sejumlah besar pengguna. Oleh karena itu, memori server hanya mempertahankan konten yang akan segera diproses.
Kapan verifikasi server -side? Saat mendapatkan informasi halaman untuk pertama kalinya, verifikasi server -side tidak akan dilakukan sama sekali. Sebagian besar pengguna akhir sangat serius.
Dalam urutan acara kembali, verifikasi akan dilakukan antara langkah 3 dan langkah 4. Dengan kata lain, verifikasi adalah setelah atribut kontrol pemuatan data dari pengguna, tetapi sebelum sebagian besar jumlah eksekusi kode. Ini berarti bahwa ketika menulis acara pengguna, biasanya dapat digunakan untuk verifikasi. Dalam keadaan normal, Anda ingin melakukan ini.
Kerugian verifikasi pada saat itu adalah: jika Anda ingin memodifikasi beberapa atribut yang mempengaruhi verifikasi dengan pemrograman, itu akan terlambat. Misalnya, Anda akan menemukan bahwa jika Anda menggunakan kode untuk mengaktifkan atau menonaktifkan atribut kontrol verifikasi atau memodifikasi kontrol verifikasi, Anda tidak akan melihat efek apa pun sebelum memproses halaman. Masalah ini dapat dihindari melalui dua metode berikut:
Ubah atribut sebelum verifikasi.
Ulang kembali kontrol setelah perubahan atribut.
Kedua metode perlu menggunakan atribut verifikasi yang efektif dan metode pada objek halaman.
API Halaman
Objek halaman mencakup beberapa atribut dan metode penting yang terkait dengan verifikasi server -side. Tabel 1 merangkum atribut dan metode ini:
Tabel 1. Atribut dan Metode Objek Halaman
Atribut atau deskripsi metode
Atribut isValid adalah atribut yang paling berguna. Atribut ini dapat memeriksa apakah seluruh formulir efektif. Cek ini biasanya dilakukan sebelum memperbarui database. Hanya semua objek validator yang valid, atributnya benar, dan nilainya tidak disimpan dalam cache.
Validator mengaitkan kumpulan semua objek verifikasi halaman ini. Ini adalah kumpulan objek yang mengimplementasikan antarmuka ivalidator.
Metode nilai memanggil metode saat verifikasi. Metode eksekusi default pada objek halaman adalah untuk beralih ke setiap perangkat verifikasi dan mengharuskan perangkat verifikasi untuk mengevaluasi dirinya sendiri.
Koleksi validator sangat berguna untuk banyak tugas. Set ini adalah kumpulan objek yang mengimplementasikan antarmuka ivalidator. Alasan mengapa saya menggunakan objek bukanlah kontrol kontrol karena objek halaman hanya memperhatikan antarmuka ivalidator. Karena semua verifikasi biasanya digunakan untuk mencapai beberapa kontrol visual ivalidator, siapa pun harus dapat menggunakan objek verifikasi apa pun dan menambahkan objek verifikasi ke halaman.
Antarmuka ivalidator berisi atribut dan metode berikut:
Tabel 2. Atribut dan metode antarmuka ivalidator
Atribut atau deskripsi metode
Atribut isValid menunjukkan apakah uji validitas yang dilakukan oleh objek verifikasi terpisah telah berlalu. Anda dapat mengubah nilai secara manual setelah verifikasi.
Atribut ErrorMessage memperkenalkan kesalahan untuk memverifikasi objek yang akan diverifikasi dan kesalahan yang dapat ditampilkan kepada pengguna.
Metode validasi diperiksa untuk validitas objek verifikasi untuk memperbarui nilai isvalidnya.
Anda dapat menggunakan antarmuka ini untuk melakukan beberapa tugas menarik. Misalnya, untuk mengatur ulang halaman ke keadaan yang efektif, gunakan kode berikut (seperti contoh yang ditunjukkan dalam C#):
Nilai ivalidator;
Foreach (val in validators) {
valuevalid = true;
}
Untuk mengeksecute seluruh urutan verifikasi, gunakan kode berikut:
Nilai ivalidator;
Foreach (val in validators) {
Val.validate ();
}
Jika Anda memiliki edisi beta 1 atau versi yang lebih tinggi, Anda juga dapat memanggil metode nilai hanya untuk objek halaman, sehingga tugas yang sama dapat diselesaikan. Untuk membuat beberapa perubahan sebelum verifikasi, metode nilai dapat dibahas. Contoh ini menunjukkan halaman yang berisi perangkat verifikasi, yang dibuka atau dimatikan sesuai dengan nilai kotak centang:
Kelas Publik Bersyarat: Halaman {
htmlinputcheckbox publik chksameas;
Public ResearchFieldValidator RFValShipAddress;
Override void validate () {) {) yang dilindungi
// Cukup periksa alamat pengiriman (jika berbeda dari alamat pembayaran)
Bool enableship =!
rfvalshipAddress.enabled = enableShip;
// Sekarang menjalankan verifikasi
base.validate ();
}
}
Verifikasi Klien
Jika halaman Anda diaktifkan oleh verifikasi klien, urutan peristiwa yang sama sekali berbeda akan terjadi selama perjalanan pulang pergi. Verifikasi klien menggunakan klien JScript & Reg; Verifikasi tidak memerlukan komponen biner.
Meskipun standarisasi bahasa JScript dilakukan dengan baik, model objek dokumen (DOM) yang digunakan dalam dokumentasi HTML di browser (DOM) belum banyak digunakan standar. Oleh karena itu, verifikasi klien hanya dilakukan di Internet Explorer 4.0 dan versi yang lebih tinggi, karena objek yang diverifikasi adalah Internet Explorer DOM.
Dari perspektif server, verifikasi klien hanya berarti bahwa kontrol verifikasi mengirimkan konten yang berbeda ke HTML. Selain itu, urutan insiden persis sama. Pemeriksaan server -side masih dilakukan. Meskipun tampaknya berlebihan, ini sangat penting karena:
Beberapa kontrol verifikasi mungkin tidak mendukung skrip klien. Ada contoh yang baik: Jika Anda ingin menggunakan fungsi verifikasi CustomValidator dan server secara bersamaan, tetapi tidak ada fungsi verifikasi klien.
Tindakan pencegahan keselamatan. Beberapa orang dapat dengan mudah mendapatkan halaman yang berisi skrip, dan kemudian menonaktifkan atau mengubah halaman. Anda tidak boleh menggunakan skrip Anda untuk mencegah data yang buruk memasuki sistem Anda, tetapi hanya bagi pengguna untuk mendapatkan umpan balik yang lebih cepat. Oleh karena itu, jika Anda ingin menggunakan CustomValidator, Anda tidak boleh memberikan fungsi verifikasi klien tanpa fungsi verifikasi server yang sesuai.
Setiap kontrol verifikasi dapat memastikan bahwa blok skrip klien standar dikirim ke halaman. Faktanya, ini hanyalah sebagian kecil dari kode, yang berisi referensi ke kode dalam pustaka skrip WebUivalidation.js. File perpustakaan skrip ini berisi semua logika yang diverifikasi oleh klien.
Tentang Perpustakaan Script
Karena verifikasi skrip kontrol web ada di pustaka skrip, kode yang diverifikasi oleh semua klien tidak diperlukan untuk secara langsung mengirimkannya ke halaman, meskipun tampaknya dilakukan di permukaan. Referensi file skrip utama mirip dengan yang berikut:
<bahasa skrip = javascript
src =/_ aspx/1.0.9999/skrip/webuivalidation.js> </script>
Secara default, file skrip akan diinstal di direktori root default di direktori _aspx, dan menggunakan skrip termasuk instruksi untuk dipanggil, yang dimulai dengan garis diagonal positif. Referensi menunjukkan bahwa setiap objek individu tidak perlu memasukkan pustaka skrip, dan semua halaman di komputer yang sama dapat merujuk file yang sama. Anda akan melihat bahwa ada juga nomor versi bahasa publik di jalur ini, sehingga versi runtime yang berbeda dapat berjalan di komputer yang sama.
Jika Anda melihat direktori root virtual default Anda, Anda akan menemukan file dan melihat konten. Posisi file -file ini ditentukan dalam file config.web. File config.web adalah file XML untuk sebagian besar pengaturan ASP+. Berikut ini adalah definisi posisi dalam file ini:
<WebControls
ClientScriptSlocation =/_ aspx/{0}/skrip/
/>
Dorong Anda untuk membaca skrip sehingga Anda dapat memahami peristiwa yang terjadi secara mendalam. Namun, disarankan agar Anda tidak memodifikasi skrip ini, karena fungsinya terkait erat dengan versi runtime tertentu. Ketika versi diperbarui, skrip ini mungkin juga perlu diperbarui. Jika proyek tertentu harus diubah, cadangan terlebih dahulu skrip ini, dan kemudian arahkan proyek Anda ke file cadangan, metode ini adalah menggunakan file konfigurasi pribadi untuk mengganti posisi file -file ini. Jika string berisi instruksi format {0}, nomor versi akan menggantikan instruksi ketika nomor versi runtime akan diganti. Yang terbaik adalah mengubah posisi ini menjadi referensi relatif atau referensi absolut.
Nonaktifkan verifikasi klien
Terkadang Anda mungkin tidak ingin memverifikasi klien. Jika jumlah bidang input kecil, verifikasi klien mungkin tidak terlalu berguna. Lagi pula, Anda harus memiliki logika yang membutuhkan satu server putaran setiap saat. Anda akan menemukan bahwa informasi dinamis pada klien akan memiliki dampak negatif pada tata letak Anda.
Untuk menonaktifkan verifikasi klien, gunakan instruksi halaman clienttarget = downlevel. Instruksi ini mirip dengan awal file ASPX:
< %@halaman bahasa = C# clientTarget = downLevel %>
Nilai default dari instruksi ini adalah otomatis, menunjukkan bahwa Anda hanya memverifikasi klien Microsoft Internet Explorer 4.0 atau versi yang lebih tinggi.
Catatan: Sayangnya, dalam Beta 1, instruksi ini tidak hanya dinonaktifkan untuk verifikasi, dan pada saat yang sama, semua kontrol web menggunakan tag HTML 3.2 untuk diproses, yang mungkin memiliki hasil yang tidak terduga. Versi final memberikan cara yang lebih baik untuk mengendalikan masalah ini.
Urutan acara klien
Urutan ini adalah urutan peristiwa yang terjadi ketika halaman yang berisi verifikasi klien:
Saat memuat browser pada halaman, Anda perlu menginisialisasi setiap kontrol verifikasi. Kontrol ini dikirim sebagai tanda <span>, dan fitur HTML mereka paling dekat dengan fitur di server. Yang terpenting, semua elemen input yang dirujuk oleh perangkat verifikasi akan "digantung" saat ini. Elemen input yang direferensikan akan memodifikasi acara kliennya untuk memanggil rutin verifikasi saat memasuki perubahan.
Kode di pustaka skrip akan dieksekusi ketika pengguna menggunakan tombol tab untuk beralih di antara setiap bidang. Ketika bidang independen tertentu diubah, kondisi verifikasi akan dievaluasi kembali, dan perangkat verifikasi akan terlihat atau tidak terlihat sesuai kebutuhan.
Ketika pengguna mencoba mengirimkan formulir, semua verifikasi akan dievaluasi. Jika semua verifikasi ini efektif, formulir akan diserahkan ke server. Jika ada kesalahan di satu atau lebih tempat, situasi berikut akan terjadi:
Pengajuan dibatalkan. Formulir tidak dikirimkan ke server.
Semua verifikasi yang tidak valid terlihat.
Jika ringkasan verifikasi berisi showummary = true, semua kesalahan dari kontrol verifikasi akan dikumpulkan dan konten diperbarui dengan kesalahan ini.
Jika ringkasan verifikasi berisi showmessageBox = true, itu akan mengumpulkan kesalahan dan menampilkan kesalahan ini di kotak informasi klien.
Karena kontrol verifikasi klien dilakukan ketika kontrol verifikasi klien dilakukan pada setiap perubahan input atau saat mengirimkan, kontrol verifikasi ini biasanya dievaluasi dua kali atau lebih dari dua kali pada klien. Harap dicatat bahwa setelah pengiriman, kontrol verifikasi ini masih akan dievaluasi kembali di server.
API Klien
Ada API kecil yang dapat digunakan pada klien untuk mencapai berbagai efek dalam kode klien Anda sendiri. Karena beberapa rutin tidak dapat disembunyikan, secara teori, Anda dapat menggunakan klien untuk memverifikasi semua variabel, karakteristik, dan fungsi yang ditentukan oleh klien. Namun, banyak dari mereka dapat diubah. Berikut ini merangkum objek klien yang kami mendorong Anda untuk digunakan.
Tabel 3. Objek Klien
Jenis Nama Deskripsi
Variabel boolean page_isvalid menunjukkan apakah halaman saat ini valid. Memverifikasi skrip selalu menjaga variabel terbaru.
Array elemen page_validator Ini adalah array yang berisi semua verifikasi pada halaman.
Variabel boolean page_validationactive menunjukkan apakah itu harus diverifikasi. Atur variabel ini ke false dapat dibuktikan dengan pemrograman.
ISVALID Boolen Atribut Setiap perangkat verifikasi klien memiliki properti, menunjukkan apakah perangkat verifikasi saat ini valid. Harap dicatat bahwa dalam versi PDC, atribut ini dicampur dengan isValid.
Melewati verifikasi klien
Salah satu tugas yang sering Anda perlu jalankan adalah menambahkan tombol "Batalkan" atau tombol navigasi pada halaman. Dalam hal ini, bahkan jika ada kesalahan pada halaman, Anda mungkin juga ingin menggunakan tombol untuk mengirimkan halaman. Karena acara OnClick Tombol Klien terjadi sebelum acara Onsubmit dari formulir, itu dapat menghindari mengirimkan inspeksi dan verifikasi yang melewati. Berikut ini menunjukkan cara menggunakan kontrol gambar HTML sebagai tombol "Batalkan" untuk menyelesaikan tugas:
<input type = gambar runat = server
Nilai = Batal
OnClick = page_validationActive = false;
OnServerClight = cmdcancel_click>
Gunakan kontrol tombol atau ImageButton untuk melakukan beberapa kebingungan, karena acara OnClick mengasumsikan bahwa itu adalah acara server -side dengan nama yang sama. Anda harus mengatur acara ini dalam skrip klien:
<ASP: ImageButton runat = server id = cmDimgcancel
alternateText = batal
OnClick = cmdcancel_click/>
<bahasa skrip = javascript>
document.all [cmdimgcancel] .onClick =
fungsi baru (page_validationactive = false;);
</script>
Metode lain untuk menyelesaikan masalah ini adalah dengan mengatur pengaturan tertentu dari tombol "Batal" sehingga tidak akan memicu acara pengiriman dalam skrip klien saat kembali. Kontrol HTMlinPutButton dan LinkButton adalah contohnya.
Efek khusus
Persyaratan umum lainnya adalah bahwa selain informasi kesalahan yang ditampilkan oleh perangkat verifikasi itu sendiri, beberapa efek lain diperlukan. Dalam hal ini, modifikasi apa pun yang Anda buat perlu dilakukan pada saat yang sama di server atau klien. Misalkan Anda perlu menambahkan label untuk mengubah warna sesuai dengan apakah inputnya valid. Berikut ini adalah cara mengimplementasikan tugas ini di server:
Public Class ChangeColorPage: Page {
label publik lblzip;
Nilai RegulaxPrespressionValidator Publik;
Override void overoad (EventArgs e) {{{{{{{{{
lblzip.forecolor = valzip.isvalid?
}
}
Semua metode di atas sempurna, tetapi selama Anda memodifikasi verifikasi di atas, Anda akan menemukan bahwa kecuali Anda melakukan operasi yang sama pada klien, itu akan terlihat sangat tidak konsisten. Kerangka kerja verifikasi akan memungkinkan Anda untuk menghindari banyak efek ganda seperti itu, tetapi tidak dapat menghindari efek lain yang harus Anda capai pada saat yang sama pada klien dan server. Berikut ini adalah fragmen yang melakukan tugas yang sama pada klien:
<Asp: Label ID = lblzip runat = server
Teks = kode pos:/>
<Asp: TextBox ID = TXTZIP runat = Server
onchange = txtziponchange ();
<Asp: RegulerxPressionValididator ID = valzip runat = server
ControlTovalidate = txtzip
errorMessage = kode pos tidak valid
ValidationXpression = [0-9] {5} /> <br>
<bahasa skrip = javascript>
Function txtziponchange () {{) {
// Jika verifikasi klien tidak ada dalam aktivitas, itu tidak akan melakukan operasi apa pun
ifof (page_validators) == tidak terdefinisi) kembali;
// Ubah warna label
lblzip.style.color = valzip.isvalid?
}
</script>
API Klien Beta 1
Untuk edisi Beta 1, beberapa fungsi yang dapat dipanggil dari skrip klien akan menyebabkan situasi lain.
Tabel 4. Fungsi dari panggilan skrip klien
Deskripsi Nama
ValidatorValidate (VAL) menggunakan perangkat verifikasi klien sebagai input. Buat perangkat verifikasi periksa inputnya dan perbarui tampilannya.
ValidatorEnable (Val, Enable) Dapatkan perangkat verifikasi klien dan nilai boolean. Mengaktifkan atau menonaktifkan perangkat verifikasi klien. Jika dinonaktifkan, perangkat verifikasi klien tidak akan dievaluasi, dan validator klien akan selalu valid.
ValidatorHookUpControl (Control, Val) memperoleh elemen input HTML dan perangkat verifikasi klien. Ubah atau buat acara perubahan elemen sehingga perangkat verifikasi dapat diperbarui selama perubahan. Fungsi ini cocok untuk verifikasi yang disesuaikan berdasarkan beberapa nilai input.
Tujuan khususnya adalah untuk mengaktifkan atau menonaktifkan perangkat verifikasi. Jika Anda ingin memverifikasi bahwa Anda hanya berlaku dalam keadaan tertentu, Anda mungkin perlu mengubah status aktivasi pada saat yang sama di server dan klien, jika tidak, Anda akan menemukan bahwa pengguna tidak dapat mengirimkan halaman.
Berikut ini adalah contoh di atas ditambah bidang.
Kelas Publik Bersyarat: Halaman {
htmlinputcheckbox publik chksameas;
Public ResearchFieldValidator RFValShipAddress;
Override void validate () {) {) yang dilindungi
Bool enableship =!
rfvalshipAddress.enabled = enableShip;
base.validate ();
}
}
Berikut ini adalah kode yang setara klien:
<Jenis input = kotak centang runat = ID server = chksameas
OnClick = OnchangesAmeas ();> sama dengan alamat pembayaran <br>
<bahasa skrip = javascript>
Fungsi onchangesameas () {
var entleship =!
ValidatorEnable (RFValShipAddress, Enableship);
}
</script>
Aturan yang efektif dan informasi kesalahan yang berguna
Setiap perangkat verifikasi menunjukkan informasi kesalahan spesifik tentang kondisi spesifik dalam kontrol tertentu. Ada beberapa aturan yang mengkonfirmasi apakah itu valid.
Semua verifikasi kosong (kecuali untuk wajib yang diperlukan Validator) dianggap valid. Jika nilai kosong tidak valid, Anda biasanya memerlukan wajib validator dan verifikasi lainnya. Anda perlu melakukan ini, karena secara umum, Anda selalu ingin menunjukkan informasi kesalahan yang berbeda pada perangkat verifikasi kosong dan efektivitas. Anda juga dapat menggunakan informasi yang tidak jelas, seperti "Anda harus memasukkan nilai, dan nilai ini harus antara 1 dan 10".
Aturan khusus lain yang digunakan ketika bidang input tidak dapat dikonversi menjadi tipe data yang ditentukan terkait dengan CompareValidator dan Rangevalidator. Proses penilaian validitas dari perbandingan controlTocompare menentukan proses penilaian validitas seperti yang dijelaskan di bawah ini:
Jika bidang input yang dirujuk oleh ControlTovalidate kosong, itu efektif.
Jika bidang input yang dirujuk oleh ControlTovalidate tidak dapat dikonversi ke tipe data yang diperlukan, itu tidak valid.
Jika bidang input yang dirujuk oleh ControlToCompare tidak dapat dikonversi ke tipe data yang diperlukan, itu valid.
Bidang input dikonversi ke tipe data yang diperlukan dan membandingkan.
Langkah ketiga terlihat sedikit tidak konsisten. Alasan untuk ini adalah karena jika perangkat verifikasi memeriksa efektivitas beberapa bidang secara bersamaan, sulit untuk menulis informasi kesalahan yang bermakna untuk perangkat verifikasi. Perangkat verifikasi independen harus digunakan untuk melaporkan situasi kesalahan di bidang input ControlToCompare. Rangevalidator memiliki metode kerja yang serupa, dengan sifat maksimum dan minimum.
Fungsi yang diaktifkan, terlihat, dan menampilkan properti
Perbedaan antara properti yang diaktifkan, terlihat dan tampilan dari perangkat verifikasi mungkin tidak terlalu jelas.
Tampilan = Tidak ada yang dapat digunakan untuk menentukan bahwa perangkat verifikasi tidak secara langsung menampilkan konten apa pun, tetapi masih mengevaluasi, masih mempengaruhi efektivitas keseluruhan, dan masih dapat menempatkan kesalahan dalam ringkasan klien dan server. Untuk verifikasi klien, nilai -nilai ini ditentukan untuk menggunakan karakteristik gaya yang terlihat atau menggunakan karakteristik gaya tampilan untuk membuka atau menutup perangkat verifikasi. Untuk verifikasi server -side, display = dinamis berarti bahwa input tidak menampilkan konten apa pun saat input valid, dan display = statis mewakili ruang yang tidak berubah. Pengaturan terakhir harus dilipat menjadi tidak ada konten ketika sel yang hanya berisi perangkat verifikasi dalam tabel valid.
Mengapa tidak hanya menggunakan visible = false untuk membuat perangkat verifikasi terlihat? Di ASP+, atribut yang terlihat dari kontrol memiliki banyak makna: kontrol visible = false tidak akan diproses atau ditampilkan sama sekali. Justru karena makna inilah yang terlihat = salah dari perangkat verifikasi berarti bahwa tidak hanya tidak menampilkan konten apa pun, tetapi juga tidak dapat digunakan. Perangkat verifikasi ini tidak akan dievaluasi, tidak akan mempengaruhi validitas halaman, juga tidak akan dimasukkan ke dalam abstrak.
Diaktifkan itu netral. Dalam kebanyakan kasus, efek diaktifkan = false dan visible = false persis sama. Dalam edisi Beta 1 atau versi yang lebih tinggi, ada perbedaan penting: dalam verifikasi klien, perangkat verifikasi yang dinonaktifkan masih akan dikirim ke browser, tetapi dalam keadaan cacat. Anda dapat menggunakan fungsi yang dapat divalidatoren dalam skrip klien untuk mengaktifkan perangkat verifikasi.
Saat menggunakan yang terlihat atau diaktifkan untuk mengontrol apakah akan memverifikasi, perhatikan pesanan pesanan di server di atas. Atau ubah sebelum verifikasi, atau verifikasi ulang setelah perubahan. Kalau tidak, nilai isvalid mereka tidak akan mencerminkan perubahan atribut.
Kontrol CustomValidator
Cara termudah untuk memperluas kerangka kerja verifikasi adalah dengan menggunakan kontrol CustomValidator. Kontrol ini dapat digunakan untuk melakukan verifikasi bahwa kontrol verifikasi lain tidak dapat dilakukan, tetapi mereka juga dapat menjalankan verifikasi yang perlu mengakses informasi di server (seperti database atau layanan web).
Jika CustomValidator dengan hanya satu fungsi verifikasi server ditambahkan, Anda akan melihat bahwa perangkat verifikasi tidak berpartisipasi dalam verifikasi klien. Ketika pengguna beralih di antara setiap bidang dengan tombol tab, CustomValidator tidak akan diperbarui, dan server putaran -trip perlu melakukan verifikasi pada satu waktu. Jika Anda ingin menggunakan CustomValidator untuk melakukan pemeriksaan yang tidak memerlukan informasi apa pun di server, Anda juga dapat menggunakan properti fungsi ClientValidation untuk membuat perangkat verifikasi sepenuhnya berpartisipasi dalam verifikasi klien. Misalkan Anda memberikan fungsi ClientValidation. Namun pada kenyataannya, itu hanya bagian dari verifikasi. Verifikasi fungsi verifikasi klien tidak melebihi verifikasi pelaksanaan di server karena peretas dapat dengan mudah melewati fungsi verifikasi.
Berikut ini adalah contoh sederhana menggunakan CustomValidator pada klien dan server, hanya periksa apakah inputnya rata. Mari kita perkenalkan fungsi server (dalam C#):
{Layanan Pihak) {Posisi
mencoba {
int i = int.fromString (nilai);
Return ((i % 2) == 0);
} Menangkap {
Mengembalikan false;
}
}
Berikut ini adalah metode deklarasi fungsi pada klien, dan fungsi verifikasi klien yang melakukan pemeriksaan yang sama. Ini biasanya merupakan formulir JScript, tetapi jika tujuan Anda adalah Microsoft & Reg;
<ASP: CustomValidator ID = CustomVal2 Runat = Server
ErrorMessage = angka tidak dapat dihapus!
ControlTovalidate = txtcustomdata
OnServalidationFunction = Servervalidation
clientValidationFunction = checkeven /> <br>
Bidang Data: <Asp: TextBox ID = TXTCUSTOSDATA RUNAT = Server />
<bahasa skrip = javascript>
<!-
Function checkeven (sumber, nilai) {{
nilai var = parseInt (nilai, 10);
if (isnan (val))
Mengembalikan false;
Return ((val % 2) == 0);
}
//->
</script>
Berikut ini adalah beberapa tindakan pencegahan menggunakan CustomValidator:
Mirip dengan semua kontrol verifikasi lainnya (kecuali untuk Wajib Validator), jika bidang input kosong, dianggap bahwa CustomValidator efektif.
Jika browser yang lebih lama digunakan atau verifikasi klien ditutup, fungsi verifikasi klien tidak dapat dipanggil. Sebelum mendefinisikan fungsi, Anda tidak perlu memeriksa fungsi browser yang digunakan di browser, tetapi Anda perlu memastikan bahwa browser tidak menyebabkan kesalahan skrip karena definisi. Pastikan untuk membuat kode klien Anda sebagai anotasi HTML, seperti yang ditunjukkan pada contoh berikut.
Dua parameter diteruskan ke fungsi klien Anda dan sesuai dengan parameter yang diteruskan ke fungsi server. Yang pertama adalah elemen perangkat verifikasi klien, dan yang kedua adalah nilai kontrol yang ditentukan oleh ControlTovalidate. Namun, pada klien, Anda dapat memilih untuk tidak mendefinisikan parameter untuk fungsi, yang akan berfungsi secara normal.
Jika Anda menggunakan versi beta1 atau lebih tinggi, Anda dapat tetap mengontrolTovalidate sebagai kosong. Dalam mode ini, fungsi server akan selalu memicu perjalanan bulat -trip, dan fungsi klien akan selalu dipicu setiap kali Anda mencoba mengirimkannya. Anda dapat menggunakan fitur ini untuk memverifikasi kontrol yang tidak dapat diverifikasi metode lain, seperti centang kotak atau tombol radio terpisah. Jika kondisi ini didasarkan pada beberapa kontrol, dan Anda tidak ingin pengguna mengevaluasi kondisi saat beralih di antara setiap bidang pada halaman, Anda dapat menggunakan metode ini.
Opsi lain dalam versi beta 1 atau lebih tinggi adalah peristiwa perubahan beberapa kontrol. Metode ini adalah menambahkan beberapa skrip tertanam yang memanggil Fungsi Klien ValidatorHookUpControl, seperti dijelaskan di atas.
Kontrol mana yang dapat diverifikasi?
Untuk mengaktifkan kontrol untuk diverifikasi dengan referensi kontrol, kontrol harus telah memverifikasi atribut. Semua kontrol yang diverifikasi memiliki properti validasiPropertyAttribute, yang menunjukkan atribut yang harus dibaca selama verifikasi. Jika Anda menulis kontrol sendiri, Anda dapat menentukan atribut yang akan digunakan dengan menyediakan salah satunya, sehingga kontrol terlibat dalam verifikasi.
Untuk memungkinkan verifikasi dilakukan secara normal pada klien, atribut harus sesuai dengan karakteristik nilai elemen HTML yang ditampilkan oleh klien. Banyak kontrol rumit (seperti Datagrid dan Kalender) tidak sebanding dengan klien dan hanya dapat diverifikasi di server. Oleh karena itu, hanya kontrol yang paling dekat dengan elemen HTML yang dapat berpartisipasi dalam verifikasi. Selain itu, kontrol harus memiliki nilai logika tunggal pada klien. Oleh karena itu, RadioButtonList dapat diverifikasi, tetapi Centang Kotak tidak bisa.
Akhir
Penjelasan verifikasi ASP+ yang disebutkan di atas mungkin telah melampaui konten yang ingin Anda pahami. Nikmati!
-------------------------------------------------- -------------------------------------------------- ------------------------
Silakan gunakan IE4.0 di atas versi 800 * 600 tampilan di situs ini
& Salin; 2001 Microsoft Corporation Hak cipta dilindungi undang -undang. Pertahankan kepemilikan. Gunakan peraturan.
Kumpulkan kode efek khusus halaman web paling praktis!