Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

merging yiidoc to yii.

  • Loading branch information...
commit 5d7906c0c61f55f84ff6ad9d14510254a4b199b6 1 parent 6769b5f
qiang.xue authored
Showing with 7,861 additions and 0 deletions.
  1. +46 −0 docs/guide/fr/basics.workflow.txt
  2. +51 −0 docs/guide/fr/caching.page.txt
  3. +160 −0 docs/guide/he/basics.application.txt
  4. +137 −0 docs/guide/he/basics.component.txt
  5. +168 −0 docs/guide/he/basics.controller.txt
  6. +90 −0 docs/guide/he/basics.convention.txt
  7. +26 −0 docs/guide/he/basics.entry.txt
  8. +14 −0 docs/guide/he/basics.model.txt
  9. +82 −0 docs/guide/he/basics.module.txt
  10. +33 −0 docs/guide/he/basics.mvc.txt
  11. +46 −0 docs/guide/he/basics.namespace.txt
  12. +105 −0 docs/guide/he/basics.view.txt
  13. +28 −0 docs/guide/he/basics.workflow.txt
  14. +78 −0 docs/guide/he/caching.data.txt
  15. +25 −0 docs/guide/he/caching.dynamic.txt
  16. +103 −0 docs/guide/he/caching.fragment.txt
  17. +59 −0 docs/guide/he/caching.overview.txt
  18. +31 −0 docs/guide/he/caching.page.txt
  19. +509 −0 docs/guide/he/database.ar.txt
  20. +383 −0 docs/guide/he/database.arr.txt
  21. +195 −0 docs/guide/he/database.dao.txt
  22. +8 −0 docs/guide/he/database.overview.txt
  23. +177 −0 docs/guide/he/extension.create.txt
  24. +31 −0 docs/guide/he/extension.integration.txt
  25. +23 −0 docs/guide/he/extension.overview.txt
  26. +266 −0 docs/guide/he/extension.use.txt
  27. +69 −0 docs/guide/he/form.action.txt
  28. +389 −0 docs/guide/he/form.builder.txt
  29. +325 −0 docs/guide/he/form.model.txt
  30. +74 −0 docs/guide/he/form.table.txt
  31. +88 −0 docs/guide/he/form.view.txt
  32. +77 −0 docs/guide/he/quickstart.first-app-yiic.txt
  33. +204 −0 docs/guide/he/quickstart.first-app.txt
  34. +26 −0 docs/guide/he/quickstart.what-is-yii.txt
  35. +60 −0 docs/guide/he/test.fixture.txt
  36. +67 −0 docs/guide/he/test.functional.txt
  37. +100 −0 docs/guide/he/test.overview.txt
  38. +79 −0 docs/guide/he/test.unit.txt
  39. +376 −0 docs/guide/he/topics.auth.txt
  40. +58 −0 docs/guide/he/topics.console.txt
  41. +104 −0 docs/guide/he/topics.error.txt
  42. +280 −0 docs/guide/he/topics.gii.txt
  43. +166 −0 docs/guide/he/topics.i18n.txt
  44. +149 −0 docs/guide/he/topics.logging.txt
  45. +111 −0 docs/guide/he/topics.performance.txt
  46. +185 −0 docs/guide/he/topics.prado.txt
  47. +93 −0 docs/guide/he/topics.security.txt
  48. +227 −0 docs/guide/he/topics.theming.txt
  49. +262 −0 docs/guide/he/topics.url.txt
  50. +173 −0 docs/guide/he/topics.webservice.txt
  51. +63 −0 docs/guide/he/upgrade.txt
  52. +349 −0 docs/guide/sv/topics.gii.txt
  53. +192 −0 docs/guide/uk/basics.application.txt
  54. +177 −0 docs/guide/uk/basics.component.txt
  55. +223 −0 docs/guide/uk/basics.controller.txt
  56. +136 −0 docs/guide/uk/basics.convention.txt
  57. +33 −0 docs/guide/uk/basics.entry.txt
  58. +36 −0 framework/messages/fr/zii.php
  59. +36 −0 framework/messages/ja/zii.php
View
46 docs/guide/fr/basics.workflow.txt
@@ -0,0 +1,46 @@
+Cycle de développement
+======================
+
+Après avoir décrit les fondamentaux de Yii, nous allons décrire le
+cycle de développement à mettre en oeuvre pour réaliser une application
+utilisant Yii. Le cycle de développement ci-dessous assume que la
+conception a déjà été réalisée.
+
+ 1. Créer le squelette de l'application. L'outil `yiic` décrit dans la
+partie [Créer sa première applicationYii](/doc/guide/quickstart.first-app)
+peut être utilisé pour accélérer cette étape.
+
+ 2. Configurer [l'application](/doc/guide/basics.application). Il faut
+adapter la configuration de l'application. Lors de cet étape, il est souvent
+nécessaire d'écrire de nouveaux composants (e.g. le composant utilisateur)
+
+ 3. Créer les classes des [modèles](/doc/guide/basics.model) pour tous les
+types de données à gérer. Ici encore, `yiic` peut être utilisé pour générer
+les [active record](/doc/guide/database.ar) liés à chaque table.
+
+ 4. Créer un [contrôleur](/doc/guide/basics.controller) pour chaque
+type de requête. Le découpage de l'application est étroitement lié à la conception.
+En général, si un modèle doit être rendu accessible aux utilisateurs, le
+contrôleur associé doit être créé. L'outil `yiic` peut aussi automatiser cette étape.
+
+ 5. Implémenter les [actions](/doc/guide/basics.controller#action) et les
+[vues](/doc/guide/basics.view) correspondantes. C'est ici que le travail
+commence.
+
+ 6. Configurer les [filtres](/doc/guide/basics.controller#filter) d'action au sein
+des contrôleurs.
+
+ 7. Créer les [thèmes](/doc/guide/topics.theming) si la fonctionnalité est
+nécessaire.
+
+ 8. Créer les traductions si [l'internationalisation](/doc/guide/topics.i18n)
+est nécessaire.
+
+ 9. Trouver les données et les vues qui peuvent être cachées et mettre en
+oeuvre les technique de [caching](/doc/guide/caching.overview) adaptées.
+
+ 10. Finalisation [tuning](/doc/guide/topics.performance) et deploiement.
+
+Pour chaque étape, il est recommandé de créer les tests unitaires associés.
+
+<div class="revision">$Id: basics.workflow.txt 1034 2008-12-04 01:40:16Z qiang.xue $</div>
View
51 docs/guide/fr/caching.page.txt
@@ -0,0 +1,51 @@
+Cache de page
+=============
+
+Le cache de page sert à mettre en cache l'intégralité d'une page. Le cache de page
+peut être mis en oeuvre à différents niveaux.
+Par exemple, en utilisant un header approprié, le navigateur peut mettre en
+cache la page en cours pour une durée définie ou encore, l'application web peut
+prendre en charge la mise en cache du contenu de la page.
+Dans cette section, nous présenterons cette dernière méthode.
+
+Le cache de page peut être considéré comme une extension du [cache par
+fragments](/doc/guide/caching.fragment). Sachant que généralement
+la génération d'une page fait intervenir un layout et une vue, il n'est
+pas possible d'appeler les méthodes [beginCache()|CBaseController::beginCache] et
+[endCache()|CBaseController::endCache] directement dans le layout. Cela est
+du au fait que le layout est appliqué dans la méthode [CController::render()]
+une fois que la vue a été évaluée.
+
+Pour cacher l'intégralité d'une page, il faut éviter l'exécution de
+l'action qui génère le contenu de la page. Pour ce faire,
+nous pouvons utiliser [COutputCache] en tant que
+[filtre](/doc/guide/basics.controller#filter). Le code suivant montre
+comment configurer le filtre de cache :
+
+~~~
+[php]
+public function filters()
+{
+ return array(
+ array(
+ 'COutputCache',
+ 'duration'=>100,
+ 'varyByParam'=>array('id'),
+ ),
+ );
+}
+~~~
+
+La configuration du filtre ci-dessus sera appliqué à toutes les actions
+du contrôleur. Nous pouvons limiter la portée du cache en utilisant
+l'opérateur "+". Plus de détails peuvent être trouvés dans la section
+[filtre](/doc/guide/basics.controller#filter).
+
+> Tip: Il est possible d'utiliser [COutputCache] en tant que filtre
+car il dérive de [CFilterWidget], ce qui signifie que c'est à la fois
+un filtre et un widget. En réalité un widget et un filtre sont très proches :
+un widget (filtre) commence avant qu'un contenu (action) soit évalué et le
+widget (filtre) se termine une fois que le contenu entre les
+balises (action) est évalué.
+
+<div class="revision">$Id: caching.page.txt 1014 2009-05-10 12:25:55Z qiang.xue $</div>
View
160 docs/guide/he/basics.application.txt
@@ -0,0 +1,160 @@
+אפליקציה
+===========
+
+האפליקציה מהווה עיבוד ראשוני של הבקשות אשר נכנסות למערכת. המטרה העיקרית שלה היא לקבל את בקשת המשתמש ולהפנות אותה לקונטרולר המתאים להמשך עיבוד הנתונים. בנוסף היא משמשת לחלק המרכזי של כל ההגדרות באפליקציה. מסיבה זו,האפליקציה נקראת גם בשם 'קונטרולר-ראשי'.
+
+האפליקציה נוצרת על ידי [סקריפט הכניסה הראשי](/doc/guide/basics.entry).
+ניתן לגשת לכל אובייקט וערך באפליקציה בעזרת [Yii::app()|YiiBase::app].
+
+
+הגדרות האפליקציה
+-------------------------
+
+כברירת מחדל, אפליקציה היא אובייקט של [CWebApplication]. להתאמה אישית, אנחנו בדרך כלל מספקים קובץ הגדרות (או מערך) כדי לאתחל את המאפיינים של קובץ/מערך ההגדרות בעת יצירת האפליקציה. דרך נוספת להתאמה אישית של האפליקציה היא על ידי הרחבת [CWebApplication].
+
+ההגדרות הם מערך של אלמנטים בפורמט של מפתח=>ערך. כל מפתח מייצג את שמו של המאפיין באובייקט של האפליקציה, וכל ערך את ערך ברירת המחדל של אותו מאפיין. לדוגמא, ההגדרות הבאות מגדירות את [שם האפליקציה|CApplication::name] ו [קונטרולר ברירת המחדל|CWebApplication::defaultController] של האפליקציה.
+
+~~~
+[php]
+array(
+ 'name'=>'Yii Framework',
+ 'defaultController'=>'site',
+)
+~~~
+
+בדרך כלל אנחנו שומרים את קובץ ההגדרות של האפליקציה בקובץ PHP נפרד (לדוגמא `protected/config/main.php`). בתוך הקובץ אנחנו מחזירים את מערך ההגדרות בצורה הבאה,
+
+~~~
+[php]
+return array(...);
+~~~
+
+כדי ליישם את ההגדרות, אנחנו מעבירים את שם קובץ ההגדרות כפרמטר לקונסטרקטור (constructor) של האפליקציה, או ל [Yii::createWebApplication()] כמו הדוגמא הבאה, שבדרך כלל נעשית ב [סקריפט הכניסה הראשי](/doc/guide/basics.entry).
+
+~~~
+[php]
+$app=Yii::createWebApplication($configFile);
+~~~
+
+> Tip|טיפ: אם ההגדרות של האפליקציה הם מורכבות, ניתן לפצל אותם לכמה קבצים, כל אחד מחזיר חלק אחר ממערך ההגדרות הכולל. לאחר מכן, בקובץ ההגדרות הראשי של האפליקציה ניתן להשתמש בפונקצית ה `include` של PHP כדי להוסיף את שאר קבצי ההגדרות ולאחד אותם למערך הגדרות אחד כולל.
+
+ספרית הבסיס של האפליקציה
+--------------------------
+
+ספרית הבסיס של האפליקציה מתיחחסת לתיקיה הראשית אשר מכילה את כל קבצי ה PHP והמידע של המערכת, הרגישים מבחינת אבטחה. כברירת מחדל, זוהי תת תיקיה בשם `protected` אשר נמצאת תחת התיקיה אשר מכילה את סקריפט הכניסה הראשי. ניתן לשנותה על ידי הגדרת המאפיין [basePath|CWebApplication::basePath] [בהגדרות האפליקציה](#application-configuration).
+
+התוכן תחת התיקיה הראשית של האפליקציה צריך להיות מוגן מגישה וצפייה ישירה ועקיפה על ידי משתמשים. בעזרת [Apache HTTP](http://httpd.apache.org/), ניתן לבצע זאת בצורה פשוטה על ידי הוספת קובץ `htaccess.` תחת התיקיה הראשית. הקובץ `htaccess.` אמור להכיל את הקוד הבא,
+
+~~~
+deny from all
+~~~
+
+רכיב האפליקציה
+---------------------
+
+הפונקציונליות של האפליקציה ניתנת להתאמה אישית בצורה קלה בעזרת הארכיטקטורה הגמישה של רכיב זה. האפליקציה מנהלת סט של רכיבי-אפליקציה, כל אחד מיישם אפשרויות מסויימות. לדוגמא, האפליקציה נעזרת ברכיבים [CUrlManager] ו [CHttpRequest] כדי לקבל את בקשת המשתמש ולנתב אותה למקום המתאים.
+
+על ידי הגדרת ערך [הרכיבים|CApplication::components] באפליקציה, ניתן להגדיר בצורה אישית את הערכים והמחלקה של כל רכיב אשר משתמשים בו באפליקציה. לדוגמא, ניתן להגדיר את הרכיב [CMemCache] בצורה כזו שיעבוד מול כמה שרתי memcache כדי לשמור תוכן במטמון,
+
+~~~
+[php]
+array(
+ ......
+ 'components'=>array(
+ ......
+ 'cache'=>array(
+ 'class'=>'CMemCache',
+ 'servers'=>array(
+ array('host'=>'server1', 'port'=>11211, 'weight'=>60),
+ array('host'=>'server2', 'port'=>11211, 'weight'=>40),
+ ),
+ ),
+ ),
+)
+~~~
+
+בקוד המוצג למעלה, אנחנו מוסיפים את האלמנט `cache` למערך של ה `components`. האלמנט `cache` הצהיר שהמחלקה של הרכיב הזה הינה `CMemCache` והערך של `servers` (שרתים) צריך להיות מוגדר כפי שהוא מוצג בקוד למעלה.
+
+כדי לגשת לרכיב באפליקציה, יש להשתמש ב `Yii::app()->ComponentID`, כש `ComponentID` מתייחס לשם היחודי של הרכיב (לדוגמא `Yii::app()->cache`).
+
+ניתן לכבות כל רכיב באפליקציה על ידי הגדרת הערך `enabled` ל false בהגדרות של אותו רכיב. ברגע שננסה לגשת לרכיב שהוא לא פעיל נקבל את הערך השווה ל Null.
+
+> Tip|טיפ: כברירת מחדל, רכיבים באפליקציה נוצרים בעת בקשתם. זה אומר שרכיב באפליקציה יכול לא להווצר כלל אם לא קראו לו במהלך הבקשה של המשתמש. כתוצאה מכך, הביצועים הכללים של האפליקציה לא מושפעים גם אם האפליקציה מוגדרת עם הרבה רכיבים. חלק מהרכיבים באפליקציה (לדוגמא [CLogRouter]) צריכים להווצר בכל מקרה בין אם קראו לאותו רכיב או לא. כדי לבצע זאת, רשום את המזהה היחודי שלהם במאפיין [preload|CApplication::preload] (טעינה מראש) של האפליקציה.
+
+
+רכיבים מרכזיים באפליקציה
+---------------------------
+
+Yii מגדירה מראש סט של רכיבים מרכזיים באפליקציה כדי לספק אפשרויות משותפות בקרב אפליקציות ווב. לדוגמא, הרכיב [request|CWebApplication::request] מעבד את בקשת המשתמש ומאפשר שימוש במידע כגון קישורים, עוגיות. על ידי הגדרת המאפיינים של רכיבים בסיסיים אלו, ניתן לשנות את אופי ההתנהלות של Yii בכל היבט כמעט.
+
+למטה מופיעים הרכיבים הבסיסיים שמוגדרים מראש על ידי [CWebApplication].
+
+
+- [assetManager|CWebApplication::assetManager]: [CAssetManager] -
+מנהל פרסום של קבצי הנכסים הפרטיים (בדרך כלל קבצי JS, CSS ותמונות).
+
+- [authManager|CWebApplication::authManager]: [CAuthManager] - ניהול בקרת גישות
+
+- [cache|CApplication::cache]: [CCache] - מספק פונקציונליות לניהול מטמון. הערה, הינך חייב לציין את שם המחלקה (לדוגמא
+[CMemCache], [CDbCache]). אחרת, יוחזר ערך השווה ל Null ברגע שתנסה לגשת לרכיב זה.
+
+- [clientScript|CWebApplication::clientScript]: [CClientScript] -
+ניהול סקריפטים בצד הלקוח (קבצי CSS ו JS).
+
+- [coreMessages|CApplication::coreMessages]: [CPhpMessageSource] -
+מספק תרגום של משפטי המקור אשר מוגדרים במערכת הפנימית של Yii.
+
+- [db|CApplication::db]: [CDbConnection] - מספק את החיבור של מסד הנתונים. הערה, הינך חייב להגדיר את המאפיין
+[connectionString|CDbConnection::connectionString] כדי להשתמש ברכיב זה.
+
+- [errorHandler|CApplication::errorHandler]: [CErrorHandler] - טיפול בשגיאות PHP ושגיאות חריגות אחרות שלא נתפסו.
+
+- [format|CApplication::format]: [CFormatter] - מעבד מידע למטרת תצוגה בלבד. אפשרות זאת קיימת מגרסא 1.1.0.
+
+- [messages|CApplication::messages]: [CPhpMessageSource] - מספק ניהול תרגומים של האפליקציה עצמה.
+
+- [request|CWebApplication::request]: [CHttpRequest] - מספק מידע הקשור לבקשת המשתמש.
+
+- [securityManager|CApplication::securityManager]: [CSecurityManager] -
+מספק שירותים הקשורים לאבטחת מידע, כגון יצירת HASH והצפנה.
+
+- [session|CWebApplication::session]: [CHttpSession] - מאפשר שימוש ב SESSIONS.
+
+- [statePersister|CApplication::statePersister]: [CStatePersister] -
+מאפשר ניהול של מידע אשר שמור באופן קבוע.
+
+- [urlManager|CWebApplication::urlManager]: [CUrlManager] - מאפשר עיבוד של קישורים ויצירתם.
+
+- [user|CWebApplication::user]: [CWebUser] - מייצג את זהות המשתמש הנוכחי.
+
+- [themeManager|CWebApplication::themeManager]: [CThemeManager] - ניהול תבניות.
+
+
+מחזור החיים של האפליקציה
+----------------------
+
+בעת טיפול בבקשת המשתמש, אפליקציה תעבור במחזור החיים הבא:
+
+0. אתחול האפליקציה בעזרת [CApplication::preinit];
+
+1. הגדרת מחלקת הטעינה האוטומטית ומחלקת טיפול בשגיאות;
+
+2. רישום רכיבים בסיסים של האפליקציה;
+
+3. טעינת הגדרות האפליקציה;
+
+4. אתחול האפליקציה בעזרת [CApplication::init]
+- רישום התנהלות האפליקציה;
+- טעינת רכיבים סטטיים של האפליקציה;
+
+5. העלאת אירוע [onBeginRequest|CApplication::onBeginRequest];
+
+6. תהליך עיבוד בקשת המשתמש:
+- עיבוד הבקשה;
+- יצירת קונטרולר;
+- הרצת קונטרולר;
+
+7. העלאת אירוע [onEndRequest|CApplication::onEndRequest];
+
+
+<div class="revision">$Id: basics.application.txt 1601 2009-12-18 04:31:19Z qiang.xue $</div>
View
137 docs/guide/he/basics.component.txt
@@ -0,0 +1,137 @@
+רכיב
+=========
+
+האפליקציות ב Yii נבנות תחת רכיבים שהינם אובייקטים אשר נכתבים על פי מפרט מסויים. רכיב הינו אובייקט של [CComponent] או מחלקות אשר נמצאות תחתיו. שימוש ברכיב בדרך כלל משמש כדי לגשת למאפיינים של אותו רכיב והעלאה וניהול של אירועים המוגדרים בו. המחלקה הבסיסית (הראשית) [CComponent] מציינת כיצד להגדיר את המאפיינים והאירועים.
+
+מאפייני רכיב
+------------------
+
+מאפיין רכיב הוא כמו משתנה במחלקה. ניתן לקרוא את הערך שבו או להגדיר לו ערך חדש. לדוגמא,
+
+~~~
+[php]
+$width=$component-»textWidth; // get the textWidth property
+$component-»enableCaching=true; // set the enableCaching property
+~~~
+
+כדי להגדיר מאפיין רכיב, כל מה שצריך לעשות זה פשוט להגדיר משתנה במחלקה של אותו רכיב. למרות זאת, אפשרות יותר גמישה תיהיה על ידי הגדרת פונקציות `קריאה` ו `כתיבה` בצורה הבאה:
+
+~~~
+[php]
+public function getTextWidth()
+{
+ return $this-»_textWidth;
+}
+
+public function setTextWidth($value)
+{
+ $this-»_textWidth=$value;
+}
+~~~
+
+הקוד המוצג למעלה מגדיר מאפיין הניתן לכתיבה בשם `textWidth` (השם אינו רגיש לאותיות גדולות-קטנות). בעת קריאה של מאפיין זה הפונקציה `getTextWidth` נכנסת לפעולה והערך שמוחזר ממנה הוא הערך של המשתנה במחלקה; באותו אופן, בעת שמירת ערך למאפיין זה הפונקציה `setTextWidth` נכנסת לפעולה. אם לא הוגדרה פונקציה לכתיבה של אותו מאפיין, המאפיין יהיה ניתן לקריאה-בלבד ובעת ניסיון לשנות את הערך שלו תזרק שגיאה. שימוש בפונקציות קריאה וכתיבה של משתנים/מאפיינים כדי לקרוא אותם ולהגדירם מאפשרת הרצת בדיקות ולוגיקות נוספות (לדוגמא ביצוע אימות נתונים, העלאת אירועים).
+
+
+»Note|הערה: ישנו הבדל קטן בין מאפיין אשר מוגדר בעזרת פונקציות קריאה/כתיבה ומאפיין אשר מוגדר בעזרת משתנה במחלקה. מאפיין המוגדר בעזרת פונקציות שמו לא רגיש לאותיות גדולות-קטנות, לעומת משתנה במחלקה שהינו רגיש לאותיות גדולות-קטנות.
+
+אירועים ברכיב
+---------------
+
+אירועי רכיב הם תכונות מיוחדות הלוקחות פונקציות (הנקראות `event handlers`) בתור הערכים שלהם. צירוף (הקצאת) פונקציה לאירוע מסויים יגרום לפונקציה לרוץ אוטומטית במקומות בהם האירוע מתרחש. לכן, ההתנהלות של הרכיב יכולה להשתנות בצורה כזאת שלא ניתן לצפות בה מראש במהלך פיתוח הרכיב.
+
+אירוע ברכיב מוגדר על ידי הגדרת פונקציה ששמה מתחיל ב 'on'. כמו שמות מאפיינים המוגדרים בעזרת פונקציות קריאה/כתיבה, שמות האירועים אינם רגישים לאותיות גדולות-קטנות. הקוד הבא מגדיר אירוע `onClicked`:
+
+~~~
+[php]
+public function onClicked($event)
+{
+ $this-»raiseEvent('onClicked', $event);
+}
+~~~
+
+איפה ש `event$` הוא אובייקט של [CEvent] או מחלקות אשר נמצאות תחתיו המייצג את פרמטר האירוע.
+
+ניתן לצרף פונקציה לאירוע זה בצורה הבאה:
+
+~~~
+[php]
+$component-»onClicked=$callback;
+~~~
+
+כש `callback$` מכוון לפונקצית PHP תקינה. פונקציה זו יכולה להיות פונקציה גלובלית או מתודה במחלקה. אם הוגדר שהיא הינה מתודה במחלקה, יש להגדיר את הערך כמערך כשהאלמנט הראשון הוא האובייקט של אותה מחלקה והשני הוא שם המתודה:
+
+~~~
+[php]
+array($object,'methodName')
+~~~
+
+פונקציה המטפלת באירוע כלשהו צריכה להראות בדומה לקוד הבא:
+
+~~~
+[php]
+function methodName($event)
+{
+ ......
+}
+~~~
+
+כש `event$` הוא משתנה המכיל מידע אודות האירוע שהועלה (הוא נוצר מהקריאה של `raiseEvent`). המשתנה `event$` הוא אובייקט של [CEvent] או מחלקות הנמצאות תחתיו. המינימום הוא שיכיל מידע של מי העלאה את האירוע.
+
+החל מגרסא 1.0.10, ניתן לנהל אירוע על ידי פונקציה אנונימית אשר נתמכת בגרסאת PHP 5.3 ומעלה, לדוגמא,
+
+~~~
+[php]
+$component-»onClicked=function($event) {
+ ......
+}
+~~~
+
+אם נקרא ל `onClicked` עכשיו, האירוע `onClicked` יבוצע (בתוך הפונקציה `onClicked`), והפונקציה אשר מטפלת באירוע זה תקרא אוטומטית.
+
+ניתן לצרף כמה פונקציות לטיפול באותו אירוע. כשהאירוע יבוצע והפונקציות יקראו, הם יבוצעו בסדר שהם צורפו לאותו אירוע. אם אחד מהפונקציות המטפלות באירוע רוצה למנוע קריאה לשאר הפונקציות המטפלות באותו האירוע, ניתן להגדיר [$event-»handled|CEvent::handled] לערך השווה ל `true` ולא יקראו פונקציות נוספות לטיפול באירוע זה.
+
+ניהול הרכיב
+------------------
+
+החל מגרסא 1.0.2, לרכיב נוספה תמיכה ב [mixin](http://en.wikipedia.org/wiki/Mixin) וניתנת לצירוף בעזרת ניהול אחד או יותר. *ניהול* הוא אובייקט שניתן `להוריש` את המתודות שלו על ידי הרכיבים המצורפים אליו כדי לאסוף פונקציונליות במקום התמחות מסויימת (לדוגמא, הורשה רגילה של מחלקות). לרכיב ניתן לצרף כמה מחלקות ניהול ובכך להשיג `הורשת מחלקות מרובה`.
+
+מחלקות ניהוליות חייבות ליישם את הממשק [IBehavior]. רוב המחלקות הניהוליות מרחיבות תחת המחלקה הבסיסית [CBehavior]. אם מחלקה ניהולית צריכה להיות מצורפת [למודל](/doc/guide/basics.model), ניתן להרחיב אותה גם מ [CModelBehavior] או [CActiveRecordBehavior] אשר מיישמות אפשרויות נוספות ספציפיות למודלים.
+
+בכדי להשתמש במחלקה ניהולית, חובה לצרף אותה לרכיב קודם על ידי קריאה למתודה בשם [attach|IBehavior::attach]. לאחר מכן אנו קוראים למתודה של מחלקה ניהולית דרך הרכיב:
+
+~~~
+[php]
+// $name uniquely identifies the behavior in the component
+$component-»attachBehavior($name,$behavior);
+// test() is a method of $behavior
+$component-»test();
+~~~
+
+ניתן לגשת למחלקה ניהולית מצורפת כמו למאפיין רגיל של הרכיב. לדוגמא, אם צרפנו מחלקה ניהולית בשם `tree` לרכיב, ניתן לקבל יחוס של אותה מחלקה על ידי שימוש ב:
+
+~~~
+[php]
+$behavior=$component-»tree;
+// equivalent to the following:
+// $behavior=$component-»asa('tree');
+~~~
+
+ניתן לכבות זמנית מחלקה מצורפת כדי שלא יהיה ניתן לגשת למתודות שלה דרך הרכיב. לדוגמא:
+
+~~~
+[php]
+$component-»disableBehavior($name);
+// the following statement will throw an exception
+$component-»test();
+$component-»enableBehavior($name);
+// it works now
+$component-»test();
+~~~
+
+ישנה אפשרות ששני מחלקות ניהוליות אשר מצורפות לאותו רכיב יכילו מתודות זהות בשמם. במקרה הזה, המתודה של המחלקה שצורפה קודם לכן תקבל זכות על פני השנייה.
+
+כשמשתמשים ביחד עם [אירועים](#component-event), מחלקות ניהוליות הרבה יותר שימושיות. מחלקה ניהולית, בעת צירופה לרכיב, יכולה לצרף כמה מתודות שלה לכמה אירועים ברכיב. על ידי ביצוע פעולה זו, המחלקה הניהולית מקבלת הזדמנות להתבונן או לשנות את רצף הביצועים הרציפים של הרכיב.
+
+החל מגרסא 1.1.0, ניתן לקרוא למאפיינים של מחלקה ניהולית דרך הרכיב אליו הם מצורפים. המאפיינים מכילים גם את המשתנים של המחלקה והמאפיינים אשר מוגדרים באמצעות פונקציות קריאה/כתיבה במחלקה הניהולית. לדוגמא, אם מחלקה ניהולית מכילה מאפיין בשם `xyz` והיא מצורפת לרכיב `a$`, אז נוכל להשתמש בביטוי `a-»xyz$` כדי לגשת למאפיין של המחלקה הניהולית המצורפת לרכיב.
+
+«div class="revision"»$Id: basics.component.txt 1474 2009-10-18 21:13:52Z qiang.xue $«/div»
View
168 docs/guide/he/basics.controller.txt
@@ -0,0 +1,168 @@
+קונטרולר
+==========
+
+`קונטרולר` הינו אובייקט של [CController] או מחלקות היורשות ממנו. הקונטרולר נוצר על ידי האפליקציה כהמשתמש מבקש אותו.
+ כשהקונטרולר רץ, הוא מבצע את הפעולה הנחוצה שבדרך כלל נעזרת במודלים ומציגה את התוכן בעזרת קבצי התצוגה.
+ `פעולה` (Action), בצורה הכי פשוטה שלו, הינו מתודה במחלקה של הקונטרולר אשר מתחילה ב `action`.
+
+לקונטרולר יש פעולה ברירת מחדל.
+ כשמשתמש אשר מבקש את הקונטרולר לא מגדיר איזה פעולה לבצע, פעולה ברירת המחדל היא זו שתרוץ.
+ כברירת מחדל, פעולת ברירת המחדל הינה `index`. ניתן לשנות זאת על ידי הגדרת המאפיין [CController::defaultAction].
+
+למטה מוצג הקוד המינימלי כדי ליצור מחלקה לקונטרולר. מאחר ולא קיימים שום פעולות במחלקה במידה והקונטרולר יבוקש על ידי המשתמש תזרק שגיאה.
+
+~~~
+[php]
+class SiteController extends CController
+{
+}
+~~~
+
+ניתוב
+-----
+
+קונטרולרים ופעולות מזוהים על ידי זיהוי יחודי. מזהה יחודי של קונטרולר הוא בפורמט של `path/to/xyz` אשר מכוונת לקובץ המחלקה של הקונטרולר `protected/controllers/path/to/xyzController.php`, כשהמזהה `xyz` יוחלף בשמות אמיתיים של קונטרולרים (לדוגמא `post` מכוון לקובץ `protected/controllers/PostController.php`).
+מזהה יחודי של פעולה הינו שמה של המתודה במחלקה ללא הקידומת של `action`. לדוגמא, אם מחלקת הקונטרולר מכילה מתודה בשם `actionEdit`, המזהה היחודי של הפעולה יהיה `edit`.
+
+» Note|הערה: בגרסאות לפני 1.0.3, הפורמט של המזהה היחודי של הקונטרולר היה `path.to.xyz` במקום `path/to/xyz`.
+
+בקשת משתמש עבור קונטרולר ופעולה כלשהי מיוצגת כניתוב.
+ נתב נוצר על ידי שרשור של מזהה היחודי של הקונטרולר והמזהה היחודי של הפעולה מופרדים בסלאש (/).
+ לדוגמא, הנתב `post/edit` מכוון אל הקונטרולר `PostController` ולפעולה `edit`.
+ וכברירת מחדל הקישור `http://hostname/index.php?r=post/edit` יטען את הקונטרולר והפעולה הללו.
+
+» Note|הערה: כברירת מחדל, נתבים רגישים לאותיות גדולות-קטנות.
+ מגרסא 1.0.1 ומעלה, ניתן לבטל את הרגישות של הנתבים לאותיות גדולות-קטנות על ידי הגדרת [CUrlManager::caseSensitive] לערך השווה ל `false` בהגדרות של האפליקציה.
+ במצב שהנתבים לא רגישים לאותיות גדולות-קטנות, וודא שהינך עוקב אחר המוסכמות ששמות התיקיות המכילות קונטרולרים כתובים באותיות קטנות באנגלית, [מפת קונטרולרים|CWebApplication::controllerMap] ו [מפת פעולות|CController::actions] משתמשים בשמות מפתח באותיות קטנות ובאנגלית.
+
+מגרסא 1.0.3 ומעלה, אפליקציה יכולה להכיל [מודולים](/doc/guide/basics.module). הניתוב לפעולה בקונטרולר שונה בפורמט שלה ועכשיו היא בפורמט של `moduleID/controllerID/actionID`. למידע נוסף קרא אודות [מודולים](/doc/guide/basics.module).
+
+יצירת אובייקט הקונטרולר
+------------------------
+
+אובייקט הקונטרולר נוצר כש [CWebApplication] מטפל בבקשה הנכנסת. עם קבלת המזהה היחודי של הקונטרולר, האפליקציה תשתמש בחוקים הבאים כדי להחליט איזה קונטרולר לטעון ואיפה קובץ המחלקה שלו נמצא.
+
+- אם [CWebApplication::catchAllRequest] מוגדר, יווצר קונטרולר בהתבסס על המאפיין הזה, והאפליקציה תתעלם מהקונטרולר שהמשתמש ביקש. מאפיין זה נועד כדי לתפוס את כל בקשות המשתמש ולהכווין אותם אל מקום אחד, לדוגמא במצב של תחזוקה באתר יהיה צורך להציג עמוד אחד שמציג הודעת תחזוקה כלשהי.
+
+- אם המזהה היחודי של הקונטרולר נמצא ב [CWebApplication::controllerMap], ההגדרות של אותו קונטרולר שנמצא ישומשו והאובייקט יווצר בהתבסס על אותם ההגדרות.
+
+- אם המזהה היחודי הוא בפורמט של `path/to/xyz`, שם המחלקה של הקונטרולר יהיה `XyzController` והקובץ ימצא תחת `protected/controllers/path/to/XyzController.php`. לדוגמא, מזהה יחודי של קונטרולר בשם `admin/user` ינותב למחלקה `UserController` וקובץ המחלקה יהיה `protected/controllers/admin/UserController.php` אם קובץ המחלקה לא קיים, תזרק שגיאה 404 [CHttpException].
+
+במקרה של שימוש במודולים (בגרסאות 1.0.3), התהליך המוצג למעלה שונה במקצת. ספציפית, האפליקציה תבדוק אם המזהה היחודי מכוון לקונטרולר בתוך מודול, במידה וכן, אובייקט של המודל יווצר קודם ולאחר מכן יווצר האובייקט של הקונטרולר.
+
+פעולה
+------
+
+כפי שצויין, ניתן להגדיר פעולה על ידי יצירת מתודה במחלקה של הקונטרולר כששמה מתחיל ב `action`. דרך יותר מתקדמת תיהיה על ידי יצירת מחלקה לפעולה ולבקש מהקונטרולר ליצור אובייקט שלה כשצריך. דרך זו מאפשרת שימוש חוזר בפעולות ויותר שימושית.
+
+כדי להגדיר פעולה בתור מחלקה יש לבצע את הפעולות הבאות:
+
+~~~
+[php]
+class UpdateAction extends CAction
+{
+ public function run()
+ {
+ // place the action logic here
+ }
+}
+~~~
+
+כדי שהקונטרולר יהיה מודע לפעולה זו, אנחנו דורסים את המתודה [actions|CController::actions] של מחלקת הקונטרולר שלנו:
+
+~~~
+[php]
+class PostController extends CController
+{
+ public function actions()
+ {
+ return array(
+ 'edit'=»'application.controllers.post.UpdateAction',
+ );
+ }
+}
+~~~
+
+בקוד למעלה, אנחנו משתמשים בשם מקוצר `application.controllers.post.UpdateAction` כדי להגדיר שקובץ מחלקת הפעולה נמצא ב `protected/controllers/post/UpdateAction.php`.
+
+באמצעות כתיבת פעולות בתור מחלקות, ניתן לארגן את האפליקציה בצורה מודולרית. לדוגמא, ניתן להשתמש במבנה האפליקציה הבא כדי לארגן את כל הקונטרולרים:
+
+~~~
+protected/
+ controllers/
+ PostController.php
+ UserController.php
+ post/
+ CreateAction.php
+ ReadAction.php
+ UpdateAction.php
+ user/
+ CreateAction.php
+ ListAction.php
+ ProfileAction.php
+ UpdateAction.php
+~~~
+
+פילטרים
+------
+
+פילטר הינו חתיכת קוד אשר מוגדרת לרוץ לפני ו/או אחרי הרצה של פעולה בקונטרולר. לדוגמא, ניתן לבדוק בעזרת פילטר אם משתמש יכול לבצע את הפעולה אותה הוא מנסה להריץ; ניתן להריץ פילטר אשר בודק את משך זמן הרצת הפעולה לצורך קבלת משך זמן הרצת הפעולה.
+
+כל פעולה יכולה להכיל כמה פילטרים. הפילטרים רצים בסדר בהם הם רשומים ברשימת הפילטרים. פילטר יכול למנוע את ההרצה של פעולה כלשהי והרצה של פילטרים נוספים הבאים אחריה.
+
+ניתן להגדיר פילטר בתור מתודה במחלקת הקונטרולר. שם המתודה חייב להתחיל ב `method`. לדוגמא, הקיום של מתודת הפילטר בשם `filterAccessControl` מגדירה פילטר בשם `accessControl`. מתודת הפילטר צריכה להיות חתומה בפורמט של:
+
+~~~
+[php]
+public function filterAccessControl($filterChain)
+{
+ // call $filterChain-»run() to continue filtering and action execution
+}
+~~~
+
+כש `filterChain$` הוא אובייקט של [CFilterChain] אשר מייצג את רשימת הפילטרים המקושרת לפעולה שהתבקשה. בתוך המתודה של הפילטר ניתן לקרוא ל `filterChain-»run$` להמשך הרצת הפילטרים הבאים והרצת הפעולה עצמה.
+
+פילטר יכול להיות גם אובייקט של [CFilter] או מחלקות היורשות ממנו. הקוד הבא מגדיר מחלקת פילטר חדשה:
+
+~~~
+[php]
+class PerformanceFilter extends CFilter
+{
+ protected function preFilter($filterChain)
+ {
+ // logic being applied before the action is executed
+ return true; // false if the action should not be executed
+ }
+
+ protected function postFilter($filterChain)
+ {
+ // logic being applied after the action is executed
+ }
+}
+~~~
+
+כדי לצרף פילטרים לפעולות, יש צורך בלדרוס את המתודה `CController::filters`. המתודה צריכה להחזיר מערך עם רשימת הפילטרים וההגדרות שלהם. לדוגמא,
+
+~~~
+[php]
+class PostController extends CController
+{
+ ......
+ public function filters()
+ {
+ return array(
+ 'postOnly + edit, create',
+ array(
+ 'application.filters.PerformanceFilter - edit, create',
+ 'unit'=»'second',
+ ),
+ );
+ }
+}
+~~~
+
+הקוד למעלה מגדיר שני פילטרים: `postOnly` ו `PerformanceFilter`. הפילטר `postOnly` הוא פילטר המבוסס על מתודה במחלקה הנוכחית (המתודה של הפילטר כבר מוגדרת ב [CController]); בזמן שהפילטר `PerformanceFilter` הוא מבוסס אובייקט. הנתיב המקוצר `application.filters.PerformanceFilter` מציין שהמחלקה לפילטר נמצאת תחת `protected/filters/PerformanceFilter`. אנחנו משתמשים במערך כדי להגדיר את הפילטר `PerformanceFilter` שיהיה ניתן ליצור אותו בעזרת אותם ערכים כמאפיינים של המחלקה של הפילטר. בדוגמא הזאת המאפיין `unit` יווצר ויוגדר לערך השווה ל `second` במחלקה `PerformanceFilter`.
+
+שימוש באופרטורים של פלוס ומינוס, ניתן להגדיר אילו פעולות הפילטר יצורף אליהם ואילו לא. בדוגמא למעלה, הפילטר `postOnly` יצורף אל הפעולות `edit` ו `create` , בזמן שהפילטר `PerformanceFilter` יצורף אל כל הפעולות **מלבד** `edit` ו `create`. אם בהגדרות הפילטר לא יוגדרו פלוס או מינוס, הפילטר יצורף אל כל הפעולות.
+
+«div class="revision"»$Id: basics.controller.txt 1264 2009-07-21 19:34:55Z qiang.xue $«/div»
View
90 docs/guide/he/basics.convention.txt
@@ -0,0 +1,90 @@
+מוסכמות
+===========
+
+Yii מעדיפה מוסכמות על הגדרות. לעקוב אחר המוסכמות וניתן יהיה לבנות אפליקציות מתוחכמות ללא צורך בכתיבה וניהול של הגדרות מסובכות. כמובן, עדיין יהיה ניתן להגדיר את כל ההגדרות של Yii כשצריך.
+
+למטה מוצגים המוסכמות המומלצים כשמתכנתים בעזרת Yii. לנוחות, אנחנו מניחים ש `webRoot` מנותב לתיקיה הראשית בה מותקנת האפליקציה של Yii.
+
+קישורים
+---
+
+כברירת מחדל, Yii מזהה קישורים בפורמט הבא:
+
+~~~
+http://hostname/index.php?r=ControllerID/ActionID
+~~~
+
+הפרמטר `r` מכוון אל [נתב](/doc/guide/basics.controller#route) אשר ניתן לעבד אותו לקונטרולר ופעולה. במידה והמזהה היחודי של הפעולה `ActionID` חסר, הקונטרולר יריץ את פעולת ברירת המחדל המוגדרת באמצעות [CController::defaultAction]; במידה והמזהה היחודי של הקונטרולר `controllerID` חסר (או הפרמטר `r` חסר) האפליקציה תריץ את הקונטרולר המוגדר כברירת מחדל בעזרת [CWebApplication::defaultController].
+
+בעזרת [CUrlManager], ניתן ליצור קישורים יותר ידידותיים גם ל SEO, כמו לדוגמא `http://hostname/ControllerID/ActionID.html`. ניתן לקרוא בהרחבה אודות אפשרות זו [בניהול קישורים](/doc/guide/topics.url).
+
+
+קוד
+----
+
+Yii ממליצה לקרוא למשתנים, פונקציות ומחלקות בפורמט של camelCase (פורמט אשר רושמים ראשונה במילה כאות גדולה ולחבר אותם ללא רווחים). שמות משתנים ופונקציות צריכות שהמילה הראשונה בשם שלהם תיהיה כולה באותיות קטנות (מילה ראשונה באותיות קטנות כל שאר המילים האות הראשונה במילה כאות גדולה ולחברם ביחד ללא רווחים), כדי להבדיל אותם משמות מחלקה (לדוגמא `$basePath`, `runController()`, `LinkPager`). למשתנים פרטיים (המוגדרים כ `private`) במחלקה מומלץ להוסיף קו תחתון (_) לשמם לדוגמא (`$_actionList`).
+
+מאחר והתמיכה במרחבי שמות לא נתמכת בגרסאות PHP מתחת ל 5.3.0, מומלץ לקרוא למחלקות בשמות יחודיים כדי למנוע סתירות בין שמות מחלקות. מסיבה זו, כל המחלקות הבסיסיות של Yii מתחילות באות 'C'.
+
+חוק ברזל לשמות מחלקות הוא שהם צריכים להסתיים במילה `Controller`. המזהה היחודי של הקונטרולר מוגדר כשם המחלקה באותיות קטנות בלבד וללא המילה `Controller`. לדוגמא, מחלקת הקונטרולר `PageController` תקבל את המזהה היחודי `page`. חוק זה מוודא שהאפליקציה תיהיה מאובטחת יותר. בנוסף הוא מציג את הקישורים בצורה נקייה יותר (לדוגמא `/index.php?r=page/index` במקום `/index.php?r=PageController/index` ).
+
+הגדרות
+-------------
+
+הגדרות הם מערך זוגות של מפתחות וערכים. כל מפתח מייצג את שמו של המאפיין של הרכיב שצריך להגדיר, וכל ערך מייצג את הערך הראשוני של אותו מאפיין. לדוגמא , `array('name'=»'My
+application', 'basePath'=»'./protected') מאתחל את המאפיינים `name` ו `basePath` באפליקציה בהתאם לערכים המוגדרים במערך.
+
+כל המאפיינים (הציבוריים - Public) באובייקט ניתנים להגדרה. אם לא הוגדרו, המאפיינים יקבלו את ערך ברירת המחדל שלהם. כשמגדירים מאפיין כלשהו, רצוי לקרוא בדוקומנטציה אודות המאפיין כדי להגדיר את הערך המתאים.
+
+קובץ
+----
+
+מוסכמות להגדרת שמות ושימוש בקבצים תלויים בסוג שלהם.
+
+שמות קבצי מחלקות צריכות להקרא על פי המחלקה הציבורית הנמצאת בהם. לדוגמא, שם הקובץ של המחלקה [CController] הוא `CController.php`. מחלקה ציבורית הינה מחלקה שניתן להשתמש בה בכל מחלקה אחרת. רצוי שכל קובץ מחלקה יכיל מחלקה ציבורית אחת לכל היותר. מחלקות פרטיות (מחלקות אשר ניתן להשתמש בהם במחלקה ציבורית אחת בלבד) יכול להיות בתוך אותו קובץ של המחלקה הציבורית שבה היא משומשת.
+
+קבצי תצוגה צריכים להקרא על פי שמות התצוגה. לדוגמא, שם קובץ התצוגה `index` יהיה `index.php`. קובץ תצוגה הוא קובץ PHP המכיל בעיקר קוד PHP ו HTML למטרת תצוגה בעיקר.
+
+קבצי הגדרות יכולים להקרא באופן שרירותי. קובץ הגדרות הוא קובץ PHP המכיל ומחזיר מערך של הגדרות.
+
+תיקיה
+---------
+
+Yii מניח כברירת מחדל כמה תיקיות אשר הוא משתמש למטרות שונות. את כל אחד ניתן להגדיר בצורה שונה במידה וצריך.
+
+- `WebRoot/protected`: זוהי [התיקיה הראשית](/doc/guide/basics.application#application-base-directory) של האפליקציה המכילה קבצים וסקריפטים של PHP רגישים. Yii מגדירה שם מקוצר ברירת מחדל בשם `application` אשר מנותבת לתיקיה זו. תיקיה זו וכל מה שבתוכה צריכה להיות מוגנת מפני גישה של משתמשי קצה. ניתן להגדירה בעזרת [CWebApplication::basePath].
+
+- `WebRoot/protected/runtime`: תיקיה זו מכילה קבצים זמניים פרטיים הנוצרים בזמן הרצת האפליקציה. תיקיה זו חייבת לקבל הרשאות כתיבה על ידי השרת. ניתן להגדירה בעזרת [CApplication::runtimePath].
+
+- `WebRoot/protected/extensions`: תיקיה זו מכילה את כל התוספים למערכת. ניתן להגדירה בעזרת [CApplication::extensionPath].
+
+- `WebRoot/protected/modules`: תיקיה זו מכילה את כל [המודולים](/doc/guide/basics.module) של האפליקציה, כל אחת מייצגת כתת-תיקיה.
+
+- `WebRoot/protected/controllers`: תיקיה זו מכילה את כל הקונטרולרים של האפליקציה. ניתן להגדירה בעזרת [CWebApplication::controllerPath].
+
+- `WebRoot/protected/views`: תיקיה זו מכילה את כל קבצי התצוגה, הכוללים את קבצי התצוגה של הקונטרולרים, קבצי תצוגת התבניות, וקבצי תצוגה מערכתיים. ניתן להגדירה בעזרת [CWebApplication::viewPath].
+
+- `WebRoot/protected/views/ControllerID`: תיקיה זו מכילה את קבצי התצוגה לקונטרולר יחיד. במקרה הזה `ControllerID` מייצג את המזהה היחודי של הקונטרולר. ניתן להגדיר זאת על ידי [CController::viewPath].
+
+- `WebRoot/protected/views/layouts`: תיקיה זו מכילה את כל קבצי התבניות של האפליקציה. ניתן להגדירה בעזרת [CWebApplication::layoutPath].
+
+- `WebRoot/protected/views/system`: תיקיה זו מכילה את כל קבצי התצוגה המערכתיים כמו התצוגה של שגיאות ולוגים של המערכת. ניתן להגדיר זאת על ידי [CWebApplication::systemViewPath].
+
+- `WebRoot/assets` : תיקיה זו מכילה את קבצי הנכסים (JS, CSS) , קבצים אלו הם פרטיים אשר ניתן לפרסמם כדי שמשתמשי קצה יוכלו לגשת אליהם. תיקיה זו צריכה לקבל הרשאות כתיבה על ידי השרת כדי לתפקד כראוי. ניתן להגדירה בעזרת [CAssetManager::basePath].
+
+- `WebRoot/themes` : תיקיה זו מכילה עיצובים שונים אשר ניתן להשתמש בהם באפליקציה. כל תת תיקיה מייצגת עיצוב בודד ששמו הוא שם התיקיה בה הוא נמצא. ניתן להגדיר את נתיב התיקיה בעזרת [CThemeManager::basePath].
+
+מסד נתונים
+--------
+
+מרבית אפליקציות הווב מגובות על ידי מסד נתונים. לצרכי תרגול טוב, אנחנו ממליצים על נתינת שמות בפורמט הבא לטבלאות ועמודות במסדי הנתונים. למרות ש Yii אינו מחייב זאת.
+
+- שמות הטבלאות והעמודות צריכות להיות כתובות באותיות קטנות בלבד.
+
+- המילים בשם צריכים להיות מופרדים בקו תחתון ( _ ) לדוגמא `product_order`.
+
+- שמות טבלאות יכולות להיות בפורמט של יחיד או רבים, אך לא שניהם. לפשטות, אנו ממליצים שימוש בפורמט של יחיד.
+
+- ניתן להגדיר קידומת לשמות טבלאות כמו `_tbl`. זה במיוחד רצוי כשהטבלאות של האפליקציה חולקות את אותו המסד עם אפליקציה נוספת. ניתן להפריד והבדיל בין הטבלאות בעזרת הקידומת שלהם.
+
+«div class="revision"»$Id: basics.convention.txt 1768 2010-02-01 01:34:15Z qiang.xue $«/div»
View
26 docs/guide/he/basics.entry.txt
@@ -0,0 +1,26 @@
+קובץ כניסה ראשי
+============
+
+קובץ הכניסה הראשי הינו סקריפט PHP אשר מקבל את בקשת המשתמש לראשונה וקובע את טעינת האפליקציה. זהו קובץ ה PHP היחידי שמשתמש הקצה יכול לבקש להריץ.
+
+ברוב המקרים, קובץ הכניסה הראשי באפליקציה של Yii מכיל את הקוד הפשוט הבא,
+
+~~~
+[php]
+// remove the following line when in production mode
+defined('YII_DEBUG') or define('YII_DEBUG',true);
+// include Yii bootstrap file
+require_once('path/to/yii/framework/yii.php');
+// create application instance and run
+$configFile='path/to/config/file.php';
+Yii::createWebApplication($configFile)-»run();
+~~~
+
+הסקריפט קודם כל טוען את קובץ הכניסה הראשי של Yii בשם `yii.php` מהתיקיה הראשית של הפריימוורק. לאחר מכן היא יוצרת אובייקט של האפליקציה עם ההגדרות הדרושות ומריצה אותו.
+
+מצב ניפוי שגיאות
+----------
+
+אפליקצית Yii יכולה לרוץ במצב של ניפוי שגיאות או במצב רגיל (תפוקתי - Production) בהתאם לערך שהוגדר במשתנה הקבוע `YII_DEBUG`. כברירת מחדל, משתנה זה מוגדר לערך השווה ל `false`, משמע מצב רגיל. כדי להריץ את האפליקציה במצב של ניפוי שגיאות, יש לקבוע את המשתנה הזה לערך השווה ל `true` לפני הוספת הקובץ `yii.php`. הרצת אפליקציה במצב של ניפוי שגיאות היא לא יעילה מאחר והיא שומרת הרבה לוגים ומידע אודות הרצת האפליקציה. מצד שני, הרצת אפליקציה במצב של ניפוי שגיאות מקלה על פיתוח האפליקציה מאחר והיא מציגה מידע ולוגים אודות השגיאות אשר קוראות במהלך הרצת האפליקציה.
+
+«div class="revision"»$Id: basics.entry.txt 1622 2009-12-26 20:56:05Z qiang.xue $«/div»
View
14 docs/guide/he/basics.model.txt
@@ -0,0 +1,14 @@
+מודל
+=====
+
+מודל הוא אובייקט של [CModel] או מחלקות היורשות ממנו. שימוש במודלים נועד כדי לשמור את המידע והלוגיקה מאחוריהם.
+
+מודל מייצג אובייקט מידע יחיד. אובייקט זה יכול לייצג רשומה אחת במסד הנתונים טבלה או טופס של נתונים שהמשתמש הזין. כל שדה של אובייקט המידע מיוצג כמאפיין של המודל. למאפיין ישנה תוית וניתן לאמת אותו מול רשימה של חוקים.
+
+Yii מיישמת שני סוגים של מודלים: מודל טופס ומודל AR. שניהם יורשים מאותה מחלקה בסיסית בשם [CModel].
+
+מודל טופס הוא אובייקט של [CFormModel]. מודל טופס נועד לאחסון מידע שהוזן על ידי המשתמש. בדרך כלל מידע זה נאסף, משומש, ונזרק. לדוגמא, בעמוד התחברות, ניתן להשתמש במודל טופס כדי לייצג מידע של שם המשתמש והסיסמא שהמשתמש הזין. למידע נוסף, יש לקרוא [כיצד לעבוד עם טפסים](/doc/guide/form.model).
+
+AR (Active Record) הינו דפוס אשר ניתן להשתמש בגישה למסד הנתונים, טבלאות ורשומות בצורה של תכנות מונחה-עצמים. כל אובייקט AR הינו אובייקט של [CActiveRecord] או מחלקות היורשות ממנו, המייצג שורה אחת בטבלה במסד הנתונים. העמודות בשורה מיוצגות כמאפיינים של אובייקט ה AR. למידע נוסף יש לקרוא אודות [Active Record](/doc/guide/database.ar).
+
+«div class="revision"»$Id: basics.model.txt 162 2008-11-05 12:44:08Z weizhuo $«/div»
View
82 docs/guide/he/basics.module.txt
@@ -0,0 +1,82 @@
+מודול
+======
+
+» Note|הערה: תמיכה במודולים קיימת מגרסא 1.0.3 ומעלה.
+
+מודול היא יחידה בפני עצמה המורכבת מ - [מודלים](/doc/guide/basics.model), [קבצי תצוגה](/doc/guide/basics.view), [קונטרולרים](/doc/guide/basics.controller) ושאר רכיבים נתמכים. במובנים רבים, מודול דומה ל[אפליקציה](/doc/guide/basics.application). ההבדל היחידי הוא שלא ניתן לפרוס מודול כפי שהוא והוא חייב להיות ממוקם בתוך אפליקציה. ניתן לגשת לקונטרולרים בתוך מודול כפי שניגשים לקונטרולר רגיל באפליקציה.
+
+מודולים יעילים בכמה תסריטים. בעבור אפליקציה גדולה במיוחד, ניתן לחלק אותה למספר מודולים, כל אחד מפותח ומתוחזק בצורה נפרדת. כמה חלקים אשר משתמשים בהם לעיתים קרובות, כמו ניהול משתמשים, ניהול תגובות, יכולים להיות מפותחים בפורמט של מודול כדי שיהיה ניתן להשתמש בהם בקלות בפרוייקטים עתידיים.
+
+יצירת מודול
+---------------
+
+מודול מאורגן על פי תיקיה ששמה הוא [המזהה היחודי|CWebModule::id] של המודול. המבנה של התיקיות בתוך מודול הוא בדומה למבנה של [התיקיות באפליקציה](/doc/guide/basics.application#application-base-directory). הדוגמא הבאה מציגה מבנה של תיקיות פשוט של מודול בשם `forum`:
+
+~~~
+forum/
+ ForumModule.php קובץ המחלקה של המודול
+ components/ מכיל רכיבים אשר ניתן להשתמש בכל מקום במודול
+ views/ מכיל קבצי וידג'טים
+ controllers/ מכיל קבצי מחלקות הקונטרולרים
+ DefaultController.php קונטרולר ברירת המחדל
+ extensions/ מכיל תוספות צד שלישי
+ models/ מכיל את קבצי המודלים
+ views/ מכיל את קבצי התצוגה
+ layouts/ מכיל את תבניות התצוגה
+ default/ DefaultController מכיל קבצי תצוגה השייכים ל
+ index.php קובץ תצוגה
+~~~
+
+מודול חייב להכיל מחלקה אשר יורשת מהמחלקה [CWebModule]. שם המחלקה נקבע על פי הביטוי `ucfirst($id).'Module'`, איפה ש `id$` מתייחס למזהה היחודי של המודול (או שמה של התיקיה של המודול). מחלקת המודול משרתת כמקום מרכזי לאחסון ושיתוף המידע לאורך כל קוד המודול. לדוגמא, ניתן להשתמש ב [CWebModule::params] כדי לשמור פרמטרים של המודול, ולהשתמש ב [CWebModule::components] כדי לשתף [רכיבי אפליקציה](/doc/guide/basics.application#application-component) ברמת המודול.
+
+» Tip|טיפ: אנו יכולים להשתמש בכלי בשם Gii כדי ליצור מודול עם המבנה הבסיסי של מודול חדש.
+
+שימוש במודול
+------------
+
+כדי להשתמש במודול, ראשית יש ליצור תיקיה בשם `modules` תחת [התיקיה הראשית](/doc/guide/basics.application#application-base-directory) של האפליקציה. לאחר מכן יש להגדיר את המזהה היחודי של המודול במאפיין [modules|CWebApplication::modules] של האפליקציה. לדוגמא, כדי להשתמש במודול המוצג למעלה `forum`, ניתן להשתמש [הגדרות אפליקציה](/doc/guide/basics.application#application-configuration) הבאות:
+
+~~~
+[php]
+return array(
+ ......
+ 'modules'=»array('forum',...),
+ ......
+);
+~~~
+
+ניתן להגדיר מודול עם המאפיינים הראשוניים שלו מוגדרים בצורה שונה. השימוש הוא דומה מאוד [להגדרות רכיב](/doc/guide/basics.application#application-component). לדוגמא, מודול ה `forum` יכול להכיל מאפיין בשם `postPerPage` בתוך מחלקת המודול שלו שניתן להגדירו [בהגדרות האפליקציה](/doc/guide/basics.application#application-configuration) בצורה הבאה:
+
+~~~
+[php]
+return array(
+ ......
+ 'modules'=»array(
+ 'forum'=»array(
+ 'postPerPage'=»20,
+ ),
+ ),
+ ......
+);
+~~~
+
+ניתן לגשת לאובייקט המודול בעזרת המאפיין [module|CController::module] של הקונטרולר הפעיל כרגע. דרך האובייקט של המודול, ניתן לגשת למידע אשר משותף ברמת המודול. לדוגמא, בכדי לגשת למידע של `postPerPage`, ניתן להשתמש בביטוי:
+
+~~~
+[php]
+$postPerPage=Yii::app()-»controller-»module-»postPerPage;
+// or the following if $this refers to the controller instance
+// $postPerPage=$this-»module-»postPerPage;
+~~~
+
+ניתן לגשת לפעולה בקונטרולר בתוך מודול על ידי [הניתוב](/doc/guide/basics.controller#route) `moduleID/controllerID/actionID`. לדוגמא, נניח שלמודול `forum` המוצג למעלה ישנו קונטרולר בשם `PostController`, ניתן להשתמש [בניתוב](/doc/guide/basics.controller#route) `forum/post/create` כדי לנתב את הבקשה אל הפעולה `create` אשר נמצאת בקונטרולר. הקישור המתאים לניתוב זה יהיה `http://www.example.com/index.php?r=forum/post/create`.
+
+» Tip|טיפ: במידה והקונטרולר הוא בתת תיקיה תחת `controllers`, אנו עדיין יכולים להשתמש בפורמט של [הניתוב](/doc/guide/basics.controller#route) המוצג למעלה. לדוגמא, נניח ש `PostController` נמצא תחת `forum/controllers/admin`, ניתן לגשת לפעולה `create` על ידי שימוש ב `forum/admin/post/create`.
+
+שרשור מודולים
+-------------
+
+ניתן לשרשר מודולים. זאת אומרת, שמודול יכול להכיל מודול נוסף. אנו קוראים לקודם *מודל אב* (*parent module*) ואת המודול תחתיו *תת מודול* (*child module*). תתי מודולים צריכים להיות ממוקמים בתוך תיקית `modules` של מודול האב. כדי לגשת לפעולה של קונטרולר בתת מודול, יש צורך להשתמש בניתוב `parentModuleID/childModuleID/controllerID/actionID`.
+
+
+«div class="revision"»$Id: basics.module.txt 2042 2009-02-25 21:45:42Z qiang.xue $«/div»
View
33 docs/guide/he/basics.mvc.txt
@@ -0,0 +1,33 @@
+מודל-תצוגה-קונטרולר (MVC)
+===========================
+
+Yii מאמצת את השימוש בדפוס של מודל-תצוגה-קונטרולר (MVC) אשר משתמשים בה לרוב בשפות פיתוח. MVC נועד להפרדת הקוד מהעיצוב כדי שלמפתחים יהיה יותר קל לשנות חלק מסויים בקוד מבלי להשפיע על חלק אחר.
+ב MVC, המודל מייצג את המידע (התוכן) והלוגיקה; התצוגה מכיל אלמנטים של ממשקי המשתמש כמו טקסט, טפסים; והקונטרולר מנהל את התקשורת בין המודל לתצוגה.
+
+בנוסף ל MVC, Yii מציגה קונטרולר-ראשי, הנקרא אפליקציה, המייצג את הנתונים בהקשר של עיבוד בקשת המשתמש. אפליקציה מעבדת את בקשת המשתמש ומנתבת אותה לקונטרולר המתאים להמשך הניהול והעיבוד.
+
+הדיאגרמה הבאה מציגה את המבנה הסטטי של אפליקציה ב Yii:
+
+![מבנה סטטי של אפליקציה ב Yii](structure.png)
+
+
+רצף עבודה אופייני
+------------------
+
+הדיאגרמה הבאה מציגה את רצף העבודה האופייני של אפליקצית Yii כשהיא מנהלת בקשת משתמש:
+
+![רצף עבודה אופייני לאפליקציה ב Yii](flow.png)
+
+1. משתמש מבצע בקשה לקישור `http://www.example.com/index.php?r=post/show&id=1` ושרת הווב מטפל בבקשה ומריץ את קובץ הכניסה הראשי `index.php`.
+2. קובץ הכניסה הראשי יוצר אובייקט של [האפליקציה](/doc/guide/basics.application) ומריץ אותו.
+3. האפליקציה מקבלת את המידע המפורט אודות בקשת המשתמש [מרכיב האפליקציה](/doc/guide/basics.application#application-component) בשם `request`.
+4. האפליקציה מחליטה את [הקונטרולר](/doc/guide/basics.controller) [והפעולה](/doc/guide/basics.controller#action) שצריך להריץ בעזרת רכיב אפליקציה בשם `urlManager`. בדוגמא זו, הקונטרולר הוא `post` אשר מנותב אל המחלקה `PostController`; והפעולה היא `show` אשר פעולתה מוגדרת בקונטרולר.
+5. האפליקציה יוצרת אובייקט של אותו קונטרולר להמשך הטיפול בבקשת המשתמש. הקונטרולר מחליט שהפעולה `show` מנותבת למתודה במחלקה בשם `actionShow`. לאחר מכן היא יוצרת ומריצה פילטרים (לדוגמא הרשאות גישה, בדיקות) המצורפים לפעולה זו. הפעולה רצה אם היא עוברת את תהליך הפילטרים.
+6. הפעולה קוראת [מודל](/doc/guide/basics.model) של `Post` אשר מספר המזהה היחודי שלו הוא `1` מתוך מסד הנתונים.
+7. הפעולה מגישה קובץ [תצוגה](/doc/guide/basics.view) בשם `show` עם המודל `Post`.
+8. קובץ התצוגה קורא ומציג את המאפיינים של מודל ה `Post`.
+9. קובץ התצוגה מריץ כמה [וידג'טים](/doc/guide/basics.view#widget).
+10. התוכן הסופי של קבצי התצוגה נכנס אל תוך [תבנית](/doc/guide/basics.view#layout).
+11. הפעולה מסיימת את הגשת קבצי התצוגה ומציגה את התוכן למשתמש.
+
+«div class="revision"»$Id: basics.mvc.txt 1622 2009-12-26 20:56:05Z qiang.xue $«/div»
View
46 docs/guide/he/basics.namespace.txt
@@ -0,0 +1,46 @@
+מרחבי שמות וקיצורי שמות לנתיבים
+========================
+
+Yii משתמשת בשמות מקוצרים לנתיבים באופן נרחב. שם מקוצר משוייך לנתיב מלא לתיקיה או קובץ כלשהו בשרת. השמות המקוצרים כתובים בפורמט של נקודות ( Dot Syntax . ), בדומה לפורמט בו משתמשים למרחבי שמות:
+
+~~~
+RootAlias.path.to.target
+~~~
+
+איפה ש `RootAlias` הוא שם מקוצר לנתיב קיים כלשהו. על ידי קריאה ל [YiiBase::setPathOfAlias], ניתן להגדיר שמות מקוצרים לנתיבים. לנוחות השימוש, Yii מגדירה מראש את השמות המקוצרים הבאים כברירת מחדל:
+
+- `system`: מתייחס לתיקיה הראשית של הפריימוורק (היכן ש Yii נמצא) .
+- `zii`: מתייחס לתיקיה של [ספריית Zii](/doc/guide/extension.use#zii-extensions)
+- `application`: מתייחס לתיקיה [הראשית](/doc/guide/basics.application#application-base-directory) של האפליקציה.
+- `webroot`: מתייחס לתיקיה בו נמצא [קובץ הגישה](/doc/guide/basics.entry) הראשי. שם מקוצר זה קיים מגרסא 1.0.3 ומעלה.
+- `ext`: מתייחס לתיקיה בה נמצאים כל [התוספים](/doc/guide/extension.overview). שם מקוצר זה קיים מגרסא 1.0.8 ומעלה.
+
+בנוסף, במידה והאפליקציה משתמשת [מודלים](/doc/guide/basics.module), נוצר שם מקוצר לכל מודול על פי שמו היחודי אשר מכוון לתיקיה הראשית של אותו מודול. אפשרות זאת קיימת מגרסא 1.0.3 ומעלה.
+
+על ידי שימוש ב [YiiBase::getPathOfAlias], ניתן להמיר שם מקוצר לנתיב המדוייק אליו הוא מכוון. לדוגמא, `system.web.CController` יתורגם לנתיב `yii/framework/web/CController` לאחר הקריאה.
+
+באמצעות שימוש בשמות מקוצרים, יבוא מחלקות ניתן לעשות בצורה קלה יחסית. לדוגמא, אם ברצוננו לייבא את המחלקה [CController], ניתן לקרוא לפקודה הבאה:
+
+~~~
+[php]
+Yii::import('system.web.CController');
+~~~
+
+שימוש בפונקצית ה [import|YiiBase::import] שונה משימוש ב `include` ו `require` מאחר והיא יותר יעילה. מכיוון שאת המחלקה אותה מייבאים לא מוסיפים מייד אלה בפעם הראשונה בה קוראים למחלקה. ייבוא של אותו מרחב שם כמה פעמים הרבה יותר מהיר משימוש ב `include_once` ו `require_once`.
+
+» Tip|טיפ: כשמתייחסים למחלקה אשר נמצאת תחת הפריימוורק של Yii, אין צורך בלייבא את אותה מחלקה. כל מחלקות הבסיס של Yii כבר מיובאות.
+
+ניתן גם להשתמש בתחביר הבא כדי לייבא תיקיה שלמה עם כל המחלקות והקבצים שנמצאים בתוכה כדי שנוכל להשתמש בהם בעת הצורך ללא כל צורך בטעינה של כל אחד מהם בנפרד.
+
+~~~
+[php]
+Yii::import('system.web.*');
+~~~
+
+מלבד [import|YiiBase::import], ניתן להשתמש בשמות מקוצרים במקומות אחרים כדי להתייחס למחלקות. לדוגמא, ניתן להשתמש בשם מקוצר כדי ליצור אובייקט של מחלקה בעזרת [Yii::createComponent], גם אם המחלקה לא נוספה בעבר.
+
+יש לזכור לא להתבלבל בין שמות מקוצרים למרחבי שמות. מרחב שם מתייחס לקיבוץ לוגי של שמות מחלקה כדי שניתן יהיה להבדיל ביניהם לבין מחלקות נוספות בעלות אותו השם, בעוד שקיצור שם נועד להתייחסות לקובץ או תיקיה. שמות מקוצרים לא סותרים את מרחבי השמות.
+
+» Tip|טיפ: מאחר ומרחבי שמות לא נתמכים בגרסאות מתחת ל 5.3.0 ב PHP, לא ניתן ליצור אובייקט של שני מחלקות שונות בעלות אותו השם. מסיבה זו, כל שמותיהם של המחלקות הבסיסיות של Yii מתחילות באות 'C' (אשר מייצג 'class' מחלקה) כדי שיהיה ניתן להבדיל בניהם לבין המחלקות שנוצרות על ידי המשתמש וכדי למנוע סתירה בין שמות המחלקות. רצוי ששמות המחלקה הנוצרים על ידי המשתמשים לא יתחילו באות 'C' מאחר וזה שמור למחלקות הבסיסיות של Yii. ושמות מחלקות שנוצרות על ידי המשתמש יתחילו באות אחרת.
+
+«div class="revision"»$Id: basics.namespace.txt 1602 2009-12-18 19:33:34Z qiang.xue $«/div»
View
105 docs/guide/he/basics.view.txt
@@ -0,0 +1,105 @@
+תצוגה
+====
+
+קובץ תצוגה הוא קובץ PHP המכיל בעיקר אלמנטים הקשורים לממשק המשתמש. קובץ זה יכול להכיל פקודות PHP, אבל רצוי שפקודות אלו לא ישנו מידע לגבי המודלים וישארו פשוטות יחסית. למען הלוגיקה של הפרדת הקוד מהעיצוב, חלקים גדולים של פקודות PHP צריכות להיות ממוקמות בקבצי הקונטרולר והמודלים ולא בקבצי התצוגה.
+
+לקובץ תצוגה יש שם אשר נועד למטרת זיהוי בעת הקריאה לאותו הקובץ. שמו של קובץ התצוגה זהה לשם הקובץ הפיזי בו הוא נשמר. לדוגמא, קובץ תצוגה בשם `edit` מתייחס לקובץ סקריפט PHP בשם `edit.php`. כדי לטעון קובץ תצוגה יש לקרוא לפונקציה [CController::render] כשהפרמטר הראשון בפונקציה הוא שמו של קובץ התצוגה אותו רוצים להציג. הפונקציה תחפש אחר קובץ התצוגה המתאים תחת הנתיב `protected/views/ControllerID`.
+
+בתוך קובץ התצוגה, ניתן לגשת לאובייקט הקונטרולר בעזרת האובייקט `this$`. לכן ניתן לגשת לכל מאפיין/משתנה של המחלקה בעזרת קריאה ל `this-»propertyName$` בתוך קובץ התצוגה.
+
+כמו כן ניתן להשתמש בשיטה הבאה כדי `לדחוף` נתונים אל קובץ התצוגה:
+
+~~~
+[php]
+$this-»render('edit', array(
+ 'varone'=»$value1,
+ 'vartwo'=»$value2,
+));
+~~~
+
+
+בקוד המוצג למעלה, הפונקציה [render|CController::render] תחלץ את המערך המוגדר בפרמטר השני כערכים. כתוצאה, בתוך קובץ התצוגה ניתן יהיה לגשת למשתנים `varone$` ו `vartwo$`.
+
+
+
+תבנית
+------
+
+תבנית מהווה כקובץ תצוגה מיוחד הנועד לעטר את קבצי התצוגה הרגילים (המוצגים למעלה). בדרך כלל הוא מכיל חלקים של ממשקי משתמש אשר מוצגים בכל מקום. לדוגמא, קובץ תבנית יכול להכיל את ראש הדף ואת תחתית הדף ולהציג את התוכן באמצע.
+
+~~~
+[php]
+......header here......
+«?php echo $content; ?»
+......footer here......
+~~~
+
+כשהערך `content$` מכיל את התוצאה של אותם קבצי תצוגה שקראנו להם קודם לכן בעזרת [render|CController::render].
+
+תבנית מיושמת ברגע שיש קריאה ל [render|CController::render]. כברירת מחדל, קובץ התצוגה `protected/views/layouts/main.php` מוגדר כקובץ התבנית. ניתן לשנות זאת על ידי שינוי הערך של [CWebApplication::layout] או [CController::layout]. כדי לקרוא לקובץ תצוגה ולהציג אותו ללא קובץ תבנית, יש לקרוא לפונקציה [renderPartial|CController::renderPartial] במקום [render|CController::render].
+
+וידג'ט
+------
+
+וידג'ט הוא אובייקט של [CWidget] או במחלקות הנמצאות תחתיו. זהו רכיב המיועד בעיקר למטרות תצוגה. וידג'טים בדרך כלל מוטמעים בקבצי תצוגה כדי ליצור ממשקים מורכבים אך כלליים. לדוגמא, וידג'ט לוח-שנה יכול לשמש כדי להציג לוח-שנה מורכב בממשק המשתמש. וידג'טים מאפשרים שימוש חוזר טוב יותר לצרכי תצוגה.
+
+כדי להשתמש ב וידג'ט השתמש בצורה הבאה בקובץ תצוגה:
+
+~~~
+[php]
+«?php $this-»beginWidget('path.to.WidgetClass'); ?»
+...תוכן כלשהו שניתן לתפוס בעזרת ה וידג'ט...
+«?php $this-»endWidget(); ?»
+~~~
+
+או
+
+~~~
+[php]
+«?php $this-»widget('path.to.WidgetClass'); ?»
+~~~
+
+הדוגמא השנייה משמשת כשהוידג'ט לא צריך לתפוס שום תוכן.
+
+ניתן לשנות את אופן ההתנהלות של הוידג'טים בעת קריאתם. בכדי לעשות זאת יש להגדיר את הערכים הראשוניים של הוידג'ט בזמן הקריאה הראשונה שלהם על ידי [CBaseController::beginWidget] או [CBaseController::widget]. לדוגמא, כשמשתמשים בוידג'ט [CMaskedTextField], אנחנו נרצה להגדיר את המסכה לשימוש. אנחנו מבצעים זאת על ידי העברת מערך כמפרמטר שני להגדרת הערכים הראשוניים כדלקמן, כשמפתחות המערך הם שמות המאפיינים של הוידג'ט והערכים של המערך הם הערכים הראשוניים של הוידג'ט:
+
+~~~
+[php]
+«?php
+$this-»widget('CMaskedTextField',array(
+ 'mask'=»'99/99/9999'
+));
+?»
+~~~
+
+כדי להגדיר וידג'ט חדש, יש ליצור מחלקה אשר יורשת מ [CWidget], וליישם את המתודות [init|CWidget::init] ו [run|CWidget::run] במחלקה:
+
+~~~
+[php]
+class MyWidget extends CWidget
+{
+ public function init()
+ {
+ // this method is called by CController::beginWidget()
+ }
+
+ public function run()
+ {
+ // this method is called by CController::endWidget()
+ }
+}
+~~~
+
+כמו בקונטרולר, וידג'ט יכול להכיל קובץ תצוגה משלו. כברירת מחדל, קבצי התצוגה של הוידג'ט נמצאים תחת התיקיה `views` בתיקיה הראשית בה המחלקה של הוידג'ט נמצא. ניתן להציג את קבצי התצוגה הללו בעזרת [CWidget::render], בדומה לפעולה הנעשית בקונטרולר. ההבדל היחיד הוא שלא ניתן להגדיר תבנית לתצוגה של הוידג'ט. בנוסף, `this$` בתוך קובץ תצוגה של וידג'ט מכוון אל האובייקט של הוידג'ט במקום האובייקט של הקונטרולר.
+
+תצוגת מערכת
+-----------
+
+תצוגת מערכת הם קבצי תצוגה אשר Yii משתמשת בהם לצרכי תצוגה של מידע אודות שגיאות ולוגים. לדוגמא, כשמשתמש מבקש קונטרולר לא קיים או פעולה שלא קיימת, Yii יזרוק שגיאה שמסבירה אודות השגיאה שהתרחשה. Yii מציג את השגיאה בתוך קובץ תצוגה מערכתי ספציפי.
+
+שמות התצוגה של קבצי תצוגת המערכת עוקבים אחר אותם חוקים. שמות כמו `errorXXX` משמשים לתצוגה של שגיאות אשר נזרקות על ידי [CHttpException] כשקוד השגיאה הוא `XXX`. לדוגמא, אם התרחשה שגיאה של [CHttpException] עם קוד שגיאה 404, קובץ התצוגה המערכתי שיוצג יהיה `error404`.
+
+Yii מספקת קבצי תצוגה מערכתיים כברירת מחדל אשר נמצאים תחת `framework/views`. ניתן להגדיר את קבצי התצוגה באופן עצמאי על ידי יצירת אותם קבצי תצוגה עם אותם השמות תחת התיקיה `protected/views/system`.
+
+
+«div class="revision"»$Id: basics.view.txt 1809 2010-02-17 22:08:34Z qiang.xue $«/div»
View
28 docs/guide/he/basics.workflow.txt
@@ -0,0 +1,28 @@
+רצף עבודת הפיתוח
+====================
+
+לאחר הסבר על יסודות Yii, אנחנו מציגים את רצף העבודה הפשוט ביותר לפיתוח אפליקצית ווב בעזרת Yii. הרצף מניח שכבר בצענו את ניתוח הדרישות בנוסף לעיצוב הדרוש לאפליקציה.
+
+1. יצירת מבנה התיקיות. כלי ה `yiic` אשר מתואר ב [יצירת אפליקצית Yii ראשונה](/doc/guide/quickstart.first-app) יכול לעזור כדי להאיץ את שלב זה.
+
+2. הגדרת [האפליקציה](/doc/guide/basics.application). שלב זה נעשה על ידי עריכת קובץ ההגדרות של האפליקציה. שלב זה יכול לדרוש גם הוספה של כמה רכיבי אפליקציה (לדוגמא רכיב המשתמשים).
+
+3. יצירת מחלקה [למודל](/doc/guide/basics.model) לכל סוג של מידע לניהול. שוב, ניתן להשתמש בכלי `yiic` כדי ליצור אוטומטית את מחלקות ה [AR](/doc/guide/database.ar) לכל טבלה שצריך במסד הנתונים.
+
+4. יצירת [קונטרולר](/doc/guide/basics.controller) לכל סוג של בקשת משתמש. מיון בקשות המשתמש תלויות בדרישות מסויימות. באופן כללי, במידה ומחלקה למודל צריכה להיות נגישה למשתמשים, יש צורך ביצירה של קונטרולר תואם למחלקה. כלי ה `yiic` יכול לבצע אוטומטית פעולה זו גם כן.
+
+5. יישום [פעולות](/doc/guide/basics.controller#action) וקבצי [התצוגה](/doc/guide/basics.view) התואמים שלהם. בשלב זה העבודה האמיתית מתבצעת.
+
+6. הגדרת [פילטרים](/doc/guide/basics.controller#filter) נחוצים לפעולות בקונטרולר.
+
+7. יצירת [תבניות](/doc/guide/topics.theming) במידה ואפשרות התבניות היא הכרחית.
+
+8. יצירת הודעות מתורגמות במידה ויש צורך [בתמיכה בכמה שפות](/doc/guide/topics.i18n).
+
+9. איתור מידע וקבצי תצוגה שניתן לשמור אותם במטמון ויישם טכניקות [מטמון](/doc/guide/caching.overview) מתאימות.
+
+10. [כיוונים אחרונים](/doc/guide/topics.performance) ופריסה.
+
+לכל אחד מהשלבים למעלה, יש צורך ביצירת בדיקות והרצתם.
+
+«div class="revision"»$Id: basics.workflow.txt 1034 2009-05-19 21:33:55Z qiang.xue $«/div»
View
78 docs/guide/he/caching.data.txt
@@ -0,0 +1,78 @@
+שמירת נתונים
+============
+
+שמירת נתונים במטמון היא דרך לשמירת משתנה PHP במטמון וקבלתו בזמן מאוחר יותר. למטרה זו, המחלקה הבסיסית של המטמון [CCache] מספקת שני מתודות עם השימוש הנפוץ ביותר: [set|CCache::set] ו [get|CCache::get].
+
+כדי לשמור את המשתנה `value$` במטמון, אנו בוחרים מזהה יחודי כלשהו וקוראים למתודה [set|CCache::set] כדי לשמור אותה:
+
+~~~
+[php]
+Yii::app()-»cache-»set($id, $value);
+~~~
+
+התוכן הנשמר יאוחסן במטמון לעד אלה אם כן הוא ימחק מסיבות שאינן תלויות באפליקציה (לדוגמא, מקום האחסון של המטמון מלא והפריטים הישנים ביותר שנשמרו ימחקו). כדי לשנות התנהגות זו, אנו יכולים להוסיף פרמטר שלישי אשר יגדיר את תפוקת הנתונים אותם אנו שומרים בזמן קריאה ל [set|CCache::set] כדי שהתוכן שנשמר במטמון ימחק אחרי פרק זמן מסויים:
+
+~~~
+[php]
+// keep the value in cache for at most 30 seconds
+Yii::app()-»cache-»set($id, $value, 30);
+~~~
+
+בזמן מאוחר יותר כשאנו צריכים לגשת למשתנה זה (בבקשה הנוכחית או אחרת), אנו קוראים למתודה א עם אותו מזהה יחודי בו שמרנו את הנתונים כדי לקבל אותם מהמטמון. אם הערך שהתקבל מהקריאה שווה ל `false`, זה אומר שהנתון לא נמצא במטמון ועלינו ליצור אותו שוב פעם.
+
+~~~
+[php]
+$value=Yii::app()-»cache-»get($id);
+if($value===false)
+{
+ // regenerate $value because it is not found in cache
+ // and save it in cache for later use:
+ // Yii::app()-»cache-»set($id,$value);
+}
+~~~
+
+‎כשבוחרים מזהה יחודי בתור השם של המטמון אותו שומרים, וודא שאותו שם הוא יחודי בקרב כל שאר המשתנים הניתנים לשמירה במטמון באפליקציה. אין צורך שהשם יהיה יחודי בין אפליקציות שונות מאחר ורכיב זה מספיק חכם כדי להבדיל בין האפליקציות בהם הוא רץ.
+
+חלק מאפשרויות האחסון, כמו MemCache, APC, תומכים באפשרות של קבלת כמה נתונים מהמטמון בקריאה אחת כקבוצה, פעולה זו חוסכת בזמן הלקוח לקבלת נתון מהמטמון. מגרסא 1.0.8, ישנה מתודה חדשה בשם [mget|CCache::mget] כדי ליישם אפשרות זו. במידה ורכיב האחסון בו משתמשים לא תומך באפשרות זו כברירת מחדל, האפליקציה תחקה את הפעולה שהמתודה [mget|CCache::mget] מבצעת.
+
+כדי למחוק נתון מהמטמון, יש לקרוא למתודה [delete|CCache::delete]; ובכדי להוריד את כל הנתונים מהמטמון יש לקרוא למתודה [flush|CCache::flush]. יש להזהר בעת השימוש במתודה [flush|CCache::flush] מאחר והיא מוחקת נתונים במטמון מאפליקציות אחרות.
+
+» Tip|טיפ: מאחר והמחלקה [CCache] מיישמת את הממשק `ArrayAccess`, ניתן להשתמש במטמון בתור מערך. להלן כמה דוגמאות:
+» ~~~
+» [php]
+» $cache=Yii::app()-»cache;
+» $cache['var1']=$value1; // equivalent to: $cache-»set('var1',$value1);
+» $value2=$cache['var2']; // equivalent to: $value2=$cache-»get('var2');
+» ~~~
+
+הגדרת תלות למטמון
+----------------
+
+מלבד הגדרת זמן קיום המטמון, ניתן להגדיר תלות מסויימת לנתונים הנשמרים במטמון כדי `לבטל` את אותם נתונים שנשמרו. לדוגמא, אם אנו שומרים תוכן של קובץ מסויים במטמון והקובץ ההוא השתנה, אנו צריכים לבטל את הנתון השמור במטמון ולשמור את תוכן הקובץ במטמון שוב פעם.
+
+אנו מייצגים תלות באובייקט של [CCacheDependency] או מחלקות היורשות ממנו. אנו קוראים לתלות מסויימת בזמן קריאה למתודה [set|CCache::set] והגדרתו כפרמטר רבעי.
+
+~~~
+[php]
+// the value will expire in 30 seconds
+// it may also be invalidated earlier if the dependent file is changed
+Yii::app()-»cache-»set($id, $value, 30, new CFileCacheDependency('FileName'));
+~~~
+
+כעת, אם נשלוף את המשתנה `value$` מתוך המטמון על ידי קריאה למתודה [get|CCache::get], התלות תכנס לפעולה ובמידה והקובץ השתנה, אנו נקבל ערך השווה ל `false`, האומר שצריך ליצור מחדש את התוכן השמור במטמון.
+
+למטה רשומים בקצרה התלויות הקיימות למטמון:
+
+- [CFileCacheDependency]: התלות משתנה אם הזמן האחרון בו הקובץ נערך השתנה.
+
+- [CDirectoryCacheDependency]: התלות משתנה אם ישנו שינוי בכל אחד מהקבצים הנמצאים בתיקיה ותתי-תיקיות.
+
+- [CDbCacheDependency]: התלות משתנה במידה והתוצאה של השאילתה השתנתה.
+
+- [CGlobalStateCacheDependency]: התלות משתנה במידה והערך הגלובלי שהוזן השתנה. משתנה גלובלי באפליקציה הינו משתנה אשר קיים לאורך כל האפליקציה. הוא מוגדר על ידי [CApplication::setGlobalState].
+
+- [CChainedCacheDependency]: התלות משתנה במידה וכל אחד מהתלויות המשורשרות משתנה.
+
+- [CExpressionDependency]: התלות משתנה במידה והתוצאה של ביטוי ה PHP היא שונה. מחלקה זו קיימת מגרסאות 1.0.4 ומעלה.
+
+«div class="revision"»$Id: caching.data.txt 1855 2010-03-04 22:42:32Z qiang.xue $«/div»
View
25 docs/guide/he/caching.dynamic.txt
@@ -0,0 +1,25 @@
+תוכן דינאמי
+===============
+
+כשמשתמשים [שמירת חלקים](/doc/guide/caching.fragment) או [שמירת עמוד שלם](/doc/guide/caching.page), אנו בדרך כלל נתקלים במצבים איפה שכל העמוד הוא יחסית תוכן סטטי מלבד חלק אחד או יותר. לדוגמא, עמוד עזרה מציג מידע סטטי אודות עזרה באתר אבל עם שמו של המשתמש שגרגע מחובר לאתר מוצג בראש העמוד.
+
+כדי לפתור בעיה זו, ניתן לשמור את התוכן במטמון על פי שם המשתמש, אך זה יהיה בזבוז מקום האחסון היקר של המטמון בו אנו משתמשים מאחר והתוכן הוא זהה בכל צורה מלבד שם המשתמש. ניתן גם לחלק את העמוד לחתיכות ולשמור אותם בנפרד, אך זה מסבך את קובץ התצוגה שלנו והקוד שלנו נראה מאוד מורכב. שיטה טובה יותר היא להשתמש באפשרות השמירה של *התוכן הדינאמי* הקיים ב [CController].
+
+תוכן דינאמי הוא חתיכת תוכן שלא צריך להשמר במטמון גם אם הוא מוקף בקוד השומר חתיכת תוכן במטמון. כדי שהתוכן יהיה תמיד דינאמי, הוא צריך להווצר כל הזמן גם אם התוכן בו הוא נמצא נשלף מתוך המטמון. מסיבה זו, אנו דורשים שתוכן דינאמי יווצר על ידי מתודה או פונקציה כלשהי.
+
+אנו קוראים ל [CController::renderDynamic] כדי להכניס תוכן דינאמי במקום הרצוי.
+
+~~~
+[php]
+...other HTML content...
+«?php if($this-»beginCache($id)) { ?»
+...fragment content to be cached...
+ «?php $this-»renderDynamic($callback); ?»
+...fragment content to be cached...
+«?php $this-»endCache(); } ?»
+...other HTML content...
+~~~
+
+בדוגמא למעלה, `callback$` מתייחס לפונקציה או מתודה תקנית של PHP. ההגדרה צריכה להיות סטרינג המתייחס למתודה במחלקה הנוכחית או פונקציה גלובלית. כמו כן היא יכולה להיות מערך אשר מתייחס למתודה במחלקה. כל הפרמטרים הנוספים שיוגדרו [renderDynamic|CController::renderDynamic] יועברו לפונקציה/מתודה אשר הוגדרה. הפונקציה/מתודה שהוגדרה צריכה להחזיר את התוכן ולא להציג אותו.
+
+«div class="revision"»$Id: caching.dynamic.txt 163 2008-11-05 12:51:48Z weizhuo $«/div»
View
103 docs/guide/he/caching.fragment.txt
@@ -0,0 +1,103 @@
+שמירת חתיכות במטמון
+================
+
+שמירת חתיכות במטמון מתייחסת לשמירה של חתיכות תוכן בעמוד. לדוגמא, אם העמוד מציג טבלה של סך הכל מכירות לשנה הזו, אנו יכולים לשמור את הטבלה במטמון כדי לחסוך את הזמן שדרוש כדי ליצור אותה בכל בקשה.
+
+כדי לשמור חתיכה במטמון, אנו קוראים ל [CController::beginCache|CBaseController::beginCache] ו [CController::endCache|CBaseController::endCache] בתוך קובץ תצוגה של קונטרולר. שני המתודות מסמנות את תחילתו וסופו של אותה חתיכה שצריכה להשמר במטמון. בדומה ל [שמירת נתונים](/doc/guide/caching.data), יש צורך בשם כמזהה יחודי של ערך מטמון זה לצורך זיהוי המטמון.
+
+~~~
+[php]
+...other HTML content...
+«?php if($this-»beginCache($id)) { ?»
+...content to be cached...
+«?php $this-»endCache(); } ?»
+...other HTML content...
+~~~
+
+בדוגמא למעלה, אם [beginCache|CBaseController::beginCache] מחזיר ערך השווה ל `false`, התוכן השמור במטמון יוכנס במקום בצורה אוטומטית; אחרת, התוכן בתוך פקודת ה `if` יורץ וישמר במטמון בעת הגעת הקוד למתודה [endCache|CBaseController::endCache].
+
+אפשרויות מטמון
+---------------
+
+בעת הקריאה ל [beginCache|CBaseController::beginCache], אנו יכולים להעביר מערך כפרמטר שני למתודה המכיל אפשרויות לאופן השמירה של החתיכה במטמון. למעשה, המתודות [beginCache|CBaseController::beginCache] ו [endCache|CBaseController::endCache] הם מעטפת נוחה של הוידג'ט [COutputCache]. לכן, אפשרויות המטמון יכולות להיות ערכים המגדירים את כל המאפיינים הקיימים ב [COutputCache].
+
+### תקופת קיום
+
+אולי האפשרות הנפוצה ביותר הינה [תקופת הזמן|COutputCache::duration] המגדירה את משך הזמן בו התוכן הנשמר במטמון תקף. הוא דומה לפרמטר התפוגה של המתודה [CCache::set]. הקוד הבא שומר את תוכן החתיכה במטמון לפרק זמן של עד שעה:
+
+~~~
+[php]
+...other HTML content...
+«?php if($this-»beginCache($id, array('duration'=»3600))) { ?»
+...content to be cached...
+«?php $this-»endCache(); } ?»
+...other HTML content...
+~~~
+
+אם אנו לא מגדירים תקופת קיום, היא תוגדר לברירת מחדל של 60, האומר שהתוכן הנשמר במטמון ימחק לאחר 60 שניות.
+
+### תלות
+
+בדומה [מטמון נתונים](/doc/guide/caching.data), ניתן להגדיר לחתיכות הנשמרות במטמון תלות כלשהי. לדוגמא, התוכן של ההודעה המוצגת תלוי במידה וההודעה השתנתה.
+
+כדי להגדיר תלות, אנו מגדירים את המאפיין [dependency|COutputCache::dependency], אשר יכול להיות אובייקט של מחלקה המיישמת את [ICacheDependency] או מערך של הגדרות אשר יכול ליצור את אובייקט התלות. הקוד הבא מציין את החתיכה הנשמרת במטמון בהתבסס על השינוי של הערך של המאפיין `lastModified`:
+
+~~~
+[php]
+...other HTML content...
+«?php if($this-»beginCache($id, array('dependency'=»array(
+ 'class'=»'system.caching.dependencies.CDbCacheDependency',
+ 'sql'=»'SELECT MAX(lastModified) FROM Post')))) { ?»
+...content to be cached...
+«?php $this-»endCache(); } ?»
+...other HTML content...
+~~~
+
+### גיוון (וריאציה)
+
+ניתן לשמור את התוכן בהתבסס על פרמטרים מסויים כדי לגוון זאת. לדוגמא, הפרופיל האישי יכול להראות שונה למשתמשים שונים. כדי לשמור את הפרופיל האישי במטמון, אנו נרצה שהתוכן הנשמר במטמון ישמר בהתבסס על מספר המשתמש הצופה בו כרגע. זה אומר שאנו צריכים להשתמש בשמות שונים בעת קראיה ל [beginCache()|CBaseController::beginCache()].
+
+במקום לבקש מהמתכנתים לגוון במזהים היחודיים בהתבסס על תבנית מסויימת, [COutputCache] כבר מכילה אפשרות כזו מובנית. למטה תקציר בנוגע לשימוש באפשרות זו.
+
+- [varyByRoute|COutputCache::varyByRoute]: על ידי הגדרת אפשרות זו ל `true`, התוכן הנשמר במטמון יגוון על ידי [הקישור](/doc/guide/basics.controller#route). לכן, כל קומבינציה של פעולה וקונטרולר התוכן שישמר יהיה שונה.
+
+- [varyBySession|COutputCache::varyBySession]: על ידי הגדרת אפשרות זו ל `true`, התוכן הנשמר במטמון יגוון על ידי המזהה היחודי (session) של המשתמש. לכן, כל משתמש יראה תוכן שונה המגיע ישירות מהמטמון.
+
+- [varyByParam|COutputCache::varyByParam]: על ידי הגדרת אפשרות זו למערך של שמות, ניתן לגוון את המטמון שנשמר בהתבסס על הערכים המגיעים מהפרמטרים של GET. לדוגמא, אם עמוד מציג את התוכן של ההודעה על פי מספרה - `id` המגיע מהפרמטר בקישור (GET) , ניתן להגדיר את [varyByParam|COutputCache::varyByParam] בתור `array('id')` כדי שכל הודעה תשמר במטמון. ללא גיוון זה ושמירה על פי הפרמטר, יכולנו לשמור הודעה אחת בלבד במטמון.
+
+- [varyByExpression|COutputCache::varyByExpression]: על ידי הגדרת אפשרות זו לביטוי ב PHP, ניתן לגוון את התוכן הנשמר בהתבסס על התוצאה של הביטוי. אפשרות זו קיימת מגרסאות 1.0.4 ומעלה.
+
+### סוגי בקשות
+
+לפעמים אנו נרצה לשמור חתיכה במטמון רק לסוגי בקשות מסויימות (GET או POST). לדוגמא, עמוד המציג טופס, אנו רוצים לשמור אותו רק כשהוא מבוקש לראשונה (דרך GET). כל שאר הבקשות לאותו הטופס (דרך POST) לא צריכות להשמר במטמון מאחר והם יכולים להכיל מידע שהמשתמש הזין. כדי לבצע זאת, אנו יכולים להגדיר את הפרמטר [requestTypes|COutputCache::requestTypes]:
+
+~~~
+[php]
+...other HTML content...
+«?php if($this-»beginCache($id, array('requestTypes'=»array('GET')))) { ?»
+...content to be cached...
+«?php $this-»endCache(); } ?»
+...other HTML content...
+~~~
+
+קינון נתונים
+--------------
+
+ניתן לקנן בעת השימוש בשמירת נתונים במטמון. זאת אומרת, שחתיכה הנשמרת במטמון עטופה בחתיכה גדולה יותר אשר גם היא נשמרת במטמון. לדוגמא, התגובות של הודעה נשמרות במטמון פנימי, והם נשמרות במטמון ביחד עם התוכן של ההודעה במטמון חיצוני.
+
+~~~
+[php]
+...other HTML content...
+«?php if($this-»beginCache($id1)) { ?»
+...outer content to be cached...
+ «?php if($this-»beginCache($id2)) { ?»
+ ...inner content to be cached...
+ «?php $this-»endCache(); } ?»
+...outer content to be cached...
+«?php $this-»endCache(); } ?»
+...other HTML content...
+~~~
+
+ניתן להגדיר אפשרויות שונות לכל שמירה במטמון במצב של קינון. לדוגמא, בקוד למעלה השמירה של המטמון הפנימית והחיצונית יכולות להיות מוגדרות עם מאפיין תקופת קיום שונות אחד מהשני. כשהתוכן הנשמר במטמון החיצוני ימחק, התוכן הנשמר במטמון הפנימי עדיין יכול לספק תוכן תקני ועדכני של אותה חתיכה שנשמרה במטמון. למרות שזה לא תקף במקרה ההפוך. במידה והשמירה במטמון החיצוני תקפה וקיימת, היא תמיד תוצג, גם אם התוכן במטמון הפנימי שנשמר כבר לא תקף וצריך להחליפו.
+
+«div class="revision"»$Id: caching.fragment.txt 956 2009-04-21 15:16:03Z qiang.xue@gmail.com $«/div»
View
59 docs/guide/he/caching.overview.txt
@@ -0,0 +1,59 @@
+‎מטמון
+=======
+
+‎מטמון הינה דרך קלה ויעילה לשיפור ביצועי אפליקצית ווב‫.‬ על ידי אחסון תוכן סטטי בתוך המטמון וקריאתו בעת הצורך‫,‬ אנו חוסכים את הזמן הדרוש כדי ליצור את אותו תוכן‫.‬
+
+‎שימוש במטמון ב Yii בדרך כלל דורש הגדרת רכיב מטמון וגישה אליו‫.‬ הגדרות האפליקציה הבאות מגדירות רכיב מטמון המשתמש בשיטת מטמון של memcache עם שני שרתים לאחסון התוכן במטמון‫.‬
+
+~~~
+[php]
+array(
+ ......
+ 'components'=»array(
+ ......
+ 'cache'=»array(
+ 'class'=»'system.caching.CMemCache',
+ 'servers'=»array(
+ array('host'=»'server1', 'port'=»11211, 'weight'=»60),
+ array('host'=»'server2', 'port'=»11211, 'weight'=»40),
+ ),
+ ),
+ ),
+);
+~~~
+
+‎בזמן הרצת האפליקציה‫,‬ ניתן לגשת לרכיב המטמון בעזרת `Yii::app()-»cache`‫.‬
+
+Yii מספקת רכיבי מטמון שונים אשר מאפשרים שמירה של תוכן במטמון במדיות שונות‫.‬
+‎לדוגמא‫,‬ רכיב ה [CMemCache] משתמשת בתוסף של PHP בשם memcache כדי להשתמש בזכרון כמדית שמירת המטמון‫; ‬הרכיב [CApcCache] משתמש בתוסף ה PHP בשם APC‫;‬
+‎ורכיב [CDbCache] שומר את המטמון במסד הנתונים‫.‬
+‎להלן סיכום של רכיבי המטמון הניתנים לשימוש ב Yii‫:‬
+
+- [CMemCache] משתמש בתוסף של PHP בשם [memcache](http://www.php.net/manual/en/book.memcache.php).
+
+- [CApcCache] משתמש בתוסף של PHP בשם [APC](http://www.php.net/manual/en/book.apc.php).
+
+- [CXCache] משתמש בתוסף של PHP בשם [XCache](http://xcache.lighttpd.net/). הערה, רכיב זה קיים מגרסאות 1.0.1 ומעלה.
+
+- [CEAcceleratorCache] משתמש בתוסף של PHP בשם [EAccelerator](http://eaccelerator.net/).
+
+- [CDbCache] משתמש בטבלה במסד הנתונים כדי לשמור את התוכן. כברירת מחדל זה יוצר ומשתמש במסד נתונים מסוג SQLite3 תחת תיקית הקבצים הזמניים באפליקציה. תוכל להגדיר את סוג מסד הנתונים לשימוש על ידי הגדרת המאפיין [connectionID|CDbCache::connectionID].
+
+- [CZendDataCache] משתמש ברכיב של PHP בשם Zend Data Cache בתור המדיה לשמירה. הערה, רכיב זה קיים מגרסא 1.0.4 ומעלה.
+
+- [CFileCache] משתמש בקבצים כדי לאחסן את התוכן השמור במטמון. זה מתאים במיוחד כדי לשמור חלקים גדולים של תוכן (כמו לדוגמא עמודים שלמים). הערה, רכיב זה קיים מגרסא 1.0.6 ומעלה.
+
+- [CDummyCache] מייצג רכיב מטמון דמה אשר לא מאחסן ולא שומר כלום במטמון. המטרה של רכיב זה היא לפשט את הקוד שדורש לבדוק אם מטמון מסויים קיים. לדוגמא, במהלך פיתוח או במידה והשרת לא תומך באותו רכיב מטמון שרוצים להשתמש, אנו יכולים להשתמש ברכיב מטמון זה. כשרכיב המטמון יהיה קיים ופעיל, ניתן יהיה להחליף לאותו רכיב מטמון בקלות. בשני המקרים, אנו נשתמש באותו הקוד `Yii::app()-»cache-»get($key)` כדי לנסות ולקבל פיסת מידע מבלי לחשוש במידה ו `Yii::app()-»cache` הוא `null`. רכיב זה קיים מגרסא 1.0.5 ומעלה.
+
+
+» Tip|טיפ: מאחר וכל אותם רכיבי מטמון יורשים מאותה מחלקה בסיסית [CCache] ‫,‬ ניתן להחליף‫ את סוג רכיב המטמון ללא שום שינוי בקוד היוצר וקורא את המטמון.‬
+
+‎ניתן להשתמש במטמון בכמה רמות שונות‫.‬ ברמה הכי נמוכה‫,‬ אנו נעזרים במטמון כדי לאחסן חתיכת מידע אחת‫,‬ כמו משתנה‫,‬ ואנו קוראים לזו ‫*‬אחסון מידע‫*.‬ ברמה הבאה‫,‬ אנו שומרים במטמון חלק מעמוד הנוצר בעזרת קובץ תצוגה‫.‬ וברמה הגבוה ביותר‫,‬ אנו שומרים עמוד שלם במטמון וטוענים את אותו עמוד מהמטמון בעת הצורך‫.‬
+
+‎בתתי נושאים הבאים‫,‬ אנו נרחיב על אופן השימוש ברכיבי המטמון השונים‫.‬
+
+» Note|הערה: כברירת מחדל‫,‬ מטמון הוא מדיום שמירה לא אמין‫.‬ הוא לא מוודא את קיומו של התוכן במטמון‫ גם אם זמנו לא עבר.‬
+‎‫לכן, רצוי לא להשתמש במטמון כמדיום שמירה קבוע (לדוגמא, לא להשתמש במטמון לשמירת מידע אודות המשתמש המחובר).‬
+
+
+«div class="revision"»$Id: caching.overview.txt 2005 2010-03-04 22:42:32Z qiang.xue $«/div»
View
31 docs/guide/he/caching.page.txt
@@ -0,0 +1,31 @@
+שמירת עמוד במטמון
+============
+
+שמירת עמוד במטמון מתייחס לשמירת כל התוכן של עמוד שלם במטמון. שמירת עמוד יכולה להתבצע במקומות שונים. לדוגמא, על ידי בחירת כותרת עמוד מתאימה, הדפדפן של הלקוח יכול לשמור את העמוד הנצפה כרגע לפרק זמן מוגבל. האפליקציה עצמה יכולה לשמור את תוכן העמוד במטמון גם כן. בתת נושא זה, אנו נתמקד על האפשרות השנייה שכרגע הצגנו.
+
+שמירת עמוד במטמון יכולה להחשב כמצב מיוחד של [שמירת חלק מהתצוגה במטמון](/doc/guide/caching.fragment)‫.‬
+מאחר ותוכן העמוד בדרך כלל נוצר על ידי צירוף תבנית לתצוגה, זה לא יעבוד פשוט על ידי קריאה ל [beginCache|CBaseController::beginCache] ו [endCache|CBaseController::endCache] בתוך קובץ התבנית.
+הסיבה היא שהתבנית מצורפת בתוך מתודת [CController::render] **אחרי** שתוכן התצוגה כבר הוערך והורץ.
+
+כדי לשמור עמוד שלם במטמון, אנו צריכים לדלג על ההרצה של הפעולה היוצרת את התוכן של העמוד. אנו יכולים להשתמש ב [COutputCache] כ [פילטר](/doc/guide/basics.controller#filter) כדי להשיג מטרה זו.
+הקוד הבא מציג כיצג ניתן להגדיר את הפילטר של המטמון:
+
+~~~
+[php]
+public function filters()
+{
+ return array(
+ array(
+ 'COutputCache',
+ 'duration'=»100,
+ 'varyByParam'=»array('id'),
+ ),
+ );
+}
+~~~
+
+הגדרות הפילטר למעלה יצרפו את הפילטר לכל הפעולות בקונטרולר. ניתן להגביל אותו לשימוש על פעולות מסויימות על ידי שמוש באופרטור של פלוס ( + ). מידע נוסף ניתן לקרוא על [פילטר](/doc/guide/basics.controller#filter).
+
+» Tip|טיפ: אנו יכולים להשתמש ב [COutputCache] כפילטר מכיוון שהוא יורש מהמחלקה [CFilterWidget], וזה אומר שזהו גם פילטר וגם וידג'ט. למעשה, הדרך בה עובד וידג'ט דומה מאוד לפילטר: וידג'ט (פילטר) מתחיל לפני שתוכן של פעולה רץ, והוידג'ט (פילטר) מסתיים אחרי שתוכן הפעולה הורץ.
+
+«div class="revision"»$Id: caching.page.txt 1014 2009-05-10 12:25:55Z qiang.xue $«/div»
View
509 docs/guide/he/database.ar.txt
@@ -0,0 +1,509 @@
+Active Record
+=============
+
+למרות שה DAO של Yii יכול לטפל בכמעט כל פעולה הקשורה למסד הנתונים, רוב הסיכויים שאנו נבזבז 90% מהזמן שלנו בכתיבת שאילתות SQL אשר מבצעות את הפעולות הנפוצות במסד הנתונים CRUD (יצירה, קריאה, עדכון ומחיקה). גם קשה לנהל את הקוד שאנו כותבים כשהוא מעורבב עם שאילתות SQL שונות. כדי לפתור בעיות אלו אנו יכולים להשתמש ב Active Record.
+
+Active Record או בקיצור AR הינה שיטת ORM (Object-Relational Mapping) נפוצה. כל מחלקת AR מייצגת טבלה במסד הנתונים אשר התכונות שלה מאופיינות כמשתנים במחלקת ה AR, ואובייקט של המחלקה מייצג שורה אחת בטבלה. פעולות CRUD נפוצות מיושמות בתור מתודות במחלקת ה AR. כתוצאה מכך, אנו יכולים לגשת למידע במסד הנתונים בצורה יותר מונחית-עצמים. לדוגמא, אנו יכולים להשתמש בקוד הבא כדי להכניס שורה חדשה בטבלה `tbl_post`:
+
+~~~
+[php]
+$post=new Post;
+$post-»title='כותרת לדוגמא';
+$post-»content='תוכן הודעה לדוגמא';
+$post-»save();
+~~~
+
+במסמך זה אנו נתאר כיצד להגדיר מחלקת AR ולהשתמש בה כדי לבצע פעולות CRUD. בחלק הבא אנו נציג כיצד להשתמש ב AR כדי לטפל בקשרים בין טבלאות במסד הנתונים. לנוחות, אנו נשתמש בטבלה הבאה למטרת הצגת הדוגמאות בחלק זה. הערה: במידה והינך עובד עם מסד נתונים מסוג MySQL, יש להחליף את `AUTOINCREMENT` ב `AUTO_INCREMENT` בשאילתה הבאה.
+
+~~~
+[sql]
+CREATE TABLE tbl_post (
+ id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
+ title VARCHAR(128) NOT NULL,
+ content TEXT NOT NULL,
+ create_time INTEGER NOT NULL
+);
+~~~
+
+» Note|הערה: שימוש ב-AR לא נועד כדי לפתור את כל הבעיות הקשורות למסדי הנתונים. השימוש הטוב ביותר בו נועד על מנת לבצע שאילות SQL פשוטות (CRUD) ושימוש בתור מודל באפליקציה. מומלץ לא להשתמש בו בעת ביצוע שאילתות SQL מורכבות. למטרה זו מומלץ להשתמש ב DAO.
+
+
+התחברות למסד הנתונים
+--------------------------
+
+AR משתמך על חיבור למסד הנתונים כדי לבצע פעולות הקשורות אליו. כברירת מחדל, AR מניח שהרכיב `db` מספק אובייקט [CDbConnection] המאפשר התחברות למסד הנתונים. הגדרות האפליקציה הבאות מציגות דוגמא לשימוש:
+
+~~~
+[php]
+return array(
+ 'components'=»array(
+ 'db'=»array(
+ 'class'=»'system.db.CDbConnection',
+ 'connectionString'=»'sqlite:path/to/dbfile',
+ // הפעלת מטמון להפחתת עומס
+ // 'schemaCachingDuration'=»3600,
+ ),
+ ),
+);
+~~~
+
+» Tip|טיפ: מאחר וה AR מסתמך על ה metadata של הטבלאות כדי להחליט לגבי סוגי העמודות בטבלאות, לוקח זמן לקרוא מידע זה אודות הטבלאות ולנתח אותו. במידה ותרשים טבלאות מסדי הנתונים שלך לא משתנה, מומלץ להפעיל את המטמון לגבי הנתונים אודות הטבלאות על ידי הגדרת המאפיין [CDbConnection::schemaCachingDuration] לערך הגדול מ-0.
+
+תמיכה ב AR מוגבלת על פי DBMS. נכון לעכשיו, ה-DBMS הבאים נתמכים:
+
+- [MySQL 4.1 או יותר](http://www.mysql.com)
+
+- [PostgreSQL 7.3 או יותר](http://www.postgres.com)
+
+- [Microsoft SQL Server 2000 או יותר](http://www.microsoft.com/sqlserver/)
+
+- [Oracle](http://www.oracle.com)
+
+
+» Note|הערה: התמיכה ב SQLServer קיימת מגרסאות 1.0.4 ומעלה. והתמיכה של Oracle קיימת מגרסאות 1.0.5 ומעלה.
+
+אם ברצונך להשתמש ברכיב אפליקציה שהוא לא `db`, או אם ברצונך לעבוד עם כמה מסדי נתונים בעזרת ה AR, רצוי שתדרוס את [CActiveRecord::getDbConnection]. המחלקה [CActiveRecord] הינה מחלקת הבסיס של כל מחלקות ה AR.
+
+» Tip|טיפ: ישנם שני דרכים לעבוד עם כמה מסדי נתונים תוך שימוש ב-AR . אם תרשים מסדי הנתונים הוא שונה, תוכל ליצור מחלקת AR בסיסית שונה אשר בתוכה יהיה צורך לדרוס את [getDbConnection|CActiveRecord::getDbConnection] בצורה שונה. דרך נוספת תיהיה לשנות את המשתנה הסטטי [CActiveRecord::db] בצורה דינאמית בעת הצורך.
+
+הגדרת מחלקת AR
+-----------------
+
+כדי לגשת לטבלה במסד הנתונים, אנו קודם צריכים להגדיר מחלקת AR היורשת מ [CActiveRecord]. כל מחלקת AR מייצגת טבלה במסד הנתונים, ואובייקט של המחלקה מייצג רשומה באותה טבלה. הדוגמא הבאה מציגה את הקוד המינימלי הדרוש למחלקת ה AR המייצגת את הטבלה `tbl_post`.
+
+~~~
+[php]
+class Post extends CActiveRecord
+{
+ public static function model($className=__CLASS__)
+ {
+ return parent::model($className);
+ }
+
+ public function tableName()
+ {
+ return 'tbl_post';
+ }
+}
+~~~
+
+» Tip|טיפ: מאחר וניתן לקרוא למחלקות AR במקומות רבים, ניתן לייבא את כל התיקיה המכילה את מחלקת ה AR, במקום לייבא אותם אחד אחד. לדוגמא, אם כל מחלקות ה AR נמצאות תחת התיקיה `protected/models`, ניתן להגדיר את האפליקציה בצורה הבאה:
+» ~~~
+» [php]
+» return array(
+» 'import'=»array(
+» 'application.models.*',
+» ),
+» );
+» ~~~
+
+כברירת מחדל, שם מחלקת ה AR הוא זהה לשם של הטבלה במסד הנתונים. יש לדרוס את המתודה [tableName|CActiveRecord::tableName] במידה והם שונים אחד מהשני. המתודה [model|CActiveRecord::model] מוגדרת בצורה הזאת לכל מחלקת AR (הסבר בהמשך).
+
+» Info|מידע: כדי להשתמש באפשרות [קידומת טבלאות](/doc/guide/database.dao#using-table-prefix) הקיימת מגרסאות 1.1.0, המתודה [tableName|CActiveRecord::tableName] של מחלקת AR צריכה להדרס בצורה הבאה,
+» ~~~
+» [php]
+» public function tableName()
+» {
+» return '{{post}}';
+» }
+» ~~~
+זאת, במקום להחזיר את שמה המלא של הטבלה, אנו מחזירים את שם הטבלה ללא הקידומת ועוטפים אותה בסוגריים מסולסלות כפולות.
+
+ניתן לגשת לערכים בעמודות של טבלה כמאפיינים של מחלקת ה AR. לדוגמא, הקוד הבא מגדיר את העמודה (מאפיין) `title`:
+
+~~~
+[php]
+$post=new Post;
+$post-»title='הודעה לדוגמא';
+~~~
+
+למרות שאנו לא מגדירים ספציפית את המאפיין `title` במחלקת ה `Post`, אנו עדיין יכולים לגשת אליו בקוד המוצג למעלה. הסיבה לכך היא מכיוון ש `title` הינו עמודה בטבלה `tbl_post` , ומחלקת ה AR מאפשרת גישה אליו כמאפיין במחלקה בעזרת פונקצית ה `__get` ב PHP. תזרק שגיאה במידה ויהיה ניסיון לגשת לעמודה אשר לא קיימת בטבלה.
+
+» Info|מידע: במדריך זה, אנו משתמשים באותיות קטנות לכל שמות הטבלאות והעמודות. זאת מאחר וכל DBMS רגיש באופן שונה לאותיות גדולות-קטנות. לדוגמא, PostgreSQL לא רגיש לאותיות גדולות-קטנות לשמות עמודות בטבלאות כברירת מחדל, ואנו חייבים לתחום את שמות העמודות בתנאים בתוך השאילתה במידה ושם העמודה מכיל שילוב של אותיות גדולות וקטנות. שימוש באותיות קטנות בלבד בשמות פותר בעיה זו.
+
+מחלקת AR מסתמכת על מפתחות ראשיים המוגדרים בטבלאות. במידה וטבלה לא מכילה מפתח ראשי, יש צורך בהגדרת המפתח הראשי במחלקה על ידי דריסה של המתודה `primaryKey` כפי שמוצג בדוגמא הבאה,
+
+~~~
+[php]
+public function primaryKey()
+{
+ return 'id';
+ // בעבור מפתחות מורכבים, יש להחזיר מערך בצורה הבאה
+ // return array('pk1', 'pk2');
+}
+~~~
+
+
+יצירת רשומה
+---------------
+
+בכדי להכניס רשומה חדשה לטבלה במסד הנתונים, אנו יוצרים אובייקט חדש של מחלקת ה AR, מגדירים את המאפיינים שלה בהתאם לעמודות בטבלה, וקוראים למתודה [save|CActiveRecord::save] כדי להשלים את תהליך ההוספה.
+
+~~~
+[php]
+$post=new Post;
+$post-»title='כותרת לדוגמא';
+$post-»content='תוכן להודעה לדוגמא';
+$post-»create_time=time();
+$post-»save();
+~~~
+
+במידה והמפתח הראשי של הטבלה הינו ערך מספרי אשר עולה אוטומטית (מוגדר כ auto_increment), לאחר ההוספה לטבלה מחלקת ה AR תכיל מפתח ראשי מעודכן. בדוגמא למעלה, המאפיין `id` משקף את המפתח הראשי של ההודעה החדשה שנוצרה כרגע, למרות שאנו לא משנים אותו בצורה ספציפית.
+
+במידה וישנו ערך ברירת מחדל לעמודה בטבלה (לדוגמא סטרינג או מספר), המאפיין במחלקת ה AR יכיל את אותו ערך ברירת מחדל לאחר יצירת הרשומה החדשה. דרך אחת לשנות ערך ברירת מחדל זה היא על ידי הגדרת המאפיין במחלקת ה AR עם ערך ברירת מחדל חדש:
+
+~~~
+[php]
+class Post extends CActiveRecord
+{
+ public $title='אנא הזן כותרת';
+ ......
+}
+
+$post=new Post;
+echo $post-»title; // זה יציג: אנא הזן כותרת
+~~~
+
+החל מגרסא 1.0.2, ניתן להגדיר ערך של [CDbExpression] למאפיין כלשהו לפני שמירת הרשומה (בין אם זה יצירת רשומה חדשה או עדכון רשומה קיימת) במסד הנתונים. לדוגמא, בכדי לשמור את הזמן הנוכחי המוחזר באמצעות הפונקציה `()NOW` ב MySQL, אנו יכולים להשתמש בקוד הבא:
+
+~~~
+[php]
+$post=new Post;
+$post-»create_time=new CDbExpression('NOW()');
+// $post-»create_time='NOW()'; לא יעבוד מאחר
+// 'NOW()' יהיה כסטרינג ולא כפונקציה
+$post-»save();
+~~~
+
+» Tip|טיפ: אף על פי ש AR מאפשר לנו לבצע פעולות הקשורות למסד הנתונים ללא צורך בכתיבה של שאילתות SQL מסובכות, אנו בדרך כלל נרצה לדעת אילו שאילתות SQL רצות מאחורי ה AR. ניתן לקבל מידע זה על ידי הפעלת אפשרות [התיעוד](/doc/guide/topics.logging) של Yii. לדוגמא, אנו יכולים להפעיל את [CWebLogRoute] בהגדרות האפליקציה, ואנו נראה את השאילתות שבוצעו בסוף כל עמוד. מגרסא 1.0.5, אנו יכולים להגדיר את המאפיין [CDbConnection::enableParamLogging] לערך השווה ל `true` בהגדרות האפליקציה כדי שהפרמטרים התחומים בשאילתה יוצגו גם הם בתיעוד.
+
+קריאת רשומה
+--------------
+
+בכדי לקרוא מידע מטבלה במסד הנתונים, אנו קוראים לאחת ממתודות ה `find` הבאות.
+
+~~~
+[php]
+// מצא את הרשומה הראשונה המשביע את התנאי שהועבר
+$post=Post::model()-»find($condition,$params);
+// מצא את הרשומה עם המפתח הראשי שהועבר
+$post=Post::model()-»findByPk($postID,$condition,$params);
+// מצא את הרשומה עם המאפיין שהועבר
+$post=Post::model()-»findByAttributes($attributes,$condition,$params);
+// מצא את הרשומה הראשונה עם השאילתה שהועברה
+$post=Post::model()-»findBySql($sql,$params);
+~~~
+
+בדוגמאות למעלה, אנו קוראים למתודות ה `find` בעזרת `()Post::model`. זכור שהמתודה הסטטית `()model` הינה הכרחית לכל מחלקת AR. המתודה מחזירה אובייקט AR אשר משתמשים בו לגשת למתודות בעלי הרשאה לאותה מחלקה בלבד (משהו דומה למתודות סטטיות במחלקה) באופן מונחה עצמים.
+
+אם המתודה `find` מוצאת רשומה המשביע את התנאים שהועברו, היא תחזיר אובייקט של `Post` כשהמאפיינים שלה מכילים את הערכים של העמודות של אותה רשומה בטבלה. לאחר מכן אנו יכולים לקרוא את הערכים שנטענו בצורה הרגילה בה אנו ניגשים למאפיינים של המחלקה, לדוגמא, `;echo $post-»title`.
+
+מתודת ה `find` תחזיר null במידה ולא נמצא שום דבר במסד הנתונים התואם לתנאים שהועברו.
+
+בעת הקריאה ל `find`, אנו משתמשים ב `condition$` ו `params$` כדי להגדיר את התנאים של השאילתה. כאן `condition$` יכול להוות סטרינג המייצג את הסעיף `WHERE` בשאילתת SQL, ו `params$` הינו מערך של פרמטרים שערכיהם צריכים להתחם במפתחות שהוגדרו מראש ב `condition$`. לדוגמא,
+
+~~~
+[php]
+// מצא את הרשומה איפה ש postID = 10
+$post=Post::model()-»find('postID=:postID', array(':postID'=»10));
+~~~
+
+» Note|הערה: בדוגמא למעלה, אנו נצטרך לבצע חיטוי לייחוס של העמודה `postID` בעבור DBMS מסויימים. לדוגמא, במידה ואנחנו משתמשים ב PostgreSQL, אנו נצטרך לכתוב את התנאי בצורה הבאה `postID"=:postID"`, מאחר ו PostgreSQL כברירת מחדל יתייחס לשמות העמודות ללא רגישות לאותיות גדולות-קטנות.
+
+כמו כן אנו יכולים להשתמש ב `condition$` כדי להגדיר תנאים מורכבים יותר. במקום סטרינג, אנו נותנים ל `condition$` להיות אובייקט של [CDbCriteria], המאפשר לנו להגדיר תנאים נוספים מלבד סעיף ה `WHERE`. לדוגמא,
+
+~~~
+[php]
+$criteria=new CDbCriteria;
+$criteria-»select='title'; // בחר רק את העמודה 'title'
+$criteria-»condition='postID=:postID';
+$criteria-»params=array(':postID'=»10);
+$post=Post::model()-»find($criteria); // $params אינו נחוץ כאן
+~~~
+
+זכור, שבעת השימוש ב [CDbCriteria] בתור התנאי של השאילתה, הפרמטר `params$` אינו נחוץ מאחר וניתן להגדיר אותו בעזרת [CDbCriteria], כפי שמוצג למעלה.
+
+כמו כן, במקום שימוש ב [CDbCriteria] ניתן להעביר מערך למתודת ה-`find`.
+שמות המפתחות והערכים מתייחסות למאפיינים של התנאים וערכיהם, בהתאם. ניתן לשכתב את הדוגמא למעלה בקוד הבא,
+
+~~~
+[php]
+$post=Post::model()-»find(array(
+ 'select'=»'title',
+ 'condition'=»'postID=:postID',
+ 'params'=»array(':postID'=»10),
+));
+~~~
+
+» Info|מידע: כשהתנאי של השאילתה עוסק בהתאמת עמודות והערכים שהוגדרו, אנו יכולים להשתמש ב [findByAttributes()|CActiveRecord::findByAttributes].
+אנו נותנים לפרמטר `attributes$` להיות מערך של שמות העמודות בתור המפתחות וערך כל מפתח הינו הערך שאותו אנו רוצים להתאמים בשאילתה. בכמה פריימוורקים (Frameworks), פעולה זו ניתנת לביצוע על ידי קריאה למתודות כמו `findByNameAndTitle`. למרות שגישה זו נראית מושכת, היא גורמת ברוב המקרים לבלבול, קונפליקטים ובעיות של רגישות לאותיות גדולות-קטנות בשמות העמודות.
+
+כשישנם מספר רב של רשומות התואמות לתנאים שהוצבו בשאילתה, אנו יכולים להביא את כולם יחדיו על ידי שימוש במתודות `findAll` הבאות, לכל אחת מהם ישנה מתודת `find` תואמת, כפי שכבר הסברנו.
+
+~~~
+[php]
+// מצא את כל הרשומות התואמות לתנאי שהועבר
+$posts=Post::model()-»findAll($condition,$params);
+// מצא את כל הרשומות בעלות המפתח הראשי שהועבר
+$posts=Post::model()-»findAllByPk($postIDs,$condition,$params);
+// מצא את כל הרשומות התואמות למאפיינים שהועברו
+$posts=Post::model()-»findAllByAttributes($attributes,$condition,$params);
+// מצא את כל הרשומות אשר תואמות לשאילתה שהועברה
+$posts=Post::model()-»findAllBySql($sql,$params);
+~~~
+
+במידה ולא נמצאו התאמות לתנאים שהוצבו בשאילתה, `findAll` תחזיר מערך ריק. זה שונה מהערך שיוחזור ממתודות `find` המחזירות null במידה ולא נמצאו רשומות.
+
+מלבד המתודות `find` ו `findAll` המתוארות למעלה, לנוחות השימוש ניתן להשתמש במתודות הבאות גם כן:
+
+~~~
+[php]
+// קבל את מספר הרשומות התואמות לתנאי שהועבר
+$n=Post::model()-»count($condition,$params);
+// קבל את מספר הרשומות התואמות לשאילתה שהועברה
+$n=Post::model()-»countBySql($sql,$params);
+// בדוק אם קיימת לפחות רשומה אחת התואמת לתנאי שהועבר
+$exists=Post::model()-»exists($condition,$params);
+~~~
+
+עדכון רשומה
+---------------
+
+לאחר שאובייקט AR עם ערכים לעמודות, ניתן לשנותם ולשמור אותם בחזרה לטבלה במסד.
+
+~~~
+[php]
+$post=Post::model()-»findByPk(10);
+$post-»title='כותרת חדש';
+$post-»save(); // שמור את השינויים במסד
+~~~
+
+כפי שניתן לראות, אנו משתמשים באותה מתודה [save()|CActiveRecord::save] כדי לבצע פעולות הוספה ועדכון. במידה ואובייקט ה AR נוצר כאובייקט חדש בעזרת שימוש באופרטור `new`, קריאה ל [save()|CActiveRecord::save] תוסיף רשומה חדשה לטבלה במסד הנתונים; במידה ואובייקט ה AR נוצר כתוצאה משימוש במתודה כמו `find` או `findAll`, קריאה ל [save()|CActiveRecord::save] תעדכן את הרשומה הקיימת בטבלה. למעשה, אנו יכולים להשתמש ב [CActiveRecord::isNewRecord] כדי להבחין במידה אובייקט ה AR הינו חדש או לא.
+
+ניתן לעדכן רשומה אחת או יותר בטבלה במסד הנתונים ללא צורך בטעינתם מראש. AR מספקת את המתודות הבאות לנוחות השימוש:
+
+~~~
+[php]
+// עדכן את הרשומות התואמות לתנאי שהועבר
+Post::model()-»updateAll($attributes,$condition,$params);
+// עדכן את הרשומות התואמות לתנאי שהועבר ולמפתחות הראשיים שהועברו
+Post::model()-»updateByPk($pk,$attributes,$condition,$params);
+// עדכן את עמודות הספירה ברשומות התואמות לתנאי שהועבר
+Post::model()-»updateCounters($counters,$condition,$params);
+~~~
+
+בדוגמא למעלה, `attributes$` הינו מערך של שמות העמודות וערכיהם; `counter$` הינו מערך של שמות העמודות וערכיהם הינו מספר עולה; ו `condition$` ו `params$` כפי שהוסבר בחלק הקודם.
+
+מחיקת רשומה
+---------------
+
+אנו יכולים למחוק רשומה במידה ואובייקט ה AR נוצר על ידי קבלת המידע מהטבלה במסד הנתונים.
+
+~~~
+[php]
+$post=Post::model()-»findByPk(10); // נניח וישנה הודעה עם המספר 10
+$post-»delete(); // מחק את הרשומה מהטבלה במסד הנתונים
+~~~
+
+הערה, לאחר המחיקה, אובייקט ה AR נשאר ללא שינוי, אבל אותה שורה בטבלה במסד הנתונים נמחקה.
+
+לנוחות ניתן להעזר במתודות הבאות כדי למחוק רשומות ללא צורך בטעינה מראש שלהם:
+
+~~~
+[php]
+// מחק את הרשומות התואמות לתנאי שהועבר
+Post::model()-»deleteAll($condition,$params);
+// מחק את הרשומות התואמות לתנאי שהועבר ולמפתחות שהועברו
+Post::model()-»deleteByPk($pk,$condition,$params);
+~~~
+
+אימות נתונים
+---------------
+
+כשמוסיפים או מעדכנים רשומה, אנו בדרך כלל צריכים לבדוק במידה והערכים שהוצבו עונים על חוקים מסויימים. זה בהחלט הכרחי במידה והערכים שמוצבים מוגדרים על ידי משתמשי קצה. בדרך כלל, אנו לא יכולים לסמוך על שום דבר המגיע מצד הלקוח.
+
+AR מבצע אימות נתונים אוטומטית בעת הקריאה ל [()save|CActiveRecord::save]. האימות מבוסס על החוקים שהוגדרו במתודת [()rules|CModel::rules] במחלקת ה AR. למידע נוסף אודות הגדרת חוקי אימות נתונים, יש לקרוא את החלק אודות [הגדרת חוקי אימות נתונים](/doc/guide/form.model#declaring-validation-rules). למטה מוצג קוד בסיסי הנחוץ לשמירה של רשומה:
+
+~~~
+[php]
+if($post-»save())
+{
+ // נתונים אומתו והרשומה נוספה/עודכנה
+}
+else
+{
+ // נתונים לא תקינים. יש לקרוא למתודה ה getErrors() לקבלת השגיאות שחזרו
+}
+~~~
+
+כשהמידע לעדכון או הוספה של רשומה מתקבל על ידי משתמשי קצה בעזרת טופס HTML , אנו צריכים להציב אותם למאפיינים התואמים במחלקת ה AR. ניתן לבצע זאת בצורה הבאה:
+
+~~~
+[php]
+$post-»title=$_POST['title'];
+$post-»content=$_POST['content'];
+$post-»save();
+~~~
+
+במידה וישנם עמודות רבים, אנו נראה רשימה ארוכה של הצבות כאלו. בכדי להקל על תהליך ההצבה ניתן להעזר במאפיין [attributes|CActiveRecord::attributes] כפי שמוצג בדוגמא למטה.
+מידע נוסף ניתן למצוא בחלק [אבטחת הצבת מאפיינים](/doc/guide/form.model#securing-attribute-assignments) ובחלק [יצירת פעולה](/doc/guide/form.action) .
+
+~~~
+[php]
+// נניח ש $_POST['Post'] הינו מערך ששמות המפתחות הינם שמות העמודות בטבלה והערכים שלהם בהתאם
+$post-»attributes=$_POST['Post'];
+$post-»save();
+~~~
+
+
+השוואת רשומות
+-----------------
+
+בדומה לשורות בטבלה, אובייקטים של AR מזוהים בצורה יחודית על ידי הערך במפתח הראשי שלהם. לכן, בכדי להשוות בין שני אובייקטים של AR, כל מה אנו צריכים לעשות זה להשוות בין את ערכי המפתחות הראשיים שלהם, בהנחה שהם שייכים לאותה מחלקת AR. למרות, שיהיה יותר קל לקרוא פשוט למתודה [()CActiveRecord::equals].
+
+» Info|מידע: בניגוד ליישום ושימוש של AR בפריימוורקס (Frameworks) שונים אחרים, Yii תומכת במפתחות ראשיים מורכבים במחלקות ה AR שלה. מפתח ראשי מורכב מכיל שני עמודות או יותר. מפתח ראשי מורכב מיוצג על ידי מערך ב Yii, בהתאמה. המאפיין [primaryKey|CActiveRecord::primaryKey] מספק את ערך המפתח הראשי של אובייקט AR.
+
+התאמה אישית
+-------------
+
+[CActiveRecord] מספקת כמה מתודות שניתנים לדריסה על ידי תתי המחלקות שלה כדי לשנות את רצף העבודה שלהם וההתנהלות.
+
+- [beforeValidate|CModel::beforeValidate] ו [afterValidate|CModel::afterValidate]: מתודות אלו נקראות לפני ואחרי ביצוע אימות הנתונים.
+
+- [beforeSave|CActiveRecord::beforeSave] ו [afterSave|CActiveRecord::afterSave]: מתודות אלו נקראות לפני ואחרי שמירת אובייקט AR.
+
+- [beforeDelete|CActiveRecord::beforeDelete] ו [afterDelete|CActiveRecord::afterDelete]: מתודות אלו נקראות לפני ואחרי מחיקת אובייקט AR.
+
+- [afterConstruct|CActiveRecord::afterConstruct]: מתודה זו רצה בכל פעם שאובייקט AR חדש נוצר בעזרת האופרטור `new`.
+
+- [beforeFind|CActiveRecord::beforeFind]: מתודה זו רצה לפני שימוש באחד ממתודות ה `find` (לדוגמא `find`, `findAll`). אפשרות זו קיימת מגרסאות 1.0.9 ומעלה.
+
+- [afterFind|CActiveRecord::afterFind]: מתודה זו רצה לאחר יצירת אובייקט AR כתוצאה מביצוע שאילתה.
+
+
+שימוש בטרנזקציה בעזרת AR
+-------------------------
+
+כל אובייקט AR מכיל מאפיין בשם [dbConnection|CActiveRecord::dbConnection] אשר מייצג אובייקט של [CDbConnection]. לכן אנו יכולים להשתמש באפשרות של [טרנזקציות](/doc/guide/database.dao#using-transactions) המסופקת על ידי ה-DAO של Yii בעת הצורך במהלך השימוש ב-AR:
+
+~~~
+[php]
+$model=Post::model();
+$transaction=$model-»dbConnection-»beginTransaction();
+try
+{
+ // שימוש ב find ו save הינם שני שלבים אשר ניתן להתערב בהם על ידי בקשות נוספות
+ // לכן אנו משתמשים בטרנזקציה כדי לוודא המשכיות
+ $post=$model-»findByPk(10);
+ $post-»title='כותרת חדשה';
+ $post-»save();
+ $transaction-»commit();
+}
+catch(Exception $e)
+{
+ $transaction-»rollBack();
+}
+~~~
+
+
+מרחבים מוגדרים
+------------
+
+» Note|הערה: תמיכה במרחבים מוגדרים נוספה מגרסאות 1.0.5 ומעלה. הרעיון המקורי של מרחבים מוגדרים הגיע מ Ruby on Rails.
+
+*מרחב מוגדר* מייצג *שם* של תנאי בשאילתה שניתן לאחד אותה ביחד עם עוד מרחבים מוגדרים ולצרף לשאילתה של AR.
+
+מרחבים מוגדרים בדרך כלל מוגדרים במתודה [CActiveRecord::scopes] בזוגות בפורמט של שם-תנאי. הקוד הבא מגדיר שני מרחבים מוגדרים, `published` ו `recently`, במחלקה של המודל `Post`:
+
+~~~
+[php]
+class Post extends CActiveRecord
+{
+ ......
+ public function scopes()
+ {
+ return array(
+ 'published'=»array(
+ 'condition'=»'status=1',
+ ),
+ 'recently'=»array(
+ 'order'=»'create_time DESC',
+ 'limit'=»5,
+ ),
+ );
+ }
+}
+~~~
+
+כל מרחב מוגדר בתור מערך שניתן לאתחל בעזרתו אובייקט של [CDbCriteria]. לדוגמא, המרחב `recently` מגדיר את המאפיין `order` בערך `create_time DESC` ואת המאפיין `limit` לערך 5, שמתורגם לתנאי בשאילתה שאמור להחזיר את חמשת ההודעות האחרונות.
+
+שימושם העיקרי של המרחבים המוגדרים הינו *שינוי והגדרה* של קריאה למתודות `find` שונות. ניתן לשרשר כמה מרחבים מוגדרים וכתוצאה מכך לבצע שאילתה הרבה יותר מוגבלת הכוללת יותר תנאים. לדוגמא, בכדי למצוא את ההודעות שפורסמו לאחרונה, אנו יכולים להשתמש בקוד הבא:
+
+~~~
+[php]
+$posts=Post::model()-»published()-»recently()-»findAll();
+~~~
+
+בדרך כלל, מרחב מוגדר צריך להיות מוגדר מצד שמאל (לבוא לפני) של המתודה `find`. כל אחד מהם מספק תנאי לשאילתה, אשר בסופו של דבר מתאחד עם תנאים אחרים, כולל את התנאי שהועבר למתודת `find`, ויוצר תנאי אחד גדול. התוצאה הסופית דומה להוספת רשימה של פילטרים לשאילתה.
+
+החל מגרסא 1.0.6, ניתן להשתמש במרחבים מוגדרים במתודות `update` ו `delete`. לדוגמא, הקוד הבא ימחק את כל ההודעות שנוספו לאחרונה:
+
+~~~
+[php]
+Post::model()-»published()-»recently()-»delete();
+~~~
+
+» Note|הערה: ניתן להשתמש במרחבים מוגדרים על מתודות במחלקה הנוכחית. זאת אומרת, המתודה צריכה להקרא על ידי `()ClassName::model`.
+
+### מרחבים מוגדרים עם פרמטרים
+
+ניתן להוסיף פרמטרים (סממנים) למרחבים מוגדרים. לדוגמא, אנו נרצה לשנות את הערך של ההודעות במרחב המוגדר בשם `recently`. בכדי לעשות זאת, במקום להגדיר את שם המרחב במתודה [CActiveRecord::scopes], אנו צריכים להגדיר מתודה ששמה הוא זהה לשם המרחב בו אנו משתמשים:
+
+~~~
+[php]
+public function recently($limit=5)
+{
+ $this-»getDbCriteria()-»mergeWith(array(
+ 'order'=»'create_time DESC',
+ 'limit'=»$limit,
+ ));
+ return $this;
+}
+~~~
+
+לאחר מכן, אנו משתמשים בביטוי הבא בכדי לקבל את שלושת ההודעות שפורסמו לאחרונה:
+
+~~~
+[php]
+$posts=Post::model()-»published()-»recently(3)-»findAll();
+~~~
+
+במידה ולא נעביר את הספרה 3 כפרמטר במתודה `recently` בקוד למעלה, אנו נקבל את חמשת ההודעות שפורסמו לאחרונה כברירת מחדל.
+
+### מרחבים מוגדרים כברירת מחדל
+
+במחלקה של מודל ניתן להגדיר מרחב מוגדר אשר יתווסף לכל השאילתות שאנו מריצים בעזרת המחלקה (כולל קישורים לטבלאות אחרות). לדוגמא, אתר התומך בכמה שפות ירצה להציג תוכן באותה שפה שהמשתמש כרגע צופה בה. מאחר וישנם שאילתות רבות בנוגע לתוכן האתר, אנו יכולים להגדיר מרחב מוגדר ברירת מחדל בכדי לפתור בעיה זו. בכדי לבצע זאת, אנו נצטרך לדרוס את המתודה [CActiveRecord::defaultScope] בצורה הבאה,
+
+~~~
+[php]
+class Content extends CActiveRecord
+{
+ public function defaultScope()
+ {
+ return array(
+ 'condition'=»"language='".Yii::app()-»language."'",
+ );
+ }
+}
+~~~
+
+כעת, הביטוי הבא אוטומטית משתמש בתנאי כפי שהוגדר למעלה:
+
+~~~
+[php]
+$contents=Content::model()-»findAll();
+~~~
+
+יש לזכור ששימוש במרחבים מוגדרים כברירת מחדל תקף רק לשאילתות מסוג `SELECT`. הוא אינו תקף לגבי `INSERT`, `UPDATE` ו `DELETE` ופשוט יתעלם מהם.
+
+«div class="revision"»$Id: database.ar.txt 1681 2010-01-08 03:04:35Z qiang.xue $«/div»
View
383 docs/guide/he/database.arr.txt
@@ -0,0 +1,383 @@
+Relational Active Record
+========================
+
+כבר ראינו ולמדנו כיצב להשתמש ב Active Record (AR) כדי לשלוף מידע מטבלה במסד הנתונים. בחלק זה, אנו נסביר כיצד להשתמש ב AR כדי לאחד כמה טבלאות המקושרות אחת לשנייה ולהחזיר את סט הנתונים המאוחד.
+
+בכדי להשתמש בקישור AR, מומלץ להגדיר את המפתחות הראשיים של הטבלאות העומדות להיות מאוחדות עם טבלאות אחרות כבר מראש. הגדרתם תעזור לשמירת ההמשכיות והאחדות של המידע המקושר.
+
+כדי לפשט את ההסבר, אנו נשתמש בתרשים מסד הנתונים המוצג בדיאגרמה הבאה בכדי להדגים את הדוגמאות בחלק זה.
+
+![דיאגרמה](er.png)
+
+» Info|מידע: תמיכה במפתחות ראשיים חיצוניים תלויה ב DBMS בו משתמשים. SQLite « 3.6.19 אינו תומך במפתחות ראשיים חיצוניים, אך עדיין ניתן להגדיר את המפתחות החיצוניים בעת יצירת הטבלה.
+
+הצהרת קישורי טבלאות
+----------------------
+
+לפני שנשתמש ב AR בכדי לבצע שאילתה מקושרת, אנו צריכים ליידע את ה AR כיצד מחלקת AR אחת מקושרת עם אחרת.
+
+הקישור בין שני מחלקות AR משתייך ישירות לקישורים בין הטבלאות המיוצגות על ידי מחלקות ה AR. מנקודת מבט של מסד נתונים, קישור בין שני טבלאות A ו B ניתן להגדרה על ידי שלושה סוגים: יחיד-ל-רבים (`one-to-many` לדוגמא `tbl_user` ו `tbl_post`), יחיד-ל-יחיד ( `one-to-one` לדוגמא `tbl_user` ו `tbl_profile`) ו רבים-ל-רבים (`many-to-many` לדוגמא `tbl_category` ו `tbl_post`). ב AR ישנם ארבע סוגים של קישורים:
+
+- `BELONGS_TO`: במידה והקישור בין טבלה א' לבין טבלה ב' הינה יחיד-ל-רבים, אז ב' שייך ל א' (לדוגמא `Post` שייך ל `User`);
+
+- `HAS_MANY`: במידה והקישור בין טבלה א' לבין טבלה ב' הינה יחיד-ל-רבים, אז א' מכיל הרבה מ ב' (לדוגמא `User` מכיל הרבה `Post`);
+
+- `HAS_ONE`: זהו מקרה מיוחד של `HAS_MANY` איפה א' מכיל לכל היותר ב' אחד (לדוגמא `User` מכיל לכל היותר `Profile` אחד);
+
+- `MANY_MANY`: זה מתייחס לקישור של רבים-ל-רבים במסד נתונים. טבלה אסוציאטיבית נחוצה בכדי לחלק את הקישור רבים-ל-רבים לקישור יחיד-ל-רבים, מאחר ומרבית ה DBMS אינם תומכים בקישור מסוג רבים-ל-רבים כברירת מחדל. בדוגמא של תרשים מסד הנתונים, הטבלה `tbl_post_category` משרתת מטרה זו. בטרמינולוגיה של AR אנו יכולים להסביר את `MANY_MANY` כקומבינציה של `BELONGS_TO` ו `HAS_MANY`. לדוגמא, `Post` שייך לכמה `Category` ו `Category` מכיל הרבה `Post`.
+
+הגדרת קישורים ב AR כרוכה בדריסה של המתודה [relations|CActiveRecord::relations] של המחלקה [CActiveRecord]. המתודה מחזירה מערך של הגדרות קישורים. כל אלמנט במערך קישור בודד בפורמט הבא:
+
+~~~
+[php]
+'VarName'=»array('RelationType', 'ClassName', 'ForeignKey', ...additional options)
+~~~
+
+`varName` מייצג את שם הקישור; `RelationType` מייצג את סוג הקישור, הוא יכול להיות אחד מהערכים: `self::BELONGS_TO`, `self::HAS_ONE`, `self::HAS_MANY` ו
+`self::MANY_MANY`; `ClassName` הינו שם מחלקת ה AR הקשור למחלקת ה AR הנוכחית; ו `ForeignKey` מייצג את המפתח(ות) הראשיים השייכים לקישור זה. אפשרויות נוספות ניתנות להגדרה בסוף האלמנט לכל קישור (הסבר בהמשך).
+
+הקוד הבא מדגים כיצד אנו מצהירים על הקישורים בין המחלקות `Post` ו `User`.
+
+~~~
+[php]
+class Post extends CActiveRecord
+{
+ ......
+
+ public function relations()
+ {
+ return array(
+ 'author'=»array(self::BELONGS_TO, 'User', 'author_id'),
+ 'categories'=»array(self::MANY_MANY, 'Category',
+ 'tbl_post_category(post_id, category_id)'),
+ );
+ }
+}
+
+class User extends CActiveRecord
+{
+ ......
+
+ public function relations()
+ {
+ return array(
+ 'posts'=»array(self::HAS_MANY, 'Post', 'author_id'),
+ 'profile'=»array(self::HAS_ONE, 'Profile', 'owner_id'),
+ );
+ }
+}
+~~~
+
+» Info|מידע: מפתח ראשי יכול להיות מורכב, המכיל שני עמודות או יותר. במקרה זה, אנו צריכים לאחד את שמות העמודות ולהפריד אותם בעזרת פסיק או רווח. עבור סוג קישור `MANY_MANY`, שם הטבלה המקושרת צריכה להיות מוגדרת במפתח החיצוני. לדוגמא, הקישור `categories` ב `Post` מוגדרת באמצעות המפתח החיצוני `tbl_post_category(post_id, category_id)`.
+
+ההצהרה של קישורים במחלקת ה AR מוסיפה בצורה עקיפה מאפיינים למחלקה אשר מהווים ייצוג של הקישורים עצמם. לאחר ביצוע שאילתה המקשרת בין טבלאות, המאפיין הנלמד יאוכלס על ידי הקישור של מחלקת ה AR. לדוגמא, אם `author$` מייצג אובייקט AR של `User`, אנו נוכל להשתמש ב `author-»posts$` בכדי לגשת לקישור של אובייקט ה `Post`.
+
+ביצוע שאילתות מקושרות
+---------------------------
+
+הדרך הפשוטה ביותר לביצוע שאילתה מקושרת היא על ידי קריאת מאפיין הקישור של אובייקט AR. במידה והמאפיין לא נקרא קודם לכן, תתבצע שאילתה מקושרת, המאחדת את שני הטבלאות המקושרות ומסננת בעזרת המפתח הראשי של אובייקט ה AR הנוכחי. תוצאת השאילתה תשמר במאפיין כאובייקט(ים) של מחלקת ה AR המקושרת. שיטה זו ידועה בשמה כ *טעינה עצלה* (lazy loading), כלומר, השאילתה המקושרת מתבצעת רק במידה וזמן שניגשים לאבוייקטים המקושרים (זאת אומרת קוראים את המאפיינים של הקישורים בין הטבלאות). הדוגמא הבאה מציגה כיצד להשתמש בשיטה זו:
+
+~~~
+[php]
+// קבלת ההודעה עם id = 10
+$post=Post::model()-»findByPk(10);
+// קבלת מידע אודות מפרסם ההודעה, כאן תתבצע שאילתה מקושרת
+$author=$post-»author;
+~~~
+
+» Info|מידע: במידה ולא קיים אובייקט לקישור מסויים, אותו מאפיין במחלקת ה AR המקשרת יכול להיות null או מערך ריק. בעבור קישורי טבלאות מסוג `BELONGS_TO` ו `HAS_ONE`, התוצאה תיהיה null; בעבור קישורי טבלאות מסוג `HAS_MANY` ו `MANY_MANY`, התוצאה תיהיה מערך ריק.
+זכור שקישורי הטבלאות מסוג `HAS_MANY` ו `MANY_MANY` מחזירים מערך של אובייקטים, תצטרכו לרוץ על כל התוצאות לפני שיהיה ניתן לגשת לכל אחד כאובייקט, אחרת, תזרק שגיאה של ניסיון לקריאה של מאפיינים לאובייקט שלא קיים.
+
+גישת ה*טעינה עצלה* נוחה מאוד לשימוש, אך היא לא יעילה במקרים מסויימים. לדוגמא, במידה ואנו רוצים לגשת למידע אודות המפרסם של `N` הודעות, שימוש ב*טעינה עצלה* תבצע `N` שאילתות מקשרות. אנו נצטרך לנקוט בגישה של *טעינה נלהבת* (eager loading) במקרים כאלו.
+
+גישת ה*טעינה נלהבת* מחזיר את האובייקטים המקושרים לאובייקט AR הראשי. ניתן לבצע זאת על ידי שימוש במתודה [with()|CActiveRecord::with] בשילוב של אחת מפקודות ה [find|CActiveRecord::find] או [findAll|CActiveRecord::findAll] במחלקת AR. לדוגמא,
+
+~~~
+[php]
+$posts=Post::model()-»with('author')-»findAll();
+~~~
+
+הקוד למעלה יחזיר מערך של אובייקטים של `Post`. בניגוד לגישה של טעינה עצלה, המאפיין `author` בכל אובייקט של `Post` כבר מאוכלס וקיים בשילוב של האובייקט של `User` לפני שאנו אפילו ניגשים לקרוא את המאפיין.
+במקום לבצע שאילתה מקשרת לכל הודעה, גישת הטעינה הנלהבת מחזירה את כל ההודעות ביחד עם המידע אודות המפרסם שלה בשאילתה אחת!
+
+ניתן להגדיר מספר רב של שמות קישורים במתודה [with|CActiveRecord::with] וגישת הטעינה הנלהבת תחזיר את כולם במכה אחת. לדוגמא, הקוד הבא מחזיר הודעות ביחד עם המידע אודות המפרסם שלהם והקטגוריה בה הם פורסמו:
+
+~~~
+[php]
+$posts=Post::model()-»with('author','categories')-»findAll();
+~~~
+
+כמו כן, אנו יכולים לקנן בין קישורים בעזרת הטעינה הנלהבת. במקום רשימה של שמות קישורים, אנו מעבירים רפרזנטציה היררכית של שמות הקישורים למתודה [with|CActiveRecord::with], כפי שמוצג בדוגמא הבאה,
+
+~~~
+[php]
+$posts=Post::model()-»with(
+ 'author.profile',
+ 'author.posts',
+ 'categories')-»findAll();
+~~~
+
+הדוגמא למעלה תחזיר את כל ההודעות ביחד עם המידע אודות המפרסם והקטגוריות בהם הם פורסמו. בנוסף היא תחזיר את המידע אודות הפרופיל של המשתמש וההודעות שלו.
+
+החל מגרסא 1.1.0, ניתן להשתמש בגישת הטעינה הנלהבת בעזרת הגדרת המאפיין [CDbCriteria::with], כפי שמוצג בדוגמא:
+
+~~~
+[php]
+$criteria=new CDbCriteria;
+$criteria-»with=array(
+ 'author.profile',
+ 'author.posts',
+ 'categories',
+);
+$posts=Post::model()-»findAll($criteria);
+~~~
+
+או
+
+~~~
+[php]
+$posts=Post::model()-»findAll(array(
+ 'with'=»array(
+ 'author.profile',
+ 'author.posts',
+ 'categories',
+ )
+);
+~~~
+
+
+אפשרויות שאילתות מקושרות
+------------------------
+
+ציינו שניתן להגדיר אפשרויות נוספות בהגדרה של קישורים. אפשרויות אלו, המוגדרות כזוגות של שמות מפתחות וערכים, מוגדרות כדי לשנות את השאילתה המקושרת. סיכום של אפשרויות אלו נמצא למטה.
+
+- `select`: רשימה של עמודות שאותם צריכים לשלוף ממחלקת ה AR המקושרת. ברירת המחדל הינה '*', שזה אומר כל העמודות, שמות העמודות באפשרות זו צריכות להיות יחודיות.
+
+- `condition`: סעיף ה `WHERE`. כברירת מחדל הוא ריק. שמות העמודות באפשרות זו צריכות להיות יחודיות.
+
+- `params`: הפרמטרים שצריכים להיות תחומים לשאילתת ה SQL שתווצר. אפשרות זו צריכה להיות מוגדרת כמערך של מפתחות וערכים. אפשרות זו קיימת מגרסאות 1.0.3 ומעלה.
+
+- `on`: סעיף ה `ON`. התנאי המוגדר כאן יצורף לתנאי של הקישור בעזרת האופרטור `AND`. שמות העמודות באפשרות זו צריכות להיות יחודיות. אפשרות זו לא תקפה לסוג קישור `MANY_MANY`. אפשרות זו קיימת מגרסאות 1.0.2 ומעלה.
+
+- `order`: סעיף ה `ORDER BY`. כברירת מחדל הוא ריק. שמות העמודות באפשרות זו צריכות להיות יחודיות.
+
+- `with`: רשימה של אובייקטים המקושרים לאובייקט זה ושיש צורך בלטעון אותם ביחד עם אובייקט זה. דע לך ששימוש לא נכון באפשרות זו יכול לגרום ללולאה אין סופית.
+
+- `jointType`: סוג האיחוד לקישור זה. כברירת מחדל הוא מוגדר ל `LEFT OUTER JOIN`.
+
+- `alias`: שם קיצור לטבלה הקשורה לקישור זה. אפשרות זו קיימת מגרסא 1.0.1. כברירת מחדל היא מוגדרת ל null, שאומר שהקיצור לטבלה הוא זהה לשם הקישור עצמו.
+
+- `together`: במידה והטבלה המקושרת עם קישור זה מאולצת לאיחוד ביחד עם הטבלה הראשית ושאר הטבלאות. אפשרות זו תקפה רק לקישורים מסוג HAS_MANY ו MANY_MANY. במידה ואפשרות זו מוגדרת ל false, הטבלה המקושרת ל HAS_MANY או MANY_MANY תאוחד עם הטבלה הראשית בשאילתה נפרדת, אשר יכול לשפר את הביצועים הכוללים של השאילתה מאחר ופחות נתונים כפולים יוחזרו. כברירת מחדל האפשרות מוגדרת ל true.
+למידע נוסף קרא את החלק "ביצועי שאילתה מקושרת". אפשרות זו קיימת מגרסא 1.0.3 ומעלה.
+
+- `group`: סעיף ה `GROUP BY`. כברירת מחדל הוא ריק. שמות העמודות באפשרות זו צריכות להיות יחודיות. אפשרות זו קיימת מגרסא 1.0.1 ומעלה.
+
+- `having`: סעיף ה `HAVING`. כברירת מחדל הוא ריק. שמות העמודות באפשרות זו צריכות להיות יחודיות. אפשרות זו קיימת מגרסא 1.0.1 ומעלה.
+
+- `index`: שמות העמודות שערכיהם צריכות להיות משומשות כמפתחות למערך המאחסן את האובייקטים המקושרים. ללא הגדרת אפשרות זו, אובייקט מקושר ישתמש במפתחות מספריים מ-0 למערך של האובייקטים המקושרים. אפשרות זו ניתנת להגדרה רק על קישורים מסוג `HAS_MANY` ו `MANY_MANY`. אפשרות זו קיימת מגרסא 1.0.7 ומעלה.
+
+בנוסף, האפשרויות הבאות קיימות גם כן לקישורים מסויימים במהלך טעינה עצלה:
+
+- `limit`: הגבלת מספר השורות לבחירה. אפשרות זו לא תקפה לקישור מסוג `BELONGS_TO`.
+
+- `offset`: מאיזה שורה להתחיל לשלוף את הנתונים. אפשרות זו לא תקפה לקישור מסוג `BELONGS_TO`.
+
+למטה אנו עורכים את הגדרת הקישור של `posts` במחלקה של `User` על ידי הוספת כמה מהאפשרויות למעלה:
+
+~~~
+[php]
+class User extends CActiveRecord
+{
+ public function relations()
+ {
+ return array(
+ 'posts'=»array(self::HAS_MANY, 'Post', 'author_id',
+ 'order'=»'posts.create_time DESC',
+ 'with'=»'categories'),
+ 'profile'=»array(self::HAS_ONE, 'Profile', 'owner_id'),
+ );
+ }
+}
+~~~
+
+כעת, ברגע שניגש ל `author-»posts$`, אנו נקבל את ההודעות של המפרסם מסודרים לפי תאריך הפרסום שלהם בסדר יורד. כל אובייקט של הודעה מכיל גם את הקטגוריות טעונות בתוכו.
+
+שמות יחודיים לעמודות
+---------------------------
+
+כששם העמודות מופיע בשני טבלאות או יותר אשר מקושרות ביחד, יש צורך בלזהות אותם צבורה יחודית. זה נעשה על ידי מתן קידומת לעמודה עם השם המקוצר של הטבלה בה היא נמצאת.
+
+בשאילתת AR מקושרת, השם המקוצר לטבלה הראשית הינו מוגדר מראש בתור 't' בזמן ששם המקוצר לטבלה המקושרת כברירת מחדל הוא זהה לשמו של הקישור שהוגדר. לדוגמא, בביטוי הבא, השמות המקוצרים לטבלאות `Post` ו `Comment` הינו `t` ו `comments`, בהתאמה:
+
+~~~
+[php]
+$posts=Post::model()-»with('comments')-»findAll();
+~~~
+
+כעת, נניח שישנה עמודה בשם `create_time` בשני הטבלאות של `Post` ו `Comment` המייצג את הזמן פרסום ההודעה וזמן פרסום התגובה, ואנו נרצה לשלוף את ההודעות ביחד עם התגובות שלהם וסידור ההודעות על פי תאריך הפרסום שלהם קודם ולאחר מכן סידור התגובות על פי תאריך הפרסום שלהם. אנו נצטרך לתת שם יחודי לעמודה `create_time` בצורה הבאה:
+
+~~~
+[php]
+$posts=Post::model()-»with('comments')-»findAll(array(
+ 'order'=»'t.create_time, comments.create_time'
+));
+~~~
+
+» Note|הערה: ההתנהגות של שמות עמודות יחודיים השתנתה החל מגרסא 1.1.0. קודם לכן בגרסאות *.1.0, כברירת מחדל Yii אוטומטית יצרה שם מקוצר לכל טבלה מקושרת, ואנו היינו צריכים להשתמש בקידומת של `.??` כדי להתייחס לשם המקוצר שנוצר אוטומטית. בנוסף, בגרסאות *.1.0, השם המקוצר שם הטבלה הראשית הוא שם הטבלה עצמה.
+
+אפשרויות דינאמיות לשאילתות מקושרות
+--------------------------------
+
+החל מגרסא 1.0.2, אנו יכולים להשתמש באפשרויות דינאמיות לשאילתות מקושרות במתודה [with|CActiveRecord::with] וגם על ידי שימוש באפשרות `with`. האפשרויות הדינאמיות ידרוס את האפשרויות הקיימות שהוגדרו במתודה [relations|CActiveRecord::relations]. לדוגמא, בעזרת המודל `User` המצויין למעלה, במידה ואנו נרצה להשתמש בגישה של טעינה נלהבת כדי להחזיר את ההודעות השייכות למפרסם *בסדר עולה* (אפשרות ה `order` בהגדרות של הקישור מוגדרת בסדר יורד), אנו יכולים לבצע את הפעולה הבאה:
+
+~~~
+[php]
+User::model()-»with(array(
+ 'posts'=»array('order'=»'posts.create_time ASC'),
+ 'profile',
+))-»findAll();
+~~~
+
+החל מגרסא 1.0.5, אפשרויות דינאמיות של שאילתות מקושרות ניתנות לשימוש בעת שימוש בגישה של טעינה עצלה בכדי לבצע שאילתה מקושרת. בכדי לעשות זאת, אנו נקרא למתודה ששמה הוא זהה לשם של הקישור ונעביר את האפשרויות הדינאמיות למתודה כפרמטר. לדוגמא, הקוד הבא מחזיר את הודעות המשתמש שהסטטוס שלהם הוא 1, `status` שווה ל 1:
+
+~~~
+[php]
+$user=User::model()-»findByPk(1);
+$posts=$user-»posts(array('condition'=»'status=1'));
+~~~
+
+
+ביצועי שאילתה מקושרת
+----------------------------
+
+בפי שתארנו כבר למעלה, השימוש בטעינה נלהבת בעיקר הוא במקרה שאנו צריכים לגשת לאובייקטים מקושרים רבים. הוא יוצר שאילתת SQL גדולה ומורכבת על ידי חיבור כל הטבלאות המקושרות. שאילתת SQL גדולה עדיפה בהרבה מקרים מאחר והיא מפשטת את השינון בהתבסס על העמודות בטבלה מקושרת. למרות, שהיא לא כל כך יעילה במקרים מסויימים.
+
+נקח כדוגמא מקרה בו אנו צריכים למצוא את ההודעות האחרונות ביחד עם התגובות שלהם. בהנחה שלכל הודעה יש 10 תגובות, שימוש בשאילתת SQL אחת גדולה, יחזיר בחזרה הרבה מידע מיותר מאחר וכל הודעה תחזור על עצמה על כל תגובה שפורסמה בה. עכשיו ננסה גישה אחרת: קודם אנו מבצעים שאילתה לקבלת ההודעות האחרונות, ולאחר מכן אנו מכן שאילתה לקבלת התגובות בתוכה. בגישה חדשה זו, אנו צריכים לבצע שני שאילתות. היתרון הוא שאנו לא מקבלים מידע מיותר בתוצאות השאילתה.
+
+אז איזה גישה יותר יעילה? אין תשובה מוחלטת. הרצת שאילתה אחת גדולה יכול להיות יותר יעיל מאחר והיא צורכת פחות משאבים ב DBMS על מנת לנתח ולהריץ את שאילתת ה SQL. מצד שני, שימוש בשאילתת SQL אחת, אנו מקבלים בסופו של דבר הרבה תוכן מיותר שדורש יותר זמן בקריאה ועיבוד שלו.
+
+מסיבה זו, Yii מספקת את האפשרות של `together` בשאילתות כדי שנוכל לבחור בין הגישות השונות לפי הצורך. כברירת מחדל, Yii מאמצת את הגישה הראשונה, כלומר, ביצוע שאילתה אחת גדולה בכדי לבצע טעינה נלהבת. אנו יכולים להגדיר את האפשרות של `together` לערך false בהגדרות של הקישור בכדי שכמה טבלאות יאוחדו בשאילתה נפרדת. לדוגמא, בכדי להשתמש בגישה השנייה כדי לבצע שאילתה שתחזיר את ההודעות האחרונות ביחד עם התגובות שלהם, אנו יכולים להגדיר את הקישור של `comments` במחלקה של `Post` בצורה הבאה,
+
+~~~
+[php]
+public function relations()
+{
+ return array(
+ 'comments' =» array(self::HAS_MANY, 'Comment', 'post_id', 'together'=»false),
+ );
+}
+~~~
+
+כמו כן אנו יכולים להגדיר אפשרות זו בצורה דינאמית בזמן שאנו מבצעים את הטעינה הנלהבת:
+
+~~~
+[php]
+$posts = Post::model()-»with(array('comments'=»array('together'=»false)))-»findAll();
+~~~
+
+» Note|הערה: בגרסאות 1.0, התנהגות ברירת המחדל של Yii תייצר ותריץ `N+1` שאילתות SQL אם ישנם `N` , שאילתות מקושרות מסוג `HAS_MANY` או `MANY_MANY`. כל קישור מסוג `HAS_MANY` או `MANY_MANY` מריץ שאילתה נפרדת. על ידי קריאה למתודה `()together` אחרי `()with`, אנו יכולים לאלץ יצירה והרצה של שאילתת SQL אחת בלבד. לדוגמא,
+» ~~~
+» [php]
+» $posts=Post::model()-»with(
+» 'author.profile',
+» 'author.posts',
+» 'categories')-»together()-»findAll();
+» ~~~
+
+
+שאילתות סטטיסטיות
+-----------------
+
+» Note|הערה: שאילתות סטטיסטיות נתמכות מגרסאות 1.0.4 ומעלה.
+
+מלבד השאילתות המקושרות המתוארות למעלה, Yii תומכת במה שנקרא שאילתות סטטיסטיות (או שאילתות מצטברות). זה מתייחס לקבלת המידע המצטבר בנוגע לאובייקט המקושר, כמו מספר התגובות לכל הודעה, ממוצע דירוג לכל מוצר, וכדומה. שאילתות סטטיסטיות ניתנות לביצוע על אובייקטים המקושרים בעזרת `HAS_MANY` (לדוגמא, הודעה מכילה הרבה תגובות) או `MANY_MANY` (לדוגמא, הודעה שייכת לכמה קטגוריות וקטגוריה מכילה כמה הודעות).
+
+ביצוע שאילתות סטטיסטיות דומה מאוד לביצוע שאילתה מקושרת כפי שתארנו קודם לכן. ראשית עלינו להגדיר את השאילתה הסטטיסטית במתודה [()relations|CActiveRecord::relations] של המחלקה [CActiveRecord] כפי שאנו עושים בשאילתות מקושרות.
+
+~~~
+[php]
+class Post extends CActiveRecord
+{
+ public function relations()
+ {
+ return array(
+ 'commentCount'=»array(self::STAT, 'Comment', 'post_id'),
+ 'categoryCount'=»array(self::STAT, 'Category', 'post_category(post_id, category_id)'),
+ );
+ }
+}
+~~~
+
+בדוגמא למעלה, אנו מגדירים שני שאילתות סטטיסטיות: `commentCount` המחשב את מספר התגובות השייכות להודעה, ו `categoryCount` המחשב את מספר הקטגוריות שהודעה שייכת אליו. זכור שהקישור בין `Post` ו `Comment` הוא `HAS_MANY`, בזמן שהקישור בין `Post` לבין `Category` הוא `MANY_MANY` (עם הטבלה המאחדת `post_category`). כפי שניתן לראות, ההגדרה דומה מאוד לזו של הקישורים שהסברנו לגביהם בחלקים הקודמים. ההבדל היחידי במקרה הזה הוא שסוג הקישור הינו `STAT`.
+
+בעזרת ההגדרה למעלה, אנו יכולים לקבל את מספר התגובות לכל הודעה בעזרת הביטוי הבא `post-»commentCount$`. כשניגש למאפיין זה בפעם הראשונה, תתבצע שאילתת SQL במיוחד לקבלת הנתון הזה. כפי שאנו כבר יודעים, גישה זו נקראת *טעינה עצלה*. אנו יכולים להשתמש *בטעינה נלהבת* במידה ואנו רוצים לדעת את כמות התגובות לכמה הודעות:
+
+~~~
+[php]
+$posts=Post::model()-»with('commentCount', 'categoryCount')-»findAll();
+~~~
+
+הקוד למעלה יבצע 3 שאילתות בכדי לקבל את כל ההודעות ביחד עם מספר התגובות שלהם ומספר הקטגוריות. שימוש בגישה של טעינה עצלה, אנו נבצע `1+N*2` שאילתות SQL אם ישנם `N` הודעות.
+
+כברירת מחדל, שאילתה סטטיסטית תבצע את הביטוי `COUNT` (ולכן תתקבל מספר התגובות ומספר הקטגוריות בדוגמא למעלה). אנו יכולים לשנות זאת על ידי הגדרת אפשרויות נוספות בזמן שאנו מצהירים זאת במתודה [()relations|CActiveRecord::relations]. האפשרויות הזמינות מסוכמות למטה.
+
+- `select` : הביטוי הסטטיסטי. כברירת מחדל הוא מוגדר כ `COUNT(*)`, האומר ספירה של תתי אובייקטים.
+
+- `defaultValue` : הערך שיש להגדיר לרשומות שלא מקבלות תוצאה מהשאילתה.
+
+- `condition`: סעיף ה `WHERE`. ברירת מחדל הוא ריק.
+
+- `params`: הפרמטרים שצריכים להתחם לשאילתת ה SQL. יש להגדיר אפשרות זו כמערך של מפתחות וערכים.
+
+- `order` : סעיף ה `ORDER BY`. כברירת מחדל הוא ריק.
+
+- `group`: סעיף ה `GROUP BY`. כברירת מחדל הוא ריק.
+
+- `having`: סעיף ה `HAVING`. כברירת מחדל הוא ריק.
+
+
+שאילתות מקושרות עם מרחבים מוגדרים
+----------------------------------
+
+» Note|הערה: תמיכה במרחבים מוגדרים קיימת החל מגרסאות 1.0.5 ומעלה.
+
+שאילתה מקושרת ניתנת לביצוע גם בצירוף של [מרחבים מוגדרים](/doc/guide/database.ar#named-scopes). היא מגיעה בשני מצבים. במצב הראשון, מרחבים מוגדרים מצורפים למודל הראשי. במצב השני, מרחבים מוגדרים מצורפים למודלים המקושרים.
+
+הקוד הבא מציג כיצד לצרף מרחב מוגדר למודל הראשי.
+
+~~~
+[php]
+$posts=Post::model()-»published()-»recently()-»with('comments')-»findAll();
+~~~
+
+זה דומה מאוד לשאילתות לא מקושרות. ההבדל היחידי הוא שישנו קריאה למתודה `()with` מיד לאחר השרשור של המרחב המוגדר. השאילתה למעלה תחזיר את ההודעות שפורסמו לאחרונה ביחד עם התגובות שלהם.
+
+והקוד הבא מציג כיצד לצרף מרחב מוגדר למודל מקושר.
+
+~~~
+[php]
+$posts=Post::model()-»with('comments:recently:approved')-»findAll();
+~~~
+
+השאילתה למעלה תחזיר את כל ההודעות ביחד עם התוגובת שאושרו. זכור ש `comments` מתייחס לשם הקישור, בזמן ש `recently` ו `approved` מתייחס למרחב מוגדר שקיים במחלקת המודל של `Comment`. שם הקישור והמרחבים המוגדרים צריכים להיות מופרדים בעזרת נקודותיים ( : ).
+
+ניתן לצרף מרחבים מוגדרים גם באפשרות של `with` בהגדרת הקישור במתודה [CActiveRecord::relations()]. בדוגמא הבאה, ברגע שאנו ניגשים למאפיין `user-»posts$`, הוא מחזיר את כל התגובות *המאושרות* של ההודעות.
+
+~~~
+[php]
+class User extends CActiveRecord
+{
+ public function relations()
+ {
+ return array(
+ 'posts'=»array(self::HAS_MANY, 'Post', 'author_id',
+ 'with'=»'comments:approved'),
+ );
+ }
+}
+~~~
+
+» Note|הערה: מרחבים מוגדרים המצורפים למודלים מקושרים צריכים להיות מוגדרים ב [CActiveRecord::scopes]. כתוצאה מכך לא ניתן להגדיר להם פרמטרים.
+
+«div class="revision"»$Id: database.arr.txt 2069 2010-01-08 05:08:29Z qiang.xue $«/div»
View
195 docs/guide/he/database.dao.txt
</
@@ -0,0 +1,195 @@
+Data Access Objects (DAO)
+=========================
+
+ה DAO מספק גישת API כללית למידע המאוחסן בסוגי מסדים שונים (DBMS). כתוצאה מכך, ה DBMS היושב מתחת ניתן לשינוי לאחד אחר ללא צורך בשינוי הקוד המשתמש ב DAO בכדי לגשת למידע.
+
+ה DAO של Yii בנוי על בסיס התוסף של PHP בשם (PDO)](http://php.net/manual/en/book.pdo.php) המספק אפשרויות אחידות לגישה למסדי DBMS נפוצים, כמו MySQL, PostgreSQL. לכן, בכדי להשתמש ב DAO של Yii יש צורך בלהתקין ולהפעיל את התוסף של PDO בשרת, וכמו כן להפעיל את התוספים הספציפים למסד הנתונים בו יהיה שימוש (לדוגמא `PDO_MYSQL`).
+
+ה DAO של Yii בנוי ברובו על בסיס ארבעת המחלקות הבאות:
+
+ - [CDbConnection]: מייצג התחברות למסד נתונים.
+ - [CDbCommand]: מייצג שאילתת SQL שצריך להריץ מול מסד נתונים.
+ - [CDbDataReader]: מייצג תוצאות שאילתת SQL מול מסד נתונים.
+ - [CDbTransaction]: מייצג טרנזקציה.
+
+בחלק זה, אנו נציג כיצד להשתמש ב DAO במקרים שונים.
+
+יצירת התחברות למסד הנתונים
+--------------------------------
+
+בכדי ליצר התחברות למסד הנתונים, יש ליצור אובייקט של [CDbConnection] ולהפעיל אותו. יש להגדיר DSN שמהווה בעצם הסטרינג המכיל את המידע הדרוש להתחברות למסד נתונים. כמו כן יהיה צורך בהגדרת שם משתמש וסיסמא להתחברות למסד הנתונים. תזרק שגיאה במידה ותיהיה בעיה בזמן ניסיון החיבור למסד הנתונים (במידה וה DSN לא תקין או שם משתמש וסיסמא לא נכונים).
+
+~~~
+[php]
+$connection=new CDbConnection($dsn,$username,$password);
+// יצירת התחברות רצוי לתחום את זה ב try ... catch
+$connection-»active=true;
+......
+$connection-»active=false; // סגירת התחברות
+~~~
+
+הפורמט של ה DSN תלוי בדרייבר של מסד הנתונים ב PDO שמשתמשים בו. בכללי, DSN מכיל את שם הדרייבר ב PDO, לאחריו נקודותיים ( : ), ולאחריו תחביר ההתחברות המדוייק לכל דרייבר. יש לעיין [דוקומנטציה](http://www.php.net/manual/en/pdo.construct.php) למידע מלא. למטה רשימה של DNS נפוצים:
+
+- SQLite: `sqlite:/path/to/dbfile`
+- MySQL: `mysql:host=localhost;dbname=testdb`
+- PostgreSQL: `pgsql:host=localhost;port=5432;dbname=testdb`
+- SQL Server: `mssql:host=localhost;dbname=testdb`
+- Oracle: `oci:dbname=//localhost:1521/testdb`
+
+מאחר ו [CDbConnection] יורשת מהמחלקה [CApplicationComponent], ניתן להשתמש בו גם [כרכיב](/doc/guide/basics.application#application-component). בכדי לעשות זאת, יש להגדיר רכיב [בהגדרות האפליקציה](/doc/guide/basics.application#application-configuration) בשם `db` (או כל שם אחר) בצורה הבאה,
+
+~~~
+[php]
+array(
+ ......
+ 'components'=»array(
+ ......
+ 'db'=»array(
+ 'class'=»'CDbConnection',
+ 'connectionString'=»'mysql:host=localhost;dbname=testdb',
+ 'username'=»'root',
+ 'password'=»'password',
+ 'emulatePrepare'=»true, // יש צורך בהגדרה זו להתקנות MySQL מסויימות
+ ),
+ ),
+)
+~~~
+
+לאחר מכן אנו נוכל לגשת לחיבור ה DB בעזרת `Yii::app()-»db` שכבר הופעלה בצורה אוטומטית. אלה אם כן אנו נגדיר באופן ספציפי את המאפיין [CDbConnection::autoConnect] ל false. שימוש בגישה זו, ההתחברות הזו ניתנת לשימוש במקומות שונים בקוד.
+
+הרצת שאילתות SQL
+------------------------
+
+לאחר יצירת התחברות למסד הנתונים, ניתן להריץ שאילתות SQL על ידי שימוש ב [CDbCommand]. ניתן לייצר אובייקט של [CDbCommand] על ידי קריאה ל [()CDbConnection::createCommand] עם השאילתה הבאה:
+
+~~~
+[php]
+$command=$connection-»createCommand($sql);
+// במידה וצריך ניתן לעדכן את שאילתת ה SQL בצורה הבאה:
+// $command-»text=$newSQL;
+~~~
+
+שאילתת SQL מתבצעת בעזרת [CDbCommand] באחת מהדרכים הבאות:
+
+- [()execute|CDbCommand::execute]: מבצעת שאילתת SQL אשר לא מחזירה מידע לקריאה, כמו `INSERT`, `UPDATE`, `DELETE`. במידה והיא בוצעה בהצלחה היא תחזיר את מספר השורות שעודכנו.
+
+- [()query|CDbCommand::query]: מבצעת שאילתת SQL אשר מחזירה שורות של מידע, כמו `SELECT`. במידה והיא בוצעה בהצלחה, היא מחזירה אובייקט של [CDbDataReader] שבעזרתו ניתן יהיה לרוץ עליו לקבלת המידע שורה שורה. לנוחות, ישנם סט של מתודות `()queryXXX` אשר כלולות שבעזרתם ניתן לקבל את התוצאה ישירות.
+
+תזרק שגיאה במידה והייתה בעיה בהרצת השאילתה.
+
+~~~
+[php]
+$rowCount=$command-»execute(); // ביצוע שאילתה שלא מחזירה מידע לקריאה
+$dataReader=$command-»query(); // הרצת שאילתת SQL
+$rows=$command-»queryAll(); // הרצת שאילתה והחזרת כל השורות של התוצאה
+$row=$command-»queryRow(); // הרצת שאילתה והחזרת השורה הראשונה בתוצאה
+$column=$command-»queryColumn(); // הרצת שאילתה והחזרה העמודה הראשונה של התוצאה
+$value=$command-»queryScalar(); // הרצת שאילתה והחזרת העמודה הראשונה בשורה הראשונה
+~~~
+
+שליפת תוצאות שאילתה
+----------------------
+
+לאחר שהמתודה [()CDbCommand::query] יוצרת את האובייקט של [CDbDataReader], ניתן לקבל את השורות מהמידע שהוחזר על ידי קריאה ל [()CDbDataReader::read] שוב ושוב. ניתן גם להשתמש ב [CDbDataReader] בתוך לולאה `foreach` של PHP בכדי לקבל שורה אחרי שורה.
+
+~~~
+[php]
+$dataReader=$command-»query();
+// קריאה ל read שוב ושוב עד שהוא מחזיר false
+while(($row=$dataReader-»read())!==false) { ... }
+// שימוש בלולאה על כל התוצאות
+foreach($dataReader as $row) { ... }
+// קבלת כל התוצאות במכה אחת כמערך
+$rows=$dataReader-»readAll();
+~~~
+
+» Note|הערה: בניגוד ל [()query|CDbCommand::query], כל המתודות של `queryXXX` מחזירות מידע בצורה ישירה. לדוגמא, [()queryRow|CDbCommand::queryRow] מחזירה מערך המייצג את השורה הראשונה של תוצאת השאילתה.
+
+שימוש בטרנזקציות
+------------------
+
+כשאפליקציה מריצה כמה שאילתות, כל אחת קוראת ו/או כותבת מידע למסד הנתונים, חשוב לדעת ולהיות בטוחים שהמסד נתונים מבצע ומריץ את כל השאילתות ולא מפספס אף אחת. טרנזקציה, המיוצגת כאובייקט של [CDbTransaction] ב Yii , ניתנת לשימוש במקרה כזה:
+
+- התחלת הטרנזקציה.
+- הרצת השאילתות אחת אחרי השנייה. כל העדכונים למסד לא מוצגים לעולם החיצון.
+- ביצוע הטרנזקציה. כעת ניתן לראות את העדכונים במידה והטרנזקציה הסתיימה בהצלחה.
+- במידה ואחת מהשאילתות נכשלת בזמן הרצה, כל הטרנזקציה חוזרת אחורה.
+
+רצף העבודה המוצג למעלה ניתן ליישום בעזרת הקוד הבא:
+
+~~~
+[php]
+$transaction=$connection-»beginTransaction();
+try
+{
+ $connection-»createCommand($sql1)-»execute();
+ $connection-»createCommand($sql2)-»execute();
+ //.... other SQL executions
+ $transaction-»commit();
+}
+catch(Exception $e) // תתבצע שגיאה במידה וישנה בעיה
+{
+ $transaction-»rollBack();