לאחרונה, כתבתי מחלקה קטנה לטיפול בעוגיות.
מקווה שתוכלו להרוויח מכך.

http://www.codepost.org/view/440

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

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

דוגמא:

קוד PHP:

 Cookie.Write("xx","this will appear twice",1);
Cookie.Write("x","bla bla",1);

alert(Cookie.Read("xx")+"\n"+Cookie.Read("x")); 


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

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

תודה על ה-Feedback

any time

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

בכל מקרה, עדכנתי את הסקריפט עם השינויים שהצעת
http://www.codepost.org/view/440

רוב תודות.

עדכון:
אני מצרף קישור עם דוגמא לשימוש - http://213.8.106.62/db/files/cookie.htm

נראה טוב
אני רואה שאני לא היחיד שלקח רעיון או שניים מפרוטוטייפ($)

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

אני האמת, לא ממש אוהב את כל ה-prototype למניהם. אני אף פעם לא הייתי מסוגל לערוך אותם שיתאימו לי...

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

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

אני משתמש בזה - http://www.fresh.co.il/vBulletin/sh...ad.php?t=161824
גם אני לעולם לא משתמש ב-inline script - חוץ מבדוגמאות.
עוד לא הבנתי למה רוב המדריכים ברשת, ממשיכים להמליץ על שימוש ב-eval

ציטוט:

מה ניתן להסיק מהתוצאות: שאני טעיתי כל הזמן הזה ( )

חבל שההודעה המדוברת לא נמצאת בארכיון (בלי קשר שאני כתבתי אותה ).

על מה אתה מדבר?

אמרתי לך "מחר", אך זה נמשך למחק, מחר ומחר... אז איכשהו החלטתי שהגיע סוף סוף הזמן לעשות לזה זמן

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

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

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

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

3. בנוסף בבדיקה בלולאה, נראה לי מיותר לעשות 2-3 בדיקות, במיוחד שאפשר ליצור את המערך באמצעות split עם המחרוזת "; " (התו נקודה פסיק ולאחריו תו רווח - בדקתי באיכספלורר 6 וכמובן בשועל, בשניהם לא נראתה בעיה להשתמש ביותר מתו אחד) ואז תמיד לבצע בדיקה אחת - האם הערך שווה ל-0.

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

על 2 השיטות הנותרות אין לי אף הערה, מחלקה מעולה

קוד:

function getCookVal(name)
{
	var pos, pos2, cook=document.cookie;

	if(cook.indexOf(name + '=') == 0)
		pos = cook.indexOf(name + '=');
	else
		pos = cook.indexOf('; ' + name + '=');

	if(pos == (-1))
		return false;

	pos += name.length + 1
	pos2 = cook.indexOf(';', pos);

	if(pos2 != (-1))
		cook = cook.substring(pos, pos2);
	else
		cook = cook.substring(pos);

	return cook;
}

דבר ראשון, תודה על התגובה
שנית, ערכתי את הקוד עפ"י ההערות שציינת (חלק מהם לפחות) והוא מופיע כאן: http://www.codepost.org/view/440

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

2. לא ממש ירדתי לסוף דעתך. למה בדיוק הכוונה?
3. אכן. האמת שממש לא העלתי על דעתי לפתור את העניין בדרך הזו ובמקום זה ביצעתי *עוד* שני בדיקות מיותרות לחלוטין - עודכן.
4. אופס . אכן מיותר לחלוטין - אחרי שהעברתי את ההשמה לבלוק של ההתניה הבנתי שאין בו צורך לכן הוא ירד לחלוטין.

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

2. לפני ביצוע הקוד:

קוד:

sGetNames = document.cookie.split("; ")

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

5. במבט נוסף נראה כי גם בשיטה Write כדאי להכניס את שלושת שורות הקוד הראשונות בתוך התנאי כבדוגמה הזאת:

קוד:

if(iDays)
{
	var dCurrent = new Date();
	dCurrent.setTime(dCurrent.getTime()+(iDays*24*60*6  0*1000));
	iDays = '; expires=' + dCurrent.toGMTString();
}
else
{
	iDays = '';
}

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

יתכן שגם קטע ה-else מיותר, רק כתבתי אותו כדי להיות בטוח שדפדפן כלשהוא לא יחזיר "Undefined".

ב javascript כל משתנה שלא הוגדר עם var שומר על הערך למשך כל התכנית (כמו משתנה שהוגדר בתוך פונקציה בעזרת static, בשפות מבוססות C )
אז typeof sGetNames == "undefined" יחזיר false רק בפעם הראשונה שהשיטה Read נקראת.

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

אבל אני לא מכיר דפדפן אחד שהיה מפרש את זה בצורה שונה.

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

http://www.codepost.org/view/440

לקחתי את הרעיון שלך. זו דרך יותר נכונה לעבוד ובעקרון אני לא ממש יודע למה זה עבד עד עכשיו
אני מצרף את הקוד ללא ההערות...

קוד PHP:

 var Cookie = {
    Read: function(sName){
        if(typeof sGetNames == "undefined" || sGetNames != document.cookie) sGetNames = document.cookie.split("; ");
        for(var i=0; i<sGetNames.length; i++){
            if((sGetNames[i].search(sName+"=") == 0)){
                return sGetNames[i].substring(sGetNames[i].search("=")+1, sGetNames[i].length);
            }
        }
        return false;
    },
    
    Write: function(sName, sValue, iDays){
        if(iDays){
            var dCurrent = new Date();
            dCurrent.setTime(dCurrent.getTime()+(iDays*24*60*6  0*1000));
            var sExp = "; expires="+dCurrent.toGMTString();
        }else sExp = "";
        document.cookie = sName.concat("=", sValue, sExp, "; path=/");
    },
    
    Remove: function(sName){
        this.Write(sName, "", -1);
    }
}; 


גם זאת נכנסת לארכיון