יצירת מחלקה עם כל ההגדרות - Config Class - חלק 2

תמלול ההרצאה: יצירת מחלקה עם כל ההגדרות - Config Class - חלק 2

הטקסט המלא של הדקות הראשונות בהרצאה «יצירת מחלקה עם כל ההגדרות - Config Class - חלק 2» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.

1. 00:02

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

2. 00:24

   לשרת אמיתי. אז אתם יכולים להגיד לי, טוב, מה הבעיה? כשסיימת לתכנת, שנייה לפני שאתה מעלה את זה לשרת אמיתי, בוא נניח שכתובת השרת האמיתי זה, בוא נניח הכתובת, נרשום אותה פה רגע, http://www.mysite.com זאת הכתובת האמיתית.

3. 00:49

   אם זאת הכתובת האמיתית אז בתוכה כנראה יהיה API/Products כי ברגע שאנחנו חושפים מערכת מ-Restful Service, REST API אז נהוג זה יהיה api ובתוכו הדברים השונים שאנחנו חושפים, מוצרים, עובדים, לקוחות, ספקים, זה משהו שהוא מאוד מקובל. אז אם זה השרת הזה מקומית חושף את הנתיבים האלה פה ככה ב-localhost 3030 כאשר

4. 01:19

   אנחנו בשרת מרוחק בואו נגיד שהשרת הזה נקרא נורפרינג. נניח קנינו את הדומיין נורפרינג אז יהיה לנו שרת שנקרא נורפרינג.com כנראה שבתוכו יהיה api/products זה השרת האמיתי שאנחנו נעלה אליו את המידע.

5. 01:37

   מה הבעיה? שנייה לפני שאתה מעלה את זה לאוויר, קח את זה, שים פה, תשנה ותעלה לאוויר. נראה פשוט.

6. 01:50

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

7. 02:15

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

8. 02:39

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

9. 02:54

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

10. 03:14

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

11. 03:31

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

12. 03:50

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

13. 04:10

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

14. 04:28

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

15. 04:59

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

16. 05:19

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

17. 05:38

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