בהמשך לדיון הקודם: בניית תשתיות.

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

חשבתי על 2 דרכים עיקריות:

1. אני טוען את הטמפלט שזה קובץ PHP עם מחלקה שתוך כדי ריצת הקוד מזינים בעזרת פונקציות מידע אליה, ובסוף כשמפעילים פונקצייה מסויימת היא מפרשת במקום את כל המידע כפי שהיא רואה לנכון.
2. אני טוען מחלקה בסוף הריצה ואליה מעביר משתנה עם אילו דפי HTML לטעון, והיא פשוט עוברת על ARRAY ומחליפה ביטויים ב-HTML במשתנים שכוללים מידע.

אילו עוד דרכים אתם מציעים לשקול?
מה אתם למדתם מהניסיון שלכם?

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

(מפתח אתרים | iBlog - בלוג בניית אתרים)

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

אם מגדירים שה- direction של הדף הוא RTL או LTR, אז רוב הבעיות האלה נפתרות

אני יצרתי לכל מודל במערכת שלי אובייקט VIEW שנטען.
כך למשל לפורום יש אובייקט VIEW משלו ולרשימת המאמרים יש אובייקט VIEW משלו.

לכל אובייקט VIEW יש את רשימת ה"תצוגות" שמתאימות לו:
ForumView -> רשימת ההודעות בפורום
ForumView -> הודעה ספציפית

וכו'.

דבר זה אפשר לי ליצור קוד מסודר להפליא. למשל, דוגמא לדף הצגת רשימת ההודעות[הדף הראשי של הפורום]:

קוד PHP:

<?php
$view = new forumView();
$forumSystem = new forumModule($db);


$view->newMsgButton();
$msgs = $forumSystem->getMsgs($msgsStart,$msgsPeerPage);

if ($msgs)
    $view->viewMsgs($msgs);
?>

החלוקה מאפשרת לי באובייקט VIEW ליצור כיצד יראה העיצוב של ההודעות בלי לדעת בכלל איך אני מוציא אותם מהDB. בהוצאת ההודעות מטפל הMODULE.

אבל על המערכת שלי אני אפרט יותר לעמוק כשיהיה לי זמן..

איתי סלע,
פיתוח מערכות תוכנה ואינטרנט.

לא הבנתי כל כך כמה דרך 2 שונה מדרך 1.

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

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

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

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

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

נ.ב:
מישהו מכיר יישום של ORM ב-PHP? או דרך להביא את ORM לידי ביטוי?

(מפתח אתרים | iBlog - בלוג בניית אתרים)

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

אני חושב שזה פתרון טוב, כי ברוב הפעמים המערך לא יותר גדול מ-40 מפתחות...
הבעיה מתחילה כשיש משהו בסדר גודל של 10,000 מפתחות..

תסתכל על Propel שבא עם symfony.
ובאופן כללי, תסתכל על symfony.

שאלתי איך אנשים מפרידים לא משום שאני לא יכול לסקור מערכות ולחפש בעצמי, אלא משום שרציתי לראות איך אנשים מתמודדים עם זה (לא מערכות, בדר"כ ההבדל זה בכמות הדינאמיות שצריך).

(מפתח אתרים | iBlog - בלוג בניית אתרים)

בקשר של ORM איך שאני רואה את זה, יש שלוש דרכים לעבוד:

1. כמות מינימלית של כתיבת SQL - בשימוש עם Propel ו Criteria של symfony או בשימוש עם ActiveRecord של Rails או כל ORM אחר שתרצה. כל מה שנשאר הוא לבחור תשתית שתהיה נוחה לך ולמטרות שלך, וגם אחת שתהיה איכותית מספיק. בכל מקרה זה מובן.
2. כתיבת שאילתות מוכנות מראש - לכתוב ORM משלך שהוא פשוט אוסף של אובייקטים שמציגים ישויות במערכת ולכתוב SQLים עבור כל פעולה על היישות הזו.
3. לכתוב את כל השאילתות - הדרך הפשוטה של לכתוב שאילתות עבור כל פעולה שאתה רוצה לעשות על מסד הנתונים.

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

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

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

אני מחיפוש על ORM לא ראיתי הרבה מידע שימושי עבורי לצערי, הרוב הסתכם ב"דרישות עבודה: ORM", דבר שלא בדיוק עוזר לי להבין איך זה בא לידי ביטוי ב-PHP ובכלל.


שאלה רלוונטית לא פחות עוסקת בבחירה נכונה של דרך ההפרדה:
קראתי את הפוסט "הטכנולוגיה הרגה לי את הטארט-אפ" (בבלוג של nercraft) ודיברו שמה על כך שבחירה לא נכונה של התשתית / שימוש בתשתית עלול לגרום למצב בו תיהיה מלחמה בין הניסיון הנואש להשתשמ בתשתית לבין הצורך האמיתי.
איך אני יכול לדעת איזו תשתית מתאימה לאתר שאני בונה?

(מפתח אתרים | iBlog - בלוג בניית אתרים)

אני מסכים שטכנולוגיות משתנות, אבל MVC זה MVC.
או לפחות המושג שאותו מתכוונים להגדיר בMVC, כבר נחרש והוגדר - ובדר"כ איתו מגיע גם ה ORM.

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

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

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

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

התחלתי לתכנן את ה-ORM, והינה מה שחשבתי עליו:

קוד PHP:

 $sql = new sql;

$sql->users(2); // return username
$sql->users(2,array('email','password')); // return array(email,password)
$sql->users('username'); // return id
$sql->users('username',array('email','password')); // return array(email,password)

$sql->users = array('email'=>'new@email.com'); // new user, return id / false
$sql->users(2) = array('email'=>'new@email.com'); // update user, return true / false
$sql->users(2) = null; // delete, return true / false

$sql->articles(array('category_id'=>1,'path_name'=>'article_path')); // return id 


משוב יתקבל בברכה =]

(מפתח אתרים | iBlog - בלוג בניית אתרים)

אני אתייחס רק לשורה האחרונה.

בORM, מה שנהוג הוא לא להגדיר את הID של האובייקטים (או במקרה שלנו שורות).
הORM אמור להכיר את היחסים בין הטבלאות שלך.

אז בגדול השורה האחרונה, לפי השורות הקודמות שלך, הייתה אמורה להיות כך:

קוד PHP:

 $category = $sql->category(1); // This should return an object of the "category"
$sql->article = array('name' => 'My first article', 'content' => 'Bla', 'category' => $category); 


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

אני לא אומר שמה שכתבתי יותר טוב, אבל זה בעצם כל הכוח של מה שנקרא ORM.

רגע, אז אם הלךוגיקה אצלי הייתה כזו:

קוד PHP:

 $sql = new sql;

$sql->{table} () = array(); // insert
$sql->{table} ( {where}, {select} ); // select
$sql->{table} ( {where} ) = array(); // update
$sql->{table} ( {where} ) = null; // delete

$sql->{table} ( {int} ); // select (where id={int}) 


מה הלוגיקה שאתה הצגת?

(מפתח אתרים | iBlog - בלוג בניית אתרים)

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

בוא ניקח את המבנה הבא כדוגמה:
3 טבלאות.

1. קטגוריות.
2. מאמרים.
3. טבלה מקשרת.

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

קוד PHP:

 $category = $sql->categories(1);
    // SELECT * FROM Categories WHERE id = 1;
$article = $sql->articles->new($data);
    // INSERT INTO Articles VALUES ($data);
    // SELECT LAST_INSERT_ID();
$sql->articlecategory->new(array('category_id' => $category->id(), 'article_id' => $article->id()));
    // INSERT INTO ArticleCategory VALUES ('1', '1'); 


ולפי איך שאני רואה את זה, נרשום את הפעולות הבאות:

קוד PHP:

 $category = $sql->categories(1);
    // SELECT * FROM Categories WHERE id = 1;
$article = $category->article->new($data)
    // INSERT INTO Articles VALUES ($data);
    // SELECT LAST_INSERT_ID();
    // * INSERT INTO ArticleCategory VALUES ('1', '1'); 


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

קוד PHP:

 $articles = $sql->category(1)->articles();
    // SELECT * FROM Articles WHERE id IN (SELECT article_id FROM ArticleCategory WHERE category_id = 1); 


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

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

קוד PHP:

 $articles = $sql->category(1)->articles(); // When ORM knows that its scope is "active" only
    // SELECT * FROM Articles WHERE id IN (SELECT article_id FROM ArticleCategory WHERE category_id = 1 AND active = 1); 


יכול להיות שזה לא במקום, אבל תסתכל על הוידאו של "איך בונים בלוג ב15 דקות" של Rails1.
ואני אומר דווקא Rails1 כי ב Rails2 האוריינטציה היא שונה במעט.
אני נותן את Rails פה כדוגמה לא כי אני מעריץ גדול שלה (למרות שאני כן), יש דברים שבה היא טובה ויש דברים שלא, אלא רק בגלל שנורא קל להבין מי נגד מי מהסתכלות על הסרטונים הפשוטים והנושא של MVC וORM מוצג בה בפשטות.

אתה יוצא ב-2 הנחות:
1. הכל מונחה ID.
2. אני תמיד יודע מה ה-ID.
בהנחה ששני אלו נכונים המ שהצגת נכון, בהנחה שאני לא בניתי ככה (באמת לכל דבר יש ID, אבל צריך להשיג אותו), אנחנו נכנסים לבעיה

אצלי הרעיון הוא כזה:

קוד PHP:

 $sql = new sql;

$sql->category('php'); // return id / false + saving category id
$article = $sql->articles('article_path'); // return id, title, content, dir_id

$menu_articles = $sql->articles(array('dir_id'=>$article['dir_id'])); // return id, title 


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

לאחר מכן שיש לי תיקייה בה אני נמצא, אני מבקש את כל המאמרים שנמצאים באותה תיקייה.

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

(מפתח אתרים | iBlog - בלוג בניית אתרים)

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

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

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

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

ככה זה.. אנחנו מתכנתים ולא אכפת לנו מהמעצבים (זה גם הולך הפוך)

ברור שאתה יכול לעשות את זה כך, אבל זה כל הרעיון של MVC.
Model - מחזיק את הלוגיקה העיסקית.
Controller - מנהל את הבקשות מהלקוח ומבצע את הפעולות על המודל.
View - משתמש במידע שבחר בשבילו ה Controller ומציג אותו למשתמש. (יכול להיות XML, יכול להיות RSS, וכנראה שהוא יהיה XHTML )

ה Controller מקבל את הבקשה, לדוגמה GET /articles/1.
הוא אומר למודל המאמרים להביא לו את המאמר הראשון ומסיים את העבודה שלו.
התצוגה מקבלת מאמר ומציגה אותו.

או למשל בהכנסה של נתונים.
ה Controller מקבל בקשה להכניס נתון, לדוגמה POST /articles
הוא אומר למודל להכניס את המידע הזה, השאלה אם הנתונים כשרים או לא לא תלויה ב Controller (איך כותבים את זה בעברית לעזאזל), אלא אך ורק במודל.
ז"א, השאלה אם הנתון שלנו עונה על כך שהוא כתובת אימייל, או פורמט של תעודת זהות, או מספרים בלבד עושה רק המודל על הנתונים שהוא מקבל לפקודת ההכנסה של הנתונים.
אם הנתון לא מתאים, הוא מעלה שגיאה, או מחזיר False ומכניס את השגיאה למערך של שגיאות שיוצגו למשתמש, או מה שלא תרצה אבל הרעיון שעומד מאחורי זה הוא שיש רק מקום אחד להכניס מאמר, רק שער אחד אם תרצה (ירון לונדון?!), והבדיקה נמצאת בשער הזה ולאו דווקא ב Controller כי בקשת הכנסה יכולה לבוא מעוד מקומות.
מאיפה אתה שואל? לדוגמה: הסבה של האתר שלך לעבודה עם Web Services.

לגבי התצוגה (ה View).
הוא אמור להיות רכיב טיפש. לקבל נתונים ולהציג אותם.
תאר לך שקיים פיצ'ר במערכת שלך שמציג 20 תגובות אחרונות למאמר מסויים.
והשירותים שהאתר שלך נותן הם: XHTML, RSS, ו Atom.

בדרך שלך, יש לך שלושה עמודי View שכל אחד מהם בוחר את הנתונים ומציג אותם למשתמש.
בMVC אמיתי ה Controller בוחר את הנתונים וכל אחד מה Viewים מציג את מה שהוא קיבל.

תאר לך שהוחלט שרוצים להוריד את כמות המידע הזו ל10 הודעות, מה עושים?
בדרך שלך, צריך לערוך את כל שלושת העמודים ולשנות את ה LIMIT מ 20 ל10.
בMVC אמיתי צריך ללכת לController, למקום שהוא בוחר את הנתונים ולשנות את הכמות מ 20 ל10.
בMVC כל תבנית View תרוץ בהתאם לפרוטוקול שממנו הגיעה הבקשה אבל אותה פונקצית Controller תרוץ, לכן השינוי יהיה רק במקום אחד.

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

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

אני יכול לשים אבל הוא לא יראה שונה מכל עמוד PHP אחר, הוא פשוט לא מריץ את השאילתות בעצמו.

ולגבי התנאים והלולאות, זה נושא אחר כבר
אני שוב אדבר על Rails כי זו דוגמה טובה
ב Rails 1 מומש רעיון ה CRUD לפשטותו, התשתית דאגה לארבעת הפעולות האלו בשבילך וקיצרה את התהליכים (Create, Read, Update, Delete).
עכשיו עלתה בעיה חדשה: Read, פעולת הקריאה, או עמוד הרשימה, לעיתים צריך להציג או לתת הרשאות מסויימות לאנשים מסויימים - וכך גם כל שאר הפעולות.

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

ב Rails 2 עושים שימוש ב RESTful Resources.
בנפרד מהעובדה ש REST מספק לך את העמודים השונים בפרומטים שונים (שאלו הדוגמאות הנפוצות באינטרנט ל REST), ב Rails משתמשים בזה כדי להגדיר מחדש את האובייקטים (המודלים, ה Resources ), עבור כל בקשה, עם הרשאות שונות כדי לחסוך ממך כל מיני תנאים.

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

ציטוט:

תאר לך שקיים פיצ'ר במערכת שלך שמציג 20 תגובות אחרונות למאמר מסויים. והשירותים שהאתר שלך נותן הם: XHTML, RSS, ו Atom. בדרך שלך, יש לך שלושה עמודי View שכל אחד מהם בוחר את הנתונים ומציג אותם למשתמש. בMVC אמיתי ה Controller בוחר את הנתונים וכל אחד מה Viewים מציג את מה שהוא קיבל. תאר לך שהוחלט שרוצים להוריד את כמות המידע הזו ל10 הודעות, מה עושים? בדרך שלך, צריך לערוך את כל שלושת העמודים ולשנות את ה LIMIT מ 20 ל10. בMVC אמיתי צריך ללכת לController, למקום שהוא בוחר את הנתונים ולשנות את הכמות מ 20 ל10. בMVC כל תבנית View תרוץ בהתאם לפרוטוקול שממנו הגיעה הבקשה אבל אותה פונקצית Controller תרוץ, לכן השינוי יהיה רק במקום אחד.

אז למה לא לעשות זאת בצורה הבאה:
במקום פיצ'ר אתייחס אליו כמודול (כי הרי בסופו של דבר, המודולים בעמוד הם אלה שמציגים אותו).
ואז אני אעשה GET /index.php?module_id=38&format=xml
כך הוא מציג את 10 ההודעות האחרונות בפורמט XML.
אבל זה פחות משנה מה יהיה ב-URL מלבד הפרמטר של module_id שמתייחס אל המודול באופן ספציפי. ואז אתה יודע מראש שלא לשלוח כותר של text/html, ולתת למודול להחליט מה הוא ירצה לעשות.

האם לא כך פשוט יותר? וחסכוני יותר במקום לטעון framework?

זה פחות או יותר מה שעושים, ה-Controller מקבל שאתה רוצה להפעיל את XML ומבקש מידע מה-Model, ולאחר מכן טוען את ה-View שמפרש את המידע אוטומטית ל-XML.
כאשר יש לך Model אחד ומספר View שונים (במידה ורוצים לשנות מ-XML ל-XHTML או ל-HTML4 זה סה"כ לשנות View, הרבה יותר יעיל).

(מפתח אתרים | iBlog - בלוג בניית אתרים)

ויש גם את העניין של templates כך שצריך ליצור template בפורמט XML...

אם זה מה שמבצעים (כמו שכתבתי) אז למה צריך framework בשביל זה? לא יותר עדיף לתכנת את זה באופן עצמאי?

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

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

זאת אומרת שנניח שמספיק שיש לי מחלקה שמתעסקת עם כל ה-output, מחלקה שמתעסקת עם ה-modules, וקובץ index.php שמחליט מה יתבצע (ה-controller) - אז כבר למעשה, בצורה הזאת, אני מממש MVC?

נראה לי מיותר להשתמש ב-framework שיכיר את כל מסד הנתונים והמבנה וכו' בשביל שבמקום לכתוב שורה מסוימת בצורה אחת, אכתוב אותה בצורה אחרת...

זה כמו שמשתמשים בשפת template חדשה ו"מגניבה" בשביל שהמעצב או מי שרוצה לשכתב את ה-template לא יהיה חייב להכיר את שפת PHP בצורה הפשוטה והמובנת ביותר שיכולה להיות ...

בוודאי

ככה עובד symfony ד"א.
יש קובץ index אחד - הוא ה Controller, והוא מפנה את הבקשה למודול המתאים, משם הבקשה עוברת (עם כל הפרמטרים שנאספו) אל ה View המתאים.

תודה על ההסברים המתמשכים

אני מחפש בגוגל וקורא על הרבה דברים שנכתבו כאן, כולל symfony ו-restful וכו', אבל פשוט לא מצליח להבין את העיקרון בהם, למעשה לא הבנתי בהם כלום.
אני מרגיש שאני מפספס כאן משהו. אם symfony מבצעת זאת בצורה ההיא, מה היחודיות בה? מה זה נותן? מהו הדבר המיוחד, מלבד נוחות למתכנת?
האם כאשר אשתמש ב-framework כמו symfony, המערכת שלי תהיה טובה יותר ובנויה בצורה נכונה יותר (מאיזו בחינה?) ; או שמלבד נוחות למתכנת, לא אקבל כלום?

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

במילה אחת שמסכמת את הכל?
נוחות.

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

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

בכל מקרה, אל תפחד. פשוט תכנס למים ותנסה להשתמש בכל אחת מהתשתיות.
תנסה את symfony ואת Rails.

ד"א, יש גם את Django שיש שיגידו שהיא לא פחות טובה

אוקי, תודה!

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

התשתיות Rails ו- Django כתובות בשפות Ruby ו- Python... אני לא מכיר אותן ... כבר התחלתי בפיתוח המערכת ואני בשלב יחסית מתקדם, ככה שהמרה של הקוד זה אופציה לא טובה...

אנסה לבדוק לעומק את symfony.
הבעיה היא שאני לא אוהב את הרעיון של templates שיוצרים לעצמם "שפות חדשות" ב-frameworks. והרוב המוחלט של ה-frameworks שקיימים היום, וגם אלו שנחשבים הכי מעולים, משתמשים ב-templates (אקרא לזה tpl) כזה וב"מנוע tpls"... אני לא מבין למה ליצור שפה חדשה כאשר יש את שפת PHP שעושה את הדבר הזה בעצמה...
זה נראה לי כ"כ מיותר ליצור שפת tpl שזה גורם לי לחשוב שכל ה-frameworks שמשתמשים בשפת tpl משלהם מנסים סתם לנפח את המערכת ולעשות אותה כביכול טובה יותר, מבחינה חיצונית. ולכן לך תדע אם שאר הקוד זה סתם מנופח...

tnadav הביא כאן בעבר הפניות למנוע template שהוא כל כך פשוט שזה גאוני. מאוד התרשמתי ממנו. במקום ליצור שפת tpl משלו, הוא השתמש במנוע של PHP כדי לתרגם את ה-tpl עם המידע שבתוכו. והנה, "מנוע tpl" שמשתמש במנוע של PHP בצורה הכי נורמלית שיש...

הנה הקישורים, שניהם מפנים לאותו ה-template engine אבל זה פשוט כתוב באתרים שונים (עם מידע שונה, אבל שוב אותו מנוע tpl):
http://massassi.com/php/articles/template_engines/
http://www.massassi.com/bTemplate/

בכל אופן אנסה להסתכל על symfony ונוספים...

שוב תודה על העזרה!

בסימפוני אתה כותב בPHP, לא בTemplates...

משום מה חשבתי בהתחלה שיש לו שפת tpl משלו, בגלל שראיתי כל מיני {label} בקוד..
עכשיו גם שמתי לב לקבצי ה-yml שזה כנראה קבצי config בשפה מסוימת. עכשיו אני קצת יותר בטוח להשתמש ב-symfony,אבדוק...

אגב, בגלל שזה MVC, אתה תמיד יכול לעשות להמיר את המחלקה שהבאתי שתתאים למחלקה של Symfony

זה בהחלט טמפלט רלוונטי...
אף אחד לא אמר שה-View נטול PHP, ואם כן תצטט את זה לפה.

(מפתח אתרים | iBlog - בלוג בניית אתרים)

כך הציגו את זה כמה frameworks שנחשבים טובים. מהם זה משתמע...

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

(מפתח אתרים | iBlog - בלוג בניית אתרים)

ציטוט:

נראה לי מיותר להשתמש ב-framework שיכיר את כל מסד הנתונים והמבנה וכו' בשביל שבמקום לכתוב שורה מסוימת בצורה אחת, אכתוב אותה בצורה אחרת...

נשמע שהתייחסת פה ל-ORM, אבל צריך להבין את הגישה:
לשאילתות קטנות הוא קצת יותר מנחמד, ברגע שמתחילים להתעסק עם JOIN התחביר של SQL הופך להיות אימתני, ובדיוק פה ORM נכנס, ונותן לך תחביר ששייך ל-PHP וקל להבין.
אז נוצר מצב שבשאילתות קטנות יש לך תחביר שקל להבין, ובשאילתות מסובכות יש לך תחביר פשוט ומחלקה שמפרשת את המידע.

בנוגע להערה על ה-template: הוא לא חייב להיות נטול PHP לחלוטין, הוא פשוט לא יבקש מידע בעצמו מהמסד נתונים, והוא יטען רק בסוף לאחר שהפעולה ברורה.

הרבה מהקטע הוא שאפשר יהיה לתכנת מהר ובקלות, ופה הייתי ממליץ על הסרטון של RoR כדי לתפוס את העיקרון:
http://media.rubyonrails.org/video/..._with_sound.mov
(נתנו את הסרטון כבר מקודם).

(מפתח אתרים | iBlog - בלוג בניית אתרים)

ציטוט:

במקור נכתב על ידי iBot נשמע שהתייחסת פה ל-ORM, אבל צריך להבין את הגישה: לשאילתות קטנות הוא קצת יותר מנחמד, ברגע שמתחילים להתעסק עם JOIN התחביר של SQL הופך להיות אימתני, ובדיוק פה ORM נכנס, ונותן לך תחביר ששייך ל-PHP וקל להבין. אז נוצר מצב שבשאילתות קטנות יש לך תחביר שקל להבין, ובשאילתות מסובכות יש לך תחביר פשוט ומחלקה שמפרשת את המידע. בנוגע להערה על ה-template: הוא לא חייב להיות נטול PHP לחלוטין, הוא פשוט לא יבקש מידע בעצמו מהמסד נתונים, והוא יטען רק בסוף לאחר שהפעולה ברורה. הרבה מהקטע הוא שאפשר יהיה לתכנת מהר ובקלות, ופה הייתי ממליץ על הסרטון של RoR כדי לתפוס את העיקרון: http://media.rubyonrails.org/video/..._with_sound.mov (נתנו את הסרטון כבר מקודם).

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

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

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

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

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

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

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

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


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

(מפתח אתרים | iBlog - בלוג בניית אתרים)

ציטוט:

זאת אומרת שנניח שמספיק שיש לי מחלקה שמתעסקת עם כל ה-output, מחלקה שמתעסקת עם ה-modules, וקובץ index.php שמחליט מה יתבצע (ה-controller) - אז כבר למעשה, בצורה הזאת, אני מממש MVC?

כן, מימשת MVC, ואפשר להגיד שבנית לעצמך Framework...

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

הרעיון של ה- CRUD הוא רעיון מאוד טוב שאני יכניס ל- Framework הבא (אני רק צריך לקרוא על PUT ו- DELETE ואיך זה מיושם ב- PHP)

הרעיון הוא שלכל פעולה יש מתודה.
Create (מיושם ב- SQL כ- INSERT) משתמש במתודה POST
Read (מיושם ב- SQL כ- SELECT) משתמש במתודה GET
Update (מיושם ב- SQL כ- UPDATE) משתמש במתודה PUT
Destroy (מיושם ב- SQL כ- DELETE) משתמש במתודה DELETE

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

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

קוד PHP:

 class User
{
    function User() {
        // Get MySQL Resource by implementing the singleton design pattern
        // Configure MySQL Resource (Exemple: enter table name, table field and the datatype of the field
    }
    
    function _index() {
        // URL: address/user
        // Called by GET method, implementing Read
    }

    function show($id) {
        // URL: address/user/show/1
        // Called by GET method, implementing Read
    }

    function add() {
        // URL: address/user/add
        // Called by GET method, implementing Read
    }

    function _create() {
        // URL: address/user
        // Called by POST method, implementing Create

        // Another code here

        // if Create OK
        $this->_index(); // Return to userlist
    }

    function update($id)  {
        // URL: address/user/update/1
        // Called by GET method, implementing Read
    }

    function _update($id) {
        // URL: address/user/1
        // Called by PUT method, implementing Create

        // Another code here

        // if Update OK
        $this->_index(); // Return to userlist
    }

    function _destroy($id) {
        // URL: address/user/1
        // Called by DELETE method, implementing Create

        // Another code here

        // if Update OK
        $this->_index(); // Return to userlist
    }
} 


ה- Framework יודע איך לטפל במחלקה הזאת, בלי להגיד לו כלום.
המבנה של ה- url הוא כזה:

קוד PHP:

 address/[<className>]/[<classFunction]/[<classArg1, 2..1,000] 


כל מה שבתוך [] הוא לא חובה.. יוצא ששום פרמטר הוא חובה.
אם אין className, אז הוא יציג את דף הבית (מחלקה בשם index?..)
כשאין classFunction הוא קורא לפונקציה index_, אם קיימת (אם אז מוציא הודעת שגיאה)
-classArg זה מן הסתם ארגומנטים לפונקציה.

כשיש בקשת POST ה- framework קורא ל- create_
כשיש בקשת PUT, הוא קורא ל- update_
כשיש בקשת DELETE הוא קורא ל- destroy‏‏_

GET משמש לקריאה לפונקציות (מסתדר לי יותר טוב בראש וגם זה קל יותר לביצוע)

אז אם ככה זה הרבה יותר פשוט משחשבתי ליישם MVC.

ובנוגע להמלצה, אז אני חושב שכדאי לשים בקבצים נפרדים את כל מה שלא תשתמש בו.
לדוגמא, אם מישהו שלח POST כדי ליצור מידע חדש, אז שלא יהיה לך בקוד את המתודות שמטפלות ב-delete וב- put. הסיבה היא שאני חושב שלא צריך לכלול דברים שהם אינם חיוניים לריצה. כלומר - אם לא צריך, אז למה לשים מלכתחילה?
היישום יהיה בצורה הבאה:
יש קובץ base שהוא מכיל את המחלקה הבסיסית. זה כולל את ה-_index כי תצטרך לקרוא אליו בכל מקרה שיהיה.
אח"כ יש קבצים נוספים של post, put ו-delete שהם מבצעים extends למחלקת הבסיס.

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

(מפתח אתרים | iBlog - בלוג בניית אתרים)

יש אופטימיזציה ויש אופטימזציה, אל תגזים.

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

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

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

דווקא הסתכלתי.. ופחות אהבתי את הדרך שבה ההפרדה מיושמת...

ייתכן שזה יעזור: http://www.phpwact.org/pattern/model_view_controller (לא יצא לי לקרוא)

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

יש לי דף ראשי index.php, הוא מכיל את הצורה הכללית של עמוד הבית. תפריט בצד שמאל, לוגו למעלה, תפריט מימין, כותרות ותפריט עליון, וחלק תחתון של העמוד. באמצע יש חלק שמתקבל בעזרת include.

לכל עמוד, שנבחר ע"י משתנה שמתקבל page (וכמובן שרצות עליו הבדיקות ההכרחיות, ורק ערך ממערך דפים יכול להבחר) יש דף php. לדוגמא, blog.php.
בדף זה יש את העיצוב הפנימי של אמצע האתר, רק החלק של blog.php שהוא די מינימאלי אפשר להגיד, ובעיקר רק מכיל את הHTML שנוצר בעקבות כל מיני queries ולוגיקה שונה בהתאם למשתנים שנתקבלו.

בנוסף, ישנו דף המכיל המון משתנים של קונפיגורציה(configuration) והוא מתווסף עוד בתחילת הindex.php ככה שהוא זהה לכל דף פנימי (blog.php) שמתווסף - והוא מכיל כל מיני הגדרות כמו posts per page וכדומה.

השאילתות למסד הנתונים מתבצעות מכל דף פנימי שמתווסף, והנתונים וההדפסה מתבצעת מיד. (למה לחכות? כל דבר שקשור לheaders, cookies וכו' מתבצע כבר בראש עמוד index.php, ובעתיד בדף נפרד שיתווסף - inputHandling)

מה אני משיג מצורת העבודה הזאת?
אני תכלס רואה את העיצוב שלי בצורה הכי פשוטה - אני סוגר את תגית הPHP לפני פלט HTML ומכניס את הנתונים הספציפים שאני צריך לתוך הטבלאות או התגים הדרושים <?php echo $blahblah?>
האתר מחולק לדפים שונים ככה שממש פשוט להתעסק איתו ולא חייב לעדכן דפים ענקיים. ובשינוי ערך במערך שמוגדר בconfiguration אפשר להוסיף דף חדש לאתר\תפריטים. (בעתיד אני אוסיף את זה לתוך מסד נתונים, כשאצטרך דינמיות או כשאצור את הadmin tools...)

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

תודה מראש לאלו שיטרחו לקרוא ולתת את חוות הדעת שלהם

ציטוט:

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

לא קראתי הכל, כי אין לי זמן, אבל תראה את זה:
http://media.rubyonrails.org/presen...ofresources.pdf

אומנם זה ל Rails 1, בלי RESTful, אבל זה נראה טוב ואולי זה יגרום לך לאהוב יותר את ה MVC