אני מקווה שהרשומה הקודמת עוררה קצת סקרנות בקשר לפלטפורמה.
ברשומה הקרובה נבין מה בדיוק עשינו ונתחיל להכיר את הטכנולוגיה שעשינו בה שימוש.
הכל כלול
הדבר הראשון שראוי לציון הוא העובדה שהתחלנו לעבוד באופן מיידי ומיד אחר כך הרצנו את האפליקציה. זה שינוי מרענן במיוחד למי שבא מכיוון JAVA ורגיל שכל פרויקט מתחיל בכמה שעות/ימים של הורדת תלויות, קונפיגורציות וכו'. כאן יש גישה של "הכל כלול" וזה אומר שכל התלויות כבר נמצאות כולל שרת אפליקציה, בסיס נתונים וכו'
בסיס נתונים?
כן. בואו נסתכל על הקובץ DataSource.groovy שנמצא בתיקיית conf. קודם כל שימו לב שההגדרות מחולקות לשלוש סביבות – development, test, production. הקונטקסט שבו משתמשים נקבע על ידי הצורה בה הרצנו את האפליקציה, למשל grails test runApp ישתמש בהגדרות של test.
בתוך ההגדרות ניתן לראות שיש שימוש HSQLDB. זהו בסיס נתונים מבוסס ג'אווה שרץ (במקרה שלנו) בתוך התהליך של שרת האפליקציה ומתאים מאוד לשלבי הפיתוח הראשוניים. הקובץ עושה שימוש בשתי צורות הרצה שלו: mem שבו אין שמירה של הנתונים לדיסק והם נעלמים כשמכבים את האפליקציה, או file שבו משפטי CRUD נשמרים לקובץ ונקראים בתחילת כל ריצה (מה שמשמר נתונים בין הפעלות). ניתן כמובן לשחק עם ההגדרות בקובץ. אם נרצה לחבר לאחת הסביבות בסיס נתונים חיצוני כמו MySql פשוט נצטרך להגדיר נתוני connection String במקום המתאים (ולשים את הדרייבר המתאים בספריית lib).
Domain classes
הדבר הראשןו שעשינו הוא הגדרת שני domain classes. אלו הישויות הבסיסיות שקיימות במערכת, עליהן מופעלת הלוגיקה והן נשמרות לבסיס הנתונים. באופן בסיסי, הדבר היחיד שצריך להגדיר במחלקות הללו הוא את השדות שלהם, למשל String title ואת היחסים בין הישויות השונות (למשל הגדרנו שפוסט שייך לבלוג). Grails עושה שימוש בטכנולוגית hibernate שהיא טכנולוגית ORM – Object Relational mapping. הטכנולוגיה הזו מגשרת על פערים שקיימים בין עולם האובייקטים ועולם בסיסי הנתונים מאפשרת להגדיר ולעבוד עם אובייקטים בלבד בזמן שהיא דואגת לסנכרון מול בסיס הנתונים (בהמשך תהיה רשומה יעודית לנושא ORM)
Controllers
הדבר השני שיצרנו הוא Controllers. מחלקות אלה מכילות את הלוגיקה של האפליקציה. הגדרנו עבודה במצב scafolled שמאפשר הצגה, יצירה ועריכה של הישות הרלוונטית. כעת אנו נמחק את הקבצים שיצרנו, ונייצר אותם שוב בעזרת הפקודה grails generate_all blogs.Post (ואותו דבר לBlog), ונפתח את הקובץ. אנו רואים שנוצר כל הקוד שמאפשר את הפעולות שמצב scafolled אפשר באופן דינמי. היתרון הוא כמובן שניתן לשנות את הקוד בהתאם לצרכים שלנו.
Views
הרכיב השלישי שקיים כעת (לאחר הרצת generate_all) הוא תיקיות Post, Blog תחת views. תיקיות אלה מכילות קבצי gsp, קבצים אלה הם קבצי תבנית של התשובה שתחזור מבקשה מסוימת. למשל הקובץ show הוא תבנית להצגת Post עם משתנים שיקבלו ערכים לפי הפוסט הרלוונטי אותו נציג בבקשה מסוימת.
Convention over configuration
ניתן כבר לראות שהפלטפורמה נשענת מאוד על המודל (MVC (Model, View, Controller. כל הישויות נוצרו בתיקיית domain, הלוגיקה בתיקיית controllers ובקבצים עם שם תואם, וכל תבניות התצוגה בתיקיית views. לפי המודל כל בקשה מגיעה לcontroller שמבצע את הפעולות הנדרשות, מעדכן את הmodel ומכין model של התוצאה אשר מועבר להצגה על ידי רכיב view.
יש כאן עוד עקרון שחשוב להבין – convention over configuration. עקרון זה אומר שכברירת מחדל יש הרבה מוסכמות במערכת שחוסכות את הצורך בהגדרות מצד המפתח. לדוגמא נגש בדפדפן להצגה של Post (הדף שמגיעים אליו לאחר יצירה של פוסט חדש). הכתובת הדפדפן היא http://localhost:8080/blogs/post/show/1 . המוסכמה אומרת שעבור כל ישות יהיה Controller בשם מתאים, ותיקיית views תואמת. בנוסף, כאשר ניגשים לURL מסוים בקונטקסט של האפליקציה, המזהה הראשון (Post) הוא שם הController, השני (Show) הוא המטודה שנפעיל באותו Controller והשלישי הוא משתנה שיקרה Id. בנוסף, הView הדיפולטיבי יהיה show בתיקית post (אלא אם המטודה תחליט לשלוח לView אחר למשל בהודעת שגיאה). כל ההתנהגות הזו ניתנת כמובן לשינוי, אך באופן דיפולטיבי אנו מקבלים פה מוסכמה מאוד נוחה בלי צורך להגדיר את זה בקבצי XML וכדומה. עקרון נוסף שכדאי להזכיר הוא DRY – Don’t repeat yourself. זוהי הרחבה של עקרון ה"אמת אחת" מהנדסת תוכנה, הקובע שכל לוגיקה צריכה להיות ממומשת פעם אחת בלבד. עקרון DRY קובע שכל דבר כגון שדה של ישות יוגדר פעם אחת בלבד, למשל שדה title של פוסט יקרא כך גם בבסיס הנתונים (וגם בשדות הטפסים שנוצרים) ואין צורך לכתוב מיפוי שקושר את הישות post לטבלה בשם Post ולמפות את השדה title לשדה בבסיסי הנתונים בעל שם זהה. כמובן ניתן למפות לטבלאות ושדות בעלי שמות אחרים (למשל אם עובדים DBA מהסוג שאוהב שמות מוזרים), אבל אם השם זהה זה מיותר ומבוצע אוטומטית.
בפוסט הבא נרחיב מעט על Groovy – השפה שמאחורי Garils ונראה חלק מהיכולות שלה.
אותיות ומספרים 