מחזור החיים של מחבר: למה כל מופע מתחיל כטיוטה ובמצב דמה

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

יצירה לעולם לא מגיעה למערכת אמיתית

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

סטטוס ומצב, ומה כל אחד באמת עונה עליו

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

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

השרת בודק מראש את הכשל היחיד שאחרת היה שקט

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

זו פעולה, לא דגל

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