<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:
-->
