כשאתה כותב תוכניות משלך מההתחלה ועד הסוף, קל לראות אותה בקרת זרימה. התוכנית מתחילה כאן, יש שם לולאה, שיחות שיטה נמצאות כאן, הכל גלוי. אבל ביישום Rails הדברים אינם כה פשוטים. במסגרת כלשהי, אתה מוותר על שליטה בדברים כמו "זרימה" לטובת דרך מהירה יותר או פשוטה יותר לבצע משימות מורכבות. במקרה של Ruby on Rails, כל בקרת הזרימה מטופלת מאחורי הקלעים, וכל מה שנשאר לך הוא (פחות או יותר) אוסף דגמים, מבט ובקרים.
הליבה של כל יישום אינטרנט הוא HTTP. HTTP הוא פרוטוקול הרשת בו דפדפן האינטרנט שלך משתמש כדי לדבר עם שרת אינטרנט. מכאן מגיעים מונחים כמו "בקשה", "GET" ו- "POST", הם אוצר המילים הבסיסי של פרוטוקול זה. עם זאת, מכיוון שהמסילה היא הפשטה של זה, לא נבלה הרבה זמן לדבר על זה.
כשאתה פותח דף אינטרנט, לחץ על קישור או הגש טופס בדפדפן אינטרנט, הדפדפן יתחבר לשרת אינטרנט באמצעות TCP / IP. לאחר מכן הדפדפן שולח לשרת "בקשה", חשוב על זה כמו טופס דואר שהדפדפן ממלא ומבקש מידע בדף מסוים. השרת מעביר בסופו של דבר לדפדפן האינטרנט "תגובה". אולם Ruby on Rails אינו שרת האינטרנט, שרת האינטרנט יכול להיות כל דבר מ- Webrick (מה שקורה בדרך כלל כשאתה מפעיל שרת Rails מ- ה
שורת פקודה) ל- Apache HTTPD (שרת האינטרנט שמספק את מרבית האינטרנט). שרת האינטרנט הוא רק מנחה, הוא לוקח את הבקשה ומעביר אותה ליישום Rails שלך, מה שמייצר את התגובה והמעבר חוזר לשרת, שבתורו מחזיר אותה לשרת לקוח. אז הזרימה עד כה היא:אחד הדברים הראשונים שיישום Rails עושה בבקשה הוא לשלוח אותו דרך הנתב. לכל בקשה יש כתובת אתר, זה מה שמופיע בסרגל הכתובות של דפדפן אינטרנט. הנתב הוא שקובע מה לעשות עם אותה URL, אם כתובת האתר הגיונית ואם כתובת האתר מכילה פרמטרים כלשהם. הנתב מוגדר ב- config / routes.rb.
ראשית, דעו כי המטרה הסופית של הנתב היא להתאים כתובת URL לבקר ופעולה (עוד על אלה בהמשך). ומכיוון שרוב יישומי Rails הם RESTful, ודברים ביישומי RESTful מיוצגים באמצעות משאבים, תראה שורות כמו משאבים: הודעות ביישומי Rails טיפוסיים. זה תואם לכתובות אתרים כמו /posts/7/edit עם בקר ההודעות, ערוך פעולה בדואר עם מספר 7. הנתב רק מחליט לאן ללכת בקשות. כך שניתן להרחיב מעט את חסימת [Rails] שלנו.
כעת, לאחר שהנתב החליט לאיזה בקר ישלח את הבקשה, ואיזו פעולה על אותו בקר, הוא שולח אותה הלאה. בקר הוא קבוצת פעולות קשורות שכולן מחוברות יחד בכיתה. לדוגמה, בבלוג כל הקוד לצפייה, יצירה, עדכון ומחיקה של פוסטים בבלוג מקושרים יחד בבקר בשם "פוסט". הפעולות פשוט נורמליות שיטות של הכיתה הזו. בקרים ממוקמים ב אפליקציות / בקרים.
אז נניח שדפדפן האינטרנט שלח בקשה ל /posts/42. הנתב מחליט שהכוונה ל הודעה בקר, הופעה השיטה והזהה של הפוסט להצגה הוא 42, כך שהוא מכנה את הופעה שיטה עם פרמטר זה. ה הופעה שיטה אינה אחראית על השימוש במודל לאחזור הנתונים ושימוש בתצוגה ליצירת הפלט. אז החסימה המורחבת שלנו [Rails] היא כעת:
המודל הוא גם הפשוט ביותר להבנה וגם הקשה ביותר ליישום. המודל אחראי על אינטראקציה עם בסיס הנתונים. הדרך הפשוטה ביותר להסביר זאת היא המודל היא קבוצה פשוטה של שיחות שיטה המחזירות אובייקטים רוביים רגילים המטפלים בכל האינטראקציות (קוראת וכותבת) מהמאגר. אז בעקבות דוגמא הבלוג, ה- API בו הבקר ישמש לאחזור נתונים באמצעות המודל ייראה כמו Post.find (params [: id]). ה פרמטרים זה מה שהנתב מנתח מכתובת האתר, פוסט הוא המודל. זה גורם לשאילתות SQL, או לעשות כל מה שצריך כדי לאחזר את פוסט הבלוג. דגמים ממוקמים ב אפליקציה / דגמים.
חשוב לציין כי לא כל הפעולות צריכות להשתמש במודל. אינטראקציה עם הדגם נדרשת רק כאשר יש לטעון נתונים מהמאגר או לשמור למאגר. ככזה, נניח סימן שאלה אחריו בתרשים הזרימה הקטן שלנו.
לבסוף, הגיע הזמן להתחיל ליצור HTML. HTML אינו מטופל על ידי הבקר עצמו, ואף אינו מטופל על ידי הדגם. הנקודה להשתמש במסגרת MVC היא למדר את הכל. פעולות בסיסי נתונים נשארות במצב, ייצור HTML נשאר בתצוגה, והבקר (נקרא על ידי הנתב) קורא לשניהם.
בדרך כלל HTML נוצר באמצעות רובי משובץ. אם אתה מכיר את PHP, כלומר קובץ HTML עם קוד PHP משובץ בתוכו, רובי מוטבע יהיה מוכר מאוד. תצוגות אלה ממוקמות ב אפליקציה / צפיות, ובקר יתקשר לאחד מהם כדי לייצר את הפלט ולשלוח אותו חזרה לשרת האינטרנט. כל מידע שאוחזר על ידי הבקר המשתמש בדגם יאוחסן בדרך כלל ב- משתנה מופע אשר בזכות כמה קסמי רובי יהיו זמינים כמשתני מופע מתוך התצוגה. כמו כן, רובי משובץ לא צריך לייצר HTML, הוא יכול לייצר כל סוג של טקסט. תראה זאת בעת יצירת XML ל- RSS, JSON וכו '.
פלט זה נשלח חזרה לשרת האינטרנט, המחזיר אותו לדפדפן האינטרנט שמסיים את התהליך.