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

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

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

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

אחד הרעיונות הוא ליצור משהו כזה:

קוד PHP:

 class controller
{
 public function __construct()
 {
  new content;
  content::add('text');
  content::add('another text');
  
 }
 public function get_output()
 {
  return content::output();
 }
}
class content
{
 private $output;
 
 public function add($text)
 {
  $this->output .= $text."\n";
 }
 
 public function output()
 {
  return $this->output;
 }
}
$controller = new controller;
echo $controller->get_output(); // out of context 


מה אתם אומרים? יעיל? או לא?

אשמח לשמוע כמה שיותר תגובות, רעיונות, הצעות, הערות וכל דבר

יום טוב

אני מדפיס חופשי מתוך אובייקטים

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

לא כלכך הבנתי.

תוכל להדגים בפיסת קוד?

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

קוד PHP:

<?
class controller
{
 // initializing content object into $this->content so the other functions would be able to access it
 private $content;
 
 public function __construct()
  {
  $this->content = new content;
  $this->content->add('text');
  $this->content->add('another text');
  
  }
 public function get_output()
 {
    return $this->content->output();
 }
}
class content
{
 private $output;
 
 public function add($text)
 {
  $this->output .= $text."\n";
 }
 
 public function output()
 {
 
  return $this->output;
 }
}
$controller = new controller;
echo $controller->get_output(); // out of context
?>

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

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

הגדרות מחלקת הודעה:

קוד PHP:

 class message
{
    private $topic;
    private $content;
 
    function loadFromDB($id) {
        // get the data by id - $topic, $content
    }
 
    function printToHTML(){
        $data = '<H2>' .$this->topic .'</H2>'
        $data .= '<P>' .$this->content .'</P>'
        return $data;
    }
} 


הגדרת פורום:

קוד PHP:

 class Forum
{
    private $name;
    private $content;
    private $messages;
    function loadFromDB($id) {
        // get the data - $forummessages by id
        // get the data - $content, $name
 
        $this->messages = array;
        foreach ($forummessages as $messageID) {
            $tmpMessage = new message;
            $tmpMessage->loadFromDB($messageID);
            array_push($this->messages, $tmpMessage);
        }
    }
    function printToHTML(){
        $data = '<H1>' .$this->name .'</H1>'
        $data .= '<P>' .$this->content .'</P>'
 
        foreach ($this->messages as $message) {
            $data .= $message->printToHTML();
        }
 
        return $data
    }
} 


ועכשיו הדף אליו נכנס המשתמש:

קוד PHP:

 $theForum = new Forum;
 
    $theForum->loadFromDB($_GET('forumID'));
 
    // page header here
 
    echo $theForum->printToHTML();
    // page footer here 


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

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

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

ואצלי רק העברת הפלט.

הבנתי את העיקרון, תודה רבה לך!

אשמח לשמוע עוד דעות מאנשים..

עוד לא תכננתי מערכת גדולה כזאת.. שאלתי הרבה שאלות בפורום אבל אף פעם לא קיבלתי תגובה שהיא לא בסגנון של: "תסתדר לבד"...

יש כל מיני מבנים של תכנון OO, זה שמצאתי בו עניין הוא התבנית MVC שככל הנראה הכי פופלארית.

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

למה לא להרוג עכבר בתותח?
(-:

כל הארכיטקטורות האלה הן נורא סקסיות, נורא גמישות, נורא... נורא ואיום.

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

אבל אנחנו מדברים כולה על מפתח בודד במערכת פורומים. מה כבר יש פה?

הגישה שלי היא תכנות מונחה עצמים. תחשוב על מה באמת יש בדף - אלה יהיו האובייקטים שאתה מתכנת.

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

קוד PHP:

 $user->printWelcomeLine(); 
if ($message->UserCanEdit()) ...
$forum->messages[$messageID]->editor = $user->name; 


</DIV>

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

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

במילים אחרות - אל תתאהב באף ארכיטקטורת תוכנה. הכל יפה ונחמד אבל אל תסבך דברים שיש להם פתרון פשוט.

(-:

-----------
פרילאנס PHP.
yuval.karmi@gmail.com

כל מה שאתה אומר נכון, אין ארכיטקטורה זהה לכל מתכנת, וכל אחד עושה מה שנוח לו.

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

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

ז"א אתה עושה נגיד לעמוד עם מחלקות include או שכל דף פונקציות כמו $message->UserCanEdit() מוגדרות מחדש?

בדרך כלל אני מקדיש דף לכל מחלקה.
מחלקות שצריכות להכיר מחלקות אחרות עושות את זה ב include
יש דף גלובלי של קבועים - constants שכולם מכירים (הודעות שגיאה, קודים, שמות משתני GET וכל השאר).
יש דף גלובלי של פונקציות שכל המערכת צריכה. למשל בדיקת שדות שהזין המשתמש, פונקציות תרגום, גישה ל DB, משלוח דוא"ל... לא זוכר מה עוד.

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

זה בגדול.
אה, שכחתי לגמרי.
יש דפי תבניות - HTML ו TPL שהמערכת משלבת לכדי דפים למשתמש.

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

אמממ... זהו אני חושב.

-----------
פרילאנס PHP.
yuval.karmi@gmail.com

אה סבבה תודה

ואם לא יעצבן אותך, נשארה לי שאלה אחרונה

יש לי דף בשם index.php שהוא בתיקיה הראשית (מה שנקרא בתוך ROOT).
יש תיקיה בשם include ובתוכה כמה דפים שאליהם אני מבצע include מתוך index, אחד הדפים מכיל את המחלקה template.
בתוך המחלקה הזאת בניתי פונקציה לטעינת תבנית מיוחדת להצגת שגיאות:

קוד PHP:

 $template->trigger_error('topic', 'message'); 


והפונקציה עצמה trigger_error מתקשרת עם פונקציה אחרת בשם load_template מתוך המחלקה עצמה:

קוד PHP:

 $this->load_template('display_error.tpl'); 


אז לסיכום זה נראה ככה:

• index.php
• include/template.inc.php

כשאני קורא לפונקציה trigger_error מתוך index.php, הפונקציה פונה למחלקה template וטוענת תבנית.
עכשיו, בגלל שטעינת התבנית מתרחשת בתוך include/template.inc.php הניתוב לקובץ צריך להיות כזה:

קוד:

../display_error.tpl

אבל בעצם הפונקציה כאילו פועלת לפי התיקיה של index כי ממנו אני קורא לה (ROOT).

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

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

מצטער על ההצפה, ואשמח לקצת עזרה

תודה!

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

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

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

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

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

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

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

בברכה,

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

נתחיל מזה שהפורום שתכננתי הוא הרבה הרבה יותר מורכב ממה שאתה מדמיין (אולי אפילו יותר מMVC), והרבה יותר נוח.

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

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

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

בכל מקרה זאת הייתה דעתי,


המשך יום טוב

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

בברכה,

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


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

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

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

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

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

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

מה שהתפתח בתחילת הדיון היה סה"כ שיטת העברת הפלט מהמחלקות החוצה.

יש לי תיקיה שלמה שקוראים לה model.
בתוך התיקיה הזאת יש כמה דפים forum, thread, message, authorization, את ה authorization אני מוריש למחלקת הcontroller שלי ודרכה אני משלב שימוש של הרשאות לכל דבר בפורום - מ-זמן עריכת ההודעה ועד גישה מינימלית לפורום.

מחלקת ה view שלי, היא בעצם מחלקה רחבה בשם template שמכילה גם שימוש בתבניות HTML לשימוש נוח בהחלפת 'סקין' וגם העברת פלט החוצה כתפקידה במקור.
גם הפונקציה שנבהלתָ מהשימוש שלה trigger_error היא בכלל לא מה שאתה חושב.

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

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

סה"כ נפלת עלי ביום רע.

יום טוב.

למה בכח?

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

זהו. זה הכל.

נגיד שאתה נכנס לקוד של מישהו אחר ומחפש את המקום בו הוא מדפיס את ההודעה. בחר את אחד מהקבצים:
messages.class
viewer.class

ובעברית עכשיו: המודל הזה כבודו במקומו מונח. למערכות מסובכות ומרובות מתכנתים הוא אפילו עוזר. אבל פה המערכת פשוטה. ההבדל הוא האם האובייקט "Message" מממש פונקציה בשם "printHTML" או לחילופין שיש אובייקט "Viewer" שיודע לקבל אובייקטים כמו Message ולבצע עליו את הפונקציה -"printHTML". זה שולי כל הסיפור הזה. זה נקרא לסדר את הקוד לפי המודל של המתכנת ולא לפי המודל הטבעי של המערכת. במערכת יש באמת message. במערכת אין באמת viewer. זה רק המצאה של המתכנת לטובת סידור הקוד.

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


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

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

המודל שעליו דיברנו נכון למערכות מסוימות אבל לא קדוש. רק מתכנת אידיוט לא יכתוב אובייקט כמו message בתכנון פורומים. אבל לא כל מתכנת יכתוב viewer. המשמעות היא שהראשון מחייב והשני - לשיקול המתכנת.

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

-----------
פרילאנס PHP.
yuval.karmi@gmail.com

זה לא מסובך כמו שאתה חושב, באמת.

הקטע שאתמול עברתי ליד המחשב של אחותי והבחנתי בפאנל ניהול של phpBB.

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

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

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

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

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

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

ציטוט:

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

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

-----------
פרילאנס PHP.
yuval.karmi@gmail.com

גמור אתה

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

קיבלת את ההודעה הפרטית ששלחתי לך?

נראה לי ניפחת קצת את MVC

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

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

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

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

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

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

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

ציטוט:

Oh man, just looking at this code makes me cringe now.

בדיוק! זה בדיוק מה שניסיתי להכניס לך לראש!

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

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

מצטער על התוקפנות מקודם

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

בברכה,

סתם לידע כללי: Ruby on Rails היא לא שפה. Ruby זו השפה, ו-Rails היא framework שכתובה ב-Ruby

אחח.. רואים שאני לא בעיניינים עכשיו.. הלכתי חזק מידי ל- JS..

דור:

וד"א, נתנאל, גם לעבוד בMVC - צריך לדעת, אני לא אומר שאתה לא יודע, אבל קל מאוד לדחוף דברים שקשורים לController במה שנקרא ה View.
אני מציע לך להסתכל קצת על CakePHP ואם אתה רוצה לנסות משהו חדש, לך על Ruby On Rails.
עריכה: בשביל ROR צריך ללמוד קצת Ruby כדי לנצל את הכוח האמיתי, אבל תכל'ס לא צריך לדעת כלום, צריך להתרגל לראש - יצאתי מנקודת הנחה שתעדיף PHP

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

תודה על התגובה.

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

קוד PHP:

 $this->user = new user;
  $this->user->parse_my_data(); 


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

קוד PHP:

 $template = new template;
$template->obtain_skin()
$template->assign_skin_style() 


ואז יש לי קבוע בשם SKIN_FOLDER
ומערך שמכיל את כל הגדרות העיצוב (ניתוב קובץ הCSS ועוד המון).

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

בדיוק מהסיבה הזו אני ממליץ על Framework מבוססת MVC

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

מספר Frameworks נפוצים (ל-PHP בלבד):
http://framework.zend.com/
http://cakephp.org/
http://www.symfony-project.com/ (יאהו משתמשים בזה ב-Yahoo Bookmarks ואם אני זוכר נכון גם ב-del.icio.us)
http://codeigniter.com/