[DOCUMENTATION] Russian:

- Sync with r20763

git-svn-id: http://framework.zend.com/svn/framework/standard/trunk@23630 44c647ce-9c0f-0410-b52a-842ac1e357ba

documentation/manual/ru/module_specs/Zend_Acl.xml

@@ -1,4 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
+<!-- EN-Revision: 20763 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.acl.introduction">
     <title>Введение</title>
@@ -6,50 +7,55 @@
     <para>
         <classname>Zend_Acl</classname> предоставляет легковесную и гибкую реализацию списка прав
         доступа (<acronym>ACL</acronym>) и управления привилегиями. Приложение может использовать
-        такие списки для контроля доступа одних объектов к другим - защищенным.
+        <acronym>ACL</acronym> для контроля доступа одних объектов к другим - защищенным.
     </para>
 
     <para>
-        В рамках данной документации,
-        <itemizedlist>
-            <listitem>
-                <para>
-                    <emphasis>Ресурс</emphasis> - объект, доступ к
-                    которому контролируется.
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    <emphasis>Роль</emphasis> - объект, который
-                    может запрашивать доступ к ресурсу.
-                </para>
-            </listitem>
-        </itemizedlist>
-
-        Говоря проще, <emphasis>роли запрашивают доступ к
-        ресурсам</emphasis>.
+        В рамках данной документации:
+    </para>
+
+    <itemizedlist>
+        <listitem>
+            <para>
+                <emphasis>Ресурс</emphasis> - объект, доступ к
+                которому контролируется.
+            </para>
+        </listitem>
+
+        <listitem>
+            <para>
+                <emphasis>Роль</emphasis> - объект, который
+                может запрашивать доступ к ресурсу.
+            </para>
+        </listitem>
+    </itemizedlist>
+
+    <para>
+        Говоря проще, <emphasis>роли запрашивают доступ к ресурсам</emphasis>.
         Например, если парковщик запрашивает доступ к автомобилю, то
         парковщик - это роль, а автомобиль - ресурс, поскольку доступ к
         автомобилю не может предоставляться всем без исключения.
     </para>
 
     <para>
-        Благодаря спецификации и использованию списка прав доступа (ACL)
+        Благодаря спецификации и использованию списка прав доступа (<acronym>ACL</acronym>)
         приложение может контролировать предоставление ролям доступа к ресурсам.
     </para>
 
     <sect2 id="zend.acl.introduction.resources">
         <title>Ресурсы</title>
         <para>
-            Создать ресурс в <classname>Zend_Acl</classname> очень просто. <classname>Zend_Acl</classname> предоставляет
+            Создать ресурс в <classname>Zend_Acl</classname> очень просто.
+            <classname>Zend_Acl</classname> предоставляет
             интерфейс ресурса <classname>Zend_Acl_Resource_Interface</classname> для
             облегчения процесса создания ресурса. Этот интерфейс содержит только
-            один метод, <code>getResourceId()</code>. Классу достаточно
-            реализовывать этот интерфейс для того, чтобы <classname>Zend_Acl</classname> рассматривал
-            объект этого класса как ресурс. Кроме того, <classname>Zend_Acl</classname>
-            предоставляет <code>Zend_Acl_Resource</code> в качестве базового
+            один метод, <methodname>getResourceId()</methodname>. Классу достаточно
+            реализовывать этот интерфейс для того, чтобы <classname>Zend_Acl</classname>
+            рассматривал объект этого класса как ресурс. Кроме того, <classname>Zend_Acl</classname>
+            предоставляет <classname>Zend_Acl_Resource</classname> в качестве базового
             класса, который разработчики могут расширять по желанию.
         </para>
+
         <para>
             <classname>Zend_Acl</classname> предоставляет древовидную структуру, в которую могут
             добавляться различные ресурсы. В этой структуре они могут быть
@@ -61,12 +67,13 @@
             правило должно действовать в каждом здании города, то проще
             прикрепить его к городу, чем крепить к каждому зданию в городе.
             Однако, для некоторых зданий могут потребоваться исключения из этого
-            правила, в <classname>Zend_Acl</classname> это достигается путем закрепления исключений за
-            каждым зданием, требующим исключений из правила.
+            правила, в <classname>Zend_Acl</classname> это достигается путем закрепления исключений
+            за каждым зданием, требующим исключений из правила.
             Ресурс может наследовать только от одного родительского ресурса,
             однако сам родительский ресурс может,
             в свою очередь, наследовать от другого родительского ресурса и т.д.
         </para>
+
         <para>
             <classname>Zend_Acl</classname> также поддерживает права доступа к ресурсам (например,
             "создание", "чтение", "обновление", "удаление"),
@@ -81,10 +88,12 @@
             Как и в случае с ресурсами, создавать роль тоже очень просто.
             Все роли должны реализовывать интерфейс
             <classname>Zend_Acl_Role_Interface</classname>. Этот интерфейс содержит
-            единственный метод <code>getRoleId()</code>. Кроме того, <classname>Zend_Acl</classname>
+            единственный метод <methodname>getRoleId()</methodname>. Кроме того,
+            <classname>Zend_Acl</classname>
             предоставляет <classname>Zend_Acl_Role</classname> в качестве базового класса,
             который разработчики могут расширять по желанию.
         </para>
+
         <para>
             В <classname>Zend_Acl</classname> роль может наследовать от одной или от нескольких
             ролей. Это реализовано для поддержки
@@ -96,27 +105,29 @@
             обоих ролей. Нет необходимости привязывать правила непосредственно
             к "Салли".
         </para>
+
         <para>
             Хотя множественное наследование ролей - очень полезная возможность,
             она также усложняет разработку. Следующий пример демонстрирует
             неопределенное условие и показывает, как <classname>Zend_Acl</classname> решает эту
             проблему.
         </para>
+
         <example id="zend.acl.introduction.roles.example.multiple_inheritance">
             <title>Множественное наследование ролей</title>
             <para>
                 Следующий код определяет три базовые роли:
-                "<code>guest</code>", "<code>member</code>" и
-                "<code>admin</code>", от которых будут наследовать другие роли.
-                Далее создается "<code>someUser</code>", он наследует от этих
+                "guest", "member" и
+                "admin", от которых будут наследовать другие роли.
+                Далее создается "someUser", он наследует от этих
                 только что созданных трех ролей. Порядок, в котором эти роли
                 появляются в массиве <varname>$parents</varname>,
                 важен. При необходимости <classname>Zend_Acl</classname> ищет правила доступа не
                 только для запрашиваемых ролей (в нашем случае,
-                "<code>someUser</code>"), но и для ролей, от которых
+                "someUser"), но и для ролей, от которых
                 запрашиваемая роль унаследована
-                (в нашем примере, "<code>guest</code>", "<code>member</code>" и
-                "<code>admin</code>"):
+                (в нашем примере, "guest", "member" и
+                "admin"):
             </para>
             <programlisting language="php"><![CDATA[
 $acl = new Zend_Acl();
@@ -137,31 +148,31 @@ echo $acl->isAllowed('someUser', 'someResource') ? 'разрешен' : 'зап
 ]]></programlisting>
             <para>
                 Поскольку нет правил, определенных специально для роли
-                "<code>someUser</code>" и ресурса
-                "<code>someResource</code>", то <classname>Zend_Acl</classname> должен производить
+                "someUser" и ресурса
+                "someResource", то <classname>Zend_Acl</classname> должен производить
                 поиск правил, которые могут быть определены для ролей,
-                от которых "<code>someUser</code>" наследуется. Сперва
-                проверяется роль "<code>admin</code>", и обнаруживается, что
+                от которых "someUser" наследуется. Сперва
+                проверяется роль "admin", и обнаруживается, что
                 для нее не определены правила доступа. Затем проверяется роль
-                "<code>member</code>", и <classname>Zend_Acl</classname> обнаруживает, что есть правило
-                разрешающее доступ для "<code>member</code>" к
-                "<code>someResource</code>".
+                "member", и <classname>Zend_Acl</classname> обнаруживает, что есть правило
+                разрешающее доступ для "member" к
+                "someResource".
             </para>
             <para>
                 Если бы <classname>Zend_Acl</classname> продолжил поиск правил, определенных для
                 родительских ролей, то обнаружил бы, что для
-                "<code>guest</code>" запрещен доступ к
-                "<code>someResource</code>". Это пример показывает противоречие,
-                так как теперь для "<code>someUser</code>" доступ к
-                "<code>someResource</code>" разрешен и запрещен одновременно.
+                "guest" запрещен доступ к
+                "someResource". Это пример показывает противоречие,
+                так как теперь для "someUser" доступ к
+                "someResource" разрешен и запрещен одновременно.
                 Конфликт произошел по причине наследования от нескольких ролей.
             </para>
             <para>
-                <classname>Zend_Acl</classname> решает эту неоднозначность, завершая запрос, как только
-                находит первое правило, которое может быть применено к запросу.
-                В этом случае, если роль "<code>member</code>"
-                проверяется раньше, чем роль "<code>guest</code>", то
-                данный пример выведет "<code>разрешен</code>".
+                <classname>Zend_Acl</classname> решает эту неоднозначность, завершая запрос, как
+                только находит первое правило, которое может быть применено к запросу.
+                В этом случае, если роль "member"
+                проверяется раньше, чем роль "guest", то
+                данный пример выведет "разрешен".
             </para>
         </example>
         <note>
@@ -180,10 +191,10 @@ echo $acl->isAllowed('someUser', 'someResource') ? 'разрешен' : 'зап
             Список контроля доступа (<acronym>ACL</acronym>) может представлять собой любое
             множество физических или виртуальных объектов. В целях
             демонстрации, мы создадим базовый
-            функционал <acronym>ACL</acronym> для системы управления содержимым (<acronym>CMS</acronym>),
-            который будет поддерживать нескольких уровней групп к множеству
-            областей. Чтобы создать новый объект <acronym>ACL</acronym>, производим инстанцирование
-            без параметров:
+            функционал <acronym>ACL</acronym> для системы управления содержимым
+            (<acronym>CMS</acronym>), который будет поддерживать нескольких уровней групп к
+            множеству областей. Чтобы создать новый объект <acronym>ACL</acronym>, производим
+            инстанцирование <acronym>ACL</acronym> без параметров:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -193,8 +204,8 @@ $acl = new Zend_Acl();
         <note>
             <para>
                 До тех пор, пока разработчик не определит какое-либо правило,
-                разрешающее доступ, <classname>Zend_Acl</classname> отказывает всем ролям в доступе ко
-                всем привилегиям на все ресурсы.
+                разрешающее доступ, <classname>Zend_Acl</classname> отказывает всем ролям в доступе
+                ко всем привилегиям на все ресурсы.
             </para>
         </note>
     </sect2>
@@ -231,22 +242,27 @@ $acl = new Zend_Acl();
                 <entry>Права, унаследованные от</entry>
               </row>
             </thead>
+
             <tbody>
               <row>
                 <entry>Гость (guest)</entry>
                 <entry>Просмотр (view)</entry>
                 <entry>Не определено</entry>
               </row>
+
               <row>
                 <entry>Сотрудник (staff)</entry>
-                <entry>Редактирование (edit), предложение на публикацию (submit), исправление (revise)</entry>
+                <entry>Редактирование (edit), предложение на публикацию (submit), исправление
+                (revise)</entry>
                 <entry>Гость</entry>
               </row>
+
               <row>
                 <entry>Редактор (editor)</entry>
                 <entry>Публикация (publish), архивирование (archive), удаление (delete)</entry>
                 <entry>Сотрудник</entry>
               </row>
+
               <row>
                 <entry>Администратор (administrator)</entry>
                 <entry>(Обладает всеми правами)</entry>
@@ -304,6 +320,13 @@ $acl->addRole(new Zend_Acl_Role('administrator'));
             ресурсы и роли наследуют правила, которые определены для их предков.
         </para>
 
+        <note>
+            <para>
+                В целом, <classname>Zend_Acl</classname> подчиняется правилу, только если более
+                точное правило не применимо.
+            </para>
+        </note>
+
         <para>
             В результате мы можем определить умеренно сложный набор правил
             минимальным кодом. Чтобы определить базовые права доступа, описанные
@@ -330,10 +353,12 @@ $acl->allow($roleGuest, null, 'view');
 $acl->allow('guest', null, 'view');
 //*/
 
-// Сотрудник наследует привилегии просмотра у Гостя, но также нуждается в дополнительных привилегиях
+// Сотрудник наследует привилегии просмотра у Гостя,
+// но также нуждается в дополнительных привилегиях
 $acl->allow('staff', null, array('edit', 'submit', 'revise'));
 
-// Редактор наследует привилегии просмотра, редактирования, отправки и исправлений у Посетителя
+// Редактор наследует привилегии просмотра, редактирования,
+// отправки и исправлений у Посетителя
 // но также нуждается в дополнительных привилегиях
 $acl->allow('editor', null, array('publish', 'archive', 'delete'));
 
@@ -342,7 +367,7 @@ $acl->allow('administrator');]]></programlisting>
 
         <para>
             Значение <constant>NULL</constant> в вызовах
-            <code>allow()</code> в этом примере используется для
+            <methodname>allow()</methodname> в этом примере используется для
             указания того, что правила, предоставляющие доступ,
             действительны для всех ресурсов.
         </para>
@@ -356,7 +381,7 @@ $acl->allow('administrator');]]></programlisting>
             Теперь у нас есть гибкий <acronym>ACL</acronym>, который может использоваться для
             определения того, достаточно ли прав имеет запрашивающий, чтобы
             производить действия в веб-приложении. Используя метод
-            <code>isAllowed()</code>, производить запросы довольно просто:
+            <methodname>isAllowed()</methodname>, производить запросы довольно просто:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -392,7 +417,6 @@ echo $acl->isAllowed('administrator', null, 'update') ?
      "разрешен" : "запрещен";
 // разрешен потому, что администратор обладает всеми привилегиями
 ]]></programlisting>
-
     </sect2>
 </sect1>
 <!--