מסתבר, שאחת הדרכים המוכרות והפשוטות ביותר לשליחת וקבלת מידע ע"י פלאש היא באמצעות המחלקה LoadVars של ActionScript. למעשה, המימוש של LoadVars דומה יותר לטעינת קובץ מקומי מאשר למימוש תקשורת על גבי פרוטוקול HTTP, כשהקשר היחיד ביניהם הוא אירוע onHTTPStatus, שמחזיר את קוד המצב של הHTTP כשזה משתנה.

המחלקה LoadVars מסוגלת לבצע שאילתות GET וPOST, ולקבל נתונים בפורמט application/x-www-form-urlencoded שזה בעצם אותו פורמט הנתונים שמשמש אותנו למסירת פרמטרים בURL, וכן להעברת תגיות הFORM על גבי פרוטוקול HTTP בשאילתות POST. המעלה הברורה כאן היא הפשטות, כשהחיסרון, הבולט לא פחות, הוא הצורך לקודד הכל ובכך להכפיל את כמות התעבורה ברשת. חיסרון נוסף הוא היעדר אפשרות מובנית לביטוי הירארכיה (כמו JSON או XML), אך זה ניתן לתיקון ע"י יצירת פורמט נתונים מותאם אישית. אך לא על זה באתי לדבר.

במאמר הזה באתי לתאר פתרון שכתבתי לצורך תקשורת יעילה בין אפליקציית Web בASP.NET לבין אפליקציית Flash באמצעות המחלקה LoadVars. עוד...

נשאלה השאלה, איך אני מאגד את שלשת השדות של תאריך הלידה (יום, חודש ושנה) לערך אחד עבור ואלידציה (Validation)?

במצב הקיים, צריך להשתמש בשלש ואלידאטורים (Validators) מסוג RequiredFieldValidator ועוד 3 מסוג RangeValidator עבור טווח הערכים (למשל ימי החודש הם מ1 עד 31), וכל זה עדיין לא יעזור אם נרצה לבדוק טווח עבור כל התאריך בשלמות ולא עבור כל חלק שלו בנפרד. לפתרון לבעיה זו כתבתי WebControl שיורש מ – BaseCompareValidator בשם DateFieldsValidator.

DateFieldsValidator פותר את כל הבעיות שהזכרתי,

• מכיל מאפיינים עבור 3 שדות (גם TextBoxים וגם DropDownListים ובעצם, כל דבר שנתמך ע"י הואלידאטורים הסטנדרטיים) אחד עבור כל חלק בתאריך
• מכיל מאפיינים MinimumValue וMaximumValue לבדיקת טווח עבור התאריך בשלמותו.
• לא תלוי בCulture מסויים (CultureInvariant).
• מבצע וולידציה הן בצד לקוח (ללא רענון הדף), והן בצד שרת (במקרה שJavaScript מבוטל או לא נתמך בלקוח).
• וכן תומך גם בכל הפיצ'רים האחרים של פקדי הואלידאציה הסטנדרטיים בFramework. עוד...

במאמר זה נביא מספר טיפים לשימוש במחלקות ממרחב שמות System.Xml מול תוכן Xhtml. וכן פתרונות לבעיות תאימות בין התקנים. הבעיות שנסקור כאן הם: איך לגרום לקורא Xml לא להתעלם מרווחים בין התגים, ואיך לקצר את זמן הטעינה על ידי דילוג על Validation מול www.w3.org.

דבר ראשון, נשים לב לבעיה קטנה שתצוץ בכל פעם שננסה לפתוח תוכן Xhtml ע"י מחלקות ממשפחת System.Xml, כל הרווחים שבין התגים ייעלמו לדוגמה השורה הבאה: עוד...

במאמר הזה נציע מספר פתרונות מעשיים למקרים בהם צריך להציג שעה מסוימת למשתמשים באזורי זמן שונים.

ניקח לדוגמה מערכת פורום. דוד, מזין הודעה בשעה 13:00 ממחשב בישראל (GMT +2), אלי שגר באנגליה בגריניץ' (GMT) יראה בשעה 11:00 אצלו את ההודעה שזה עתה נוספה לפורום - בעוד שעתיים בשבילו. זה יקרה במקרה שהשרת כשירשום את ההודעה למסד הנתונים, יצרף אליה את שדה "שעת יצירה" לפי שעון ישראל. למרות שגם אם השרת ירשום את השעה לפי שעון גריניץ' עדיין תהיה אי נוחות לדוד לראות שהודעתו צורפה שעתיים לפני שהוא צירף אותה בפועל.

המסקנה המתבקשת היא, שלא משנה לפי איזה איזור זמן תשמור את הנתונים, צריך להמיר אותם לפני ההצגה עבור כל משתמש  לגופו. אנו נסקור כאן שני דרכים להתמודדות עם הבעיה ואת חסרונותיהם. בכל הדוגמאות השרת ישמור את הנתונים לפי שעון GMT. עוד...

למרות שהמאמר הזה כבר פורסם באדיבות בבלוג של ג'סטין אנג'ל, אביא אותו אצלי בשנית, בעיקר בגלל שראיתי את השאלה הזאת עולה שוב ושוב בפורומים השונים.

הפתרון הבא עוסק בזיהוי נכון של קידוד דף הWeb בשימוש במחלקות כמו WebRequest. הבעיה במקרים אלו היא שלא תמיד בוני האתרים טורחים לשלוח עם הדפים שהם כותבים את הHeader (כותרת http) שמזהה את קידוד הדף, ולכן במקרים אלו צריך קודם לקרוא את הדף עד הסוף, ורק אז לשלוף את כותרת הmeta המתאימה מהדף עצמו ולקודד איתה את הדף. עוד...

הבעיה שבה נתקלתי היא, למצוא דרך נוחה להשתמש באותה הפונקציה (בדוגמה שלנו זה ‏BasicPattern‏) בתוך ומחוץ ל‏SqlTransaction‏ בלי לשכתב אותה פעמיים.‏

מאילוצי המבנה של ספריות ה‎.NET‎‏ יש צורך לכתוב כל אחת מהפונקציות האלה (ובמקרים רבים יש הרבה כאלה) פעמיים: פעם אחת תוך פתיחת חיבור חדש למסד הנתונים, ופעם שנייה תוך שימוש בחיבור שכבר נפתח עבור הטרנסקציה ע"י הפונקציה הקודמת (בדוגמה שלנו זה ‏SimpleTransactionPattern‏).

הפתרון שלי בא בצורת מחלקה חדשה שהענקתי לה את השם ‏DbConnection‏. במחלקה קיימים שני ‏Constructorים:

1. New(ByVal enforceTransaction As Boolean)‎
2. New(ByVal connection As DbConnection, ByVal enforceTransaction As Boolean)

המתאימים לאתחול המחלקה כמופע ראשוני או כמופע מקונן. מופע ראשוני הוא זה שבעצם פתח את החיבור ורק הוא יוכל לסגור אותו. להבדיל, המופע מקונן ישתמש בחיבור ובטרנסקציה (אם קיימת) של המופע הראשוני ולא יוכל לסגור את החיבור.
הבנאי הראשון מקבל רק פרמטר אחד שקובע אם צריך לפתוח טרנסקציה. הבנאי תמיד יבנה מופע ראשוני של המחלקה. הבנאי השני דומה לבנאי הראשון בהבדל אחד, שאם מעבירים לו כפרמטר מופע אחר של המחלקה הוא יבנה מופע מקונן של המחלקה. עוד...