| 123456789101112131415161718192021222324252627282930313233343536373839404142434445 |
- <sect1 id="zend.view.abstract">
- <title>Zend_View_Abstract</title>
- <para>
- <code>Zend_View_Abstract</code> הינו מחלקת הבסיס עליה <code>Zend_View</code> מבוססת; <code>Zend_View</code> בעצמה בסך הכל מרחיבה אותה ומגדירה את המתודה
- <code>_run()</code> (אשר מיוחסת לאחר מכן אל <code>render()</code>).
- </para>
- <para>
- מתכנתים רבים רוצים להרחיב את <code>Zend_View_Abstract</code> ולהוסיף פונקציונליות מותאמת אישית,
- ובאופן בלתי נמנע נתקלים בבעיות עם העיצוב שלה, המסמך הזה נועד להצגת ההחלטות מאחורי עיצוב הרכיב הזה.
- </para>
- <para>
- <code>Zend_View</code> היא סוג של אנטי-מנוע-טמפלייטס בכך שהיא משתמשת ב PHP בתור מנוע טמפלייט.
- כתוצאה מכך כל הפונקציות של PHP קיימות, וסקריפטים של תצוגה מקבלים את כל האובייקטים הקיימים.
- </para>
- <para>
- <code>Zend_View::_run()</code> מבצע את הדבר הבא:
- </para>
- <programlisting role="php"><![CDATA[
- protected function _run()
- {
- include func_get_arg(0);
- }
- ]]>
- </programlisting>
- <para>
- לכן, סקריפטים של התצוגה יכולים לגשת לאובייקט הנוכחי (<code>$this</code>), וכל המתודות או המשתמשים של אותו אובייקט.
- מאחר וכמה פעולות מבוססת על משתמשים עם גישה וראות מסויימת, זה גורם לבעיה: סקריפט התצוגה יכול לקרוא למתודות מסויימות שהוא לא אמור או לדרוס הגדרות ישירות.
- לדוגמא תארו לעצמכם שסקריפט התצוגה ידרוס את <code>$_path</code> או <code>$_file</code> -- כל קריאות נוספות ל <code>render()</code> לא יפעלו.
- </para>
- <para>
- למרבה המזל, PHP 5 מכילה פתרון לבעיה זו עם הגדרות הראות שלה: משתמשים פרטיים לא ניתנים לגישה או דריסה על ידי אובייקט אשר מרחיב מחלקה מסויימת. זה הוביל לעיצוב המחלקה הנוכחית:
- מאחר ו <code>Zend_View</code> מרחיב את <code>Zend_View_Abstract</code>, סקריפטי תצוגה מוגבלים רק למתודות וערכים ציבוריים ומוגנים של <code>Zend_View_Abstract</code> --
- ולמעשה מגבילים את האפשרויות והפעולות שניתן לבצע, ומאפשר לנו לאבטח איזורים קריטיים במערכת מפני שימוש לא נכון או לא תקני שלהם בסקריפטי תצוגה.
- </para>
- </sect1>
- <!--
- vim:se ts=4 sw=4 et:
- -->
|