Skip to content
Browse files

merge from yiidoc.

  • Loading branch information...
1 parent 9428094 commit 871212032fc1a076d31dd9951d1787327998c2b9 qiang.xue committed
Showing with 3,726 additions and 2,008 deletions.
  1. +1 −1 docs/blog/pl/post.admin.txt
  2. +1 −1 docs/blog/pl/start.design.txt
  3. +2 −2 docs/blog/ru/final.deployment.txt
  4. +1 −1 docs/blog/ru/final.logging.txt
  5. +3 −3 docs/blog/ru/post.admin.txt
  6. +1 −1 docs/blog/zh_cn/post.admin.txt
  7. +2 −2 docs/guide/de/basics.application.txt
  8. +1 −1 docs/guide/de/basics.component.txt
  9. +88 −1 docs/guide/de/basics.controller.txt
  10. +1 −1 docs/guide/de/basics.convention.txt
  11. +12 −8 docs/guide/de/basics.module.txt
  12. +72 −24 docs/guide/de/basics.namespace.txt
  13. +1 −1 docs/guide/de/basics.view.txt
  14. +6 −4 docs/guide/de/basics.workflow.txt
  15. +13 −1 docs/guide/de/changes.txt
  16. +2 −2 docs/guide/de/database.arr.txt
  17. +1 −1 docs/guide/de/form.action.txt
  18. +43 −6 docs/guide/de/form.builder.txt
  19. +5 −5 docs/guide/de/quickstart.first-app.txt
  20. +1 −1 docs/guide/de/toc.txt
  21. +268 −199 docs/guide/de/topics.auth.txt
  22. +139 −52 docs/guide/de/topics.console.txt
  23. +3 −2 docs/guide/de/topics.i18n.txt
  24. +2 −2 docs/guide/de/topics.performance.txt
  25. +1 −1 docs/guide/de/topics.security.txt
  26. +34 −4 docs/guide/de/topics.theming.txt
  27. +49 −49 docs/guide/id/basics.application.txt
  28. +58 −44 docs/guide/id/basics.component.txt
  29. +125 −43 docs/guide/id/basics.controller.txt
  30. +67 −49 docs/guide/id/basics.convention.txt
  31. +13 −13 docs/guide/id/basics.entry.txt
  32. +1 −1 docs/guide/id/basics.model.txt
  33. +15 −21 docs/guide/id/basics.module.txt
  34. +16 −16 docs/guide/id/basics.mvc.txt
  35. +80 −21 docs/guide/id/basics.namespace.txt
  36. +40 −38 docs/guide/id/basics.view.txt
  37. +13 −12 docs/guide/id/basics.workflow.txt
  38. +40 −40 docs/guide/id/caching.data.txt
  39. +15 −15 docs/guide/id/caching.dynamic.txt
  40. +57 −58 docs/guide/id/caching.fragment.txt
  41. +44 −45 docs/guide/id/caching.overview.txt
  42. +21 −21 docs/guide/id/caching.page.txt
  43. +69 −1 docs/guide/id/changes.txt
  44. +129 −107 docs/guide/id/database.ar.txt
  45. +241 −181 docs/guide/id/database.arr.txt
  46. +44 −19 docs/guide/id/database.dao.txt
  47. +41 −41 docs/guide/id/extension.create.txt
  48. +7 −7 docs/guide/id/extension.integration.txt
  49. +9 −9 docs/guide/id/extension.overview.txt
  50. +39 −17 docs/guide/id/extension.use.txt
  51. +16 −16 docs/guide/id/form.action.txt
  52. +143 −94 docs/guide/id/form.model.txt
  53. +1 −1 docs/guide/id/form.overview.txt
  54. +15 −15 docs/guide/id/form.table.txt
  55. +60 −23 docs/guide/id/form.view.txt
  56. +3 −3 docs/guide/id/index.txt
  57. +89 −105 docs/guide/id/quickstart.first-app.txt
  58. +7 −8 docs/guide/id/quickstart.installation.txt
  59. +13 −14 docs/guide/id/quickstart.what-is-yii.txt
  60. +20 −10 docs/guide/id/toc.txt
  61. +123 −84 docs/guide/id/topics.auth.txt
  62. +138 −41 docs/guide/id/topics.console.txt
  63. +76 −26 docs/guide/id/topics.error.txt
  64. +52 −37 docs/guide/id/topics.i18n.txt
  65. +45 −48 docs/guide/id/topics.logging.txt
  66. +35 −35 docs/guide/id/topics.performance.txt
  67. +16 −5 docs/guide/id/topics.prado.txt
  68. +29 −29 docs/guide/id/topics.security.txt
  69. +232 −4 docs/guide/id/topics.theming.txt
  70. +75 −31 docs/guide/id/topics.url.txt
  71. +13 −13 docs/guide/id/topics.webservice.txt
  72. +1 −1 docs/guide/pl/basics.application.txt
  73. +24 −1 docs/guide/pl/basics.controller.txt
  74. +45 −12 docs/guide/pl/basics.namespace.txt
  75. +8 −1 docs/guide/pl/changes.txt
  76. +75 −30 docs/guide/pl/topics.auth.txt
  77. +148 −25 docs/guide/pl/topics.console.txt
  78. +3 −2 docs/guide/pl/topics.i18n.txt
  79. +1 −1 docs/guide/pl/topics.security.txt
  80. +21 −1 docs/guide/pl/topics.theming.txt
  81. +4 −4 docs/guide/ru/basics.application.txt
  82. +25 −2 docs/guide/ru/basics.controller.txt
  83. +71 −13 docs/guide/ru/basics.namespace.txt
  84. +2 −2 docs/guide/ru/basics.view.txt
  85. +4 −4 docs/guide/ru/basics.workflow.txt
  86. +9 −2 docs/guide/ru/changes.txt
  87. +1 −1 docs/guide/ru/extension.create.txt
  88. +5 −5 docs/guide/ru/extension.use.txt
  89. +20 −21 docs/guide/ru/form.action.txt
  90. +3 −3 docs/guide/ru/form.builder.txt
  91. +8 −5 docs/guide/ru/form.model.txt
  92. +2 −1 docs/guide/ru/quickstart.first-app.txt
  93. +1 −1 docs/guide/ru/test.functional.txt
  94. +1 −1 docs/guide/ru/test.overview.txt
  95. +106 −32 docs/guide/ru/topics.auth.txt
Sorry, we could not display the entire diff because it was too big.
View
2 docs/blog/pl/post.admin.txt
@@ -107,4 +107,4 @@ Powyższy kod jest bardzo prosty. Najpierw usuwane są wszystkie komentarze, kt
> Tip|Wskazówka: Musimy jawnie usunąć wszystkie komentarze dla usuniętej wiadomości, ponieważ SQLite nie wspiera ograniczeń klucza obcego. W silnikach bazy danych, które wpierają ograniczanie (takich jak MySQL, PostgreSQL), ograniczenie klucza obcego może zostać tak zdefiniowane, że silnik bazy danych automatycznie usunie powiązane komentarze w momencie usuwania wiadomości. W takim przypadku nie będziemy potrzebowali w naszym kodzie jawnego usuwania.
-<div class="revision">$Id: post.admin.txt 1810 2010-02-18 00:24:54Z qiang.xue $</div>
+<div class="revision">$Id: post.admin.txt 2425 2010-09-05 01:30:14Z qiang.xue $</div>
View
2 docs/blog/pl/start.design.txt
@@ -4,7 +4,7 @@ Ogólna koncepcja
W oparciu o analizę wymagań, zdecydowaliśmy się używać następujące bazy danych w celu przechowywania trwałych danych dla naszej aplikacji blogowej:
* Tabela `tbl_user` przechowuje informacje o użytkownikach, włączając w to ich nazwy oraz hasła.
- * Tabela `tbl_post` przechowuje informacje o postach w blogu. Składa się ona przede wszystkim z następujących kolumn:
+ * Tabela `tbl_post` przechowuje informacje o psotach w blogu. Składa się ona przede wszystkim z następujących kolumn:
- `title` (tytuł): wymagany, tytuł wiadomości;
- `content` (zawartość): wymagana, zawartość treści wiadomości, zapisana w [formacie Markdown](http://daringfireball.net/projects/markdown/syntax);
- `status` (status): wymagany, status wiadomości, który może przyjmować następujące wartości:
View
4 docs/blog/ru/final.deployment.txt
@@ -26,8 +26,8 @@ return array(
мы увидим результат, сгенерированный действием `index` контроллера записей.
-Включение кэширование схемы
------------------------
+Включение кэширования схемы
+---------------------------
ActiveRecord полагается на метаданные о таблицах для определения
информации о столбце, поэтому тратится время для чтения метаданных и их
View
2 docs/blog/ru/final.logging.txt
@@ -3,7 +3,7 @@
Рабочее веб-приложение часто нуждается в сложном журналировании различных
событий. В нашем приложении мы бы хотели журналировать появление ошибок,
-возникающих при в работе приложения. Это могут быть ошибки программирования или
+возникающих при работе приложения. Это могут быть ошибки программирования или
неправильной работы пользователей с системой. Журналирование этих ошибок
поможет нам улучшить наше приложение.
View
6 docs/blog/ru/post.admin.txt
@@ -28,7 +28,7 @@ public function actionAdmin()
}
~~~
-Данный код полностью сгенерирован `yiic`. Сначала создаётся модель `Post` с сценарием
+Данный код полностью сгенерирован `yiic`. Сначала создаётся модель `Post` со сценарием
`search` [scenario](/doc/guide/ru/form.model), которую мы будем использовать для
сбора критериев поиска, указанных пользователем. Далее мы присваиваем
данные, введённые пользователем, модели. И, наконец, мы выводим отображение
@@ -71,7 +71,7 @@ $this->breadcrumbs=array(
)); ?>
~~~
-Для вывода записей мы используем компонент [CGridView], который позволяет
+Для вывода записей мы используем компонент [CGridView], который
разбивает данные на страницы и позволяет их сортировать по столбцам.
Наше изменение касается, главным образом, отображения каждого столбца.
К примеру, для столбца `title` мы указываем, что он должен содержать
@@ -137,4 +137,4 @@ protected function afterDelete()
> удаление комментариев в случае удаления записи. В этом случае нет необходимости
> удалять комментарии в коде.
-<div class="revision">$Id: post.admin.txt 1810 2010-02-18 00:24:54Z qiang.xue $</div>
+<div class="revision">$Id: post.admin.txt 2425 2010-09-05 01:30:14Z qiang.xue $</div>
View
2 docs/blog/zh_cn/post.admin.txt
@@ -22,7 +22,7 @@ public function actionAdmin()
}
~~~
-上面的代码由 `yiic` 工具生成,未作任何修改。它首先创建了一个 `search` [场景(scenario)](/doc/guide/form.model) 下的 `Post` 模型。我们将使用此模型收集用户指定的搜索条件。然后我们把用户可能会提供的数据赋值给模型。 最后,我们以此模型显示 `admin` 视图。
+上面的代码由 `yiic` 工具生成,且未作任何修改。它首先创建了一个 `search` [场景(scenario)](/doc/guide/form.model) 下的 `Post` 模型。我们将使用此模型收集用户指定的搜索条件。然后我们把用户可能会提供的数据赋值给模型。 最后,我们以此模型显示 `admin` 视图。
下面就是 `admin` 视图的代码:
View
4 docs/guide/de/basics.application.txt
@@ -67,7 +67,7 @@ Anwendungsverzeichnis
Im Anwendungsverzeichnis sind alle sicherheitsempfindlichen Dateien der
Applikation abgelegt. Per Voreinstellung ist dies der `protected`-Ordner
im Verzeichnis, das auch das Startscript enthält. Der Pfad zum
-Anwendungsverzeichnis kann in der Konfiguration über
+Anwendungsverzeichnis kann in der [Konfiguration](/doc/guide/basics.application#application-configuration) über
[basePath|CWebApplication::basePath] angepasst werden.
Sämtliche Inhalte in diesem Verzeichnis sollten vor Zugriff über das Web
@@ -228,4 +228,4 @@ Beim Bearbeiten eines Requests durchläuft eine Anwendung diesen Zyklus:
7. Auslösen des [onEndRequest|CApplication::onEndRequest]-Events
-<div class="revision">$Id: basics.application.txt 2311 2010-08-09 13:01:12Z alexander.makarow $</div>
+<div class="revision">$Id: basics.application.txt 2488 2010-09-20 11:38:02Z mdomba $</div>
View
2 docs/guide/de/basics.component.txt
@@ -196,4 +196,4 @@ Behavior zum Beispiel eine Eigenschaft namens `xyz` besitzt und an eine
Komponente `$a` angebunden wurde, kann mit `$a->xyz` darauf zugegriffen
werden.
-<div class="revision">$Id: basics.component.txt 2181 2010-06-14 20:01:23Z qiang.xue $</div>
+<div class="revision">$Id: basics.component.txt 2346 2010-08-28 13:12:27Z mdomba $</div>
View
89 docs/guide/de/basics.controller.txt
@@ -144,6 +144,93 @@ protected/
UpdateAction.php
~~~
+
+### Binden von Actionparametern
+
+Seit Version 1.1.4 unterstützt Yii das automatische Binden von
+Actionparametern. Das bedeutet, dass eine Controlleraction Parameter
+definieren kann, deren Werte automatisch entsprechend ihrem Namen aus
+`$_GET` befüllt werden.
+
+Nehmen wir zum besseren Verständnis an, ein `PostController` soll eine neue
+Action `create` bekommen, die folgende zwei Parameter benötigt:
+
+* `category`: Eine Integerzahl, die für die Kategorie-ID steht, unter der ein
+neuer Beitrag angelegt werden soll;
+* `language`: Eine Zeichenkette, die die Sprache des neuen Beitrags angibt.
+
+Eine mögliche, allerdings relativ langweilige Umsetzung könnte die benötigten
+`$_GET`-Parameter wie folgt auslesen:
+
+~~~
+[php]
+class PostController extends CController
+{
+ public function actionCreate()
+ {
+ if(isset($_GET['category']))
+ $category=(int)$_GET['category'];
+ else
+ throw new CHttpException(404,'invalid request');
+
+ if(isset($_GET['language']))
+ $language=$_GET['language'];
+ else
+ $language='en';
+
+ // ... fun code starts here ...
+ }
+}
+~~~
+
+Verwendet man stattdessen das Actionparameter-Feature, vereinfacht sich diese
+Aufgabe wie folgt:
+
+~~~
+[php]
+class PostController extends CController
+{
+ public function actionCreate($category, $language='en')
+ {
+ $category=(int)$category;
+
+ // ... fun code starts here ...
+ }
+}
+~~~
+
+Beachten Sie, dass die Actionmethode `actionCreate` jetzt zwei Aufrufparameter
+erhalten hat. Deren Name muss exakt mit den in `$_GET` erwarteten Parametern
+übereinstimmen. Für den `$language`-Parameter is außerdem der Vorgabewert `en`
+definiert. Er wird verwendet, wenn kein `language`-Wert in `$_GET` enthalten
+ist. Da für `$category` kein solcher Vorgabewert definiert wurde, wird
+automatisch eine [CHttpException] mit Fehlercode 400 geworfen, falls dieser
+Parameter nicht im Request übergeben wird.
+
+Seit Version 1.1.5 kann Yii auch automatisch Parameter vom Typ Array erkennen.
+Dazu verwendet man das Type Hinting Feature von PHP wie folgt:
+
+~~~
+[php]
+class PostController extends CController
+{
+ public function actionCreate(array $categories)
+ {
+ // Yii stellt sicher, dass $categories ein Array ist
+ }
+}
+~~~
+
+Man gibt also in der Funktionsdeklaration das Schlüsselwort `array` vor
+`$categories` an. Falls `$_GET['categories']` ein String ist, wird es
+automatisch in ein Array (mit diesem String als einzigem Element) umgewandelt.
+
+> Note|Hinweis: Falls ein Parameter ohne Angabe von `array` deklariert wurde,
+> *muss* ein Skalarwert (also kein Arrray!) übergeben werden. Ist der
+> Parameter in `$_GET` trotzdem ein Array, wird eine HTTP-Exception
+> geworfen.
+
+
Filter
------
@@ -235,4 +322,4 @@ Filter angewendet werden soll und auf welche nicht. Oben soll der Filter
weder Plus noch Minus in der Filterkonfiguration auftauchen, wird der Filter
auf alle Actions angewendet.
-<div class="revision">$Id: basics.controller.txt 1264 2009-07-21 19:34:55Z qiang.xue $</div>
+<div class="revision">$Id: basics.controller.txt 2576 2010-10-28 02:46:14Z qiang.xue $</div>
View
2 docs/guide/de/basics.convention.txt
@@ -163,4 +163,4 @@ nicht gemischt. Der Einfachheit halber empfehlen wir den Singular.
insbesondere nützlich, wenn sich mehrere Anwendungen eine Datenbank teilen
müssen.
-<div class="revision">$Id: basics.convention.txt 1768 2010-02-01 01:34:15Z qiang.xue $</div>
+<div class="revision">$Id: basics.convention.txt 2345 2010-08-28 12:51:08Z mdomba $</div>
View
20 docs/guide/de/basics.module.txt
@@ -128,11 +128,15 @@ Die entsprechende URL für diese Route wäre dann
Verschachtelte Module
---------------------
-Module können ineinander verschachtelt werden. Das bedeutet, dass ein Modul
-ein weiteres Modul enthalten kann. Wir nennen ersteres *Elternmodul*, letzeres
-*Kindmodul*. Kindmodule müssen im `modules`-Verzeichnis des Elternmoduls
-abgelegt werden. Um eine Controller-Action in einem Kindmodul aufzurufen,
-sollte man die Route `elternModulID/kindModulID/controllerID/actionID`
-verwenden.
-
-<div class="revision">$Id: basics.module.txt 2041 2010-04-11 03:54:25Z qiang.xue $</div>
+Module können in unbegrenzter Tiefe ineinander verschachtelt werden. Das bedeutet,
+dass ein Modul ein weiteres Modul enthalten kann, welches wiederum ein anderes
+Modul beherbergt. Wir nennen ersteres *Elternmodul*, letzeres
+*Kindmodul*. Kindmodule müssen in der
+[modules|CWebModule::modules]-Eigenschaft des jeweiligen Elternmoduls
+angebeben werden und zwar genauso wie in der Anwendungskonfiguration
+(siehe oben).
+Um eine Controller-Action in einem Kindmodul aufzurufen,
+wird die Route `elternModulID/kindModulID/controllerID/actionID`
+verwendet.
+
+<div class="revision">$Id: basics.module.txt 2363 2010-08-29 02:35:15Z qiang.xue $</div>
View
96 docs/guide/de/basics.namespace.txt
@@ -10,31 +10,33 @@ RootAlias.pfad.zu.ziel
~~~
wobei `RootAlias` für den Alias eines existierenden Verzeichnisses steht.
-Durch Aufrufen von [YiiBase::setPathOfAlias()] kann man neue Pfadaliase
-definieren. Folgende Rootaliase stehen bequemerweise schon bereit:
+
+Mit [YiiBase::getPathOfAlias()] erhält man den aufgelösten Pfad zu einem
+Alias. `system.web.CController` würde zum Beispiel nach
+`yii/framework/web/CController` übersetzt werden.
+
+Über [YiiBase::setPathOfAlias()] kann man auch neue Rootaliase definieren.
+
+Rootaliase
+----------
+
+Die folgenden praktischen Rootaliase werden von Yii schon vorbelegt:
- `system`: Verweist auf das Frameworkverzeichnis von Yii
- - `zii`: Verweist auf das Verzeichnis der
-[Zii-Bibliothek](/doc/guide/extension.use#zii-extensions).
- - `application`: Verweist auf das
-[Anwendungsverzeichnis](/doc/guide/basics.application#application-base-directory)
- - `webroot`: Steht für das Verzeichnis, das das
-[Startscript](/doc/guide/basics.entry) enthält. Dieser Alias ist seit
-Version 1.0.3 verfügbar.
- - `ext`: Verweist auf das Verzeichnis, das alle
-[Erweiterungen](/doc/guide/extension.overview) enthält. Dieser Alias steht
-seit Version 1.0.8 zur Verfügung.
+ - `zii`: Verweist auf das Verzeichnis der [Zii-Bibliothek](/doc/guide/extension.use#zii-extensions).
+ - `application`: Verweist auf das [Anwendungsverzeichnis](/doc/guide/basics.application#application-base-directory)
+ - `webroot`: Steht für das Verzeichnis, das das [Startscript](/doc/guide/basics.entry) enthält. Dieser Alias ist seit Version 1.0.3 verfügbar.
+ - `ext`: Verweist auf das Verzeichnis, das alle [Erweiterungen](/doc/guide/extension.overview) enthält. Dieser Alias steht seit Version 1.0.8 zur Verfügung.
Falls die Anwendung [Module](/doc/guide/basics.module) verwendet, wird für
jedes Modulstammverzeichnis ein zusätzlicher RootAlias in Form der ModulID
angelegt. Dieses Feature steht seit Version 1.0.3 zur Verfügung.
-Mit [YiiBase::getPathOfAlias()] erhält man den aufgelösten Pfad zu einem
-Alias. `system.web.CController` würde zum Beispiel nach
-`yii/framework/web/CController` übersetzt werden.
+Importieren von Klassen
+-----------------------
-Mit Aliasen können Klassen sehr bequem importiert werden. Möchte man zum
-Beispiel den Quelltext für [CController] importieren,
+Über Aliase kann man auch sehr bequem eine Klassendatei einbinden.
+Möchte man zum Beispiel den Quelltext für [CController] importieren,
genügt dieser Aufruf:
~~~
@@ -44,13 +46,37 @@ Yii::import('system.web.CController');
Die [import|YiiBase::import]-Methode ist wesentlich effizienter als `include` und
`require`. Eine importierte Klassendatei wird erst eingebunden, wenn die
-entsprechende Klasse zum ersten mal verwendet wird. Auch wenn ein Namespace
+entsprechende Klasse zum ersten mal verwendet wird (das geschieht über den
+PHP-Autoloader-Mechanismus). Auch wenn ein Namespace
mehrfach importiert wird, ist das wesentlich schneller als `include_once` oder
`require_once` zu verwenden.
> Tip|Tipp: Klassen aus dem Yii-Framework braucht man nicht zu importieren
> oder mit include einzubinden. Alle Kernklassen von Yii sind bereits importiert.
+###Verwenden einer Classmap
+
+Seit Version 1.1.5 kann Yii Anwenderklassen auch
+vorimportieren. Diesen Mechanismus verwendet Yii bereits intern
+für seine Kernklassen. Vorimportierte Klassen können überall in einer
+Anwendung ohne expliziten Import oder Include verwendet werden. Das ist
+insbesondere für Frameworks oder Libraries nützlich, die auf Yii aufbauen.
+
+Um eine Reihe von Klassen vorzuimportieren muss folgender Code vor
+[CWebApplication::run()] ausgeführt werden:
+
+~~~
+[php]
+Yii::$classMap=array(
+ 'KlassenName1' => 'pfad/zu/KlassenName1.php',
+ 'KlassenName2' => 'pfad/zu/KlassenName2.php',
+ ......
+);
+~~~
+
+Importieren von Verzeichnissen
+------------------------------
+
Um ein komplettes Verzeichnis zu importieren, kann man folgende Syntax
verwenden. Die darin enthaltenen Klassendateien werden dann bei Bedarf
automatisch eingebunden.
@@ -66,11 +92,14 @@ Beispiel auch ein Alias übergeben werden, um eine Instanz der entsprechenden
Klasse zu erzeugen, auch wenn die Klassendatei vorher noch nicht eingebunden
war.
-Verwechseln Sie einen Pfadalias bitte nicht mit einem Namespace. Ein Namespace
-bezieht sich auf eine logische Gruppe von Klassen, um sie von anderen
-Klassennamen zu unterscheiden, selbst sie genauso heißen. Ein
-Pfadalias hingegen bezieht sich auf eine Klassendatei oder ein Verzeichnis.
-Ein Pfadalias kollidiert nicht mit einem Namespace.
+Namespace
+---------
+
+Ein Namespace bezieht sich auf eine logisch zusammengehörige Gruppe von
+Klassen, um sie von anderen Klassen zu unterscheiden, selbst wenn diese den
+selben Namen haben. Verwechseln Sie Namespaces bitte nicht mit Pfadaliasen.
+Ein Pfadalias ist eher eine praktische Abkürzung für eine Datei oder ein
+Verzeichnis. Er hat mit einem Namespace nichts zu tun.
> Tip|Tipp: Da PHP vor Version 5.3.0 von Haus aus noch keine Namespaces
> unterstützt, können Sie keine Instanzen von unterschiedlichen Klassen mit
@@ -80,4 +109,23 @@ Ein Pfadalias kollidiert nicht mit einem Namespace.
> 'C' für das Yii-Framework zu reservieren und eigene Klassen mit
> anderen Präfixen zu versehen.
-<div class="revision">$Id: basics.namespace.txt 1602 2009-12-18 19:33:34Z qiang.xue $</div>
+
+Klassen mit Namespace
+---------------------
+
+Eine Klasse mit Namespace bezeichnet eine Klasse, die innerhalb eines
+nichtglobalen Namespaces definiert wurde. Die Klasse `application\components\GoogleMap`
+wurde z.B. im Namespace `application\components` definiert. Namespaces setzen
+PHP 5.3.0 oder höher voraus.
+
+Ab Version 1.1.5 können Klassen aus Namespaces ohne expliziten Import
+verwendet werden. Man kann z.B. `application\components\GoogleMap` verwenden,
+ohne die zugehörige Klassendatei vorher explizit einzubinden. Dies wird durch
+durch einen verbesserten Autoloading-Mechanismus von Yii ermöglicht.
+
+Um Klassen mit Namespace automatisch einzubinden, muss der Namespace ähnlich
+wie ein Pfadalias benannt sein. Die Klasse `application\components\GoogleMap`
+muss zum Beispiel an dem Ort gespeichert werden, der dem Pfadalias
+`application.components.GoogleMap` entspricht.
+
+<div class="revision">$Id: basics.namespace.txt 2630 2010-11-08 21:13:33Z qiang.xue $</div>
View
2 docs/guide/de/basics.view.txt
@@ -147,4 +147,4 @@ Yii stellt eine Reihe von Vorgabe-Systemviews bereit, die unter
`framework/views` zu finden sind. Man kann sie leicht anpassen, indem
man gleichnamige Viewdateien in `protected/views/system` anlegt.
-<div class="revision">$Id: basics.view.txt 1809 2010-02-17 22:08:34Z qiang.xue $</div>
+<div class="revision">$Id: basics.view.txt 2367 2010-08-29 17:29:22Z qiang.xue $</div>
View
10 docs/guide/de/basics.workflow.txt
@@ -17,9 +17,11 @@ einige Anwendungskomponenten (z.B. die "user component", die Benutzerkomponente)
angelegt werden.
3. Erstellen der jeweiligen [Model](/doc/guide/basics.model)-Klassen für
-alle vorkommenden Daten. Auch hier kann `yiic` verwendet werden, um
-automatisch [ActiveRecord](/doc/guide/database.ar)-Klassen für alle beteiligten
-Datenbanktabellen zu generieren.
+alle vorkommenden Daten. Die [ActiveRecord](/doc/guide/database.ar)-Klassen
+für alle Datenbanktabellen können mit dem `Gii`-Werkzeug erstellt werden, das in den
+Kapiteln [Automatische Codegenerierung] und [Erstellen der ersten
+Yii-Anwendung](doc/guide/quickstart.first-app#implementing-crud-operations)
+beschrieben wird.
4. Erstellen der [Controller](/doc/guide/basics.controller)-Klassen
für zusammengehörende Anfragen. Wie die einzelnen Anfragen zu einem Controller
@@ -49,4 +51,4 @@ Onlinestellung.
Für jeden der obigen Schritte kann es nötig sein, "Test cases" (sinngem:
automatisierte Funktionstests) zu erstellen und durchzuführen.
-<div class="revision">$Id: basics.workflow.txt 1034 2009-05-19 21:33:55Z qiang.xue $</div>
+<div class="revision">$Id: basics.workflow.txt 2388 2010-08-30 22:56:26Z alexander.makarow $</div>
View
14 docs/guide/de/changes.txt
@@ -3,6 +3,18 @@ Neue Features
Diese Seite fasst die wesentlichen neuen Features jeder Yii-Version zusammen.
+Version 1.1.5
+-------------
+
+ * [Actions und Binden von Parametern in Konsolenbefehlen](/doc/guide/topics.console)
+ * [Autoload-Unterstützung von Klassen mit Namespace](/doc/guide/basics.namespace)
+ * [Unterstützung von Widget-Views in Themes](/doc/guide/topics.theming#theming-widget-views)
+
+Version 1.1.4
+-------------
+
+ * [Automatisches Binden von Actionparametern](/doc/guide/basics.controller#action-parameter-binding)
+
Version 1.1.3
-------------
@@ -123,4 +135,4 @@ Version 1.0.5
* [CUrlManager] unterstützt nun das Parametrisieren des Routenteils einer URL. Siehe:
- [Parametrisierte Routen in URL-Regeln](/doc/guide/topics.url#parameterizing-routes)
-<div class="revision">$Id: changes.txt 2217 2010-06-22 23:51:05Z qiang.xue $</div>
+<div class="revision">$Id: changes.txt 2633 2010-11-09 10:05:20Z haertl.mike $</div>
View
4 docs/guide/de/database.arr.txt
@@ -251,7 +251,7 @@ OUTER JOIN`.
Mit dem Standardwert `null` wird der Beziehungsname als Alias verwendet.
- `together`: Ob ein JOIN der verknüpften Tabelle mit der Haupt- bzw. anderen Tabellen
-erzwungen werden soll. Diese Option ist nur für HAS_MANY und MANY_MANY von Bedeutung.
+erzwungen werden soll. Diese Option ist nur für `HAS_MANY` und `MANY_MANY` von Bedeutung.
Setzt man diesen Wert auf `false`, wird eine separate SQL-Abfrage für die verknüpfte Tabelle
ausgeführt, wodurch die ganze Abfrage in manchen Fällen beschleunigt wird, da
weniger gleiche Daten pro Zeile übertragen werden müssen. Ist die Option `true`
@@ -580,4 +580,4 @@ class User extends CActiveRecord
verwendet werden, die in [CActiveRecord::scopes] definiert wurden. Man kann
daher keine parametrisierten Scopes verwenden.
-<div class="revision">$Id: database.arr.txt 2288 2010-07-30 00:36:04Z qiang.xue $</div>
+<div class="revision">$Id: database.arr.txt 2350 2010-08-28 18:57:21Z qiang.xue $</div>
View
2 docs/guide/de/form.action.txt
@@ -37,7 +37,7 @@ der Seite zu ermitteln, für die der Benutzer zunächst authentifiziert werden
musste. Die Komponente `Yii::app()->user` ist vom Typ [CWebUser] (oder einer
Kindklasse) und steht für Informationen der aktuellen Benutzersitzung
(z.B. Benutzername, Status). Weitere Einzelheiten dazu finden Sie unter
-[Authentifizierung und Berechtigungen](/doc/guide/topics.auth).
+[Authentifizierung und Autorisierung](/doc/guide/topics.auth).
Sehen wir uns die folgende Anweisung aus obigem Code genauer an:
View
49 docs/guide/de/form.builder.txt
@@ -152,12 +152,17 @@ verknüpft sein. Die Angaben für ein Element werden in Form einer
Damit wird festgelegt, dass das entsprechende Modelattribut `username` heißt
und das Eingabefeld vom Typ `text` mit einem `maxlength`-Attribut von 32
-sein soll. Es können auch noch weitere [CFormInputElement]-Optionen im Array
-angegeben werden. Mit der [hint|CFormInputElement::hint]-Option kann man zum
+sein soll.
+
+So kann jede beschreibbare Eigenschaft eines [CFormInputElement]s konfiguriert
+werden. Mit der [hint|CFormInputElement::hint]-Option kann man so zum
Beispiel einen Hilfstext angeben oder mit [items|CFormInputElement::items] die
Elemente in einer DropDown-, CheckBox- oder RadioButton-List bestimmen
-(entsprechend den Methoden in [CHtml]).
-
+(entsprechend den Methoden in [CHtml]). Handelt es sich bei einer Option nicht
+um den Namen einer [CFormInputElement]-Eigenschaft, wird sie als Attribut
+des entsprechenden HTML-Elements verwendet. Im obigen Beispiel wird daher
+z.B. das `maxlength`-Attribut als HTML-Attribut des entsprechenden
+Eingabefeldes gerendert.
Sehen wir uns die [type|CFormInputElement::type]-Option näher an. Mit ihr wird
der Typ des Eingabefelds festgelegt. Der Typ `text` steht zum Beispiel für ein
@@ -176,9 +181,41 @@ Haus aus" von [CFormInputElement] erkannt:
- checkboxlist
- radiolist
+Von allen diesen eingebauten Typen wollen wir näher auf die Verwendung der
+"Listen"-Typen eingehen, also `dropdownlist`, `checkboxlist` und `radiolist`.
+Diese Typen erfordern, dass die [items|CFormInputElement::items]-Eigenschaft
+des entsprechenden Eingabeelements wie folgt angegeben wird:
+
+~~~
+[php]
+'gender'=>array(
+ 'type'=>'dropdownlist',
+ 'items'=>User::model()->getGeschlechtOptions(),
+ 'prompt'=>'Bitte wählen:',
+),
+
+...
+
+class User extends CActiveRecord
+{
+ public function getGeschlechtOptions()
+ {
+ return array(
+ 0 => 'Männlich',
+ 1 => 'Weiblich',
+ );
+ }
+}
+~~~
+
+Dieser Code erzeugt eine Dropdownliste mit dem Aufforderungstext "Bitte
+wählen:". Die Liste enthält die Optionen "Männlich" und "Weiblich", so wie
+sie von der `getGeschlechtOptions`-Methode in der `User`-Klasse geliefert
+werden.
+
Daneben kann die [type|CFormInputElement::type]-Option auch den Namen
einer Widgetklasse oder deren Pfadalias enthalten. Die Widgetklasse muss
-lediglich [CInputWidget] erweitern. Beim Rendern des Elements
+lediglich [CInputWidget] oder [CJuiInputWidget] erweitern. Beim Rendern des Elements
wird eine Instanz der angegebenen Widgetklasse mit den angegebenen
Elementparametern erzeugt und gerendert.
@@ -499,4 +536,4 @@ noch fast genauso viel Code wie bisher braucht. Trotzdem kann sich der Einsatz
lohnen, da das Formular in einer separaten Datei definiert wird und sich
der Entwickler so besser auf die Logik konzentrieren kann.
-<div class="revision">$Id: form.builder.txt 2232 2010-06-26 22:42:03Z qiang.xue $</div>
+<div class="revision">$Id: form.builder.txt 2353 2010-08-28 20:45:26Z qiang.xue $</div>
View
10 docs/guide/de/quickstart.first-app.txt
@@ -2,8 +2,8 @@ Erstellen der ersten Yii-Anwendung
==================================
Um einen ersten Eindruck von Yii zu bekommen, demonstrieren wir zunächst, wie
-man mit dem `yiic`-Befehl eine Anwendung anlegt.
-`yiic` ist ein Hilfsprogramm, mit dem man u.a. automatisch
+man mit `yiic` (einem Kommandozeilenbefehl) eine Anwendung erstellt und mit
+`Gii` (einem mächtigen, webbasierten Codegenerator) automatisch
verschiedene Codeteile generieren kann. Das Installationsverzeichnis von
Yii nennen wir im folgenden `YiiVerzeichnis`, das Webverzeichnis entsprechend
`WebVerzeichnis`.
@@ -154,9 +154,9 @@ Erstellen von CRUD-Operationen
Kommen wir nun zum unterhaltsamen Teil: Wir möchten CRUD-Operationen (
für "*C*reate, *R*ead, *U*pdate, *D*elete", "Erstellen, Lesen, Aktualisieren, Löschen")
-für die eben erstellte Tabelle `User` bereitstellen. Eine typische
+für die eben erstellte Tabelle `tbl_user` bereitstellen. Eine typische
Aufgabenstellung aus der Praxis. Statt den nötigen Code mühevoll selbst zu schreiben,
-können Sie dazu den leistungsstarken Codegenerator Gii verwenden.
+können Sie dazu den leistungsstarken Codegenerator `Gii` verwenden.
> Info|Info: Gii steht seit Version 1.1.2 zur Verfügung. In früheren Versionen
> wurde auch für die CRUD-Generierung der erwähnte `yiic`-Befehl verwendet.
@@ -263,4 +263,4 @@ schreiben zu müssen!
![Seite zum Erstellen eines neuen Benutzers](first-app7.png)
-<div class="revision">$Id: quickstart.first-app.txt 2310 2010-08-07 09:32:55Z alexander.makarow $</div>
+<div class="revision">$Id: quickstart.first-app.txt 2375 2010-08-30 12:19:23Z mdomba $</div>
View
2 docs/guide/de/toc.txt
@@ -55,7 +55,7 @@
* Spezialthemen
- [Automatisierte Codegenerierung](topics.gii)
- [URL-Management](topics.url)
- - [Authentifizierung und Berechtigungen](topics.auth)
+ - [Authentifizierung und Autorisierung](topics.auth)
- [Themes und Skins](topics.theming)
- [Protokollierung (Logging)](topics.logging)
- [Fehlerbehandlung](topics.error)
View
467 docs/guide/de/topics.auth.txt
@@ -1,61 +1,70 @@
-Authentifizierung und Berechtigungen
-====================================
-
-Authentifizierung und Berechtigungen (engl.: authorization) spielen bei einer
-Webseite dann eine Rolle, wenn diese für bestimmte Benutzer nur beschränkt
-zugänglich sein soll. Bei der *Authentifizierung* wird geprüft, ob jemand auch
-tatsächlich der ist, der er vorgibt zu sein. In der Regel kommen dazu
-Benutzername und Passwort zum Einsatz. Man könnte aber auch alle anderen
-zur Identifizierung geeigneten Methoden verwenden, wie z.B. eine Chipkarte,
-den Fingerabdruck, etc. Über die *Berechtigung* wird festgestellt, ob die
-authentifizierte (bzw. auch identifizierte) Person auch berechtigt ist, die
-angegebene Ressource zu verändern. Normalerweise wird dazu geprüft, ob die
+Authentifizierung und Autorisierung
+===================================
+
+Diese beiden Themen spielen dann eine Rolle, wenn einige Webseiten nur für
+bestimmte Benutzer zugänglich sein sollen. Bei der *Authentifizierung* wird
+geprüft, ob jemand auch tatsächlich der ist, der er vorgibt zu sein. Meist
+geschieht das per Benutzernamen und Passwort. Man könnte aber auch eine andere
+zur Identifizierung geeignete Methode verwenden, z.B. eine Chipkarte,
+den Fingerabdruck, etc. Über die *Autorisierung* wird festgestellt, ob die
+identifizierte (also authentifizierte) Person auch tatsächlich berechtigt
+ist, bestimmte Ressourcen zu manipulieren. Normalerweise wird dazu geprüft, ob die
Person einer bestimmten Rolle zugeordnet ist, die Zugriff auf die Ressource
hat.
-Yii hat ein eigenes Authentifizierungs-/Berechtigungs-Framework
-(Auth-Framework) eingebaut, das einfach anzuwenden ist und an spezielle
-Bedürfnisse angepasst werden kann.
+Yii hat ein einfach anzuwendendes Authentifizierungs-/Autorisierungs-Framework
+(Auth-Framework) eingebaut, das leicht an spezielle Bedürfnisse angepasst werden kann.
-Zentraler Bestandteil des Yii-Auth-Frameworks ist eine in der Anwendung
-vordefinierte *Userkomponente* (Benutzerkomponente), ein Objekt,
-dass das [IWebUser]-Interface implementiert. Die Userkomponente stellt die
-beständigen Identitätsdaten für den aktuellen Benutzer dar.
+Zentraler Bestandteil dieses Frameworks ist eine in der Anwendung
+vordefinierte *Userkomponente* (Benutzerkomponente), die
+das [IWebUser]-Interface implementiert. Diese Userkomponente stellt die
+beständigen Identitätsdaten des aktuellen Benutzers dar.
Über `Yii::app()->user` kann von jeder Stelle aus darauf zugegriffen werden.
-Mittels der Userkomponente können wir über [CWebUser::isGuest] prüfen,
-ob ein Benutzer angemeldet ist oder nicht. Wir können einen Benutzer mit
-[login|CWebUser::login] an- bzw. mit [logout|CWebUser::logout] abmelden.
-Mit [CWebUser::checkAccess] können wir prüfen, ob der Benutzer bestimmte
-Operationen ausführen kann. Und wir können außerdem den [eindeutigen
-Bezeichner|CWebUser::name] und weitere beständige Identitätsdaten des
+Mittels der Userkomponente kann man über [CWebUser::isGuest] prüfen,
+ob ein Benutzer angemeldet ist oder nicht. Man kann einen Benutzer mit
+[login|CWebUser::login] und [logout|CWebUser::logout] an- bzw. abmelden oder
+mit [CWebUser::checkAccess] prüfen, ob der Benutzer bestimmte
+Operationen ausführen kann. Außerdem kann man den [eindeutigen
+Namen|CWebUser::name] bzw. auch andere beständige Identitätsdaten des
Benutzers abfragen.
Definieren der Identitätsklasse
-------------------------------
-Um einen Benutzer zu authentifizieren, definieren wir eine Identitätsklasse
-(engl.: identity class), die die eigentliche Authentifizierungslogik enthält.
-Die Identitätsklasse sollte das Interface [IUserIdentity] implementieren. Je nach
-Authentifizierungsmethode (z.B. OpenID, LDAP), können unterschiedliche
-Identitätsklassen angelegt werden. Für den Anfang empfiehlt es sich, zunächst
-[CUserIdentity] zu erweitern. Diese Klasse ist die Basisklasse für alle
-Authentifzierungsmethoden, die auf Benutzernamen und Passwort basieren.
-
-Die Hauptaufgabe beim Anlegen einer Identitätsklasse besteht darin, die Methode
-[IUserIdentity::authenticate] zu implementieren. Eine Identitätsklasse kann auch
-weitere Identitätsdaten deklarieren, die während einer Benutzersitzung beständig
-gehalten werden sollen.
-
-Im folgenden Beispiel verwenden wir einen [ActiveRecord](/doc/guide/database.ar)
-um eine gegebene Kombination aus Benutzername und Passwort anhand der Daten in
-der Benutzertabelle einer Datenbank zu prüfen. Wir überschreiben außerdem die
-Methode `getId`, damit sie die Variable `_id` zurückliefert, die wir während
-der Authentifizierung gesetzt haben (standardmäßig würde der Benutzername als
-ID zurückgegeben werden). Während der Authentifizierung speichern wir mit
-[CBaseUserIdentity::setState] den ausgelesenen Wert für `title` in einem
-Status (engl.: state) mit dem selben Namen.
+Wie bereits erwähnt, geht es bei der Authentifizierung darum, die Identität
+eines Benutzers zu prüfen. Bei einer typischen Webanwendung werden dazu meist
+ein Benutzername und ein Passwort herangezogen. Es kann aber auch andere
+Methoden geben, die entsprechend eine andere Implementierung erfordern. Damit
+die Art der Authentifizierung geändert werden kann, führt das
+Yii Auth-Framework eine Identitätsklasse (engl.: identity class) ein.
+
+Eine Identitätsklasse enthält die eigentliche Logik zur Authentifizierung und
+sollte das [IUserIdentity]-Interface implementieren. So können Klassen für
+verschiedene Identifizierungsmethoden (z.B. OpenID, LDAP, Twitter
+OAuth oder Facebook Connect) angelegt werden. Um eine eigene Identitätsklasse
+zu erstellen, empfiehlt es sich für den Anfang, [CUserIdentity] zu erweitern.
+Das ist die Basisklasse für alle Methoden, die auf Benutzername und Passwort
+basieren.
+
+Im wesentlichen muss eine neue Identitätsklasse nur die Methode
+[IUserIdentity::authenticate] implementieren. Sie kapselt die Kernlogik
+zur Authentifizierung. Daneben können noch weitere identitätsbezogene Daten
+deklariert werden, die während einer Benutzersitzung beständig bereitgehalten
+werden sollen.
+
+#### Ein Beispiel
+
+Im folgenden Beispiel zeigen wir, wie man eine Identitätsklasse zur
+datenbankgestützten Authentifizierung verwendet. Ein Besucher wird dazu
+Benutzernamen und Passwort in ein Anmeldeformular eingeben. Diese Daten werden
+dann mittels [ActiveRecord](/doc/guide/database.ar) gegen eine Benutzertabelle
+in der Datenbank geprüft. Das Beispiel demonstriert dabei gleich mehreres:
+
+1. Wie man `authenticate()` für eine DB-gestützte Prüfung der Anmeldedaten implementiert.
+2. Dass man die `CUserIdentity::getId()`-Methode überschreiben kann, um die Eigenschaft `_id` statt des Benutzernamens zurückzuliefern, wie das in der Basisimplementierung der Fall ist.
+3. Wie man die Methode `setState()` ([CBaseUserIdentity::setState]) verwendet, um weitere Daten dauerhaft für spätere Requests zu speichern
~~~
[php]
@@ -85,32 +94,35 @@ class UserIdentity extends CUserIdentity
}
~~~
-Daten, die (durch Aufruf von [CBaseUserIdentity::setState]) in einem Status
-gespeichert werden, werden an [CWebUser] übergeben, wo sie in
-einem beständigen Speicher, wie etwa der Session, abgelegt werden.
-Auf diese Daten kann wie auf Eigenschaften von [CWebUser] zugegriffen werden.
-Wir können zum Beispiel die Information `title` des aktuellen Benutzers über
-`Yii::app()->user->title` abfragen. (Dies ist seit Version 1.0.3 möglich. In
-früheren Versionen mussten wir stattdessen
+Im nächsten Abschnitt zu An- und Abmeldung werden wir sehen, dass diese
+Identitätsklasse an die login-Methode des Benutzerobjekts übergeben wird.
+Sämtliche Informationen, die (per Aufruf von [CBaseUserIdentity::setState]) in
+einem Status gespeichert wurden, werden dort in einem beständigen
+Speicher, wie etwa der Session, abgelegt. Diese Daten stehen dann direkt als
+Eigenschaften von [CWebUser] zur Verfügung. In unserem Beispiel haben wir den
+Titel über `$this->setState('title', $record->title);` gespeichert. Wurde der
+Anmeldeprozess durchlaufen, kann man daher die `title`-Information des aktuellen
+Benutzers über `Yii::app()->user->title` abrufen. (Dies ist seit Version 1.0.3
+möglich. In früheren Versionen musste man stattdessen
`Yii::app()->user->getState('title')` verwenden.)
-
> Info|Info: Standardmäßig verwendet [CWebUser] die Session als beständigen
-Speicher für Identitätsdaten. Wenn die cookie-basierte Anmeldung aktiviert
+Speicher für solche Identitätsdaten. Wenn die cookie-basierte Anmeldung aktiviert
wird (indem [CWebUser::allowAutoLogin] auf true gesetzt wurde), können
Identitätsdaten auch in einem Cookie gespeichert werden. Stellen Sie sicher,
-dass sie keine heiklen Informationen (z.B. Passwörter) beständig halten.
+dass Sie hier keine vertraulichen Informationen (z.B. Passwörter) speichern.
An- und Abmelden
----------------
-Mit der Identitätsklasse und der Userkomponente können wir An- und
-Abmeldeoperationen leicht implementieren.
+Nachdem wir an einem Beispiel demonstriert haben, wie eine Identitätsklasse
+erstellt wird, kann man diese nun zum einfachen An- und Abmelden verwenden.
+Das folgende Beispiel zeigt, wie dies erreicht wird:
~~~
[php]
-// Benutzer per übergebenem Benutzernamen/Passwort anmelden
+// Benutzer mit übergebenem Benutzernamen/Passwort anmelden
$identity=new UserIdentity($username,$password);
if($identity->authenticate())
Yii::app()->user->login($identity);
@@ -121,42 +133,105 @@ else
Yii::app()->user->logout();
~~~
-Standardmäßig wird ein Benutzer abgemeldet, wenn er für eine bestimmte Zeit
-nicht aktiv war. Diese hängt von der
+Wir erzeugen hier eine neues UserIdentity-Objekt und übergeben die
+Anmeldedaten (also die `$username`- und `$password`-Werte aus dem
+Anmeldeformular) an den Konstruktor. Danach rufen wir einfach die
+`authenticate()`-Methode auf. Falls erfolgreich, übergeben wir die
+Identitätsinformationen an die Methode [CWebUser::login], die diese dann in
+einem Permanentspeicher (standardmäßig der Sesssion) ablegt, um sie für
+späteren Requests verfügbar zu machen. Schlägt die Authentifizierung fehl,
+können wir über die `errorMessage`-Eigenschaft weitere Informationen dazu
+abfragen.
+
+Ob ein Benutzer erfolgreich authentifiziert wurde, kann in der gesamten
+Anwendung einfach über `Yii::app()->user->isGuest` geprüft werden. Verwendet
+man einen Permanentspeicher, wie die Session (Standard) und/oder ein Cookie
+(wie im folgenden Beschrieben), um die Identitätsinformationen zu speichern,
+kann der Anwender über mehrere aufeinanderfolgende Requests angemeldet
+bleiben. In diesem Fall wird die Identitätsklasse bzw. der gesamte
+Anmeldeprozess nicht bei jedem Request benötigt bzw. durchlaufen. Stattdessen
+lädt CWebUser die Identitätsinformationen automatisch aus dem entsprechenden
+Permanentspeicher und verwendet sie um den Rückgabewert von
+`Yii::app()->user->isGuest` zu bestimmen.
+
+
+### Cookie-basierte Anmdeldung
+
+Ein Benutzer wird automatisch wieder abgemeldet, wenn er für einen bestimmten
+Zeitraum nicht aktiv war. Die Dauer hängt von der
[Session-Konfiguration](http://de2.php.net/manual/de/session.configuration.php)
-ab. Um dieses Verhalten zu ändern, können wir die Eigenschaft
+ab. Möchte man das ändern, kann man die Eigenschaft
[allowAutoLogin|CWebUser::allowAutoLogin] der Userkomponente auf true setzen
-und eine Dauer als Parameter an die [CWebUser::login]-Methode übergeben. Der
+und eine Dauer als zweiten Parameter an die [CWebUser::login]-Methode übergeben. Der
Benutzer bleibt dann für die angegebene Zeit angemeldet, auch wenn das
Browserfenster geschlossen wird. Beachten Sie, dass der Benutzer dazu in
seinem Browser Cookies akzeptieren muss.
~~~
[php]
-// Benutzer für 7 Tage angemeldet lassen.
-// Stellen Sie sicher, dass allowAutoLogin
-// in der Userkomponente auf true gesetzt ist
+// Benutzer für 7 Tage angemeldet lassen. Stellen Sie sicher,
+// dass allowAutoLogin in der Userkomponente auf true gesetzt ist
Yii::app()->user->login($identity,3600*24*7);
~~~
+Wie bereits erwähnt, werden Daten, die man über [CBaseUserIdentity::setState]
+speichert, ebenfalls im Cookie abgelegt, falls man die cookie-basierte
+Anmeldung verwendet. Wenn der Besucher das nächste mal angemeldet wird, werden
+diese Daten aus dem Cookie ausgelesen und im Status über `Yii::app()->user`
+bereitgestellt.
+
+Auch wenn Yii Maßnahmen bereitstellt, um eine Veränderung dieser Cookiedaten
+auf der Clientseite zu verhindern, empfehlen wir unbedingt, keine sensiblen
+Daten als Status zu speichern. Stattdessen sollte man solche Daten auf der
+Serverseite in einem Permanentspeicher (z.B. einer Datenbank) ablegen und bei
+Bedarf wiederherstellen.
+
+Für jede seriöse Webanwendung empfehlen wir außerdem folgende Strategie, um
+die Sicherheit bei cookie-basierter Anmeldung zu verbessern:
+
+* Zum Zeitpunkt, wenn ein Benutzer sich erfolgreich anmeldet, erzeugt man
+einen zufälligen Schlüssel, der sowohl im Statuscookie als auch im
+Permanentspeicher (z.B. Datenbank) auf dem Server gespeichert wird.
+
+* Wenn der Benutzer bei einem späteren Request per Cookie angemeldet wird, überprüft man, ob die
+beiden Schlüsselwerte übereinstimmen, bevor die Anmeldung durchgeführt wird.
+
+* Wenn der Benutzer sich neu über das Anmeldeformular einloggt, muss ein neuer
+Schlüssel erzeugt werden
+
+Damit schließt man aus, dass der Besucher ein altes Statuscookie wiederverwendet,
+dessen Statusinformationen aber schon nicht mehr gültig sind.
+
+Zur Umsetzung dieser Strategie müssen folgende beiden Methoden überschrieben
+werden:
+
+* [CUserIdentity::authenticate()]: Hier wird die eigentliche Authentifizierung
+durchgeführt. Wurde der Benutzer authentifiziert, sollte man hier einen neuen
+Zufallsschlüssel erzeugen und diesen sowohl in der Datenbank als auch im
+Identitätstatus (mit [CBaseUserIdentity::setState]) speichern.
+
+* [CWebUser::beforeLogin()]: Diese Methode wird beim Anmelden eines
+Benutzers aufgerufen. Hier sollte man den Schlüssel aus dem Statuscookie mit
+dem in der Datenbank vergleichen.
+
Zugangskontrollfilter
---------------------
-Der Zugangskontrollfilter (engl.: access control filter) ist ein
-vorläufiges Berechtigungssystem, das überprüft, ob der aktuelle Benutzer eine
-bestimmte Controller-Action ausführen darf. Die Berechtigungsprüfung basiert
-auf dem Benutzernamen, der IP-Adresse des Clients und dem Requesttyp. Er steht
-als Filter mit dem Namen ["accessControl"|CController::filterAccessControl]
-zur Verfügung.
+Mit dem Zugangskontrollfilter (engl.: access control filter) lässt sich prüfen,
+ob der aktuelle Benutzer die gewünschte Controlleraction ausführen darf. Die
+Prüfung erfolgt anhand des Benutzernamens, der IP-Adresse des Clients und dem
+Requesttyp. Dieser einfache Filter steht als Anwendungskomponente
+["accessControl"|CController::filterAccessControl] bereit.
-> Tip|Tipp: Der Zugangskontrollfilter reicht für einfache Szenarien aus. Für
-kompliziertere Zugriffskontrollen können Sie die rollenbasierte
-Zugriffskontrolle (RBAC) einsetzen, die wir in Kürze behandeln werden.
+> Tip|Tipp: Der Zugangskontrollfilter ist für einfache Fälle gedacht.
+Kompliziertere Berechtigungsregeln kann man mit der rollenbasierten
+Zugriffskontrolle (RBAC) umsetzen, die wir im nächsten Abschnitt
+behandeln werden.
-Um den Zugriff auf Actions in unserem Controller zu regeln, aktivieren wir den
-Zugangskontrollfilter indem wir [CController::filters] überschreiben (siehe
-[Filter](/doc/guide/basics.controller#filter) für weitere Details zur
-Anwendung von Filtern).
+Um diesen Filter in einem Controller zu verwenden, überschreibt man die
+[CController::filters]-Methode wie folgt (siehe auch
+[Filter](/doc/guide/basics.controller#filter) zu näheren Details über
+die Anwendung von Filtern):
~~~
[php]
@@ -172,11 +247,11 @@ class PostController extends CController
}
~~~
-Hier legen wir fest, dass der
-[Zugangskontrollfilter|CController::filterAccessControl] auf alle Actions von
-`PostController` angewendet werden soll. Die ausführlichen Berechtigungsregeln
-für den Filter werden definiert, indem wir [CController::accessRules]
-im Controller überschreiben.
+Mit dieser Funktion legt man fest, dass der
+[Zugangskontrollfilter|CController::filterAccessControl] auf alle Actions des
+`PostController`s angewendet werden soll. Die spezifischen Berechtigungen
+werden in der Methode [CController::accessRules] angegeben, die man z.B. so
+überschreiben kann:
~~~
[php]
@@ -203,22 +278,21 @@ class PostController extends CController
}
~~~
-Dieser Code legt drei Regeln über jeweils ein Array fest. Das erste Element
+Hier werden drei Regeln in jeweils einem Array definiert. Das erste Element
eines solchen Arrays ist entweder `'allow'` (erlaube) oder `'deny'` (verbiete). Die
-restlichen Name-Wert-Paare legen die Gültigkeit der Regel fest. Die Regeln
-oben lesen sich wie folgt: Die Actions `create` und `edit` können nicht von
-anonymen Benutzern aufgerufen werden. Die `delete`-Action kann von Benutzern
-mit der Rolle `admin` ausgeführt werden. Und die `delete`-Action kann von
+weiteren Name-Wert-Paare bestimmen, wann diese Regel gilt. Die Regeln
+oben bedeuten der Reihe nach, dass die `create`- und `edit`-Actions nicht von
+anonymen Benutzern aufgerufen werden können. Die `delete`-Action darf von Benutzern
+mit der Rolle `admin` ausgeführt werden. Und die `delete`-Action darf von
keinem Benutzer ausgeführt werden.
Die Zugriffsregeln werden eine nach der anderen in der Reihenfolge ihrer
-Definition ausgewertet. Die erste Regel, die vollständig mit dem vorliegenden
-Kontext (z.B. Benutzername, Rolle, IP-Adresse) übereinstimmt, bestimmt das Ergebnis
-der Berechtigungsprüfung. Falls es sich um eine `allow`-Regel handelt, kann die
-Action ausgeführt werden. Liegt eine `deny`-Regel vor, kann die Action nicht
-ausgeführt werden. Wenn keine der Regeln mit dem aktuellen Kontext übereinstimmt,
-kann die Action immer noch ausgeführt werden.
-
+Definition geprüft. Die erste Regel, die vollständig auf den aktuellen
+Kontext (z.B. Benutzername, Rolle, IP-Adresse) zutrifft, bestimmt das
+Ergebnis. Falls es sich um eine `allow`-Regel handelt, darf die
+Action ausgeführt werden, liegt eine `deny`-Regel vor, darf sie nicht
+ausgeführt werden. Passt keine der definierten Regeln auf den aktuellen
+Kontext, darf die Action ausgeführt werden.
> Tip|Tipp: Um sicherzustellen, dass eine Action nicht doch unter einem bestimmten
> Kontext ausgeführt werden kann, ist es hilfreich, eine immergültige
@@ -233,10 +307,10 @@ kann die Action immer noch ausgeführt werden.
> ),
> );
> ~~~
-> Diese Regel ist nötig, da eine Action ausgeführt werden kann, wenn keine
-> Regel mit einem gegebenen Kontext übereinstimmt.
+> Diese Regel ist nötig, da eine Action ausgeführt werden darf, falls keine
+> anderslautende passende Regel gefunden wurde.
-Eine Zugriffsregel kann auf folgende Kontextparameter zutreffen:
+Eine Regel kann folgende Kontextparameter enthalten:
- [actions|CAccessRule::actions]: Definiert, welche Actions diese Regel
betrifft. Dies sollte ein Array aus Action-IDs sein, Groß-/Kleinschreibung
@@ -258,10 +332,10 @@ Hier können drei spezielle Zeichen verwendet werden:
- [roles|CAccessRule::roles]: Definiert, welche Rollen diese Regel
betrifft. Dazu wird die [rollenbasierte
-Zugriffskontrolle](#role-based-access-control) verwendet, die wir im nächsten
+Zugriffskontrolle](/doc/guide/topics.auth#role-based-access-control) verwendet, die wir im nächsten
Abschnitt beschreiben werden. Konkret wird diese Regel angewendet, wenn
[CWebUser::checkAccess] für eine der Rollen true zurückliefert. Beachten Sie,
-dass Sie Rollen vor allem in `allow`-Regeln einsetzen sollen, da eine Rolle
+dass Sie Rollen vor allem in `allow`-Regeln einsetzen sollten, da eine Rolle
per Definition eine Erlaubnis darstellt, etwas bestimmtes zu tun. Und obwohl
wir hier den Begriff `roles` (Rollen) verwenden, kann der Wert tatsächlich
jedem beliebigen Autorisierungselement entsprechen, inklusive Rollen, Tätigkeiten und
@@ -280,25 +354,24 @@ können Sie `$user` für `Yii::app()->user` verwenden. Diese Option ist seit
Version 1.0.3 verfügbar.
-### Umgang mit Autorisierungsergebnissen
+### Verhalten nach der Autorisierung
-Wenn die Autorisierung verweigert wird, der Benutzer also nicht berechtigt
-ist, die angegebene Action auszuführen, liegt eine der beiden folgenden
-Situationen vor:
+Wurde eine Autorisierung verweigert, so ist der Benutzer nicht berechtigt,
+die gewünschte Action auszuführen und es passiert folgendes:
- - Falls der Benutzer nicht angemeldet ist und die Eigenschaft
-[loginUrl|CWebUser::loginUrl] der Userkomponente auf die URL der Anmeldeseite
-gesetzt wurde, wird der Browser auf diese Seite umgeleitet. Beachten Sie, dass
+ - War der Benutzer nicht angemeldet und zeigt die Eigenschaft
+[loginUrl|CWebUser::loginUrl] der Userkomponente auf die URL der Anmeldeseite,
+so wird der Browser auf diese Seite umgeleitet. Beachten Sie, dass
[loginUrl|CWebUser::loginUrl] standardmäßig auf die Seite `site/login` zeigt.
- - Andernfalls wird eine HTTP-Exception mit dem Fehlercode 403 angezeigt.
+ - In allen anderen Fällen wird eine HTTP-Exception mit dem Fehlercode 403 angezeigt.
-Beim Konfigurieren der [loginUrl|CWebUser::loginUrl] kann eine relative oder
-absolute URL angegeben werden. Man kann auch ein Array angeben, das an
-[CWebApplication::createUrl] übergeben wird, um damit eine URL zu erzeugen.
+[loginUrl|CWebUser::loginUrl] kann als relative oder absolute URL angegeben werden.
+Man kann auch ein Array konfigurieren, das dann an [CWebApplication::createUrl]
+übergeben wird, um damit eine URL zu erzeugen.
Das erste Element dieses Arrays sollte die [Route](/doc/guide/basics.controller#route)
-zur Anmelde-Action eines Controllers angeben. Der Rest kann aus
-Name-Wert-Paaren für GET-Parameter bestehen. Ein Beispiel:
+zur Anmeldeaction angeben. Der Rest kann aus Name-Wert-Paaren für GET-Parameter bestehen.
+Hier ein Beispiel:
~~~
[php]
@@ -306,19 +379,17 @@ array(
......
'components'=>array(
'user'=>array(
- // Dies entspricht auch dem Vorgabewert
+ // Dies entspricht dem Vorgabewert
'loginUrl'=>array('site/login'),
),
),
)
~~~
-Wenn der Browser auf die Anmeldeseite umgeleitet wird und die Anmeldung
-erfolgreich verläuft, können wir den Browser zurück auf die Seite schicken,
-bei der die Autorisierung verweigert wurde. Woher wissen wir die URL dieser
-Seite? Wir können sie über die Eigenschaft [returnUrl|CWebUser::returnUrl] der
-aktuellen Userkomponente beziehen. Dadurch können wir wie folgt vorgehen, um die
-Umleitung durchzuführen:
+Wurde der Browser auf die Anmeldeseite umgeleitet und verläuft die Anmeldung
+erfolgreich, kann man den Browser zurück zu der Seite schicken, bei der
+die Autorisierung verweigert wurde. Die URL dieser Seite kann über die Eigenschaft
+[returnUrl|CWebUser::returnUrl] der Userkomponente abgerufen werden:
~~~
[php]
@@ -331,7 +402,7 @@ Rollenbasierte Zugriffskontrolle
Die rollenbasierte Zugriffskontrolle (RBAC, engl.: role-based access control)
bietet eine einfache und trotzdem leistungsfähige zentralisierte
Zugriffssteuerung. Für weitere Ausführungen zum Vergleich von RBAC mit anderen
-traditionelleren Verfahren der Zugriffskontrolle beachten Sie bitte auch den
+traditionellen Verfahren der Berechtigungsprüfung beachten Sie bitte auch den
entsprechenden [Wiki-Artikel](http://de.wikipedia.org/wiki/RBAC) (evtl. auch
in der ausührlicheren [englischen
Version](http://en.wikipedia.org/wiki/Role-based_access_control)).
@@ -339,9 +410,8 @@ Version](http://en.wikipedia.org/wiki/Role-based_access_control)).
Yii implementiert über seine
[authManager|CWebApplication::authManager]-Komponente ein hierarchisches
RBAC-Schema. Im folgenden behandeln wir zunächst die Grundkonzepte dieses
-Schemas. Wir beschreiben dann, wie Autorisierungsdaten definiert werden.
-Schließlich zeigen wir, wie die Autorisierungsdaten bei der Zugriffsprüfung
-verwendet werden.
+Schemas. Danach beschreiben wir, wie man Autorisierungsdaten definiert und
+schließlich wie man diese für die Berechtigungsprüfung verwendet.
### Übersicht
@@ -359,42 +429,40 @@ besteht aus den Tätigkeiten `Beiträge verwalten` und `Benutzer verwalten`.
Die Tätigkeit `Benutzer verwalten` könnte aus den Operationen
`Benutzer anlegen`, `Benutzer aktualisieren` und `Benutzer löschen` bestehen.
Um das System noch flexibler zu machen, erlaubt es Yii
-sogar, dass eine Rolle aus weiteren Rollen oder Operationen besteht, eine
-Tätigkeit aus anderen Tätigkeiten und eine Operation aus anderen Operationen.
-
-Ein Autorisierungselement wird eindeutig über seinen Namen identifiziert.
-
-Ein Autorisierungselement kann mit einer *Geschäftsregel* (engl.: business
-rule) verbunden sein. Eine Geschäftsregel ist ein kurzer PHP-Code, der
-ausgeführt wird, wenn eine Zugriffsprüfung unter Bezug auf das Element
-stattfindet. Die vom Element dargestellte Berechtigung wird dem Benutzer nur
-dann erteilt, wenn die Ausführung dieses Codes true zurückliefert. Wenn wir
-zum Beispiel eine Operation `aktualisiereBeitrag` definieren,
-können wir eine Geschäftsregel hinzufügen, die prüft, ob die ID des Benutzers
+sogar, dass eine Rolle aus weiteren Rollen oder Operationen, eine
+Tätigkeit aus anderen Tätigkeiten und eine Operation aus anderen Operationen
+besteht.
+
+Ein Autorisierungselement wird eindeutig über seinen Namen identifiziert und
+kann mit einer *Geschäftsregel* (engl.: business
+rule) verbunden sein. Eine Geschäftsregel ist ein PHP-Schnippsel, das
+ausgeführt wird, wenn die Berechtigung für das Element geprüft wird.
+Liefert dieser Code true zurück, so ist der Benutzer zu diesem Element
+berechtigt. Definiert man zum Beispiel eine Operation `aktualisiereBeitrag`,
+kann man eine Geschäftsregel hinzufügen, die prüft, ob die ID des Benutzers
mit derjenigen des Beitragsautors übereinstimmt, so dass nur der Autor selbst
berechtigt ist, seine Beiträge zu aktualisieren.
-Durch den Einsatz von Autorisierungselementen können wir ein
+Durch den Einsatz von Autorisierungselementen kann man eine
*Autorisierungshierarchie* aufbauen. Ein Element `A` ist das Elternelement
eines anderen Elements `B` in der Hierarchie, wenn `A` aus `B` besteht (oder
anders ausgedrückt `A` die von `B` dargestellten Berechtigung(en) erbt).
-Ein Element kann mehrere Kindelemente haben und auch mehrere Elternelemente
-besitzen. Eine Autorisierungshierarchie ist daher eher ein Graph partieller
+Ein Element kann sowohl mehrere Kind- als auch mehrere Elternelemente
+haben. Eine Autorisierungshierarchie ist daher eher ein Graph partieller
Ordnung als eine Baumstruktur. In dieser Hierarchie stehen Rollen auf der
obersten Ebene, Operationen auf der untersten und Tätigkeiten zwischen diesen
beiden.
-Haben wir eine Autorisierungshierarchie erstellt, können wir Benutzern Rollen
-aus dieser Hierarchie zuweisen. Wenn einem Benutzer eine Rolle zugewiesen
-wurde, hat er alle von der Rolle dargestellten Berechtigungen. Weisen wir
+Wurde die Autorisierungshierarchie einmal erstellt, kann man Benutzer zu den
+Rollen in dieser Hierarchie hinzufügen. Ein Benutzer, dem eine Rolle
+zugewiesen wurde, hat alle von dieser Rolle dargestellten Berechtigungen. Weist man
einem Benutzer z.B. die Rolle `administrator` zu, hat er Administratorrechte,
was die Tätigkeiten `Beiträge verwalten` und `Benutzer verwalten` beinhaltet
(sowie die zugehörigen Operationen wie `Benutzer anlegen`).
-Jetzt beginnt der vergnügliche Teil. In einer Controller-Action möchten wir
-prüfen, ob der aktuelle Benutzer den angegebenen Beitrag löschen kann.
-Verwenden wir die RBAC-Hierarchie und -Zuweisung, kann das ganz leicht wie
-folgt erledigt werden:
+Am einfachsten stellt sich die Anwendung dar: Möchte man in einer
+Controlleraction prüfen, ob der aktuelle Benutzer den Beitrag
+löschen kann, geht das so:
~~~
[php]
@@ -404,18 +472,14 @@ if(Yii::app()->user->checkAccess('löscheBeitrag'))
}
~~~
-### Konfiguration des Berechtigungsmanagers
+### Konfigurieren des Autorisierungsmanagers
-Bevor wir damit loslegen können, eine Autorisierungshierarchie anzulegen
-und den Zugriffschutz zu verwenden, müssen wir die Anwendungskomponente
-[authManager|CWebApplication::authManager] konfigurieren. Yii bietet zwei
-Arten von Berechtigungsmanagern (engl.: authorization manager):
-[CPhpAuthManager] und [CDbAuthManager].
-Ersterer verwendet eine PHP-Datei zum Speichern der Autorisierungsdaten,
-letzerer eine Datenbank. Beim Konfigurieren der
-[authManager|CWebApplication::authManager]-Komponente müssen wir angeben,
-welche Klasse wir benutzen wollen, und welche Startwerte für deren
-Eigenschaften verwendet werden sollen. Ein Beispiel:
+Bevor man eine Autorisierungshierarchie anlegen und den Zugriffsschutz
+einsetzen kann, muss die [authManager|CWebApplication::authManager]-Komponente
+konfiguriert werden. Yii bietet hier zwei Typen an: [CPhpAuthManager] und [CDbAuthManager].
+Der erste speichert die Autorisierungsdaten in einer PHP-Datei, der andere
+in der Datenbank. Über die Klasse kann man einen dieser Typen, sowie dessen
+Starteigenschaften konfigurieren:
~~~
@@ -434,7 +498,7 @@ return array(
);
~~~
-Danach können wir über `Yii::app()->authManager` auf den
+Jetzt kann man über `Yii::app()->authManager` auf den
[authManager|CWebApplication::authManager] zugreifen.
> Note|Hinweis: Wenn Sie Umlaute für die Bezeichnung Ihrer
@@ -448,8 +512,8 @@ Konfiguration der Datenbankverbindung die Eigenschaft
Das Anlegen einer Autorisierungshierarchie beinhaltet drei Schritte:
Autorisierungselemente anlegen, zwischen diesen Elementen Beziehungen
definieren und Benutzern Rollen zuweisen. Die
-[authManager|CWebApplication::authManager]-Komponente bietet eine ganze Reihe
-von APIs um dies zu bewerkstelligen.
+[authManager|CWebApplication::authManager]-Komponente bietet hierfür
+eine ganze Reihe von APIs.
Rufen Sie je nach Art des Elements eine der folgenden Methoden auf, um ein
Autorisierungselement zu erstellen:
@@ -458,7 +522,7 @@ Autorisierungselement zu erstellen:
- [CAuthManager::createTask] (erzeugt Tätigkeit)
- [CAuthManager::createOperation] (erzeugt Operation)
-Wenn wir eine Reihe von Autorisierungselementen angelegt haben, können wir mit
+Hat man eine Reihe von Autorisierungselementen angelegt, kann man mit
den folgenden Methoden Beziehungen zwischen diesen Elementen definieren:
- [CAuthManager::addItemChild] (definiert Eltern-Kind-Beziehung)
@@ -466,14 +530,14 @@ den folgenden Methoden Beziehungen zwischen diesen Elementen definieren:
- [CAuthItem::addChild] (definiert Kind-Beziehung von Elternelement aus)
- [CAuthItem::removeChild] (entfernt Kind-Beziehung von Elternelement aus)
-Um schließlich einzelnen Benutzern Rollen zuzuweisen rufen wir folgende Methoden
+Um schließlich einzelnen Benutzern Rollen zuzuweisen, ruft man folgende Methoden
auf:
- [CAuthManager::assign] (weist Rolle zu)
- [CAuthManager::revoke] (entfernt zugewiesene Rolle)
-Unten sehen wir ein Beispiel, wie wir mit der verfügbaren API ein
-Autorisierungshierarchie aufbauen:
+Unten sehen Sie ein Beispiel, wie man mit dieser API eine
+Autorisierungshierarchie aufbaut:
~~~
[php]
@@ -511,31 +575,37 @@ $auth->assign('redakteur','redakteurC');
$auth->assign('admin','adminD');
~~~
-> Info|Info: Das Verfahren oben mutet etwas langwierig an, dient aber lediglich
-Demonstrationszwecken. In der Regel müssen Entwickler
-Benutzerschnittstellen entwerfen, mit denen Autorisierungshierarchien
-intuitiver erstellt werden können.
+Wurden diese Hierarchie einmalig erstellt, wird sie automatisch von der
+[authManager|CWebApplication::authManager]-Komponente (also
+z.B. [CPhpAuthManager] oder [CDbAuthManager]) geladen. Man muss obigen
+Code also nur einmal ausführen, NICHT bei jeden Request.
+
+> Info|Info: Das Verfahren oben mutet etwas umständlich an. Es soll
+> aber lediglich das Prinzip demonstrieren. In der Regel wird der
+> Entwickler eine geeignete Verwaltungsschnittstelle entwerfen, mit
+> der man Autorisierungshierarchien intuitiver erstellen kann.
+
-### Verwenden von Geschäftsregeln
+### Anwendung von Geschäftsregeln
-Beim Definieren einer Autorisierungshierarchie können wir eine Rolle, eine
+Erstellt man eine Autorisierungshierarchie, kann man eine Rolle, eine
Tätigkeit oder eine Operation mit einer sogenannten *Geschäftsregel* versehen.
-Auch beim Zuweisen einer Rolle an einen Benutzer können wir eine
-Geschäftsregel angeben. Eine Geschäftsregel ist ein Stück PHP-Code,
-der bei der Zugriffsprüfung ausgeführt
-wird. In obigem Beispiel haben wir der Tätigkeit `aktualisiereEigenenBeitrag`
-eine Geschäftsregel zugeordnet. In dieser Geschäftsregel prüfen wir einfach,
-ob die ID des aktuellen Benutzers mit der Autor-ID des Beitrags übereinstimmt.
-Bei der Zugriffsprüfung wird die post-Information (also der Beitrag) vom
+Auch beim Zuweisen einer Rolle an einen Benutzer kann man eine solche
+Geschäftsregel angeben. Eine Geschäftsregel ist ein PHP-Schnippsel,
+der während der Berechtigungsprüfung ausgeführt wird. In obigem Beispiel
+wurde bei der Tätigkeit `aktualisiereEigenenBeitrag`
+eine solche Geschäftsregel definiert. Darin wird einfach geprüft,
+ob die ID des aktuellen Benutzers mit der des Autors übereinstimmt.
+Bei der Zugriffsprüfung wird der Beitrag (post) vom
Entwickler im Array `$params` übergeben.
-### Zugriffsprüfung
+### Berechtigungsprüfung
-Bevor wir eine Zugriffsprüfung durchführen können, brauchen wir erst den
-Namen des Autorisierungselements. Um zum Beispiel zu testen, ob der aktuelle
-Benutzer einen Beitrag erstellen kann, würden wir prüfen, ob er die von der
-Operation `erstelleBeitrag` dargestellte Berechtigung besitzt. Für die Prüfung
-rufen wir dann [CWebUser::checkAccess] auf:
+Um die Berechtigungsprüfung durchzuführen, braucht man zunächst den Namen des
+Autorisierungselements. Will man zum Beispiel zu testen, ob der aktuelle
+Benutzer einen Beitrag erstellen kann, muss die Berechtigung zur Operation
+`erstelleBeitrag` ermittelt werden. Dazu ruft man [CWebUser::checkAccess]
+wie folgt auf:
~~~
[php]
@@ -545,10 +615,10 @@ if(Yii::app()->user->checkAccess('erstelleBeitrag'))
}
~~~
-Wenn die Autorisierungsregel mit einer Geschäftsregel verbunden ist, die
-weitere Parameter erfordert, können wir diese ebenfalls mit übergeben. Um zum
-Beispiel zu prüfen, ob ein Benutzer einen Beitrag aktualisieren darf, können
-wir so vorgehen:
+Ist eine Geschäftsregel mit weiteren Parametern mit dem Element verbunden,
+können diese ebenfalls mit übergeben werden. Um zum Beispiel zu prüfen, ob
+ein Benutzer einen bestimmten Beitrag aktualisieren darf, würde man die
+Beitragsdaten in `$params` übergeben:
~~~
[php]
@@ -563,16 +633,15 @@ if(Yii::app()->user->checkAccess('aktualisiereEigenenBeitrag',$params))
> Note|Hinweis: Standardrollen können seit Version 1.0.3 verwendet werden.
-Viele Webanwendungen verwenden einige spezielle Rollen, die den meisten oder
-allen Systembenutzern zugewiesen werden müssen. Wir könnten zum Beispiel allen
-authentifizierten Benutzern einige Berechtigungen zuweisen wollen. Es würde
-viel zusätzlichen Verwaltungsaufwand bedeuten, wenn wir diese Rollenzuweisung
-jeweils einzeln durchführen und speichern wollten. Um dieses Problem zu
-umgehen, können wir *Standardrollen* (engl.: default roles) verwenden.
+In vielen Webanwendungen gibt es einige Rollen, denen praktisch alle Benutzer
+zugewiesen werden sollen, um z.B. alle authentifizierten Benutzer mit
+bestimmten Basisberechtigungen zu versehen. Man könnte also diesen Rollen
+jeden einzelnen Benutzer zuwiesen, was allerdings relativ hohen Verwaltungsaufwand
+bedeutet. Stattdessen kann man aber auch *Standardrollen* (engl.: default roles) verwenden.
Eine Standardrolle ist eine Rolle, die implizit allen Benutzern zugewiesen
-wird und zwar authentifizierten Benutzern genauso, wie Gästen. Wir müssen sie
-nicht explizit einem Benutzer zuweisen. Beim Aufruf von
+wird und zwar authentifizierten Benutzern genauso, wie Gästen. Man muss ihnen
+nicht explizit Benutzer zuweisen. Beim Aufruf von
[CWebUser::checkAccess] werden zunächst die Standardrollen überprüft, als ob
sie dem Benutzer zugewiesen worden wären.
@@ -592,8 +661,8 @@ return array(
);
~~~
-Da eine Standardrolle jedem Benutzer zugewiesen wird, muss sie normalerweise
-mit einer Geschäftsregel verbunden werden, um festzustellen, ob die Rolle
+Da eine Standardrolle jedem Benutzer zugewiesen wird, wird sie normalerweise
+mit einer Geschäftsregel verbunden, um festzustellen, ob die Rolle
wirklich auf den Benutzer zutrifft. Der folgende Code definiert zum Beispiel
zwei Rollen, "authentifiziert" und "gast", die letzendlich authentifizierten
Benutzern und Gästen entsprechend zugeordnet werden.
@@ -607,4 +676,4 @@ $bizRule='return Yii::app()->user->isGuest;';
$auth->createRole('gast','Gast-Benutzer', $bizRule);
~~~
-<div class="revision">$Id: topics.auth.txt 1808 2010-02-17 21:49:42Z qiang.xue $</div>
+<div class="revision">$Id: topics.auth.txt 2638 2010-11-11 14:18:59Z jefftulsa@gmail.com $</div>
View
191 docs/guide/de/topics.console.txt
@@ -1,31 +1,42 @@
Konsolenanwendungen
===================
-Konsolenanwendungen werden bei einer Webanwendung hauptsächlich für
-Offline-Arbeiten verwendet, wie z.B. zur Codegenerierung, zum Erstellen eines
-Suchindexes, zum Verschicken von E-Mails etc. Auch hierfür bietet Yii ein
-Framework, um solche Anwendungen systematisch und objektorientiert zu erstellen.
+Konsolenanwendungen werden hauptsächlich für Offline-Arbeiten eingesetzt,
+z.B. zur Codegenerierung, um Suchindizes zu Erstellen oder auch um Emails zu
+versenden. Auch für sie bietet Yii ein objektorientiertes Framework.
+Damit können solche Anwendungen auf die selben Ressourcen (z.B. DB-Verbindungen)
+zugreifen, wie die Webapplikation.
-Jeder Konsolenbefehl wird in Yii durch ein [Kommando|CConsoleCommand]
-repräsentiert. Eine [Konsolenanwendung|CConsoleApplication] wiederum
-kümmert sich darum, einen Aufruf von der Kommandozeile an das entsprechende
-Kommando weiterzuleiten. Diese Anwendung wird in einem eigenen Startscript
-erstellt. Um einen Konsolenbefehl aufzurufen, führt man an
-der Kommandozeile also z.B. folgenden Befehl aus:
+Überblick
+---------
+
+Verschiedene Konsolenarbeiten werden in Yii jeweils durch einen
+[Befehl|CConsoleCommand] repräsentiert. Um einen Konsolenbefehl anzulegen, wird die Klasse
+[CConsoleCommand] erweitert.
+
+Konsolenbefehle werden von einer [Konsolenanwendung|CConsoleApplication]
+verwaltet. Eine solche Konsolenanwendungen verhält sich wie eine Webanwendung:
+Sie kann genauso konfiguriert werden und wird ebenfalls über
+ein Startscript aufgerufen.
+
+An der Eingabeaufforderung wird ein Befehl in diesem Format aufgerufen:
~~~
-php eingangsScript.php KommandoName Param0 Param1 ...
+php eingangsScript.php BefehlsName Param0 Param1 ...
~~~
-`KommandoName` bezieht sich hier auf den Namen des Kommandos wobei
-Groß-/Kleinschreibung nicht berücksichtigt wird. `Param0`, `Param1` usw.
-sind Parameter, die an die Kommandoinstanz übergeben werden.
+Startscript
+-----------
-Das Startscript kann ähnlich wie das einer Webanwendung aussehen:
+Wie oben erwähnt, benötigt man zum Ausführen eines Konsolenbefehls ein Startscript.
+Webanwendung, die mit `yiic webapp` angelegt wurden, enthalten bereits
+eine Konsolenanwendung inklusive dem entsprechenden Startscript unter
+`protected/yiic.php`.
+
+Man kann ein Startscript aber auch von Hand anlegen:
~~~
[php]
-defined('YII_DEBUG') or define('YII_DEBUG',true);
// Einbinden der Yii-Startdatei
require_once('pfad/zum/yii/framework/yii.php');
// Erstellen und Starten der Applikation
@@ -33,68 +44,144 @@ $configFile='pfad/zur/config/datei.php';
Yii::createConsoleApplication($configFile)->run();
~~~
-Nun kann man von [CConsoleCommand] abgeleitetete Kommandoklassen
-erstellen. Jede Kommandoklasse sollte wie das entsprechende Kommando heißen,
-ergänzt um `Command`. So würde z.B. eine Klasse `EmailCommand` ein Kommando
-`email` zu definieren. Alle Kommandoklassen sollten
-in einem Unterverzeichnis `commands` im
-[Anwendungsverzeichnis](/doc/guide/basics.application#application-base-directory)
-abgelegt werden.
+Konsolenbefehle
+---------------
+
+Konsolenbefehle werden in Form einer Klasse in dem Verzeichnis abgelegt,
+das unter [CConsoleApplication::commandPath] konfiguriert wurde. Standardmäßig
+verweist dieser Pfad auf `protected/commands`.
+
+Eine Klasse für einen Konsolenbefehl muss von [CConsoleCommand]
+abgeleitetet werden. Der Name dieser Klasse muss dem Format `XyzCommand`
+entsprechen, wobei `Xyz` dem großgeschriebenen Befehlsnamen entspricht.
+Für einen `sitemap`-Befehl müsste die Klasse also `SitemapCommand` heißen.
+Daher ist bei Konsolenbefehlen die Groß-/Kleinschreibung zu berücksichtigen.
> Tip|Tipp: Verwendet man [CConsoleApplication::commandMap], können
Kommandoklassen auch anderen Namenskonventionen folgen und an anderen Orten
liegen.
-Am wichtigsten bei einer eigenen Kommandoklasse ist die Methode
-[CConsoleCommand::run]. Sie wird beim Ausführen des Kommandos
-Bmit den Kommandozeilenparametern als Array aufgerufen. Hier ein Beispiel:
+Innerhalb einer Klasse für einen Konsolenbefehl führt man dann entweder die
+einzelnen Actions des Befehls auf (wie weiter unten beschrieben) oder
+überschreibt die Methode [CConsoleCommand::run()] wie folgt:
+
+~~~
+[php]
+public function run($args) { ... }
+~~~
+
+wobei `$args` die weiteren Aufrufparameter des Befehls enthält.
+
+
+Actions eines Konsolenbefehls
+-----------------------------
+
+> Note|Hinweis: Actions stehen erst seit Version 1.1.5 in Konsolenbefehlen zur
+> Verfügung.
+
+Oft kann ein Konsolenbefehl weitere Aufrufparameter zulassen.
+So könnte ein `sitemap`-Befehl zum Beispiel den Typ der zu erzeugenden Sitemap
+erwarten. Wie in [CController] kann man einen Befehl daher in verschiedene
+Actions unterteilen, von der sich jede um eine spezielle Teilaufgabe kümmert.
+
+Eine solche Befehlsaction besteht aus einer Methode in der Befehlsklasse,
+deren Name dem Format `actionXyz` entspricht. `Xyz` entspricht dem
+großgeschriebenen Actionnamen. Eine Methode `actionIndex` definiert demzufolge
+eine Action namens `index`.
+
+Um eine solche Action auszuführen, ruft man den Befehl in folgender Form auf:
+
+~~~
+php entryScript.php BefehlsName ActionName --Option1=Wert1 --Option2=Wert2
+...
+~~~
+
+Die weiteren Option/Wert-Paare werden als Aufrufparameter an die Actionmethode
+übergeben. Der Wert der Option `xyz` wird dabei als `$xyz` an die Methode
+gesendet.
~~~
[php]
-class EmailCommand extends CConsoleCommand
+class SitemapCommand extends CConsoleCommand
{
- public function run($args)
- {
- $receiver=$args[0];
- // Email an $receiver senden
- }
+ public function actionIndex($typ, $limit=5) { ... }
+ public function actionInit() { ... }
}
~~~
-Auch in einer Konsolenanwendung kann man jederzeit über `Yii::app()` auf die
-Anwendung zugreifen. Und auch die Konfiguration erfolgt analog zu einer
+Alle folgenden Konsolenbefehle führen letztendlich zu einem Aufruf von `actionIndex('News',5)`:
+
+~~~
+php entryScript.php sitemap index --typ=News --limit=5
+
+// $limit wird mit Vorgabewert belegt
+php entryScript.php sitemap index --typ=News
+
+// $limit wird mit Vorgabewert belegt
+// Da 'index' die Standardaction ist, kann der Actioname auch weggelasssen werden
+php entryScript.php sitemap --typ=News
+
+// Die Reihenfolge der Optionen spielt keine Rolle
+php entryScript.php sitemap index --limit=5 --typ=News
+~~~
+
+Wir eine Option ohne Wert angegeben (z.B. `--typ` statt `--typ=News`), so wird der
+Wert auf (boolean) `true` gesetzt.
+
+> Note|Hinweis: Alternative Optionsformate wie z.B. `--typ News` oder `-t News` werden nicht unterstützt.
+
+Ein Parameterwert kann als Array angegeben werden indem er in der Funktion als Array deklariert wird:
+
+~~~
+[php]
+public function actionIndex(array $typen) { ... }
+~~~
+
+Um den Arraywert anzugeben, wird die entsprechende Option beim Aufruf einfach mehrfach aufgeführt:
+
+~~~
+php entryScript.php sitemap index --typen=News --typen=Article
+~~~
+
+Dieser Befehl wird in den Aufruf `actionIndex(array('News','Article'))` übersetzt.
+
+
+Zugriff auf Ressourcen
+----------------------
+
+Auch in einer Konsolenanwendung kann man über `Yii::app()` auf die
+Anwendungsinstanz zugreifen. Und auch die Konfiguration erfolgt analog zu einer
Webanwendung. Für Datenbankzugriffe kann man zum Beispiel eine Komponente
`db` konfigurieren. In der Regel liegt die Konfiguration als PHP-Datei vor.
-Der Pfad dazu wird im Konstruktor an die Anwendung übergeben (bzw. im Startscript an
-[createConsoleApplication|YiiBase::createConsoleApplication]).
+Der Pfad dazu wird im Konstruktor an die Anwendung übergeben (bzw. an
+[createConsoleApplication|YiiBase::createConsoleApplication] im Startscript).
Verwendung des `yiic`-Befehls
-----------------------------
-Wir haben den `yiic`-Befehl bereits verwendet, um die [erste Yii-Anwendung
-zu erstellen](/doc/guide/quickstart.first-app). Der `yiic`-Befehl
-ist tatsächlich auch nur eine Konsolenanwendung mit dem Startscript
-`framework/yiic.php`. Mit `yiic` kann man das Grundgerüst einer Webanwendung
+Der `yiic`-Befehl wurde bereits zum [Erstellen der ersten Yii-Anwendung](/doc/guide/quickstart.first-app)
+verwendet. Tatsächlich ist der `yiic`-Befehl auch eine Konsolenanwendung
+mit dem Startscript `framework/yiic.php`. Mit `yiic` kann man das Grundgerüst einer Webanwendung
anlegen, Controller- und Modelklassen erstellen, Code für CRUD-Operationen
erzeugen, zu übersetzende Textmeldungen extrahieren etc.
-Man kann `yiic` um eigene Kommandos ergänzen. Dazu sollte zunächst
+Man kann `yiic` auch eigene Befehle hinzufügen. Dazu sollte zunächst
eine Webanwendung erstellt werden, wie im Kapitel [Erstellen der
ersten Yii-Anwendung](/doc/guide/quickstart.first-app) beschrieben. Der Befehl
-`yiic webapp` erzeugt zwei Dateien im `protected`-Verzeichnis mit: `yiic` und
-`yiic.bat`. Das sind *lokale* Versionen des `yiic`-Befehls, die speziell für
-diese Webanwendung erstellt wurden.
+`yiic webapp` legt (u.a.) zwei Dateien im `protected`-Verzeichnis an: `yiic` und
+`yiic.bat`. Das sind *lokale* Versionen des `yiic`-Befehls, speziell für
+diese Webanwendung.
-Eigene Kommandos kann man in `protected/commands` ablegen. Ruft man dann
-`yiic` auf, werden die eigenen Kommandos zusätzlich zu den Standardbefehlen
-angezeigt. Man kann auch spezielle Kommandos für `yiic shell` erstellen.
-Die Kommandklasse muss dazu ins Verzeichnis `protected/commands/shell` gelegt werden.
+In `protected/commands` kann man eigene Befehle ablegen. Ruft man dann
+`yiic` auf, werden diese Befehle zusätzlich zu den Standardbefehlen
+angezeigt. Man kann auch spezielle Befehle für die `yiic shell` erstellen,
+indem man die Befehlsklasse im Verzeichnis `protected/commands/shell` ablegt.
-Seit Version 1.1.1 kann man auch globale Kommandos erstellen, die dann von
+Seit Version 1.1.1 ermöglicht Yii auch globale Befehle, die von
allen Yii-Anwendungen auf einem Server verwendet werden können. Dazu muss die
-Umgebungsvariable `YII_CONSOLE_COMMANDS` definiert werden, die auf ein
-existierendes Verzeichnis zeigt. Sämtliche Kommandos in diesem Verzeichnis
+Umgebungsvariable `YII_CONSOLE_COMMANDS` auf ein existierendes Verzeichnis
+mit Befehlsklassen verweisen. Alle Befehle in diesem Verzeichnis
stehen dann bei jedem Aufruf von `yiic` zur Verfügung.
-<div class="revision">$Id: topics.console.txt 1870 2010-03-09 22:23:19Z qiang.xue $</div>
+<div class="revision">$Id: topics.console.txt 2580 2010-10-28 18:08:46Z qiang.xue $</div>
View
5 docs/guide/de/topics.i18n.txt
@@ -163,7 +163,8 @@ ausgehen, dass Sie die vorgegebene [CPhpMessageSource] zur Speicherung der
können Sie den `yiic`-Befehl zum Verwalten der Übersetzungen verwenden. Mit
dem `message`-Kommando können Sie die zu übersetzenden Meldungen aus
ausgewählten Quelldateien extrahieren und bei Bedarf mit bereits vorhandenen
-Übersetzungen zusammenführen.
+Übersetzungen zusammenführen. Für weitere Details zur Verwendung des
+`message`-Komandes führen Sie bitte `yiic help message` aus.
Seit Version 1.0.10 können Textmeldungen einer Erweiterung (z.B. einem Widget
oder einem Modul) gesondert behandelt werden, sofern
@@ -304,4 +305,4 @@ Ziel-Locale vorgegebene Währungsmuster verwendet.
formatiert die gegebene Zahl, indem sie das in der Ziel-Locale vorgegebene
Prozentsatz-Muster verwendet.
-<div class="revision">$Id: topics.i18n.txt 2068 2010-04-22 16:42:16Z alexander.makarow $</div>
+<div class="revision">$Id: topics.i18n.txt 2522 2010-09-30 21:13:25Z alexander.makarow $</div>
View
4 docs/guide/de/topics.performance.txt
@@ -80,7 +80,7 @@ auf Serverebene einsetzen, um die Performance einer Applikation weiter
zu erhöhen. Tatsächlich fällt das beschriebene Cachen mit
[APC](/doc/guide/topics.performance#enabling-apc-extension) in diese
Kategorie. Es gibt auch andere Servertechniken, wie den [Zend
-Optimizer](http://Zend.com/ZendOptimizer),
+Optimizer](http://www.zend.com/en/products/guard/zend-optimizer)
[eAccelerator](http://eaccelerator.net/) oder
[Squid](http://www.squid-cache.org/), um nur einige zu nennen.
@@ -194,4 +194,4 @@ einzubinden.
</head>
~~~
-<div class="revision">$Id: topics.performance.txt 1622 2009-12-26 20:56:05Z qiang.xue $</div>
+<div class="revision">$Id: topics.performance.txt 2343 2010-08-26 21:10:08Z alexander.makarow $</div>
View
2 docs/guide/de/topics.security.txt
@@ -142,4 +142,4 @@ Yii::app()->request->cookies[$name]=$cookie;
~~~
-<div class="revision">$Id: topics.security.txt 1458 2009-10-16 15:03:59Z qiang.xue $</div>
+<div class="revision">$Id: topics.security.txt 2535 2010-10-11 08:28:08Z mdomba $</div>
View
38 docs/guide/de/topics.theming.txt
@@ -13,21 +13,30 @@ befinden sich unterhalb von `WebVerzeichnis/themes`. Es kann jeweils immer nur e
aktiv sein.
> Tip|Tipp: Das Standardverzeichnis für Themes kann auch an einem anderen Ort
-als `WebVerzeichnis/themes` liegen. Konfigurieren Sie dazu einfach die beiden
+als `WebVerzeichnis/themes` liegen. Dazu konfiguriert man einfach die beiden
Eigenschaften [basePath|CThemeManager::basePath] (Basispfad) und
[baseUrl|CThemeManager::baseUrl] (Basis-URL) der
[themeManager|CWebApplication::themeManager]-Anwendungskomponente.
-Um ein Theme anzuwenden, setzen Sie die Eigenschaft [theme|CWebApplication::theme]
+
+Verwenden von Themes
+--------------------
+
+Um ein Theme anzuwenden, setzt man die Eigenschaft [theme|CWebApplication::theme]
der Webanwendung auf den Namen des gewünschten Themes. Dies kann
entweder in der
[Anwendungskonfiguration](/doc/guide/basics.application#application-configuration)
oder während der Laufzeit in einer Controller-Action geschehen.
> Note|Hinweis: Beim Namen eines Themes spielt die Groß-/Kleinschreibung eine
-> Rolle. Wenn Sie versuchen, ein Theme anzuwenden, das es gar nicht gibt,
+> Rolle. Wenn man ein Theme konfiguriert, das es gar nicht gibt,
> liefert `Yii::app()->theme` den Wert `null` zurück.
+
+
+Erstellen eines Themes
+----------------------
+
Die Inhalte eines Themeverzeichnisses sollten genau wie im
[Anwendungsverzeichnis](/doc/guide/basics.application#application-base-directory)
abgelegt werden. Alle View-Dateien müssen sich zum Beispiel in `views`,
@@ -117,6 +126,27 @@ wird das Theme `basic` verwendet. Das bedeutet, dass das Layout in
verwendet wird. Falls Yii dort keine Viewdatei findet, verwendet es die
Datei in `protected/views`.
+
+Themes für Widgets
+------------------
+
+Ab Version 1.1.5 können Themes auch für Widget-Views verwendet werden. Rendert
+man einen Widgetview mit [CWidget::render()], sucht Yii auch im
+Themeverzeichnis nach einer entsprechenden Datei.
+
+Möchte man den View `xyz` eines Widgets `Foo` in ein Theme einbeziehen, so
+legt man zunächst einen Ordner `Foo` (dem Namen des Widgets) im aktiven
+Themeverzeichnis an. Falls die Widgetklasse Namespaces (seit PHP 5.3.0)
+verwendet, wie z.B. `\app\widgets\Foo`, sollte dieser Ordner `app_widgets_Foo`
+heißen. Man ersetzt in diesem Fall also die Namespace-Separatoren mit einem
+Unterstrich.
+
+Jetzt legt man die Viewdatei `xyz.php` in diesem Verzeichnis ab. Falls das
+aktuelle Theme `basic`ist, sollte man also nun eine Datei
+`themes/basic/views/Foo/xyz.php` haben, die dann vom Widget
+verwendet wird, um den ursprünglichen View zu ersetzen.
+
+
Widgets global anpassen
-----------------------
@@ -309,4 +339,4 @@ Unterschiede sind:
- Eine Skin kann mit einem Theme versehen werden
- Skins beeinflußen die Leistung mehr, als Widgets global anzupassen
-<div class="revision">$Id: topics.theming.txt 2172 2010-06-07 19:56:01Z qiang.xue $</div>
+<div class="revision">$Id: topics.theming.txt 2619 2010-11-04 15:30:43Z qiang.xue $</div>
View
98 docs/guide/id/basics.application.txt
@@ -2,26 +2,26 @@ Aplikasi
========
Aplikasi menggambarkan konteks dijalankannya pemrosesan sebuah permintaan. Tugas
-utamanya adalah memecahkan permintaan pengguna dan meneruskannya ke pengontrol
-terkait guna pemrosesan selanjutnya. Ia juga bertindak sebagai tempat pusat
-untuk memelihara konfigurasi tingkat-aplikasi. Oleh karena itu, aplikasi juga
-disebut `pengontrol-depan`.
+utamanya adalah menangani permintaan pengguna dan meneruskannya ke kontroler(controller)
+guna pemrosesan selanjutnya. Aplikasi juga bertindak sebagai tempat pusat
+untuk menyimpan konfigurasi tingkat-aplikasi. Oleh karena itu, aplikasi juga
+disebut `kontroler-depan(front controller)`.
-Aplikasi dibuat sebagai kerangka tunggal oleh [naskah entri](/doc/guide/basics.entry).
-Kerangka aplikasi dapat diakses di mana saja melalui [Yii::app()|YiiBase::app].
+Aplikasi dibuat sebagai singleton(tunggal) oleh [skrip entri](/doc/guide/basics.entry).
+Singleton aplikasi dapat diakses di mana saja melalui [Yii::app()|YiiBase::app].
Konfigurasi Aplikasi
--------------------
-Standarnya, aplikasi adalah turunan dari [CWebApplication]. Untuk
-mengkustomisasinya, kami sediakan file konfigurasi (atau array) guna mengawali nilai
-propertinya saat turunan aplikasi dibuat. Alternatif cara mengkustomisasi aplikasi
-adalah dengan memperluas [CWebApplication].
+Secara default, aplikasi adalah instance dari [CWebApplication]. Untuk
+mengkustomisasinya, kita pada umumnya menyediakan file konfigurasi (atau array) untuk inisialisasi nilai
+propertinya saat instance aplikasi dibuat. Cara alternatif mengkustomisasi aplikasi
+adalah dengan menurunkan [CWebApplication].
-Konfigurasi adalah array pasangan kunci-nilai. Setiap kunci mewakili nama
-properti turunan aplikasi, dan setiap nilai adalah nilai awal dari properti
-tersebut. Sebagai contoh, koonfigurasi berikut
+Konfigurasi adalah array pasangan kunci-nilai(key-value). Setiap kunci mewakili nama
+properti instance aplikasi, dan setiap nilai adalah nilai awal dari properti
+tersebut. Sebagai contoh, konfigurasi berikut
mengkonfigurasi aplikasi [name|CApplication::name] dan properti
[defaultController|CWebApplication::defaultController]
aplikasi.
@@ -34,8 +34,8 @@ array(
)
~~~
-Biasanya kami menyimpan konfigurasi dalam naskah PHP terpisah (misal
-`protected/config/main.php`). Di dalam naskah, kami mengembalikan
+Biasanya kita menyimpan konfigurasi dalam skrip PHP terpisah (misal
+`protected/config/main.php`). Di dalam skrip, kita mengembalikan
array konfigurasi sebagai berikut,
~~~
@@ -43,18 +43,18 @@ array konfigurasi sebagai berikut,
return array(...);
~~~
-Untuk menerapkan konfigurasi, kami mengoper nama file konfigurasi sebagai
-parameter bagi pembentuk aplikasi, atau ke [Yii::createWebApplication()]
-seperti yang berikut, yang biasanya dikerjakan dalam [naskah entri](/doc/guide/basics.entry):
+Untuk menerapkan konfigurasi, kita mengirim nama file konfigurasi sebagai
+sebuah parameter bagi constructor aplikasi, atau ke [Yii::createWebApplication()]
+, yang biasanya dikerjakan dalam [skrip entri](/doc/guide/basics.entry), seperti berikut:
~~~
[php]
$app=Yii::createWebApplication($configFile);
~~~
-> Tip: Jika konfigurasi aplikasi sangat kompleks, kami dapat memisahannya
+> Tip: Jika konfigurasi aplikasi sangat kompleks, kita dapat memisahkannya
ke dalam beberapa file, masing-masing mengembalikan bagian array konfigurasi.
-Selanjutnya, dalam file konfigurasi utama, kami memanggil PHP `include()` guna
+Selanjutnya, dalam file konfigurasi utama, kita memanggil PHP `include()` guna
menyertakan file konfigurasi lainnya dan menggabungkannya ke dalam array
konfigurasi yang lengkap.
@@ -63,14 +63,14 @@ Direktori Basis Aplikasi
-----------------------
Direktori basis aplikasi merujuk ke direktori root yang berisi semua
-data dan naskah PHP sensitif-keamanan. Standarnya, ia berupa subdirektori
-bernama `protected` yang ditempatkan di bawah direktori yang berisi naskah
-entri. Ia dapat dikustomisasi melalui setelan properti
+data dan skrip PHP yang sensitif. Secara default, direktori ini adalah subdirektori
+bernama `protected` yang ditempatkan di bawah direktori yang berisi skrip
+entri. Direktori ini dapat dikustomisasi melalui konfigurasi properti
[basePath|CWebApplication::basePath] dalam [konfigurasi aplikasi](#application-configuration).
-Isi di dalam direktori basis aplikasi harus dilindungi dari akses oleh
+Isi di dalam direktori basis aplikasi harus terlindung dari akses oleh
para pengguna Web. Dengan [Apache HTTP
-server](http://httpd.apache.org/), ini bisa dilakukan secara mudah dengan
+server](http://httpd.apache.org/), hal ini bisa dilakukan secara mudah dengan
menempatkan file `.htaccess` di bawah direktori basis. Adapun isi file `.htaccess`
adalah sebagai berikut,
@@ -84,14 +84,14 @@ Komponen Aplikasi
Fungsionalitas aplikasi dapat dikustomisasi secara mudah dan diperkaya dengan
arsitektur komponennya yang fleksibel. Aplikasi mengatur satu set komponen
aplikasi, masing-masing mengimplementasi fitur tertentu.
-Sebagai contoh, aplikasi memecahkan permintaan pengguna dengan bantuan komponen [CUrlManager]
+Sebagai contoh, aplikasi menangani permintaan pengguna dengan bantuan komponen [CUrlManager]
dan [CHttpRequest].
Dengan mengkonfigurasi properti [komponen|CApplication::components] aplikasi,
-kita bisa mengkustomisasi kelasi dan nilai properti setiap komponen
+kita bisa mengkustomisasi kelas dan nilai properti setiap komponen
aplikasi yang dipakai dalam sebuah aplikasi. Sebagai contoh, kita dapat
-mengkonfigurasi komponen [CMemCache] agar ia bisa menggunakan multipel server memcache
-untuk caching,
+mengkonfigurasi komponen [CMemCache] agar bisa menggunakan beberapa server memcache
+untuk penembolokan(caching),
~~~
[php]
@@ -114,17 +114,17 @@ Dalam contoh di atas, kita menambahkan elemen `cache` pada array `components`. E
`cache` menyatakan bahwa kelas komponennya adalah
`CMemCache` dan properti `servers` juga harus diinisialisasi.
-Untuk mengakses komponen aplikasi, gunakan `Yii::app()->ComponentID`, di mana
+Untuk mengakses komponen aplikasi, gunakan `Yii::app()->ComponentID`, dengan
`ComponentID` merujuk pada ID komponen (contoh `Yii::app()->cache`).
-Komponen aplikasi dapat dimatikan dengan menyetel `enabled` menjadi false
-dalam konfigurasinya. Null dikembalikan saat kita mengakses komponen yang dimatikan.
+Komponen aplikasi dapat dinonaktifkan dengan menyetel `enabled` menjadi false
+dalam konfigurasinya. Null dikembalikan saat kita mengakses komponen yang telah dinonaktifkan.
-> Tip: Secara standar, komponen aplikasi dibuat bila diperlukan. Ini berarti
+> Tip: Secara default, komponen aplikasi dibuat bila diperlukan. Ini berarti
komponen aplikasi mungkin tidak dibuat sama sekali jika tidak diakses
-saat pengguna meminta. Hasilnya, performansi keseluruhan mungkin tidak menurun
-walaupun aplikasi dikonfigurasi dengan banyak komponen. Beberapa komponen
-aplikasi (contoh [CLogRouter]) mungkin perlu dibuat tidak peduli apakah ia
+saat pengguna melakukan request. Hasilnya, performa aplikasi keseluruhan tidak akan menurun
+walaupun dikonfigurasi dengan banyak komponen. Beberapa komponen
+aplikasi (contoh [CLogRouter]) mungkin perlu dibuat tidak peduli apakah
diakses atau tidak. Untuk melakukannya, daftarkan ID masing-masing dalam properti [preload|CApplication::preload]
aplikasi.
@@ -133,26 +133,26 @@ Komponen Aplikasi Inti
Yii sudah mendefinisikan satu set komponen aplikasi inti guna menyediakan fitur
yang umum dalam aplikasi Web. Sebagai contoh, komponen
-[request|CWebApplication::request] dipakai untuk memecahkan permintaan pengguna
+[request|CWebApplication::request] dipakai untuk menangani permintaan pengguna
dan menyediakan informasi seperti URL, cookies. Dengan mengkonfigurasi properti
-komponen inti ini, kita dapat mengubah perilaku standar Yii dalam hampir segala
+komponen inti ini, kita dapat mengubah perilaku standar Yii dalam hampir di segala
aspek.
Di bawah ini kami mendata komponen inti yang dideklarasikan oleh
[CWebApplication].
- [assetManager|CWebApplication::assetManager]: [CAssetManager] -
-mengatur penerbitan file asset privat.
+mengatur publikasi file asset privat.
- [authManager|CWebApplication::authManager]: [CAuthManager] - mengatur role-based access control (RBAC).
- [cache|CApplication::cache]: [CCache] - menyediakan fungsionalitas
-caching data. Catatan, Anda harus menetapkan kelas sebenarnya (misal
+penembolokan(caching) data. Catatan, Anda harus menetapkan kelas sebenarnya (misal
[CMemCache], [CDbCache]). Jika tidak, null akan dikembalikan saat Anda
mengakses komponen ini.
- [clientScript|CWebApplication::clientScript]: [CClientScript] -
-mengatur naskah klien (javascript dan CSS).
+mengatur skrip klien (javascript dan CSS).
- [coreMessages|CApplication::coreMessages]: [CPhpMessageSource] -
menyediakan terjemahan pesan inti yang dipakai oleh Yii framework.
@@ -172,13 +172,13 @@ terjemahan pesan yang dipakai oleh aplikasi Yii.
informasi terkait dengan permintaan penggguna.
- [securityManager|CApplication::securityManager]: [CSecurityManager] -
-menyediakan layanan terkait-keamanan, seperti hashing, enkripsi.
+menyediakan layanan terkait keamanan, seperti hashing, enkripsi.
- [session|CWebApplication::session]: [CHttpSession] - menyediakan
-fungsionalitas terkait-sesi.
+fungsionalitas terkait sesi.
- [statePersister|CApplication::statePersister]: [CStatePersister] -
-menyediakan metode persisten kondisi global.
+menyediakan metode persisten kondisi global(global state persistence).
- [urlManager|CWebApplication::urlManager]: [CUrlManager] - menyediakan
fungsionalitas penguraian dan pembuatan URL.
@@ -204,16 +204,16 @@ sebagai berikut:
3. Mengambil konfigurasi aplikasi;
4. Menginisialisasi aplikasi dengan [CApplication::init()]
- - Mengambil komponen statis aplikasi;
+ - Registrasi behavior aplikasi
- Mengambil komponen aplikasi statis;
5. Menghidupkan event [onBeginRequest|CApplication::onBeginRequest];
6. Mengolah permintaan pengguna:
- - Memecah permintaan pengguna;
- - Membuat pengontrol;
- - Menjalankan pengontrol;
+ - Menangani permintaan pengguna;
+ - Membuat kontroler;
+ - Menjalankan kontroler;
7. Menghidupkan event [onEndRequest|CApplication::onEndRequest];
-<div class="revision">$Id: basics.application.txt 846 2009-03-17 17:35:33Z qiang.xue $</div>
+<div class="revision">$Id: basics.application.txt 2488 2010-09-20 11:38:02Z mdomba $</div>
View
102 docs/guide/id/basics.component.txt
@@ -1,16 +1,16 @@
Komponen
========
-Aplikasi Yii dibangun setelah komponen berupa obyek ditulis menjadi
-spesifikasi. Sebuah komponen adalah turunan dari
-[CComponent] atau kelas sebelumnya. Pemakaian komponen meliputi
+Aplikasi Yii dibangun dari komponen-komponen yang berupa objek yang ditulis ke sebuah
+spesifikasi. Sebuah komponen adalah isntance dari
+[CComponent] atau kelas induknya. Pemakaian komponen meliputi
pengaksesan propertinya dan memunculkan/menangani event-nya. Kelas basis
[CComponent] menetapkan bagaimana untuk mendefinisikan properti dan event.
Properti Komponen
-----------------
-Properti komponen seperti variabel anggota public sebuah obyek. Kita dapat
+Properti komponen seperti variabel anggota public sebuah objek. Kita dapat
membaca nilainya atau menempatkan sebuah nilai ke dalamnya. Sebagai contoh,
~~~
@@ -19,7 +19,7 @@ $width=$component->textWidth; // ambil properti textWidth
$component->enableCaching=true; // setel properti enableCaching
~~~
-Untuk mendefinisikan properti komponen, kita cuku mendeklarasian variabel
+Untuk mendefinisikan properti komponen, kita cukup mendeklarasikan variabel
anggota public dalam kelas komponen. Cara yang lebih fleksibel adalah dengan
mendefinisikan metode getter (pengambil) dan setter (penyetel) seperti berikut:
@@ -36,31 +36,31 @@ public function setTextWidth($value)
}
~~~
-Kode di atas mendefinisikan properti yang bisa ditulis dengan nama `textWidth` (nama
-sensitif jenis huruf). Ketika membaca properti, `getTextWidth()` dipanggil
-dan nilai yang dihasilkannya menjadi nilai properti; Hal yang mirip, saat menulis
-properti, `setTextWidth()` dipanggil. Jika metode penyetel tidak didefinisikan,
-properti akan menjadi hanya-baca dan menulisinya akan memunculkan sebuah
+Kode di atas mendefinisikan properti yang bisa ditulis bernama `textWidth` (nama
+bersifat case-sensitive). Ketika membaca properti, `getTextWidth()` dipanggil
+dan nilai yang dihasilkannya menjadi nilai properti; Demikian juga pada saat menulis
+properti, `setTextWidth()` yang dipanggil. Jika metode penyetel tidak didefinisikan,
+properti akan menjadi hanya-baca(read-only) dan menulisinya akan memunculkan sebuah
eksepsi. Menggunakan metode pengambil dan penyetel untuk mendefinisikan sebuah
-properti memiliki keuntungan bahwa logika tambahan (seperti melakukan validasi, memunculkan event)
+properti memiliki manfaat bahwa logika tambahan (seperti melakukan validasi, memunculkan event)
dapat dijalankan saat membaca dan menulis properti.
->Note|Catatan: Ada perbedaan menyolok antara properti yang didefinisikan via metode
+>Note|Catatan: Ada sedikit perbedaan antara properti yang didefinisikan via metode
pengambil/penyetel dan variabel anggota kelas. Nama pengambil/penyetel
-tidak sensitif jenis huruf sementara variabel anggota kelas sensitif jenis huruf.
+tidak bersifat case-sensitive sementara variabel anggota kelas bersifat case-sensitive..
Event Komponen
--------------
Event komponen adalah properti khusus yang mengambil metode (disebut `pengendali event`)
-sebagai nilainya. Melampirkan (menempatkan) metode ke sebuah event akan
+sebagai nilainya. Melampirkan (menempatkan) sebuah metode ke sebuah event akan
menyebabkan metode dipanggil secara otomatis di tempat di mana event
dimunculkan. Oleh karena itu, perilaku komponen bisa diubah dengan cara yang
-tidak bisa dilihat selama pengembangan komponen.
+tidak terduga selama tahap pengembangan komponen.
Event komponen didefinisikan dengan mendefinisikan sebuah metode yang namanya dimulai
dengan `on`. Seperti nama properti yang didefinisikan via metode pengambil/penyetel, nama event tidak
-sensitif jenis huruf. Kode berikut mendefinisikan sebuah event `onClicked`:
+case-sensitive. Kode berikut mendefinisikan sebuah event `onClicked`:
~~~
[php]
@@ -70,7 +70,7 @@ public function onClicked($event)
}
~~~
-di mana `$event` adalah turunan [CEvent] atau anak kelasnya yang menyediakan
+di mana `$event` adalah instance dari [CEvent] atau anak kelasnya yang menyediakan
parameter event.
Kita dapat melampirkan sebuah metode ke event ini seperti berikut:
@@ -80,11 +80,11 @@ Kita dapat melampirkan sebuah metode ke event ini seperti berikut:
$component->onClicked=$callback;
~~~
-di mana `$callback` merujuk ke PHP callback yang benar. Ia bisa berupa fungsi
-global atau metode kelas. Jika metode kelas, callback harus dibentuk sebagai
+dengan `$callback` merujuk ke PHP callback yang benar. `$callback` bisa berupa fungsi
+global atau metode kelas. Jika berupa metode kelas, callback harus dibentuk sebagai
array: `array($object,'methodName')`.
-Tanda tangan pengenali event harus seperti berikut:
+Tanda pengenal event harus seperti berikut:
~~~
[php]
@@ -94,37 +94,46 @@ function methodName($event)
}
~~~
-di mana `$event` merupakan parameter yang menjelaskan event (ia berasal dari
-panggilan `raiseEvent()`). Parameter `$event` adalah turunan dari [CEvent] atau
-kelas sebelumnya. Pada kondisi minimum, ia berisi informasi mengenai siapa
+dengan `$event` merupakan parameter yang menjelaskan event (berasal dari
+panggilan `raiseEvent()`). Parameter `$event` adalah instance dari [CEvent] atau
+kelas induk. Pada kondisi minimum, parameter ini berisi informasi mengenai siapa
yang memunculkan event.
-Jika kita memanggil `onClicked()` sekarang, event `onClicked` akan dimunculkan (di dalam
+Mulai dari versi 1.0.10, sebuah handler event dapat berupa fungsi tidak bernama yang
+didukung PHP 5.3 ke atas. Misalnya,
+~~~
+[php]
+$component->onClicked=function($event) {
+ ......
+}
+~~~
+
+Jika kita memanggil `onClicked()` sekarang, event `onClicked` akan dijalankan (di dalam
`onClicked()`), dan pengendali event terlampir akan dipanggil secara
otomatis.
-Sebuah event dapat dilampirkan ke multipel pengendali. Saat event dimunculkan,
-pengendali akan dipanggil dengan urutan di mana ia dilampirkan ke event.
+Sebuah event dapat dilampirkan ke beberapa pengendali. Saat event dijalankan,
+pengendali akan dipanggil dengan urutan yang dilampirkan ke event.
Jika sebuah pengendali memutuskan untuk menghindari pemanggilan pengendali berikutnya,
bisa dilakukan dengan menyetel [$event->handled|CEvent::handled] menjadi true.
-Perilaku Komponen
+Behavior Komponen
-----------------
-Mulai dari versi 1.0.2, sebuah komponen sudah ditambahkan guna mendukung [mixin](http://en.wikipedia.org/wiki/Mixin)
-dan dapat dilampirkan dengan satu atau beberapa perilaku. Sebuah *perilaku* adalah obyek
+Mulai dari versi 1.0.2, komponen sudah ditambahkan dukungan terhadap [mixin](http://en.wikipedia.org/wiki/Mixin)
+dan dapat dilampirkan dengan satu atau beberapa behavior. Sebuah *behavior(perilaku)* adalah objek
yang metodenya bisa 'inherited' (diturunkan) dengan komponen lampirannya dalam arti pengumpulan
-fungsionalitas daripada spesialisasi (misal, penurunan kelas normal).
-Komponen dapat dilampirkan ke beberapa perilaku dan selanjutnya melakukan 'multipel penurunan'.
+fungsionalitas alih-alih spesialisasi (misal, penurunan kelas normal).
+Komponen dapat dilampirkan ke beberapa behavior dan selanjutnya melakukan 'multi penurunan(multiple inheritance)'.
-Kelas perilaku harus mengimplementasikan antar muka [IBehavior]. Umumnya perilaku dapat
-diperluas dari kelas basis [CBehavior]. Jika perilaku perlu dilampirkan ke sebuah
-[model](/doc/guide/basics.model), ia juga bisa