11 במאי 2022, 22:11
@amp-Software-0 אמר במחיקת פרמטר שנשלח ב read:
בדיקה אם המשתמש כבר הקיש ערך ב approval
אז למה שלא תעשה לכל approval,read נפרד?
מחיקת פרמטר שנשלח ב read
-
@איש-ימיני
בקיצור ממה נפשך אם ימות שולחים הכל מההתחלה אז זה נדרס ואם לאו אז דרוס לבד -
באם שולחים שוב את אותו בקשה מקבלים רק את התשובה השניה, כלומר ימות דורסים את מה שנשלח קודם
אבל עדיין זה לא יעזור לי
כי הרי אני צריך לבדוק (באמצעותisset($_GET['approval'])), אם המשתמש הקיש כבר את התשובה ל approval אז שיבצע פעולה בהתאם, ואם הוא לא הקיש שיבקש ממנו את approval באמצעות read
[כדי שאחרי שהוא יקיש, הסקריפט ידע לא לבקש ממנו את זה שוב אלא להתקדם הלאה]
עכשיו, בפעם השניה שאני יצטרך את approval אני לא יוכל לבדוק את הבדיקה הנ"ל, מכיון שבכל מקרה אני יקבל תשובה שהמשתמש כבר הקיש - מהפעם הקודמת, אז אין לי אפשרות לדעת אם הוא כבר הקיש או לא בפעם הנוכחית
לצורך זה רציתי אפשרות לשדר לימות שימחקו את הפרמטר הזה, שלא ישלחו לי אותו שוב, ואז בפעם השניה שאני יבקש אותו הבדיקה תהיה באמת אפקיטיבית אם הוא כבר הקיש או לא -
@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 להבנתי הפתרון הכי נכון הוא שיהיה אפשר להגדיר בשלוחה/תגובת שרת שהערך הקודם יידרס.
זה מצריך פיתוח מצד ימות המשיח
מציע לך לפנות במייל ולבקש הצעת מחיר ו/או לפתוח שרשור חדש ב"הצעות לפיתוח"