Validation - ולידציה
ControlToValidate לשדה, מוחקים את ה-ErrorMessage, ומציבים * כטקסט, בצבע אדום.Type כ-Integer, אחרת ההשוואה נעשית כמחרוזת, ו-4000 ייראה כ"בין 200 ל-800".ValueToCompare = 0 ואופרטור NotEqual, כי RequiredFieldValidator לא יודע שהפריט הראשון "בחר" אינו בחירה אמיתית.args.Value ומעדכנת args.IsValid. בצד השרת היא אירוע ServerValidate עם אותה לוגיקה.Page.IsValid לפני פעולה, כדי שהקוד לא ירוץ עם קלט שגוי.Dynamic, כך שההודעה לא תופס מקום כשאין שגיאה. בדמו הוצמדה כוכבית לתיבת הטקסט בזכות זה.פרקי ההרצאה: Validation - ולידציה
תמלול ההרצאה: Validation - ולידציה
הטקסט המלא של הדקות הראשונות בהרצאה «Validation - ולידציה» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
בשיעור הקודם ראינו מספר שיטות לטיפול בשגיאות שיכולות לקרות בצד השרת. בשיעור הזה אנחנו הולכים לראות כיצד ניתן לבצע מניעה של כמה שיותר שגיאות. מה זה אומר?
אנחנו בתור מתכנתי ASP.NET יכולים לבצע פעולה שנקראת ולידציה, כלומר אימות המידע שנקלט מהלקוח. הפעולה הזאת יכולה למנוע שגיאות שיכולות לקרות בצד של השרת וגם בצד של הלקוח.
בואו נסתכל מה הכוונה, בואו נוסיף קובץ עבור דף details. יש לי פה דף aspx שנקרא details.aspx ואני מעוניין לקלוט פרטים שונים מהמשתמש בדף הזה. בואו נתחיל עם נתון מאוד פשוט שאני רוצה מהמשתמש וזה בעצם את השם הפרטי שלו.
בגלל שאני רוצה את השם הפרטי לקחת אותו בצד של השרת ולדוגמה לשמור אותו בבסיס נתונים, אז תיבת הטקסט שתאפשר לי לקבל את השם הפרטי תהיה ASP.2 טקסט בוקס, כלומר תיבת צד שרת.
אפילו נגדיר את האתר הזה בעברית. בנוסף יש לי פה לחצן שיאפשר לקבל את הפרטים בצד של השרת. עכשיו הלקוח יכול להכניס שם פרטי בתיבת הטקסט, ללחוץ על לחצן send ואני רוצה בעזרת המידע שנשלח לקבל אותו ולשמור אותו באיזשהו בסיס נתונים.
פה לצורך העניין, לצורך הדוגמה רק נבצע איזשהו קוד בלחצן בכדי לראות שהמידע אכן הגיע אלינו. לדוגמה, response.write ונכתוב את הערך מתיבת הטקסט וקוד השרת.
בואו נריץ את הדף ויש לנו כרגע אפשרות להכנסת שם פרטי. אני מכניס שם פרטי, לוחץ על לחצן שלח, המידע נשלח מהלקוח לשרת, שם הוא מתקבל והשרת מבצע איתו פעולה כלשהי, כרגע רק הצגנו את המידע על הדפדפן בחזרה.
אבל מה היה קורה אם המשתמש לא הכניס דבר בתיבת הטקסט? ולחץ הלחצן שלח האם גם אז היה נשלח מידע לצד של השרת.
אז אנחנו רואים שאכן כשאני לוחץ על הלחצן המידע נשלח לצד של השרת שכמובן מקבל מידע ריק ואת זה אנחנו רוצים למנוע. במידה ומבחינתי המידע הזה הוא מידע מנדטורי כלומר חובה להכנסה שדה חובה אני רוצה לבצע איזושהי בדיקה שתאמר למשתמש שהוא חייב להכניס את המידע.
יותר מזה אני לא רוצה לאפשר שליחת מידע כלשהו לשרת אם אכן הוא לא הכניס לי כאן שום דבר. אנחנו יכולים לראות שכאשר אני לוחץ על הלחצן שלח, כאן למטה מופיע פרוגרס בר בדפדפן שמציין שאכן מתבצעת איזושהי ריקווסט לצד של השרת.
אנחנו רוצים את הריקווסט הזאת למנוע. אז ראשית בואו נחשוב על השאלה הבאה, היכן בדיוק אמורה להתבצע הבדיקה האם המשתמש הכניס שם פרטי או לא? מה זאת אומרת היכן?
יש לנו בכל התהליך הזה שני מחשבים. יש לנו את המחשב של הלקוח שמריץ את הדפדפן, וזה מחשב לכל דבר שמסוגל לבצע בדיקות. ויש לנו את המחשב בצד השרת שבו קיים אתר האינטרנט, גם הוא מחשב לכל דבר וגם הוא מסוגל לבצע בדיקות.
בואו נחשוב איפה היינו עושים את הבדיקה האם המשתמש הכניס שם פרטי או לא הכניס שם פרטי בכדי להציג הודעת שגיאה.
אז ראשית, אם הייתי עושה את הבדיקה הזאת בצד של השרת לא הייתה שום בעיה, אם הלקוח היה לוחץ על לחצן שלח הייתה מתבצעת ריצה לשרת, אנחנו יכולים לראות את ה-progress bar פה למטה, השרת היה מבצע בדיקה האם יש לי מידע בתיבת הטקסט או לא, ובמידה ולא הוא מחזיר תשובה שלילית ללקוח,
כלומר שגיאה על הכנס שם פרטי. אבל במידה והבדיקה הייתה מתבצעת בצד של השרת עדיין היה פה משהו מיותר, והדבר שהיה פה מיותר וריצה מיותרת לשרת מכדי שהשרת יבצע את הבדיקה ויחזיר לנו תשובה.
הרי ברור שהבדיקה הזאת יכלה להתבצע גם בצד של הלקוח, במחשב הלקוח, בעזרת הדפדפן, כך שבסופו של דבר הריצה לשרת הייתה נמנעת, וזה חוסך כמובן זמן ללקוח וזו ריצה מיותרת.
אז אם הייתי מבצע את הבדיקה הזאת במחשב הלקוח, המחשב של הלקוח היה בודק האם שם פרטי קיים בתיבת הטקסט או לא קיים, במידה ושם פרטי לא קיים בתיבת הטקסט, המחשב של הלקוח היה יכול פשוט מאוד לבטל את הריצה לשרת ולהציג הודעת שגיאה.
היתרון בשיטה הזאת כמובן, חסכתי לעצמי ריצה מיותרת לצד של השרת. אבל איזה בעיה הייתה יכולה לעלות במידה והבדיקה הייתה מתבצעת במחשב הלקוח? בואו נחשוב, איך הבדיקה אמורה להתבצע במחשב הלקוח?
במחשב הלקוח, מחשב שמריץ את הדפדפן, הבדיקה יכולה להתבצע בהפרת שפת סקריפט שהדפדפן מכיר ומסוגל להריץ.
לדוגמה ג'אווה סקריפט. הבעיה קיימת כאשר לא כל דפדפן מסוגל להריץ ג'אווה סקריפט. הדפדפנים הגדולים תומכים בג'אווה סקריפט. דפדפנים נדירים ונפוצים פחות לא מכירים ג'אווה סקריפט לפעמים.
ולכן, במידה והבדיקה הייתה רק בצד הלקוח, יכול להיות שדפדפן מסוים לא תומך בג'אווה סקריפט ויכול להיות דפדפן שכן תומך בג'אווה סקריפט אבל מבחינת הלקוח, הלקוח לא מאשר לו להריץ ג'אווה סקריפט.
זאת הגדרה של הדפדפן. במצב כזה הבדיקות בצד הלקוח לא יתבצעו ואכן יגיע מידע לא תקין בצד של השרת. אז התשובה לשאלה ששאלתי מקודם היא היכן צריכה להתבצע הבדיקה?
התשובה היא הבדיקה צריכה להתבצע גם בצד הלקוח וגם בצד השרת. הסיבה שהבדיקה צריכה להתבצע בצד הלקוח זה בגלל שרוב הדפדפנים תומכים בג'אווה סקריפט ויבצעו את הבדיקה בג'אווה סקריפט והבדיקה תגרום לחיסכון בריצה מיותרת לשרת ברוב רוב המקרים.
הסיבה שהבדיקה צריכה להתבצע בנוסף בצורה חוזרת גם בצד השרת היא בגלל שיכול להיות מצב שאחוז קטן מהגולשים לא תתבצע הבדיקה אצלהם בג'אווה סקריפט בין אם דפדפן שלהם לא תומך בג'אווה סקריפט ובין אם הם לא אישרו הרצאת JavaScript בדפדפן שלהם אפילו שהוא תומך ב-JavaScript.
במצב כזה הבדיקה צריכה לחזור שוב פעם במחשב השרת בשפת SP.NET כמובן עם שפת C-Sharp בכדי למנוע מצב שבו לקוח שלא בדק ב-JavaScript אכן שלח לי מידע שגוי.
אז אנחנו צריכים עכשיו לחשוב איך לבצע את הבדיקה הזאת שמידע קיים או לא קיים בתיבת הטקסט גם בצד הלקוח וגם בצד השרת. אנחנו הולכים לעשות את זה אפילו בלי לכתוב שורת קוד אחת.
בואו נסתכל איך זה מתבצע. יש לנו את הטולבוקס. בטולבוקס ישנו טאב מיוחד שנקרא ולידיישן. בטאב הזה ישנם מספר רכיבים