טכניקות ניידות

JS, כמו JAVA , היא אחת מהשפות מזן חדש, בעלות "במה עצמאית"- "platform-independent", וכך ניתן לפתח תכנית ב-JS, ולצפות שנוכל להריץ אותה, ללא כל שינוי על דפדפן רשת התומך בשימוש ב-JS, באמצעות כל סוג של מחשב בעל מערכת הפעלה כלשהי.

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

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

א. מאפייני פלטפורמה, דפדפן וגרסה ומפרטיהם ( )specification.
ב. באגים ורמת-שפת-הניידות, כולל חוסר הניידות של JS עבור דפדפנים שאינם תומכים בה.

נסמן : i.e = Internet Explorer n = Navigator

1. ניידות פלטפורמה ודפדפן

כאשר מפתחים קוד JS בעל תפוקה איכותית - בדיקות וידע של מפרט פלטפורמה, מפרט ספק ומפרט גרסא בנושא חוסר ניידות, הם "בעלי הברית" הראשיים שלנו. אם אנו יודעים, לדוגמא, ש n-2, על פלטפורמת Macintosh מספקת את הזמן באופן שגוי, בסביבות שעה בערך, נוכל לפעול על מנת להתמודד עם זה.

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

אם אנו יודעים כי i.e 4 ו- n-4 תומכים במידה רבה במודלים דינמיים שונים של html, נוכל לכתוב דפים שישתמשו במנגנון המתאים בהסתמך על הדפדפן שבשימוש.

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

א. הגישה של Least-Common-Denominator

אחת מהטכניקות להתמודד עם חוסר ניידות היא להתחמק מהם כמו ממגיפה/ מטרד.
לדוגמא, האובייקט Date ב-n-2 מחולל באגים באופן הידוע לשמצה. אם נרצה כי משתמשי n-2 יוכלו להשתמש בתכניותינו, אנו יכולים פשוט להימנע משימוש באובייקט זה, ולא לסמוך על שימוש בו.

דוגמא נוספת היא ש n-3 ו i.e-3 תומכים בתכונה opener של האובייקט Window, אך n-2 לא. גישה זו אומרת, כי לא נשתמש בתכונה זו וניצור בעצמנו תכונה זהה , כאשר נפתח חלון חדש.

newWin = window.open("", "new", "width=500, height=300");
newWin.creator = self;

ב . גישת הקוד ההגנתי

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

לדוגמא, אם נאתחל את תכונת ה- status של אובייקט ה- Window מהאירוע onMouseOver על מנת להציג הודעה מותאמת בשורת המצב, שורת המצב מתנקה כאשר מזיזים את העכבר מהקישור מלבד במערכת ההפעלה Windows בגירסאות n-2,3. על מנת לתקן זאת, נוכל לסגל לעצמנו את ההרגל של לכלול את האירוע onMouseOut על מנת לנקות את שורת המצב.

יצירת טכניקה על מנת לבחון את הימצאותה של מתודה בגרסא מסוימת. לדוגמא, המתודה ( )split של אובייקט ה- String קיימת רק עבור יישומי גרסא 1.1 .

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

if(s.split)
  a = s.split(":");
else
  a = mysplit(s,":");

ג. שיטת עקיפת הבאגים

כאשר שתי השיטות הקודמות אינן עובדות, נמצא עצמנו עובדים על פי שיטת עקיפת הבאגים. דוגמא לכך נוגעת לתכונת ה- bgColor של אובייקט ה- Document.

ב- windows ו- macintosh , ניתן לאתחל תכונה זו בזמן ריצה על מנת לשנות את צבע הרקע של המסמך.
לרוע המזל, כאשר ננסה לבצע זאת ב- unix בגרסאות n-2,3 , הצבע משתנה, אך, תכן המסך נעלם באופן זמני.

אם רצינו ליצור אפקט מיוחד על ידי שינוי צבע הרקע, יכולנו להשתמש באובייקט ה- Navigator לבדיקה בפלטפורמת unix, ובפשטות להימנע מן האפקט המיוחד עבור פלטפורמה זו, הקוד ייראה כך :

var nobg = (parseInt(navigator.appVersion) < 4) && 
           (navigator.appName.indexOf("Netscape") != -1) && 
    	   (navigator.appVersion.indexOf("X11") != -1);
if(!nobg)
  animate_bg_color();

ד. התעלמות מהבעיה

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

ה. להיכשל בחינניות

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

לדוגמא, טכניקת החלפת התמונה – The Document Object Model אינה עובדת ב- n-2 או i.e.-3 ואין שום שיטה לעקוף זאת. איננו יכולים אף להתפתות בלהריץ את התכנית על פלטפורמות אלו, ובמקום, עלינו להודיע בנימוס למשתמש על חוסר הניידות.

2. ניידות בדפדפנים ללא Java Script

אלו הם דפדפנים אשר אינם בעלי יכולות JS, או דפדפנים אשר המשתמש מנע את אפשרות השימוש ב-JS בשל בעיות אבטחה. בשל העובדה, כי דפדפנים אלו אכן קיימים, עלינו לעצב את האתר שלנו כך שהדפים ייכשלו "בחינניות".
על מנת לבצע זאת, עלינו לנקוט שתי פעולות :

עלינו להבטיח כי קוד ה- JS אינו מופיע כאילו הינו קוד HTML.

עלינו להציג הודעה למשתמש /המבקר באתר כי אין באפשרות הדפדפן שלו להציג את הדף כראוי.

דפדפנים התומכים ב- JS, מבצעים את הקוד בתוך תגי <script> ו- <script/>.
דפדפנים שאינם תומכים ב-JS, מזהים תגים אלו ובפשטות מתעלמים מתכן הקוד הכלול בתוכם.
דפדפנים ישנים, אינם מכירים תגים אלו כלל, ולכן אינם מסוגלים לזהותם ומתייחסים אל כל אותו קוד כאל טקסט של HTML.

באם לא ננקוט צעדים על מנת למנוע זאת, משתמשים בעלי דפדפנים ישנים, יראו את כל אותו קוד JS בתור התכן של הדף שיהיה מוצג עבורם. על מנת למנוע זאת, נעטוף את קוד ה-JS שלנו בתוך הערת HTML כבדוגמא זו :

<SCRIPT LANGUAGE="Java Script">
  <!- כאן מתחילה ההערה על מנת להחביא את הסקריפט 
    // -JS כאן מגיע קוד ה 
  --> כאן מסתיימת ההערה המחביאה את הסקריפט
</SCRIPT>