מחיקת פרמטר שנשלח ב read
-
@amp-Software-0 אפשר להגדיר בערך השני שלא יבקש שוב. ושישאר עם מה שנקלט כבר.
-
@amp-Software-0
למשל אם הוא הקיש למעלה מ20 אז הוא מבקש אישור אחרי שאתה מקבל את האישור ויצאת מה exit תדרוס את הנתון -
@avrham
לא הבנתי מה אתה מתכוין.אני אולי יסביר יותר בפירוט את הבעיה:
אם אני צריך במוצרים מסויימים אישור על כמות חריגה.
צורת קבלת האישור ממשתמש מתבצעת על ידי שליחתreadעם פרמטרapprovalבצורה כזו:- במקרה שהוקשה הקשה חריגה
- בדיקה אם המשתמש כבר הקיש ערך ב
approval - אם לא הקיש - הדפסת בקשת
readלקבל את הפרמטרapproval - אם כבר הקיש- לפעול בהתאם למה שהקיש
אוקי, הלאה.
נניח שבמוצר מספר 004 הוקשה כמות חריגה, והוא הקיש לי 1 (אישור) בפרמטרapproval
זאת אומרת שמעכשיו והלאה הסקריפט מקבל כל הזמן פרמטרapproval=1כעת, אם במוצר 010 אני שוב צריך לבקש ממנו אישור,
שוב הטכניקה דלעיל לא תעבוד לי, מכיון שאין לי דרך לבדוק את הבדיקה הנ"ל (האם להדפיס לו בקשתreadעל אישור הכמות, או לפעול בהתאם למה שהקיש) כי ערךapprovalכבר מאוכלס!
לכן אני חייב למחוק את ערךapprovalאחרי שלב 4 דלעיל, כך שימות המשיח לא ישלחו לי אותו יותר, ואז כשיגיע למוצר 010 הבדיקה תעבוד מצויין כי אכן הבדיקה אםapprovalמאוכלס תהיה אפקטיביתתודה לכל המשיבים! (אין לי מספיק מוניטין כדי להצביע..)
-
@amp-Software-0 אמר במחיקת פרמטר שנשלח ב read:
לכן אני חייב למחוק את ערך approval אחרי שלב 4 דלעיל,
ומה הבעיה?
-
@nyh אמר במחיקת פרמטר שנשלח ב read:
@amp-Software-0
מה אם unset($_GET['aproval'])?unsetמסיר את הפרמטר מהאובייקט$_GETאבל זה עוזר רק לפעם הנוכחית, בשליחה הבאה ימות המשיח ישלחו לי את זה שוב.. -
@לעזור-לכולם אמר במחיקת פרמטר שנשלח ב read:
@amp-Software-0 אמר במחיקת פרמטר שנשלח ב read:
לכן אני חייב למחוק את ערך approval אחרי שלב 4 דלעיל,
ומה הבעיה?
איך אני מוחק? הרי זה פרמטר שימות שולחים אלי ב URL לשרת
איך מוחקים כזה ערך? גם אם אני מוחק בסרקיפט אצלי את הערך, עדיין, ב read הבא אני שוב יקבל אותו מימות -
@amp-Software-0 אוקיי, אז ברגע שנתקבל מידע מימות ב read תשמור אותו במשתנה/ קובץ אחר. ואז תקרא לו . מה הבעייה?
-
@amp-Software-0 אמר במחיקת פרמטר שנשלח ב read:
בדיקה אם המשתמש כבר הקיש ערך ב approval
אז למה שלא תעשה לכל approval,read נפרד?
-
@לעזור-לכולם
אתה צודק, זה אחד הקומבינות שעשיתי. זה אמנם עונה על הבעיה שהצגתי לעיל, אבל לא פותר אותה באופן מלא.
עדיין תשאר הבעיה באותו read בעצמו, כלומר באותו מוצר ממש.
נגיד אם הוא הקיש כמות חריגה במוצר 004 ורוצה לתקן, אז אני שולח לו שוב read לקבל כמות מוצר 004, עכשיו כעת אחרי שהוא הקיש את הכמות והיא שוב פעם חריגה אין לי אפשרות לוודא את זה מולו, כי כבר קיבלתי את ה approval למוצר הספציפי הזה... -
@avrham אמר במחיקת פרמטר שנשלח ב read:
@amp-Software-0 אוקיי, אז ברגע שנתקבל מידע מימות ב read תשמור אותו במשתנה/ קובץ אחר. ואז תקרא לו . מה הבעייה?
כי המשתנה ימחק
הרי בכל read מתבצעת קריאה מחודשת לשרת, ככה שהמשתנים מתאפסים
האפשרות היחידה זה לאכלס את זה ב db (ליצור טבלה שמכילה את כל החיוגים, ולאחסן את הפרמטר ברשומה של השיחה לפי מזהה השיחה), זה גם אפשרות שעשיתי פעם. כמובן שזה קובמינה מאוד לא נוחה, ולא תקינה.. -
@amp-Software-0
עריכה טעיתי
כמובן גם לזה אפשר לעשות קומבינה
אבל באמת עדיף שימות יסדרו את זה -
למה שלא תקרא לזה approval-004?
-
@amp-Software-0 אמר במחיקת פרמטר שנשלח ב read:
עדיין תשאר הבעיה באותו read בעצמו, כלומר באותו מוצר ממש.
נגיד אם הוא הקיש כמות חריגה במוצר 004 ורוצה לתקן, אז אני שולח לו שוב read לקבל כמות מוצר 004, עכשיו כעת אחרי שהוא הקיש את הכמות והיא שוב פעם חריגה אין לי אפשרות לוודא את זה מולו, כי כבר קיבלתי את ה approval למוצר הספציפי הזה... -
@לעזור-לכולם אמר במחיקת פרמטר שנשלח ב read:
@amp-Software-0 אמר במחיקת פרמטר שנשלח ב read:
עדיין תשאר הבעיה באותו read בעצמו, כלומר באותו מוצר ממש.
נגיד אם הוא הקיש כמות חריגה במוצר 004 ורוצה לתקן, אז אני שולח לו שוב read לקבל כמות מוצר 004, עכשיו כעת אחרי שהוא הקיש את הכמות והיא שוב פעם חריגה אין לי אפשרות לוודא את זה מולו, כי כבר קיבלתי את ה approval למוצר הספציפי הזה...OK.
@amp-Software-0
בשביל זה אפשר לעשות בדיקה אם approval-004 קיים כבר תקרא לו approval-004-0\1\2 וכו' ותתיחס בתכלס רק למספר הכי גבוהה -
-
@MGM-IVR אמר במחיקת פרמטר שנשלח ב read:
@לעזור-לכולם אמר במחיקת פרמטר שנשלח ב read:
@amp-Software-0 אמר במחיקת פרמטר שנשלח ב read:
עדיין תשאר הבעיה באותו read בעצמו, כלומר באותו מוצר ממש.
נגיד אם הוא הקיש כמות חריגה במוצר 004 ורוצה לתקן, אז אני שולח לו שוב read לקבל כמות מוצר 004, עכשיו כעת אחרי שהוא הקיש את הכמות והיא שוב פעם חריגה אין לי אפשרות לוודא את זה מולו, כי כבר קיבלתי את ה approval למוצר הספציפי הזה...OK.
@amp-Software-0
בשביל זה אפשר לעשות בדיקה אם approval-004 קיים כבר תקרא לו approval-004-0\1\2 וכו' ותתיחס בתכלס רק למספר הכי גבוההאתה צודק זה רעיון מצויין
[אני חשבתי לעשות approval-004-20 כלומר להכניס את הכמות שהוא הקיש ביחד עם המוצר, הבעיה אם הוא יקיש אותה פעם נוספת... (למרות שאם הוא יקיש 1 הוא יעבור, אבל למקרה שהקיש 2 ואז התחרט)
בפתרון שלך זה פותר גם את זה] -
@מנסה אמר במחיקת פרמטר שנשלח ב read:
איפה אתה שומר את המוצרים שהוא מזמין תוך כדי שיחה?
[אולי תוכל לשחק אם שלוחות]
בדאטה בייס חיצוני
כל בחירה של כמות נרשם מיידית ב db -
@amp-Software-0 להבנתי הפתרון הכי נכון הוא שיהיה אפשר להגדיר בשלוחה/תגובת שרת שהערך הקודם יידרס.
זה מצריך פיתוח מצד ימות המשיח
מציע לך לפנות במייל ולבקש הצעת מחיר ו/או לפתוח שרשור חדש ב"הצעות לפיתוח" -
@amp-Software-0 אמר במחיקת פרמטר שנשלח ב read:
לצורך זה רציתי אפשרות לשדר לימות שימחקו את הפרמטר הזה, שלא ישלחו לי אותו שוב, ואז בפעם השניה שאני יבקש אותו הבדיקה תהיה באמת אפקיטיבית אם הוא כבר הקיש או לא
@eliyahu זו המסקנא שגם אני הגעתי אליה, אבל כתבתי כאן למקרה ואולי יש למישהו פתרון פשוט יותר, כמו שבאמת הציעו כאן כמה
-
אתה יכול [אולי] לעשות שאת אישורי הכמות החריגה יהיה בשלוחה אחרת, [זאת אומרת שזה יעביר אותו לשלוחה ששואלת האם לאשר או לא, ולפי התשובה שם תטפל בנתונים שבDB שלך
אח"כ תחזיר אותו לשלוחה הרגילה מהמקום בו הוא נמצא [אם זה שייך אצלך, תלוי בצורת התקשור]
-
הוזכר על-ידי ל לעזור לכולם
-
הוזכר על-ידי C Chaim